6.    COCOMO II: Assumptions and phase/activity distributions

6.1             Introduction

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.

6.2             Waterfall and MBASE/RUP Phase Definitions

6.2.1       Waterfall Model Phases and Milestones

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 1.         COCOMO II Waterfall Milestones

1.       Begin Plans and Requirements Phase.  (Completion of Life Cycle Concept Review - LCR)

§ Approved, validated system architecture, including basic hardware-software allocations.

§ Approved, validated concept of operation, including basic human-machine allocations.

§ Top-level life-cycle plan, including milestones, resources, responsibilities, schedules, and major activities.

2.       End Plans and Requirements Phase.  Begin Product Design Phase.  (Completion of Software Requirements Review - SRR)

§ Detailed development plan – detailed development milestone criteria, resource budgets, organization, responsibilities, schedules, activities, techniques, and products.

§ Detailed usage plan – counterparts of the development plan items for training, conversion, installation, operations, and support.

§ Detailed product control plan – configuration management plan, quality assurance plan, overall V&V plan (excluding detailed test plans).

§ Approved, validated software requirements specifications – functional, performance, and interface specifications validated for completeness, consistency, testability, and feasibility.

§ Approved (formal or informal) development contract – based on the above items.

3.       End Product Design Phase.  Begin Detailed Design Phase.  (Completion of Product Design Review - PDR)

§ Verified software product design specification.

§ Program component hierarchy, control and data interfaces through unit level*.

§ Physical and logical data structure through field level.

§ Data processing resource budgets (timing, storage, accuracy).

§ Verified for completeness, consistency, feasibility, and traceability to requirements.

§ Identification and resolution of all high-risk development issues.

§ Preliminary integration and test plan, acceptance test plan, and user’s manual.

4.       End Detailed Design Phase.  Begin Code and Unit Test Phase.  (Completion of design walkthrough or Critical Design Review for unit - CDR)

§ Verified detailed design specification for each unit.

§ For each routine (< 100 source instructions) within the unit, specifies name, purpose, assumptions, sizing, calling sequence, error exits, inputs, outputs, algorithms, and processing flow.

§ Data base description through parameter/character/bit level.

§ Verified for completeness, consistency, and traceability to requirements and system design specifications and budgets.

§ Approved acceptance test plan.

§ Complete draft of integration and test plan and user’s manual.

5.       End Code and Unit Test Phase.  Begin Integration and Test Phase.  (Satisfaction of Unit Test criteria for unit - UTC)

§ Verification of all unit computations, using not only nominal values but also singular and extreme values.

§ Verification of all unit input and output options, including error messages.

§ Exercise of all executable statements and all branch options.

§ Verification of programming standards compliance.

§ Completion of unit-level, as-built documentation.

6.       End Integration and Test Phase.  Begin Implementation Phase.  (Completion of Software Acceptance Review - SAR)

§ Satisfaction of software acceptance test.

§ Verification of satisfaction of software requirements.

§ Demonstration of acceptable off-nominal performance as specified.

§ Acceptance of all deliverable software products: reports, manuals, as-built specifications, data bases.

7.       End Implementation Phase.  Begin Operations and Maintenance Phase.  (Completion of System Acceptance Review)

§ Satisfaction of system acceptance test.

§ Verification of satisfaction of system requirements.

§ Verification of operational readiness of software, hardware, facilities, and personnel.

§ Acceptance of all deliverable system products: hardware, software, documentation, training, and facilities.

§ Completion of all specified conversion and installation activities.

8.       End Operations and Maintenance Phase (via Phaseout).

§ Completion of all items in phaseout plan: conversion, documentation, archiving, transition to new system(s).

* A software unit performs a single well-defined function, can be developed by one person, and is typically 100 to 300 source instructions in size.

6.2.2       MBASE and Rational Unified Process (RUP)  Phases and Milestones

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.

 

 

 

 

 

Figure 1.                   Life Cycle Phases

6.3             Phase Distribution of Effort and Schedule

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.

Table 5.         MBASE and RUP Phase Distribution Percentages

 

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

6.3.1       Variations in Effort and Schedule Distributions

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.

6.3.2       Distribution of Effort Across Life Cycle Phases

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).

 

6.3.3       Distribution of Schedule Across Life Cycle Phases

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

6.4             Waterfall and MBASE/RUP Activity Definitions

6.4.1       Waterfall Model Activity Categories

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.

6.4.2        Waterfall Model Work Breakdown Structure

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

 

6.4.3       MBASE/RUP Model Activity Categories

6.4.3.1              Background

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.

6.4.3.2              Phase and Activity Category Definitions

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

6.5             Distribution of Effort Across Activities

6.5.1       Waterfall Model Activity Distribution

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

 

6.5.2       MBASE/RUP Model Activity Distribution Values

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.

6.6             Definitions and Assumptions

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.