COnstructive COst MOdel II (COCOMO® II) is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity. COCOMO® II is the latest major extension to the original COCOMO® (COCOMO® 81) model published in 1981. It consists of three submodels, each one offering increased fidelity the further along one is in the project planning and design process. Listed in increasing fidelity, these submodels are called the Applications Composition, Early Design, and Post-architecture models.
COCOMO II has three different models :
- The Application Composition ModelSuitable for projects built with modern GUI-builder tools. Based on Object Points.
- The Early Design ModelThis model is used to make rough estimates of a project's cost and duration before it is entire architecture is not determined. It uses a small set of new Cost Drivers, and new estimating equations. Based on Unadjusted Function Points or KSLOC.
For the Early Design and Post Architecture Model :
Where a = 2.5, SFj = scale factor, EMi = effort multiplier
BRAK = Percentage code discarted due to requirement volatility
ASLOC = size of adapted components
AT = percents of components adapted
ATPROD = Automatic Translation Productivity
AAM = Adaptation Adjustment Multiplier
COCOMO'II adjusts for the effects of reengineering in its effort estimate. When a project includes automatic translation, following list must be estimated :
- Automatic translation productivity (ATPROD), estimated from previous development efforts
- The size, in thousands of Source Lines of Code, of untranslated code (KSLOC) and of code to be translated (KASLOC) under this project.
- The percentage of components being developed from reengineered software (ADAPT)
- The percentage of components that are being automatically translated (AT).
The effort equation is adjusted by 15 cost driver attributes in COCOMO'81, but COCOMO'II defines seven cost drivers (EM) for the Early Design estimate:
- Personnel capability
- Product reliability and complexity
- Required reuse
- Platform difficulty
- Personnel experience
- Facilities
- Schedule constraints.
COCOMO'II models software projects as exhibiting decreasing returns to scale. Decreasing returns are reflected in the effort equation by an exponent for SLOC greater than unity. This exponent varies among the three COCOMO'81 development modes (organic, semidetached, and embedded). COCOMO'II does not explicitly partition projects by development modes. Instead the power to which the size estimate is raised is determined by five scale factors: - Precedentedness (how novel the project is for the organization)
- Development flexibility
- Architecture/risk resolution
- Team cohesion
- Organization process maturity.
- The Post-Architecture ModelThis is the most detailed COCOMO II model. It is used after project's overall architecture is developed. It has new cost drivers, new line counting rules, and new equations.
Use of reengineered and automatically translated software is accounted for as in the Early Design equation (ASLOC, AT, ATPROD, and AAM). Breakage (BRAK), or the percentage of code thrown away due to requirements change is accounted for in 2.0. Reused software (RUF) is accounted for in the effort equation by adjusting the size by the adaptation adjustment multiplier (AAM). This multiplier is calculated from estimates of the percent of the design modified (DM), percent of the code modified (CM), integration effort modification (IM), software understanding (SU), and assessment and assimilation (AA). Seventeen effort multipliers are defined for the Post-Architecture model grouped into four categories:- Product factors
- Platform factors
- Personnel factors
- Project factors
A single development schedule estimate is defined for all three COCOMO'II models :
Where c = 3, SFj scale factor and SCED% = schedule compression/expansion parameter.
Category of Projects For Which Cocomo Is applicable:
COCOMO® II can be used for the following major decision situations
- Making investment or other financial decisions involving a software development effort
- Setting project budgets and schedules as a basis for planning and control
- Deciding on or negotiating tradeoffs among software cost, schedule, functionality, performance or quality factors
- Making software cost and schedule risk management decisions
- Deciding which parts of a software system to develop, reuse, lease, or purchase
- Making legacy software inventory decisions: what parts to modify, phase out, outsource, etc
- Setting mixed investment strategies to improve organization's software capability, via reuse, tools, process maturity, outsourcing, etc
- Deciding how to implement a process improvement strategy, such as that provided in the SEI CMM
No comments:
Post a Comment