Philippe Kruchten Comments by Email 8/8/05
The relationship between total effort and project duration is one of the best understood in software engineering, mostly through the work of Barry Boehm and the COCOMO. A few cost drivers affect the result, as well as different calibration depending on the type of software (MIS application, embedded, etc.). COCOMO was developed in 1981, and its successor COCOMO II in 2000.
For example: A 100 person-month project, with all cost drivers at nominal value takes 14 months according to COCOMO; staffing would start at 3 persons, and culminate at 8 or 9 (7.1 average) in what we call the construction phase in RUP. But a 200 person-month project would take 19 months with staffing going from 5 to 12 (10.5 average). It would however deliver less than twice the code (35K for the first 67K for the 2nd).
There are numerous COCOMO resources on the net. I often use the NASA calculator: http://www1.jsc.nasa.gov/bu2/
COCOMO.html. The same page contains plenty of other pointers.
Not exact science, but allows you to confirm some "Leroy Roscoe" rule of thumb numbers, like: Are you in the right ballpark, or off by a factor 2 or 3 ...
Philippe Adds Later:
Here are the COCOMO 1 cost drivers I referred to:
- Product attributes
- Required software reliability
- Size of application database
- Complexity of the product
- Hardware attributes
- Run-time performance constraints
- Memory constraints
- Volatility of the virtual machine environment
- Required turnaround time
- Personnel attributes
- Analyst capability
- Software engineer capability
- Applications experience
- Virtual machine experience
- Programming language experience
- Project attributes
- Use of software tools
- Application of software engineering methods
- Required development schedule
For an explanation see: http://www.mhhe.com/engcs/compsci/pressman/
information/olc/COCOMO.html. For COCOMO 2 see: http://sunset.usc.edu/research/COCOMOII/
For more on cost drivers see: http://www.softstarsystems.com/
cdtable.htm (COSTAR is a commercial tool that uses and extends COCOMO).
However, 100 man-day projects are probably too small for COCOMO. A 100 man-day
project is probably best done with 3 people x 6 weeks, or 4 persons x 5 weeks.
After that you have a hard time distributing the work and synchronizing. There are
exceptions to this, for example:
- If there are many different and simple things to do, requiring different expertise, and
- When the architecture of the software system is stable, understood and untouched as in the case of an update of an existing system. (All these things are taken into account by COCOMO cost drivers.)
The size of project that Philippe quotes for applying COCOMO is, of course, much larger than we originally postulated at the beginning. Perhaps the concept of "economies of scale" is at work here? Certainly for small projects, the smaller the project the higher is the percentage of administrative overhead. Even so, the resulting durations shown by COCOMO seem to me to be quite optimistic. Perhaps these are the "theoretical" durations before the application of allowances for the "cost drivers" that, in practice, inevitably take over. On this basis the number of software development projects that end up being late should not surprise us. The problem is not with the project but with the baseline of reference!
Philippe's later observations for a 100 man-day project seem much more realistic and consistent with our own predictions. Philippe is Dr. Philippe Kruchten, Professor of Electrical Engineering, University of British Columbia, BC, formerly lead architect for the Rational Unified Process. His latest book is The Rational Unified Process Made Easy - A Practitioner's Guide to the RUP, Addison Wesley, 2003