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.

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.

How FPA and COCOMO II play together

As I told you lately there are several ways to estimate the effort for software projects. Most important for all of them is that they don't just create their values through some kind of voodoo magic. They have to use a comprehensible and parameterizable way for their calculation. First this is needed to get a better base for argumentations with you project stakeholders. Second you'll have to review your calculation during the development and when it is finished to adjust those parameters for future calculations.

Instead of thinking about an own, totally new way of estimation it often is much better to use the experiences of others and fall back to well proven methods. It's not only that you can learn from them. But you have also by far less problem when arguing your numbers. I've really often undergone and observed how high values for the first effort estimation based on the developers experience frightened the project management or the customer. As a result the developers are forced to recalculate (!) until the values are low enough. *sigh* What a bad, bad way, almost allways leading into a project failing or at least a strong delay. Estimations based on more academic methods are accepted much more instead.

My favorite methods are the function point analysis (FPA) together with COCOMO II. The first one is a method that examines the software project from five angles. Those are external inputs, external outputs, external inquieries, internal logical files, and external interface files. Based on parameters their complexity is rated as low, medium, or high. At the end they are counted for each type and complexity multiplied with a defined value. Adding all together results into the unadjusted function points, an abstract unit for the size of a software. Too fast? Don't panic, I'll document this here in a later entry and you'll see how simple it is. But the FPA isn't finished here. Non-functional requirements also have influence on the effort. So there are 14 general system characteristics, each one with six descriptions and assigned values from 0 to 5. 0 means that there is no influence, 5 shows a high impact of the characteristic for the project. All together lead to a value adjustment factor between 0.65 and 1.35. Multiplied with the unadjasted function point you now get the total adjusted function points. I'll also cover this in detail later.

And now? How does it help me to know that my project has a size of 2731 total adjusted function points? The next step is to determine the total program size for the used language. There are different tables available, like http://www.qsm.com/FPGearing.html. The values here help you to get a feeling for the size of your application in source lines of code (SLOC). So for our TAF value above we would get 166,591 SLOC in JEE, 161,129 in C#, and 95,585 in Smalltalk. For some this may be astonishing, but not for Smalltalkers with Java and .NET experience. *smile* The table of languages on the page above also shows Notes or SQL. That doesn't mean that all those languages fit for the same problems. Also some of the newer languages like Ruby or Python are missing.

Even if we're now a step further we still don't know the effort. This will be calculated with the help of COCOMO II. This method provides formulars which take the software size as estimated above as an input parameter. Another one is the size of reused code. There are several more input parameters, but the most important are the scaling factors, the product factors, the platform factors, the personnel factors, and the project factors. Alltogether 22 factors have to be rated between very low and extra high by given questions and answers. Playing around with the result values shows how much influence the answers have. As a result you get the total effort and the duration. COCOMO II is more complex than the FPA, but it is also not so difficult to handle. I'll write about it later, too.

Right here the estimation isn't finished. But you allready have got the most important values: How much will it cost (in personnel) and how long will it last. Doing this more often, in different project and with reviews of project in progress or finished projects you'll get more training in estimate the size right and to rate the general system characteristics and the factors better. COCOMO II additionally allows you to adjust the parameters to your company and environment. So you'll get even better estimations.

The role of software cost estimation

One great and important question of customers is how much it will cost what they get. This naturally applies for software projects too. But due to the nature of software development that it is often unclear what exactly is wanted and that the requirements are typically changing about two to three percent each month. So software development is no simple production process. Like in every other technological development costs can't be calculated. They have to be estimated based on the determinant factors.

Very often those estimations are done through just asking the developers. But they've got only their small view on the whole work. A closer look at the tables of Capers Jones shows number from 60% for coding and unit testing in web projects down to 19% for both in military projects. Over all web projects consist out of seven activities while military projects separate between 25 different tasks. There are also other types of development projects listed. The average of coding and unit testing is about 28%, without web projects only about 22%. So even the typical practice of just doubling the developers estimation is by far too low. Additionally most developers see less effort for coding and testing as it is needed in reality. The experienced programmers are asked, but they map their performance on all team members, also the slower ones.

Based on the estimation the project planing will be done. Staffing and timeline, resources and actions. But if the basic numbers are too low the whole planing is not coherent. Sooner or later this will be detected, but correcting it will be expensive. Additionally very often the project vastly delays. As a solution to handle this, a comprehensible process for the software cost estimation is needed. It has to offer methods to cover all the aspects of a software system in a common understandable way, to transpose the results into the target environment, and to regard the influence hard and soft constraints for the project. It also has to offer setscrews for later adjustments after comparing the estimation with current review results. So you'll get a learning and self improving system.

An approved combination for this work is the function point analysis in combination with COCOCMO II. I'll start a series of articles here where I'll give a managable introduction how to use those two methods together and improve your estimations through later justification.