One of the questions that frequently gets asked in development planning is how much time should be spent on the various phases of an IT project. I dont have the answer but I did look up in my favorite Bible on development practices as actually practiced, Caper Jones book Applied Software Measurement. I did not find exactly what I wanted among the information on thousands of projects – but I did find a reference to Kurt Wiegers June 1993 article in Computer Language – Implementing Software Engineering. I list the results here because I plan to find an updated profile and publish those numbers as well:
11% – Preliminaries – work done prior to actual system definition
> specific training
> feasibility discussion
> project management planning
> hardware and software appraisal
24% – Specification – work done delineating scope and details of system
> gather customer requirements
> writing functional specifications
> building and evaluating user interface and other prototypes
> building an essential dataflow model
> reviewing the specification documents
11% – Design – transform general specs into detail design requirements
> data, process, and user interface modeling
> program architecture
> database design
> menus, screen, and report layouts
> module design and definition prototypes
> inspect and review design documents
33% – Implementation/Coding – coding, testing, documenting the executables
> create and tune the database design
> code and test input screens and layouts
> code and test reports and graphics output
> code and test help, backup, security, interfaces
> inspect and review each phase
6% – Testing – preparing and conducting tests for crossover to production
> unit stress test against plan
> inetgration tests between major modules
> system wide tests in parallel
3% – Writing – users manuls, on-line help, training, system docs
12% – maintenance All work done after system delivery
> Corrective – fixing defects
> Perfective – adding enhancements
> Adaptive – change to keep system functioning in a changed environ
> plus other user support
There you have it. This is a typical client-server development cycle but before the Web and Agile systems view of what development is all about.
Hear the moaning at the Wailing Wall of Agile and Extreme Developmentistes ?
“Oh woe to the bad old days where 46% of the time was spent on top heavy specification and design.” “Look at the paltry 6% of the time spent on testing. And so late in the process.” “And 3% of the time wasted on system documents – such extravagance!”
But if we take the risk diminishment approach, which this reviewer learned about 15 years before 1993, then the process might look a bit more robust. The risk diminishment approach says briefly but always look for risks to a projects success. At every step in the process see what the 5 top risks are and how that step has changed, reduced or added to the risks. In the latter case, does this require reasessment of the direction or feasibility of the project?
Constant risk diminishment was the champion of good project measures plus test-first-and-often design and development. In the risk diminishment light, suddenly “build and evaluate user interface and other prototypes” has a lot more power. Likewise for “data, process, and user interface modeling” or inspect and review design documents”. Suddenly Kurts process has more robustness.
What Agile and Extreme Programming have done is brought the key concepts of risk diminishment plus active and sustained stakeholder participation in every phase of a project to the fore. These are now regarded as necessary (but not sufficient) conditions for successful project development. A good think.
(c)JBSurveyer 2005