Section defines the particular COCOMO II assumptions about what life-cycle phases and labor categories are covered by its effort and schedule estimates. These and other definitions given in Section 6 were used in collecting all the data to which COCOMO II has been calibrated. If you use other definitions and assumptions, you need to either adjust the COCOMO II estimates or recalibrate its coefficients.
COCOMO II has been developed to be usable by projects employing either waterfall or spiral processes. For these to be reasonably compatible, the waterfall implementation needs to be strongly risk-driven, in order to avoid incurring large amounts of rework not included in spiral-model-based estimates. Fortunately, this was the case for the normative waterfall implementation provided in Chapter 4 of [Boehm 1981] as the underlying process model for COCOMO 81.
The implementation of the spiral model used by COCOMO II also needs an added feature: a set of well-defined common milestones which can serve as the end points between which COCOMO II estimates and actuals are assessed. In 1995, we devoted parts of two COCOMO II Affiliates’ workshops to determining such milestones. The result was the set of Anchor Point milestones: Life Cycle Objectives (LCO), Life Cycle Architecture (LCA), and Initial Operational Capability (IOC) [Boehm 1996]. Those milestones were a good fit to key life-cycle project commitment points being used within both our commercial and government contractor Affiliate communities. The LCO and LCA milestones involve concurrent rather than sequential development and elaboration of a system’s operational concept, requirements, architecture, prototypes, life-cycle plan, and feasibility rationale. The milestones correspond well with real-life commitment milestones: LCO is roughly equivalent to getting engaged; LCA to getting married; and IOC to having your first child.
These anchor points and the stakeholder win-win extension of the spiral model became the key milestones in our Model-Based (System) Architecting and Software Engineering (MBASE) life-cycle process model [Boehm-Port 1999; Boehm et al. 1999]. We have also collaborated with one of our Affiliates, Rational, Inc., to ensure the compatibility of MBASE and the Rational Unified Process (RUP). Thus, we have adopted Rational’s approach to the four main spiral-oriented phases: Inception, Elaboration, Construction, and Transition. Rational has adopted our definitions of the LCO, LCA, and IOC anchor point milestones defining the entry and exit criteria between the phases [Royce 1998; Kruchten 1999; Jacobson et al. 1999].
Section 6.2 proceeds to define the content of the milestones used as end points for the waterfall and MBASE/RUP spiral models to which COCOMO II project estimates are related. Section 6.3 compares the phase distributions of effort and schedule used by COCOMO II for the waterfall and initial MBASE/RUP spiral process models. Section 6.4 defines the activity categories for the Waterfall and MBASE/RUP spiral models, and their content. Section 6.5 presents the corresponding effort distributions by activity for each Waterfall and MBASE/RUP phase. Section 6.6 covers other COCOMO II assumptions, such as the labor categories considered as "project effort," and the number of person-hours in a person-month. Appendix B then builds upon the phase distributions of effort and schedule to provide an estimation model for incremental development.
Table 42 defines the milestones used as end points for COCOMO II Waterfall phase effort and schedule estimates. The milestone definitions are the same as those in [Boehm 1981; Table 4-1].
A basic risk-orientation is provided with the inclusion of “Identification and resolution of all high-risk development issues” as a Product Design milestone element. However, the other early milestones should have a more risk-driven interpretation. For example, having “…specifications validated for…feasibility” by the end of the Plans and Requirements phase of a user-interactive system development would imply doing an appropriate amount of user-interface prototyping.
Table 43 defines the milestones used as end points for COCOMO II MBASE/RUP phase effort and schedule estimates (the content of the Life Cycle Objectives (LCO) and Life Cycle Architecture (LCA) milestones are elaborated in Table 44). The definitions of the Inception Readiness Review (IRR) and Product Release Review (PRR) have been added in Table 43. They ensure that the Inception and Transition phases have milestones at each end between which to measure effort and schedule. The PRR is defined consistently with its Rational counterpart in [Royce 1998; Kruchten 1999]. The IRR was previously undefined; its content focuses on the preconditions for a successful Inception phase.
|
Table 2. MBASE and Rational Unified Software Development Process Milestones |
|
1. Inception Readiness Review (IRR) § Candidate system objectives, scope, boundary § Key stakeholders identified § Committed to support Inception phase § Resources committed to achieve successful LCO package |
|
1. Life Cycle Objectives Review (LCO) § Life Cycle Objectives (LCO) Package (see Table 44) § Key elements of Operational Concept, Prototype, Requirements, Architecture, Life Cycle Plan, Feasibility Rationale § Feasibility assured for at least one architecture, using the criteria: § Acceptable business case § A system developed from the architecture would support the operational concept, be compatible with the prototype, satisfy the requirements, and be buildable within the budgets and schedules in the life-cycle plan. § Feasibility validated by an Architecture Review Board (ARB) § ARB includes project-leader peers, architects, specialty experts, key stakeholders [Marenzano 1995]. § Key stakeholders concur on essentials, commit to support Elaboration phase § Resources committed to achieve successful LCA package |
|
2. Life Cycle Architecture Review (LCA) § Life Cycle Architecture (LCA) Package (see Table 44) § Feasibility assured for selected architecture (see above) § Feasibility validated by ARB § Stakeholders concur on their success-critical items, commit to support Construction, Transition, and Maintenance phases. § All major risks resolved or covered by risk management plan § Resources committed to achieve Initial Operational Capability (IOC), life-cycle support |
|
3. Initial Operational Capability (IOC) § Software preparation, including both operational and support software with appropriate commentary and documentation; initial data preparation or conversion; the necessary licenses and rights for COTS and reused software, and appropriate operational readiness testing. § Site preparation, including initial facilities, equipment, supplies, and COTS vendor support arrangements. § Initial user, operator and maintainer preparation, including selection, teambuilding, training and other qualification for familiarization usage, operations, or maintenance. § Successful Transition Readiness Review § Plans, preparations for full conversion, installation, training, and operational cutover § Stakeholders confirm commitment to support Transition and Maintenance phases |
|
4. Product Release Review (PRR) § Assurance of successful cutover from previous system for key operational sites § Personnel fully qualified to operate and maintain new system § Stakeholder concurrence that the deployed system operates consistently with negotiated and evolving stakeholder agreements § Stakeholders confirm commitment to support Maintenance phase |
|
Table 3. Detailed LCO and LCA Milestone Content |
||
|
Milestone Element |
Life Cycle Objectives (LCO) |
Life Cycle Architecture (LCA) |
|
Definition of Operational Concept |
Top-level system objectives and scope System boundary Environment parameters and assumptions Current system shortfalls Operational concept: key nominal scenarios, stakeholder roles and responsibilities |
Elaboration of system objectives and scope by increment Elaboration of operational concept by increment Nominal and key off-nominal scenarios |
|
System Prototype(s) |
Exercise key usage scenarios Resolve critical risks |
Exercise range of usage scenarios Resolve major outstanding risks |
|
Definition of System and Software Requirements |
Top-level capabilities, interfaces, quality attribute levels, including: Evolution requirements Priorities Stakeholders’ concurrence on essentials |
Elaboration of functions, interfaces, quality attributes by increment Identification of TBDs (to-be-determined items), evolution requirements Stakeholders’ concurrence on their priority concerns |
|
Definition of System and Software Architecture |
Top-level definition of at least one feasible architecture Physical and logical elements and relationships Choices of COTS and reusable software elements Identification of infeasible architecture options |
Choice of architecture and elaboration by increment Physical and logical components, connectors, configurations, constraints COTS, reuse choices Domain-architecture and architectural style choices Architecture evolution parameters |
|
Definition of Life cycle Plan |
Identification of life-cycle stakeholders Users, customers, developers, maintainers, interfacers, general public, others Identification of life-cycle process model Top-level stages, increments Top-level WWWWWHH* by stage |
Elaboration of WWWWWHH for Initial Operational Capability (IOC) Partial elaboration, identification of key TBDs for later increments |
|
Feasibility Rationale |
Assurance of consistency among elements above via analysis, measurement, prototyping, simulation, etc. Business case analysis for requirements, feasible architectures |
Assurance of consistency among elements above Rationale for major options rejected All major risks resolved or covered by risk management plan within the life-cycle plan |
|
* WWWWWHH: Why, What, When, Who, Where, How, How Much |
||
Figure 4 shows the relationship of the Waterfall and MBASE/RUP phases and the most likely COCOMO II model to be used in estimating effort and schedule. The milestones have some variation due to the differences in distribution of effort and schedule between the two models.
Provisional phase distributions of effort and schedule are provided below for both the Waterfall and MBASE/RUP process models. These are provisional since not enough calibration data has been collected on phase distributions to date.
The Waterfall phase distribution percentages in Table 45 are numbers from COCOMO 81 used in USC COCOMO II.2000. The percentages vary as product size varies from 2 KSLOC to 512 KSLOC. The values are taken from the COCOMO 81 Semidetached (average) mode provided in Table 6-8 of [Boehm 1981], except for the Transition phase. This phase was undefined in COCOMO 81 and is set equal to MBASE values in Table 46. The percentages from PRR to SWAR add up to 100%. The percentages for Plans and Requirements and Transition are in addition to the 100% of the effort and schedule quantities estimated by COCOMO II.
|
Table 4. Waterfall Phase Distribution Percentages |
||
|
Phase (end points) |
Effort% |
Schedule% |
|
Plans and Requirements (LCCR-PRR) |
7 (2-15) |
16-24 (2-30) |
|
Product Design (PRR-PDR) Programming (PDR-UTC) Detailed Design (PDR-CDR) Code and Unit Test (CDR-UTC) Integration and Test (UTC-SWAR) |
17 64-52 27-23 37-29 19-31 |
24-28 56-40 20-32 |
|
Transition (SWAR-SAR) |
12 (0-20) |
12.5 (0-20) |
The MBASE phase distribution percentages in Table 46 are chosen to be consistent with those provided for the Rational RUP in [Royce 1998] and [Kruchten 1999]. They are rescaled to match the COCOMO II definition that 100% of the development effort is done in the Elaboration and Construction phases (between the LCO and IOC milestones, for which most calibration data is available). The corresponding figures for the RUP development cycle are also provided in Table 46.
|
|
MBASE |
RUP |
||
|
Phase (end points) |
Effort% |
Schedule% |
Effort% |
Schedule% |
|
Inception (IRR to LCO) |
6 (2-15) |
12.5 (2-30) |
5 |
10 |
|
Elaboration (LCO to LCA) |
24 (20-28) |
37.5 (33-42) |
20 |
30 |
|
Construction (LCA to IOC) |
76 (72-80) |
62.5 (58-67) |
65 |
50 |
|
Transition (IOC to PRR) |
12 (0-20) |
12.5 (0-20) |
10 |
10 |
|
Totals: |
118 |
125 |
100 |
100 |
The effort and schedule distributions in the Waterfall model vary somewhat by size, primarily reflecting the amount of integration and test required. But the major variations in both the Waterfall model and MBASE/RUP phase effort and schedule quantities come in the phases outside the core development phases (Plans & Requirements and Transition for Waterfall; Inception and Transition for MBASE/RUP).
These large variations are the main reason that the main COCOMO II development estimates do not cover these outer phases (the other strong reason is that calibration data is scanty for the outer phases).
At this time, there is no convenient algorithm for determining whether your Inception phase effort will be nearer to 2% than 15% and Inception phase schedule will be nearer to 2% than 30% of the COCOMO II development cost estimates. The best we can offer at this time is Table 47, which identifies the primary effort and schedule drivers for the Inception and Transition phases.
These are presented in descending order of their effect on Inception phase effort and schedule, and as well as possible in ascending order of their corresponding effect on the Transition phase.
|
Table 6. Inception and Transition Phase Effort and Schedule Drivers |
||
|
Factor |
Inception |
Transition |
|
1. Complexity of LCO issues needing resolution |
Very Large |
Small |
|
2. System involves major changes in stakeholder roles and responsibilities |
Very Large |
Large |
|
3. Technical risk level |
Large |
Some |
|
4. Stakeholder trust level |
Large |
Considerable |
|
5. Heterogeneous stakeholder communities: Expertise, task nature, language, culture, infrastructure |
Large |
Large |
|
6. Hardware/software integration |
Large |
Large |
|
7 Complexity of transition from legacy system |
Considerable |
Large |
|
8. Number of different installations, classes of installation |
Some |
Very Large |
|
Note: Order of ratings – Small, Some, Considerable, Large, Very Large |
||
For example, on Factor 1, the stakeholders might enter the Inception phase with a very strong consensus that they wish to migrate some well-defined existing capabilities to a highly feasible client-server architecture. In this case, one could satisfy the LCO criteria with roughly 2% each of the development effort and schedule. On the other hand, if the stakeholders entered the Inception phase with strongly conflicting positions on desired capabilities, priorities, infrastructure, etc., it could take up to 15% of the development effort and 30% of the development schedule to converge to a stakeholder-consensus LCO package.
However, these differences would have a relatively low effect on the amount of effort and schedule it would take to transition the system as defined by the LCO. So the baseline Transition phase percentages of 12% added effort and 12.5% added schedule would be reasonable initial values to use.
Some of the Inception issues might persist into the Elaboration phase; such persisting issues are the main source of the variations in relative effort and schedule between the Elaboration and Construction phases shown in Table 46. Thus, if you estimate 30% added Inception schedule to achieve a difficult LCO consensus, you may wish to adjust the Elaboration schedule upward from 37.5% to something like 42%. Factors like your COCOMO II TEAM rating would provide additional total effort and schedule to divide between Elaboration and Construction.
In some cases, a factor can have a strong effect on both the Inception and Transition phases. Factor 2 is an example: if the system’s effects involve changes in stakeholder roles and responsibilities (e.g., turf, control, power), the amount of effort and schedule will be increased significantly both in negotiating the changes and implementing them.
Some additional sources of variation in phase distributions are deferred for later versions of COCOMO II. These include phase-dependent effort multipliers (as in Detailed COCOMO 81); effects of language level (reduced Construction effort for very high level languages); and effects of optimizing one’s project on development cost, schedule, or quality.
Figure 5 shows the Waterfall and MBASE phases for distribution of estimated effort. The Waterfall phase distributions are adapted from those in [Boehm 1981; Table 6-8]. The figure shows that distribution of effort varies by size of the product and the size exponent, E. The size exponent E corresponds to the three modes in COCOMO 81. Note that the effort distribution for a small project with a low value for E has the most effort in the Code and Unit Test phase. The top line shows this condition. A large project with a value of E has the most effort concentrated in the Integration and Test phase. This is shown by the bottom line. These distributions of effort are for a Waterfall model project where the development is done in a single sequence through the phases.
Figure
2.
Effort Distribution

