Software Metrics and Processes
There is whole sub–field
of software metrics, and there has been some discussion on New Grange about
this. My take on the New Grange threads is they haven't found the real source
of software metrics, which is Barry Boehm's COCOMO II models at University of
Southern California. A quick search on the web for "software
metrics" will turn up many of the answers to the questions being asked on
New Grange. There are several approaches to the problem of development metrics
that I've found useful. For the non-software types the use of metrics is
similar to estimating guidebooks for concrete or steel. "How long will it
take to build a building can be estimated by how much steel there is to
COCOMO II, is a
current modeling process for non–OO projects (functionally decomposed
software rather than object decomposed software). It provides effort
estimates based on parameters provided by the user. It has a long history,
starting at TRW and Barry's book on the subject of cost estimating.
There is an
alternative to the lines of code approach of COCOMO II and that is Function
Points. This is a somewhat complex method of counting the functional
"points" of the system and determining how many man days the
development will take.
The final approach is
to use an OO oriented system, that captures how many classes have been
identified, the complexity factor of the development (Ala COCOMO II) and
compute how long it will take to develop the classes. There is a tool at
Steve McConnell's site that computes the time and labor estimates using
classes — based on COCOMO II. This works for projects down to a moderate
number of classes, but not for "small" projects.
Each of thee methods
requires careful planning and is fraught with risk if the parameters are not
defined properly. Regression testing of the results is on way to
"calibrate" the models. But of course this requires that good
metrics were gathered on previous projects. This is the "chicken or the
There is another set of
"metrics" which is used for Software Quality Assurance. Any good
search engine with "OO Metrics" in the text will find the home sites
for these metrics.
Processes - UML, XP, and other development processes
In the software process
domain there are many good texts and papers. The primary approach is the
Software Engineering Institute's Capability Maturity Model. This can be found
at the Software Engineering Institute.
The debate between heavy weight and light weight processes has
been going on for some time. The light weight process include eXterme
Programming (XP). This approach has gained more favor recently with the
introduction of better text books as well as alternative implementation.
Process Elaboration Phase: best Practices in Implementing the UP, Scott
Ambler, R&D Books, 2000. This is the second in a series of Rational
Unified Process books. Although the Unified Process would not be considered light
weight there are many aspects of RUP that can be applied to light weigh
processes and the improvement of organizations using them.
Programming Explained: Embrace Change, Kent Beck, Addison Wesley, 1999.
Programming Installed, Ron Jeffries, Ann Anderson and Chet Hendrickson,
Addison Wesley, 2000
eXtreme Programming, Kent Beck and martin Flower, Addison Wesley, 2000
CMM Implementation Guide: Choreographing
Software Process Improvement, Kim Caputo, Addison Wesley, 1998. This is
a detailed guide book on deploying the SW–CMM. Along with the next book,
these texts describe how to plan and deploy a CMM–based process
Software Process Improvement: Practical Guidelines for Business Success,
Sami Zahran, Addison Wesley, 1998.
Software Process Improvement, Robert Grady, Prentice Hall. Grady is at
HP and leads the process improvement effort there.
News, is a journal sponsored by the DoD Data & Analysis Center for
It contains articles and references to many of the issues in software
project management. Subscriptions are free (our tax dollars at work).