With the advent of software cost modeling tools such as COCOMO [Boehm, 1981] the potential ability for software engineers to correctly estimate the project life cycle was greatly enhanced. Software tools such as Excel provide the calculation engines needed to factor the data and compute the results much easier.
However, with this ease of use, comes the increased potential for error, as the models depend on the value of the various parameters used in computation. The miss-estimation of any of these can lead to startlingly different results.
One of the most often miss-calculated areas of estimation is maintenance.
For the purposes of this discussion the Excel COCOMO model [Williams, 1992] will be used which models the CLEF for intermediate COCOMO.
4 Degrees of Refactoring Summary
Observations of software projects in the maintenance phase has yielded the following patterns based on the percentage of code being replaced, each pattern requires changes to the parameters used to feed the COCOMO model. A discussion of each pattern is in the sections below.
Name % of Change Parameters to be adjusted Maintenance 0%-25% SCHED(0), AEXP (1), VEXP(1), ACAP(1) Correction or Enhancement 26%-50% SCHED(1), AEXP(0), VEXP(0), ACAP(0) Major Correction 51%-75% SCHED(1+), AEXP(-1), VEXP(0), ACAP(-1) New Project 76%+ SCHED(1+), AEXP(-1), VEXP(0), ACAP(-1-)
The numbers in ( ) represent the column shit that should be contemplated in the cost driver table in the ‘Help-Rating System’ tab in the Excel spreadsheet. A negative number indicates a left shift (e.g. NM à LO) a positive number indicates a right shift (e.g. NM à HI). Additionally, the models column ‘D’ “How Much Do We Have To Create New” should reflect the estimated percentage.
Parameters to be reconsidered as a function of those changes:
Reasons to reconsider
TOOL Have there been tool improvements since project inception? If the tool has changed, there should be at least a (-1) shift. RELY Have the requirements for reliability changed? DATA Has the database complexity changed? CPLX Has the business logic gotten more complex or have large numbers of exceptions or special cases been added? Maintenance
This pattern is a well known one and assumes no requirements changes and little or no new feature enhancements. Bug fixing and/or refactoring (the two should be exclusive of each other [Fowler, 1999]) are the rule for this model. It is assumed that the team is well experienced in the code being modified (if not adjust left ACAP, AEXP, PCAP, VEXP, LEXP) and know the requirements well. It also implies an existing depth of tests [Beck, 2000] that can be used to verify that bug fixes do not break existing functionality.
Correction or Enhancement
A correction or enhancement implies significant requirements and design change with the schedule being adjust to cover the required reviews, etc. The implication is that a significant body of new tests will be written to test the new functionality above and beyond the existing test (some of which may be deprecated).
This model is also appropriate when making a significant tools change, as new tool semantics (behavior, API, etc) will have a strong impact on system performance and stability. Inevitably, even if the code compiles in the new tool, significant refactoring of functions will be required to get them to be performant or stable at run time.
A major correction implies the removal or complete redesign of significant subsystems. If these subsystems participate in a stack of functionality, the impact can be significant. Dependency analysis should be preformed to determine the effected subsystems whose volatility must be considered when adjusting the schedule even if the code required interfacing with the new/changed subsystems in minimal. This is the most frequently overlooked schedule adjustment factor. A multiplier should be applied (e.g. an adjustment to CPLX) if multiple interrelated subsystems are changing at the same time as additional system complexity will cause stabilization challenges.
Simply put, changing more the 75% of the code even if it is assumed the requirements have changed constitutes a “do-over”. Careful analysis of the parameters for each subsystem must be undertaken and additional time allocated for running the old and new system in parallel and for churn caused by attempting to educate teams as to the new architecture.
Bibliography [Beck, 2000] Beck, Kent “Extreme Programming Explained”, Addison-Wesley, 2000 [Boehm, 1981] Boehm, Barry "Software Engineering Economics", Prentice Hall 1981 [Fowler, 1999] Fowler, Martin “Refactoring: Improving the Design of Existing Code”, Addison-Wesley, 1999 [Williams, 1992] An Excel COCOMO Model [download]