Exciting day

Today it has been an exciting day. While preparing my presentation about software cost estimation I got a call by the school of our daughters. Janina has had an accident during the gymnastic exercises. While she tried to get a basketball she noticed a crackle and a pain in her rear. So they called an ambulance and she's been driven to the hospital. Meanwhile I fetched my wife and we drove to the hospital, too. She stayed there during the medical examination and I drove back to work. Fortunately it seems to be nothing serious. But we've been scarried.

So the next thing has been my presentation. The feedback has been good. First I stumbled a bit and lost the thread once. But then it got more and more fluent and I've been able to add some side notes out of my experience. Like at my last presentation about requirements engineering if noticed that the motivation part and the theoretical informations are ok. But I need to change both presentations into a more practical approach with more real life examples to demonstrate the advantage of the usage of the described techniques. I'll now first fix some smaller bugs in both presentations, a kind of minor release, and then think about how to better communicate the ideas and necessities behind them. The last step will be a translation into English and a migration from PowerPoint to my new Keynote layout. I'm currently designing it for an upcoming presentation about the risks and opportunities of changes.

The last event yesterday should have been the Apple keynote. Ok, the new MacBook Air is a nice peace of hardware. But currently not for me. I've got my MacBook for six month now and it's still very good. So I think I'll change in about two years again and then will get a system with a quad core, 4 GB RAM and a 200 GB SSD for 1.500 Euros. *smile* Now I'm awaiting OS X 10.5.2 which is expected to be released soon.

Ending the silence

The time between today and my last entry is about three weeks. Over twenty days where I havn't had the time to just write some word. *sigh* But now it can go on.

During this time I've mostly been busy starting a larger project at my employer. My role here is the system architect and I'm also take part in rolling out the requirement engineering together with the standards definition and tool evaluation. We decided us for the IRqA, a really nice tool, especially the next release. Visure gave us a little preview. The tool is more powerful than DOORS, cheaper, and the service is really, really good. So now we're on our way, analysing our customers requirements and writing fine use cases. *smile*

A large part of my time at home went into my current article about continuations. Even if it is a small article it had cost a lot of work. I've had much troubles to find the right words to demonstrate this technique in a practical way. But know it is finished and delivered and I can concentrate on my next article about Erlang.

Beside doing serious things I've also wasted some time playing around with my new gadget. My new mobile phone should be a smartphone. And after comparing several models trying to find out what exactly I want I've decide for the Nokia E61i. It's a real nice device, not too large, pwerful, and playing wonderful together with my Mac - I've allready installed a neat OS X theme - and some WLANs where I've tried it.

So now I can go on developing in Erlang and write about it - here and in my next article. This system still fascinates me and I see a very large potential for future applications. Even if it is not Erlang itself its technology will influence many others. The current discussions on the Squeak lists demonstrate this allready.

Forgotten software development tasks

It allways seems to be the same. Again I've heard about two different software development projects which are more in trouble than needed. The first one has no real requirements engineering and an unorganized process. There's a continous flow of new requirements which also flow unbundled, unpriorized, and continous into the development. As a result the software updates are short planned and testing is difficult. That's a noxious environment for the software quality and for the developers. I don't know very much about this project, but I've once been responsible to cleanup a project in an almost similar situation. The first step has been the establishment of an iterative process with timeboxes. I've choosen 6 weeks, but this depends on the individual project situation. The second step was the installation of my request management system, a simple web application for the management of requirements and issues. Finally I've set up a process of collecting and documenting the requirements and their dependencies, priorized them, and published the features of the next three releases - with decrescent likeliness. The result has been a steady development with predictable results for our customers. Additionally we've been able to do a better resource planning so that a part of the team had the time to dig into the sources and improve them.

The second project I've been told about had two cost estimations for the finalization. One seems to be relative realistic, following the opinion of the team members. It has been done through the current project manager, who has a very good reputation in his team. But the estimation is also high. The other one has been done through the his predecessor. His estimation is much lower. So even if he has been replaced due to his flop before, the management now follows him. The lower costs are much more convenient. I can't believe it, what's happening there? Doing software cost estimation is one of my interests. And I always get relative high numbers using the function point analysis and COCOMO II. The people around me are very often scared about those numbers and so they are sometimes not accepted. But when a project moves towards the end I often see that the estimated effort is almost accurate. So it makes no sense to tell oneself a lie.

Both cases show how software development consist of more than just coding. Capers Jones analyzed a lot of projects and categorized them into six different types: web, MIS, outsourcing, commercial, system, and military. These types have diferent numbers of activities and percentages of work effort per activity. The minimum number is 7 activities, the maximum 25. Take a look at the table inside the referenced document. It show's very good what to keep in mind when realizing a software project. And even if it is unpleasing it is just the truth.

Importance of Requirements Engineering and Software Cost Estimation

Once again I've read about a software project which underestimated the importance of a continuous requirements engineering together with a calibrated software cost estimation. And once again this underestimation led to problems with the calculated budget. The result has been a higher pressure on the developers and a lower quality due to less testing.

This could be astonishing if this kind of problem is totally new. But it happens since years and years again. And only few are learning from those problems. It's known a long time that customers and developers don't know all requirements from the start, that the requirements are changing 2 to 3 percent each month, that the number of rrequirements is growing if it isn't priorized and controlled, that the deviation of the first estimation is very large and a calibration over the time is needed, and that developers often only esitmate their work which is only a relative small part of a complete software project.

Maybe some of the unexperienced project managers read this.

OOP 2007 - Requirements engineering and contracts

The track of Chris Rupp covered the influence of the requirements engineering on contracts. She pointed out that there often are communication problems between customers and developers. So a good formalized requirements documentation is not enough. It only helps to do things right but not to do the right things. Both, customer and developer, have to find the same wording and need knowledge of each others domain. Also there are requirements that are subliminal to the customer. So contracts which allow to specify requirements during the realization are needed. To get an individual method for each project she presented RCDA which stands for require, commit, deliver, and accept. Require and accept artefacts are delivered from the customer to the contractor, commit and deliver artefacts from the contractor to the customer. The exchanged artefacts for each step have to be clearly defined in the contract. Different ways are possible, e.g. strict of fluffly requirements in the request and according to that a detailed or simple commit.

So the contract is very important, but not everything. And there are no perfect requirements. There are many concerns which have to be controlled by both involved parties to let them not be controlled by those concerns.