The MBASE distribution of effort is taken from Table 46. The distribution of effort in the table is 72 to 80 % for the Construction phase which includes Detailed Design, Code and Unit Test, and Integration and Test. The shaded areas in Figure 5 are approximations of the distribution of the Construction effort.
Contrast the Waterfall distributions with the MBASE/RUP distributions. MBASE/RUP emphasizes planning up front and smaller, repeated iterations to develop the product. This makes the distribution of effort less dependent on size and scale factors. The iterative approach also starts the product integration earlier reducing large-system integration gridlock that can occur if integration is left till the last step (as in the Waterfall model).
Figure 6 shows the Waterfall and MBASE phase distribution of estimated schedule. The waterfall distributions are taken from [Boehm 1981; Table 6-8]. As with effort discussed above, schedule varies with size and the scale factor. The two lines bound the range of Waterfall schedule distribution showing a small easy project and a large difficult project.
The MBASE schedule distribution is taken from Table 46. The shaded areas show the range of distribution for each phase.
Figure
3.
Distribution of Schedule

The COCOMO II Waterfall model estimates effort for the following eight major activities [Boehm 1981; Table 4-2]:
· Requirements Analysis: Determination, specification, review, and update of software functional, performance, interface, and verification requirements.
· Product Design: Determination, specification, review, and update of hardware-software architecture, program design, and database design.
· Programming: Detailed design, code, unit test, and integration of individual computer program components. Includes programming personnel planning, tool acquisition, database development, component-level documentation, and intermediate level programming management.
· Test Planning: Specification, review, and update of product test and acceptance test plans. Acquisition of associated test drivers, test tools, and test data.
· Verification and Validation: Performance of independent requirements validation, design V & V, product test, and acceptance test. Acquisition of requirements and design V & V tools.
· Project Office Functions: Project-level management functions. Includes project-level planning and control, contract and subcontract management, and customer interface.
· Configuration Management and Quality Assurance: Configuration management includes product identification, change control, status accounting, operation of program support library, development and monitoring of end item acceptance plan. Quality assurance includes development and monitoring of project standards, and technical audits of software products and processes.
· Manuals: Development and update of users’ manuals, operators’ manuals, and maintenance manuals.
When the COCOMO II model is used to estimate effort, the estimated effort can be distributed across the major activities. Section 6.5 provides the percentage distributions of activity within each phase.
The COCOMO II Waterfall and MBASE/RUP activity distributions
are defined in more detail via work breakdown structures. Table 48 shows a work breakdown structure
outline adapted from [Boehm 1981; Figure 4-6B]. This WBS excludes the
requirements-related activities done up to SRR.
|
Table 7. Software Activity Work Breakdown Structure |
|
1. Management 1.1. Cost, schedule, performance management 1.2. Contract management 1.3. Subcontract management 1.4. Customer interface 1.5. Branch office management 1.6. Management reviews and audits |
|
2. System Engineering 2.1. Software Requirements 2.1.1. Requirements update 2.2. Software product design 2.2.1. Design 2.2.2. Design V & V 2.2.3. Preliminary design review 2.2.4. Design update 2.2.5. Design tools 2.3. Configuration management 2.3.1. Program support library 2.4. End item acceptance 2.5. Quality assurance 2.5.1. Standards |
|
3. Programming 3.1. Detailed design 3.2. Code and unit test 3.3. Integration |
|
4. Test and Evaluation 4.1. Product test 4.1.1. Plans 4.1.2. Procedures 4.1.3. Test 4.1.4. Reports 4.2. Acceptance test 4.2.1. Plans 4.2.2. Procedures 4.2.3. Test 4.2.4. Reports 4.3. Test support 4.3.1. Test beds 4.3.2. Test tools 4.3.3. Test data |
|
5. Data 5.1. Manuals |
This section defines phase and activity distribution estimators for projects using the life-cycle model provided by USC’s Model-Based (System) Architecting and Software Engineering (MBASE) approach and the Rational Unified Process (RUP). Both MBASE and RUP use the same phase definitions and milestones. MBASE has a more explicit emphasis on a stakeholder win-win approach to requirements determination and management. RUP accommodates such an approach but more as an option.
In developing these estimators, we have tried to maintain strong consistency with the published Rational phase and activity distributions in [Royce 1998; Kruchten 1999; Jacobson et al. 1999], and with the published anchor point/MBASE phase boundary definitions in [Boehm 1996, Boehm-Port 1999]. We have iterated and merged drafts of the estimators and definitions with Rational.
Our main sources of information on the Rational phase and activity distributions are:
The common table of default estimators of effort and schedule distribution percentages by phase on page 148 of Royce, page 118 of Kruchten, and page 335 of Jacobson et al.
The default estimators of total project activity distribution percentages in Table 10-1, page 148 of Royce. These in turn draw on the definitions of the activity categories in Royce’s Life Cycle Phase Emphases (Table 8-1, page 120) and Default Work Breakdown Structure --WBS-- (Figure 10-2, pages 144-145).
We and Rational agree that these and the COCOMO table values below cannot fit all project situations, and should be considered as draft values to be adjusted via context and judgement to fit individual projects. We have research activities underway to provide stronger guidance on the factors affecting phase and activity distributions.
Thus, we have begun with the overall phase and activity distributions in [Royce 1998] and used these to develop a set of default MBASE/RUP phase and activity distributions for use in COCOMO II as a counterpart to those provided for the waterfall model. In the process, we found the need to elaborate a few of the activity-category definitions in Royce’s Figure 10-2 (e.g., including configuration management within Environment; adding stakeholder coordination as a Management activity and stakeholder requirements negotiation as a Requirements activity; and including explicit Transition Plan and Evolution Plan activities in Deployment). We also modified a few definitions and allocations (using “evolution” in place of “maintenance;” splitting “Business case development” and “Business case analysis” between Management and Assessment).
For comparison, we have reproduced Royce’s WBS as Table 49 and provided the counterpart COCOMO II WBS as Table 50. We have also orthogonalized the WBS organization in Table 50 (e.g., for each phase X, the planning WBS element is AXA and the control element is AXB), and provided more explicit categories corresponding to the Level 2 and 3 project-oriented Key Process Areas in the SEI Capability Maturity model. An exception is Software Quality Assurance, where we agree with Royce that all activities and all people are involved in SQA, and that a separate WBS element for QA is inappropriate.
|
Table 8. Rational Unified Process Default Work Breakdown Structure [Royce 1998] |
|
A Management AA Inception phase management AAA Business case development AAB Elaboration phase release specifications AAC Elaboration phase WBS baselining AAD Software development plan AAE Inception phase project control and status assessments AB Elaboration phase management ABA Construction phase release specifications ABB Construction phase WBS baselining ABC Elaboration phase project control and status assessments AC Construction phase management ACA Deployment phase planning ACB Deployment phase WBS baselining ACC Construction phase project control and status assessments AD Transition phase management ADA Next generation planning ADB Transition phase project control and status assessments |
|
B Environment BA Inception phase environment specification BB Elaboration phase environment baselining BBA Development environment installation and administration BBB Development environment integration and custom toolsmithing BBC SCO database formulation BC Construction phase environment maintenance BCA Development environment installation and administration BCB SCO database maintenance BD Transition phase environment maintenance BDA Development environment maintenance and administration BDB SCO database maintenance BDC Maintenance environment packaging and transition |
|
C Requirements CA Inception phase requirements development CAA Vision specification CAB Use case modeling CB Elaboration phase requirements baselining CBA Vision baselining CBB Use case model baselining CC Construction phase requirements maintenance CD Transition phase requirements maintenance |
|
D Design DA Inception phase architecture prototyping DB Elaboration phase architecture baselining DBA Architecture design modeling DBB Design demonstration planning and conduct DBC Software architecture description DC Construction phase design modeling DCA Architecture design model maintenance DCB Component design modeling DD Transition phase design maintenance |
|
E Implementation EA Inception phase component prototyping EB Elaboration phase component implementation EBA Critical component coding demonstration integration EC Construction phase component implementation ECA Initial release(s) component coding and stand-alone testing ECB Alpha release component coding and stand-alone testing ECC Beta release component coding and stand-alone testing ECD Component maintenance ED Transition phase component maintenance |
|
F Assessment FA Inception phase assessment planning FB Elaboration phase assessment FBA Test modeling FBB Architecture test scenario implementation FBC Demonstration assessment and release descriptions FC Construction phase assessment FCA Initial release assessment and release description FCB Alpha release assessment and release description FCC Beta release assessment and release description FD Transition phase assessment FDA product release assessment and release descriptions |
|
G Deployment GA Inception phase deployment planning GB Elaboration phase deployment planning GC Construction phase deployment GCA User manual baselining GD Transition phase deployment GDA Product transition to user |
|
Acronyms: SCO – Software Change Order WBS – Work Breakdown Structure |
|
Table 9. COCOMO II MBASE/RUP Default Work Breakdown Structure |
|
A Management AA Inception phase management AAA Top-level Life Cycle Plan (LCO version of LCP) AAB Inception phase project control and status assessments AAC Inception phase stakeholder coordination and business case development AAD Elaboration phase commitment package and review (LCO package preparation and ARB review) AB Elaboration phase management ABA Updated LCP with detailed Construction plan (LCA version of LCP) ABB Elaboration phase project control and status assessments ABC Elaboration phase stakeholder coordination and business case update ABD Construction phase commitment package and review (LCA package preparation and ARB review) AC Construction phase management ACA Updated LCP with detailed Transition and Maintenance plans ACB Construction phase project control and status assessments ACC Construction phase stakeholder coordination ACD Transition phase commitment package and review (IOC package preparation and PRB review) AD Transition phase management ADA Updated LCP with detailed next-generation planning ADB Transition phase project control and status assessments ADC Transition phase stakeholder coordination ADD Maintenance phase commitment package and review (PR package preparation and PRB review) |
|
B Environment and Configuration Management (CM) BA Inception phase environment/CM scoping and initialization BB Elaboration phase environment/CM BBA Development environment installation and administration BBB Elaboration phase CM BBC Development environment integration and custom toolsmithing BC Construction phase environment/CM evolution BCA Construction phase environment evolution BCB Construction phase CM BD Transition phase environment/CM evolution BDA Construction phase environment evolution BDB Transition phase CM BDC Maintenance phase environment packaging and transition |
|
C Requirements CA Inception phase requirements development CAA Operational Concept Description and business modeling (LCO version of OCD) CAB Top-level System and Software Requirements Definition (LCO version of SSRD) CAC Initial stakeholder requirements negotiation CB Elaboration phase requirements baselining CBA OCD elaboration and baselining (LCA version of OCD) CBB SSRD elaboration and baselining (LCA version of SSRD) CC Construction phase requirements evolution CD Transition phase requirements evolution |
|
D Design DA Inception phase architecting DAA Top-level System and Software Architecture Description (LCD version of SSAD) DAB Evaluation of candidate COTS components DB Elaboration phase architecture baselining DBA SSAD elaboration and baselining DBB COTS integration assurance and baselining DC Construction phase design DCA SSAD evolution DCB COTS integration evolution DCC Component design DD Transition phase design evolution |
|
E Implementation EA Inception phase prototyping EB Elaboration phase component implementation EBA Critical component implementation EC Construction phase component implementation ECA Alpha release component coding and stand-alone testing ECB Beta release (IOC) component coding and stand-alone testing ECC Component evolution ED Transition phase component evolution |
|
F Assessment FA Inception phase assessment FAA Initial assessment plan (LCO version; part of SDP) FAB Initial Feasibility Rationale Description (LCO version of FRD) FAC Inception phase element-level inspections and peer reviews FAD Business case analysis (part of FRD) FB Elaboration phase assessment FBA Elaboration of assessment plan (LCA version; part of SDP) FBB Elaboration of feasibility rationale (LCA version of FRD) FBC Elaboration phase element-level inspections and peer reviews FBD Business case analysis update FC Construction phase assessment FCA Detailed test plans and procedures FCB Evolution of feasibility rationale FCC Construction phase element-level inspections and peer reviews FCD Alpha release assessment FCE Beta release (IOC) assessment FD Transition phase assessment |
|
G Deployment GA Inception phase deployment planning (LCO version; part of SDP) GB Elaboration phase deployment planning (LCA version; part of SDP) GC Construction phase deployment planning and preparation GCA Transition plan development GCB Evolution plan development GCC Transition preparation GD Transition phase deployment |
|
Acronyms: ARB -- Architecture Review Board CM -- Configuration Management COTS -- Commercial-Off-The-Shelf FRD -- Feasibility Rationale Description IOC -- Initial Operational Capability milestone LCA -- Life Cycle Architecture milestone LCO -- Life Cycle Objectives milestone LCP -- Life Cycle Plan OCD -- Operational Concept Description PR -- Product Release milestone PRB -- Product Review Board SSAD -- System and Software Architecture Description SSRD -- System and Software Requirements Definition |
Tables 51 through 54, adapted from [Boehm 1981; Tables 7-1, 7-2, 7-3], show the distribution of eight major activities (discussed in Section 6.4.1) across the estimated project effort per phase. The activity distribution values are interpolated for projects that are between values in the table.
For example, a project with size 128 KSLOC and an exponent of 1.12 would spend 28% of its effort in Integration and Test, see Table 54 Overall Phase Percentage row. From Table 54 we see that the Requirement Analysis activity takes 2.5% of the 28%, Product Design takes 5% of the 28%, Programming takes 39% of the 28%, and so on. We see that the activity tables break up the estimated effort for a phase into the different activities that occur during the phase.
|
Table 10.
Plans and
Requirements Activity Distribution |
||||||||||||||||||
|
|
Size Exponent |
|||||||||||||||||
|
|
E = 1.05 |
E = 1.12 |
E = 1.20 |
|||||||||||||||
|
Size: |
S |
I |
M |
L |
S |
I |
M |
L |
VL |
S |
I |
M |
L |
VL |
|
||||
|
Overall Phase
Percentage |
|
|
6 |
|
7 |
7 |
7 |
7 |
7 |
8 |
8 |
8 |
8 |
8 |
|
||||
|
Requirements
Analysis |
|
|
46 |
|
48 |
47 |
46 |
45 |
44 |
50 |
48 |
46 |
44 |
42 |
|
||||
|
Product Design |
|
|
20 |
|
16 |
16.5 |
17 |
17.5 |
18 |
12 |
13 |
14 |
15 |
16 |
|
||||
|
Programming |
|
|
3 |
|
2.5 |
3.5 |
4.5 |
5.5 |
6.5 |
2 |
4 |
6 |
8 |
10 |
|
||||
|
Test Planning |
|
|
3 |
|
2.5 |
3 |
3.5 |
4 |
4.5 |
2 |
3 |
4 |
5 |
6 |
|
||||
|
V&V |
|
|
6 |
|
6 |
6.5 |
7 |
7.5 |
8 |
6 |
7 |
8 |
9 |
10 |
|
||||
|
Project Office |
|
|
15 |
|
15.5 |
14.5 |
13.5 |
12.5 |
11.5 |
16 |
14 |
12 |
10 |
8 |
|
||||
|
CM/QA |
|
|
2 |
|
3.5 |
3 |
3 |
3 |
2.5 |
5 |
4 |
4 |
4 |
3 |
|
||||
|
Manuals |
|
|
5 |
|
6 |
6 |
5.5 |
5 |
5 |
7 |
7 |
6 |
5 |
5 |
|
||||
|
S: 2 KSLOC; I: 8
KSLOC; M: 32 KSLOC; L: 128 KSLOC; VL: 512 KSLOC |
|
||||||||||||||||||
|
Table 11.
Product Design
Activity Distribution |
||||||||||||||||||
|
|
Size Exponent |
|||||||||||||||||
|
|
E = 1.05 |
E = 1.12 |
E = 1.20 |
|||||||||||||||
|
Size: |
S |
I |
M |
L |
S |
I |
M |
L |
VL |
S |
I |
M |
L |
VL |
|
||||
|
Overall Phase
Percentage |
|
|
16 |
|
17 |
17 |
17 |
17 |
17 |
18 |
18 |
18 |
18 |
18 |
|
||||
|
Requirements
Analysis |
|
|
15 |
|
12.5 |
12.5 |
12.5 |
12.5 |
12.5 |
10 |
10 |
10 |
10 |
10 |
|
||||
|
Product Design |
|
|
40 |
|
41 |
41 |
41 |
41 |
41 |
42 |
42 |
42 |
42 |
42 |
|
||||
|
Programming |
|
|
14 |
|
12 |
12.5 |
13 |
13.5 |
14 |
10 |
11 |
12 |
13 |
14 |
|
||||
|
Test Planning |
|
|
5 |
|
4.5 |
5 |
5.5 |
6 |
6.5 |
4 |
5 |
6 |
7 |
8 |
|
||||
|
V&V |
|
|
6 |
|
6 |
6.5 |
7 |
7.5 |
8 |
6 |
7 |
8 |
9 |
10 |
|
||||
|
Project Office |
|
|
11 |
|
13 |
12 |
11 |
10 |
9 |
15 |
13 |
11 |
9 |
7 |
|
||||
|
CM/QA |
|
|
2 |
|
3 |
2.5 |
2.5 |
2.5 |
2 |
4 |
3 |
3 |
3 |
2 |
|
||||
|
Manuals |
|
|
7 |
|
8 |
8 |
7.5 |
7 |
7 |
9 |
9 |
8 |
7 |
7 |
|
||||
|
S: 2 KSLOC; I: 8
KSLOC; M: 32 KSLOC; L: 128 KSLOC; VL: 512 KSLOC |
|
||||||||||||||||||
|
Table 12.
Programming
Activity Distribution |
|
||||||||||||||||||
|
|
Size Exponent |
|
|||||||||||||||||
|
|
E = 1.05 |
E = 1.12 |
E = 1.20 |
|
|||||||||||||||
|
Size: |
S |
I |
M |
L |
S |
I |
M |
L |
VL |
S |
I |
M |
L |
VL |
||||
|
Overall Phase
Percentage |
68 |
65 |
62 |
59 |
64 |
61 |
58 |
55 |
52 |
60 |
57 |
54 |
51 |
48 |
||||
|
Requirements
Analysis |
|
|
5 |
|
4 |
4 |
4 |
4 |
4 |
3 |
3 |
3 |
3 |
3 |
||||
|
Product Design |
|
|
10 |
|
8 |
8 |
8 |
8 |
8 |
6 |
6 |
6 |
6 |
6 |
||||
|
Programming |
|
|
58 |
|
56.5 |
56.5 |
56.5 |
56.5 |
56.5 |
55 |
55 |
55 |
55 |
55 |
||||
|
Test Planning |
|
|
4 |
|
4 |
4.5 |
5 |
5.5 |
6 |
4 |
5 |
6 |
7 |
8 |
||||
|
V&V |
|
|
6 |
|
7 |
7.5 |
8 |
8.5 |
9 |
8 |
9 |
10 |
11 |
12 |
||||
|
Project Office |
|
|
6 |
|
7.5 |
7 |
6.5 |
6 |
5.5 |
9 |
8 |
7 |
6 |
5 |
||||
|
CM/QA |
|
|
6 |
|
7 |
6.5 |
6.5 |
6.5 |
6 |
8 |
7 |
7 |
7 |
6 |
||||
|
Manuals |
|
|
5 |
|
6 |
6 |
5.5 |
5 |
5 |
7 |
7 |
6 |
5 |
5 |
||||
|
S: 2 KSLOC; I: 8
KSLOC; M: 32 KSLOC; L: 128 KSLOC; VL: 512 KSLOC |
||||||||||||||||||
|
Table 13.
Integration and
Test Activity Distribution |
|
||||||||||||||||||
|
|
Size Exponent |
|
|||||||||||||||||
|
|
E = 1.05 |
E = 1.12 |
E = 1.20 |
|
|||||||||||||||
|
Size: |
S |
I |
M |
L |
S |
I |
M |
L |
VL |
S |
I |
M |
L |
VL |
||||
|
Overall Phase
Percentage |
16 |
19 |
22 |
25 |
19 |
22 |
25 |
28 |
31 |
22 |
25 |
28 |
31 |
34 |
||||
|
Requirements
Analysis |
|
|
3 |
|
2.5 |
2.5 |
2.5 |
2.5 |
2.5 |
2 |
2 |
2 |
2 |
2 |
||||
|
Product Design |
|
|
6 |
|
5 |
5 |
5 |
5 |
5 |
4 |
4 |
4 |
4 |
4 |
||||
|
Programming |
|
|
34 |
|
33 |
35 |
37 |
39 |
41 |
32 |
36 |
40 |
44 |
48 |
||||
|
Test Planning |
|
|
2 |
|
2.5 |
2.5 |
3 |
3 |
3.5 |
3 |
3 |
4 |
4 |
5 |
||||
|
V&V |
|
|
34 |
|
32 |
31 |
29.5 |
28.5 |
27 |
30 |
28 |
25 |
23 |
20 |
||||
|
Project Office |
|
|
7 |
|
8.5 |
8 |
7.5 |
7 |
6.5 |
10 |
9 |
8 |
7 |
6 |
||||
|
CM/QA |
|
|
7 |
|
8.5 |
8 |
8 |
8 |
7.5 |
10 |
9 |
9 |
9 |
8 |
||||
|
Manuals |
|
|
7 |
|
8 |
8 |
7.5 |
7 |
7 |
9 |
9 |
8 |
7 |
7 |
||||
|
S: 2 KSLOC; I: 8
KSLOC; M: 32 KSLOC; L: 128 KSLOC; VL: 512 KSLOC |
||||||||||||||||||
The last two activity tables handle the situation where development or maintenance is performed as a level of effort. In other words, there is a fixed amount of staff that will be working on the project and the eight major activities are divided among the fixed staffing.
As an example, a maintenance project has 10 staff for 12 months (120 Person-Months), a size of 8 KSLOC, and an exponent of 1.20. From Table 56 we see that Requirements Analysis will consume 6% of the staff’s effort or 7.2 PM, Program Design will consume 11% of the staff’s effort or 13.2 PM, Programming will consume 39% of the staff’s effort or 46.8 PM, and so on.
|
Table 14.
Development
Activity Distribution |
||||||||||||||||||
|
|
Size Exponent |
|||||||||||||||||
|
|
E = 1.05 |
E = 1.12 |
E = 1.20 |
|||||||||||||||
|
Size: |
S |
I |
M |
L |
S |
I |
M |
L |
VL |
S |
I |
M |
L |
VL |
|
||||
|
Requirements
Analysis |
|
|
6 |
|
5 |
5 |
5 |
5 |
5 |
4 |
4 |
4 |
4 |
4 |
|
||||
|
Product Design |
|
|
14 |
|
13 |
13 |
13 |
13 |
13 |
12 |
12 |
12 |
12 |
12 |
|
||||
|
Programming |
48 |
47 |
46 |
45 |
45 |
45 |
44.5 |
44.5 |
44.5 |
42 |
43 |
43 |
44 |
45 |
|
||||
|
Test Planning |
|
|
4 |
|
4 |
4 |
4.5 |
5 |
5.5 |
4 |
4 |
5 |
6 |
7 |
|
||||
|
V&V |
10 |
11 |
12 |
13 |
11 |
12 |
13 |
13.5 |
14 |
12 |
13 |
14 |
14 |
14 |
|
||||
|
Project Office |
|
|
7 |
|
8.5 |
8 |
7.5 |
7 |
6.5 |
10 |
9 |
8 |
7 |
6 |
|
||||
|
CM/QA |
|
|
5 |
|
6.5 |
6 |
6 |
6 |
5.5 |
8 |
7 |
7 |
7 |
6 |
|
||||
|
Manuals |
|
|
6 |
|
7 |
7 |
6.5 |
6 |
6 |
8 |
8 |
7 |
6 |
6 |
|
||||
|
S: 2 KSLOC; I: 8
KSLOC; M: 32 KSLOC; L: 128 KSLOC; VL: 512 KSLOC |
|
||||||||||||||||||
|
Table 15.
Maintenance
Activity Distribution |
||||||||||||||||||
|
|
Size Exponent |
|||||||||||||||||
|
|
E = 1.05 |
E = 1.12 |
E = 1.20 |
|||||||||||||||
|
Size: |
S |
I |
M |
L |
S |
I |
M |
L |
VL |
S |
I |
M |
L |
VL |
|
||||
|
Requirements
Analysis |
|
|
7 |
|
6.5 |
6.5 |
6.5 |
6 |
6 |
6 |
6 |
6 |
5 |
5 |
|
||||
|
Product Design |
|
|
13 |
|
12 |
12 |
12 |
12 |
12 |
11 |
11 |
11 |
11 |
11 |
|
||||
|
Programming |
45 |
44 |
43 |
42 |
41.5 |
41.5 |
41 |
41 |
41 |
38 |
39 |
39 |
40 |
41 |
|
||||
|
Test Planning |
|
|
3 |
|
3 |
3 |
3.5 |
4 |
4.5 |
3 |
3 |
4 |
5 |
6 |
|
||||
|
V&V |
10 |
11 |
12 |
13 |
11 |
12 |
13 |
13.5 |
14 |
12 |
13 |
14 |
14 |
14 |
|
||||
|
Proect Office |
|
|
7 |
|
8.5 |
8 |
7.5 |
7 |
6.5 |
10 |
9 |
8 |
7 |
6 |
|
||||
|
CM/QA |
|
|
5 |
|
6.5 |
6 |
6 |
6 |
5.5 |
8 |
7 |
7 |
7 |
6 |
|
||||
|
Manuals |
|
|
10 |
|
11 |
11 |
10.5 |
10.5 |
10.5 |
12 |
12 |
11 |
11 |
11 |
|
||||
|
S: 2 KSLOC; I: 8
KSLOC; M: 32 KSLOC; L: 128 KSLOC; VL: 512 KSLOC |
|
||||||||||||||||||
Table 57 shows the resulting COCOMO II MBASE/RUP default phase and activity distribution values. The first two lines show the Rational and COCOMO II schedule percentages by phase. Their only difference is that the Rational percentages sum to 100% for the full set of Inception, Elaboration, Construction, and Transition phases (IECT), while COCOMO II counts the core Elaboration and Construction phases as 100%. This is done because the scope and duration of the Inception and Transition phases are much more variable, and because less data is available to calibrate estimation models for these phases. For COCOMO II, this means that the current model covering the Elaboration and Construction phases is considerably more accurate and robust than we could achieve with counterpart models that would include the Inception and/or Transition phases.
Lines 1 and 2 in Table 57 show the Rational and COCOMO II phase distributions for the project’s schedule in months. Lines 3 and 4 in Table 57 show the corresponding phase distributions for effort. The sum of the COCOMO II percentages for the total IECT project span is 125% for schedule and 118% for effort.
|
Table 16. COCOMO II MBASE/RUP Phase and Activity Distribution Values |
|
|||||||
|
|
|
Development |
|
Total |
Total |
|||
|
|
Inception |
Elaboration |
Construction |
Transition |
Royce |
COCOMO II |
Maintenance |
|
|
Rational Schedule |
10 |
30 |
50 |
10 |
100 |
|
|
|
|
COCOMO II Schedule |
12.5 |
37.5 |
62.5 |
12.5 |
|
125 |
|
|
|
Rational Effort |
5 |
20 |
65 |
10 |
100 |
|
|
|
|
COCOMO II Effort |
6 |
24 |
76 |
12 |
|
118 |
100 |
|
|
Activity % of phase / IECT |
100 |
100 |
100 |
100 |
118 |
100 |
||
|
Management |
14 |
12 |
10 |
14 |
12 |
13 |
11 |
|
|
Environment / CM |
10 |
8 |
5 |
5 |
12 |
7 |
6 |
|
|
Requirements |
38 |
18 |
8 |
4 |
12 |
13 |
12 |
|
|
Design |
19 |
36 |
16 |
4 |
18 |
22 |
17 |
|
|
Implementation |
8 |
13 |
34 |
19 |
29 |
32 |
24 |
|
|
Assessment |
8 |
10 |
24 |
24 |
29 |
24 |
22 |
|
|
Deployment |
3 |
3 |
3 |
30 |
6 |
7 |
8 |
|
Lines 6 to 12 in Table 57 show the default percentage of effort by activity for each of the MBASE/RUP phases. For example, the Management activities are estimated to consume 14% of the effort in the Inception phase, 12% in the Elaboration phase, 10% in Construction, and 14% in Transition. For the total IECT span, the Management activities consume
(14%)(6%) + (12%)(24%) + (10%)(76%) + (14%)(12%) = 13%
This sum is slightly larger but quite comparable to the IECT percentage of 12% derived from Royce’s Table 10-1. The WBS definitions in Tables 49 and 50 are sufficiently similar that the values in Table 57 can be applied equally well to both.
These values can be used to determine draft project staffing plans for each of the phases. For example, suppose there was a 100 KSLOC software system that had an estimated development effort of 466 PM and an estimated schedule of 26 months. From lines 2 and 4 of Table 57, we can compute the estimated schedule and effort of the Construction phase as:
Schedule: (26 Mo.) (.625) = 16.25 Mo.
Effort: (466 PM) (.76) = 354 PM
The average staff level of the Construction phase is thus:
354 PM/ 16.25 Mo. = 21.8 persons.
We can then use lines 6-12 of Table 57 to provide a draft estimate of what these 21.8 persons will be doing during the Construction phase. For example, the estimated average number of personnel performing Management activities is:
(21.8 persons) (.10) = 2.2 persons
Table 58 shows the full set of draft activity estimates for the Construction phase.
|
Table 17. Example Staffing Estimate for Construction Phase |
||
|
Activity |
Percentage |
Average Staff |
|
Total |
100 |
21.8 |
|
Management |
10 |
2.2 |
|
Environment |
5 |
1.1 |
|
Requirements |
8 |
1.7 |
|
Design |
16 |
3.5 |
|
Implementation |
34 |
7.4 |
|
Assessment |
24 |
5.2 |
|
Deployment |
3 |
0.7 |
These staffing estimates can be used for other purposes as well. When multiplied by associated average labor costs for activity categories, they can be used as starting points for project WBS and budget allocations, or for earned values associated with phase deliverables.
It is important to understand that these numbers are just
draft starting points for the actual numbers you use to manage your
project. Every project will have special
circumstances which should be considered in adjusting the draft values (see
also [Royce 1998; p. 218; Kruchten 1999; pp.118-119; Jacobson et al. 1999; p.
336]). For example, an ultra-reliable
product will have higher Assessment efforts and costs; a project with a stable
environment already in place will have lower up-front Environment efforts and
costs. The COCOMO II research agenda
includes activities to provide further guidelines for adjusting the phase and activity
distributions to special circumstances.
Even then, however, the estimated phase and activity distribution
numbers should be subject to critical review.
As with other COCOMO II estimates, the phase and activity distribution
estimates should be considered as a stimulus to thought, and not as a
substitute for thought.
COCOMO II’s definitions and assumptions are similar to those for COCOMO 81 [Boehm 1981; pp. 58-61], but with some differences. Here is a summary of similarities and differences.
1. Sizing. COCOMO 81 just used Delivered Source Instructions for sizing. COCOMO II uses combinations of Function Points (FP) and Source Lines of Code for the Early Design and Post-Architecture models, with counting rules in [IFPUG 1994] for FP and Table 63 for SLOC.
2. Development Periods Included. For the Waterfall process model, COCOMO II uses the same milestone end points (Software Requirements Review to Software Acceptance Review) as COCOMO 81. For the MBASE/RUP process model, COCOMO II uses the Life Cycle Objectives and Initial Operational Capability milestone as end points for counting effort and schedule. Details for both are in Section 6.2.
3. Project Activities Included. For the Waterfall process model, COCOMO II includes the same activities as did COCOMO 81. For the MBASE and RUP process models, the Work Breakdown Structures in Section 6.4 define the project activities included by phase. For all the models, all software development activities such as documentation, planning and control, and configuration management (CM) are included, while database administration is not. For all the models, the software portions of a hardware-software project are included (e.g., software CM, software project management) but general CM and management are not. Both models have add-on efforts for a front-end phase (Plans and Requirements for COCOMO 81; Inception for (MBASE/RUP). COCOMO II differs from COCOMO 81 in having add-on efforts for a back-end Transition phase, including conversion, installation, and training. As discussed in Section 6.3 the size of these add-on efforts can vary a great deal, and their effort estimates should be adjusted for particularly small or large add-on endeavors.
4. Labor categories included. COCOMO 81 and COCOMO II estimates both use the same definitions of labor categories included as direct-charged project effort vs. overhead effort. Thus, they include project managers and program librarians, but exclude computer center operators, personnel-department personnel, secretaries, higher management, janitors, and so on.
5. Dollar Estimates. COCOMO 81 and COCOMO II avoid estimating labor costs in dollars because of the large variations between organizations in what is included in labor costs, e.g. unburdened (by overhead cost), burdened, including pension plans, office rental, and profit margin. Person months are a more stable quantity than dollars given current inflation rates and international money fluctuations.
6. Person-month definition. A COCOMO PM consists of 152 hours of working time. This has been found to be consistent with practical experience with the average monthly time off because of holidays, vacation, and sick leave. To convert a COCOMO estimate in person-months to other units, use the following:
|
Person-hours: multiply by 152 |
|
Person-days: multiply by 19 |
|
Person-years: divide by 12 |
Some implementations, such as USC COCOMO II, provide an adjustable parameter for the number of person-hours per person-month. Thus, if you enter 137 (10% less) for this parameter, USC COCOMO II will increase your person-month estimate by 10%, and calculate an appropriately longer development schedule.