Project for Success

Questioning the Role of Requirements Engineering in the Causes of Safety-Critical Software Failures by C. W. Johnson and C. M. Holloway questions the usual blame placed on inadequate requirements engineering for software project failures (safety-critical software). The paper is here.

The paper then presents the following list as root causes of the project failure identified incorrectly under inadequate requirements engineering.

1. lack of stakeholder involvement
2. incorrect environmental assumptions
3. communications failures within development teams
4. inadequate conflict management
5. lack of contextual detail

I find #4 interesting in particular. We suffered a bit from #4 in current project. The project required input from different departments (marketing, operation, client service and etc) which had different interests. It was a difficult process to draw a decision to everyone's satisfaction. The lesson was to work out conflict resolution process early among stakeholders.

It is a great checklist for early phase of a software project and a great starting point for discussion with project sponsors & project leaders.

See Alistair Cockburn's blog about the paper.

Belief

We do not believe in ourselves until someone reveals that deep inside us something is valuable, worth listening to, worthy of our trust, sacred to our touch.

Once we believe in ourselves, we can risk curiosity, wonder, spontaneous delight, or any experience that reveals the human spirit.

- E. E. Cummings

Chief Engineer

The top product development program at Toyota is the chief engineer (CE). CE is the project leader, project manager and technical leader all rolled into one. CE designs the system and is ultimately responsible for delivering value to the customer and the program's commercial success. CE therefore is usually sponsored by someone in vice-president level.

In Toyota product development, managers with no technical skills are moved to manage other things. Knowledgeable engineers without interest in people and money are sent to R&D.

During the program, CE becomes the primary voice of the customer. Because of this, a person with the background and experience to establish an emotional connection with the target customer is selected as CE for a program.

Therefore selecting chief engineer for a program is the critical first step of Toyota product development process.

Once selected, CE focuses on value discovery process and value definition. CE then communicates customer-defined value & vehicle-level performance objectives and aligns the vehicle-level performance goals of the entire program team.

Another interesting thing is the document called shijisho produced by CE. This is a concept paper that outlines the CE's vision for the new vehicle. The literal translation of shijisho is "direct order document" almost like a military order.

Elements of Toyota's Lean Product Development

This is from Lean Product and Process Development by Allen C. Ward.

• All Toyota developers spend about half of their first year assembling and selling cars. The final customers & the customers for the product development process.


• Identifies the critical skills associated with each job.
  
  1. Understands the basic engineering principles
  2. Works fast enough to keep up with the team
  3. Takes responsibility for the work
  4. Can teach the skills


• Keeping people in position long enough to become expert and to get good feedback on their decisions.


• Require engineers to "get their hands dirty".


• Developers must be evaluated on their contributions to project success.

Follow Process Mapping with Walk Through

I have never walked through a process mapping or a process flow during the discovery phase of a project. This simple technique was mentioned in a local lean group meet-up.

Just pick up a process map and physically follow the process where the operational people are. Opportunity to talk to people on the ground, learn more about what they do and review the current process mapping. It can lead to rich learning experience. Rich context around the words and drawings.

Definitely something to try next time.

Standards

I'm reading Toyota Production System by Taiichi Ohno. In "The True Intention of the Ford System" chapter, he quotes Ford's book regarding standards.

One has to go rather slowly on fixing standards, for it is considerably easier to fix a wrong standard than a right one. There is the standardizing which marks inertia, and the standardizing which marks progress. Therein lies the danger in loosely talking about standardization.

And the rest of the passage talks about that standards effort should not be directed from above or it does not lead to progress.

Schema Validation in XFire

I'm working on a small web services project at the moment. I'm using Spring 2.0.5, XFire 1.2.6 on Java 1.5. One of the technical requirements was to have schema validation turned on for requests. Quick google search returned the two blog entries by Alexander Ananiev (first and second).

Second solution is much simpler because it uses JAXB to do the validation. It looked simple so decided to use it. Unfortunately when I applied the second solution, I got this cryptic error message.

org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element ’tns:application’.

First solution didn't work either. I spent whole afternoon on trying to fix the issue but gave up because had other higher priority stories.

A week later, I got a mail from a developer who was having trouble talking to my application. The request was received by the server and a response message was returned but his client application could not process the response message.

The problem was that first element in soap body had wrong namespace associated. First element of the soap body tag had namespace of wsdl while the rest of the message had namespace of the xsd schema. After trying some fruitless configuration changes, I started thinking that this may be a defect in XFire.

Quick google search returned the following entry in XFire JIRA.

Apparently it's behaviour introduced in recent versions of XFire. The solution mentioned in the Jira entry suggests to use JAXWSProfile when generating server stubs. The detail of how to use the WS profile is here.

Another change I had to make was to use org.codehaus.xfire.jaxws.JAXWSServiceFactory instead of org.codehaus.xfire.jaxb2.JaxbServiceFactory.

This problem occured on server and client side so I couldn't detect it.

Sorting out namespace issue also fixed the schema validation issue I had earlier. It turned out that the namespace problem was causing the schema validation above because the first element had wrong namespace.

Well... Web services experience wasn't not quite what I expected. Lots of hidden gotchas....

I will post on general web services experiences and lessons learned later.