COCOMOII/Chapter 5/Boehm et al. - 2 -

CHAPTER 5

Emerging extensions

5.1 Applications Composition: The Application Point Model

As discussed under future trends in Chapter 1, a rapidly increasing number of projects are being developed using Applications Composition methods. These methods rely on having an Integrated Computer-Aided Software Engineering (ICASE) environment to expedite product development. ICASE environments generally include the following capabilities:

  1. An applications framework (e.g. client-server or peer-to-peer message-passing) with middleware to integrate and manage the execution of the applications components.
  1. A set of common utilities, such as a graphic user interface (GUI) builder, a database management system, and a networking support package.
  1. Frequently, a domain architecture and set of reusable domain components, and a repository for managing and accessing the components and other reusable assets.
  1. Development tools for design, Construction , integration, and test.

Not all applications can be developed this way. But for applications which fit the ICASE capabilities, products traditionally requiring 10-20 people for 1-2 years can be developed by 2-6 people in 2-6 months.

Applications composition products clearly cannot be sized in source lines of code (SLOC). Capabilities such as GUI builders and visual programming systems make the concept of SLOC largely irrelevant. To a lesser degree, sizing metrics such as function points (FP) are too low-level to match the degree of generality and variability often used to scope an applications composition project in its early stages. Often, the product goes through several GUI iterations and is well along toward completion before such quantities as the number of inputs or queries can be estimated well.

In searching for an appropriate sizing metric for applications composition, we found a highly attractive metric called Object Points, developed by Banker, Kauffman, and Kumar for estimation of ICASE-based financial applications. They used the number of screens, reports, and third-generation language (3GL) modules for their basic sizing primitives. They followed the function point convention of weighting these by complexity and adding them together to obtain an overall size metric, which they then adjusted for reuse.

5.1.1 Object Point Data and Experiments

In [Banker et al., 1991], they analyzed 19 applications composition projects developed over 2 years with an ICASE environment in a banking organization. They found that Object Points correlated with reuse-adjusted effort about as well as Function Points (the R-squared values were 0.73 for OP's and 0.75 for FP's). They also found that productivity went up significantly between Year 1 and Year 2, as indicated by the NOP/PM (New Object Points per person-month) data in Table 5.1. In performing a further regression analysis across the year 1 and year 2 projects, they found that OP’s accounted for the productivity gain more accurately than did FP’s. Note also that the project efforts tend to be relatively small; none is higher than 72 person-months (PM). New OP’s (NOP) are total OP’s adjusted for reuse.

[Insert Table 5.1]

A subsequent statistically designed experiment [Kauffman and Kumar 1993] involved four experienced project managers using Object Points and Function Points to estimate the effort required on two completed projects (3.5 and 6 actual person-months), based on project descriptions of the type available at the beginning of such projects. The experiment found that Object Points and Function Points produced comparably accurate results (slightly more accurate with Object Points, but not statistically significant). From a usage standpoint, the average time to produce an Object Point estimate was about 47% of the corresponding average time for Function Point estimates. Also, the managers considered the Object Point method easier to use (both of these results were statistically significant).

5.1.2 Application Point Estimation Procedure

In reviewing these studies, we felt that their OP’s were a better match than FP’s for estimating Applications Composition project effort. We adopted their OP counting rules, but made two changes to their approach:

  1. We added rating scales for determining a project’s productivity rate in NOP/PM, in terms of the ICASE system’s maturity and capability, and the developers’ experience and capability in using the ICASE environment. As the year 1 projects in Table 5.1 had an average productivity of 7 NOP/PM (and an average maturity and experience of 6 months: the ICASE tool was under Construction and the developers were new to its use), while the year 2 projects had an average productivity of 25 NOP/PM and an average maturity and experience of 18 months, we used these as the Low and High levels in rating scale for determining the productivity rate.
  1. We changed the name from Object Points to Application Points, to avoid confusion with a number of sizing metrics for more conventional object-oriented applications using such features as class affiliation, inheritance, encapsulation, and message passing [Chidamber-Kemerer, 1994; Henderson-Sellers, 1996].

Figure 5.1 presents the baseline COCOMOII Application Point procedure for estimating the effort involved in Application Composition and prototyping projects. It is a synthesis of the procedure in Appendix B.3 of [Kauffman-Kumar, 1993] and the productivity data from the nineteen project data points in [Banker et al. 1991]. Definitions of terms in figure 5.1 are as follows:

·  NOP: New Object Points (Object Point count adjusted for reuse).

·  srvr: number of server (mainframe or equivalent) data tables used in conjunction with the SCREEN or REPORT.

·  clnt: number of client (personal workstation) data tables used in conjunction with the SCREEN or REPORT.

·  %reuse: the percentage of screens, reports, and 3GL modules reused from previous applications, prorated by degree of reuse.

Analogous definitions of Total Screen Views and Total Report Sections can be applied to a non client-server application.

[Insert Figure 5.1]

The Application Point procedure can be applied fairly straightforwardly by hand. Thus, for example, if your application has 10 medium-complexity screens, 8 medium-complexity reports, and 6 3GL modules, your total application-point size is:

2*10 + 5*8 + 10*6 = 20 + 40 + 60 = 120AP

If you expect 25% reuse, your new application-point size is:

(120AP)(.75) = 90 NAP

If you have a relatively mature and capable (High-rated) ICASE environment and a relatively immature and less capable (Low-rated) team in ICASE usage, your average rating is Nominal, and your expected productivity rate will 13 NAP/PM. Your estimated project effort is thus:

90 NAP/13 NAP/PM @ 7PM

5.1.3 Application Point Estimation Accuracy and Maturity

Table 5.2 summarizes the accuracy of the Application Point procedure in estimating the effort for the 19 projects in Table 5.1.

[Insert Table 5.2]

Even on the calibration data, the percentage of estimates within 30% of the actuals (Pred (.30)) is less than 50% for the full sample. However, the percentage of estimates within a factor of 2 of the actuals (Pred (X2)) is 89% for the full sample. Thus, it appears reasonable to associate a factor of 2 with the optimistic and pessimistic range limits for an Application Point estimate.

We have not been able to collect much further data on applications composition projects. Thus, at this time, we prefer to present Application Points as an emerging extension of COCOMOII. It is relatively easy to apply by hand, and is worth using experimentally on applications composition projects, even though there is considerable more work to be done on detailed counting rules and cost drivers (see Figure 5.1). Also, there are other possible approaches being experimentally applied such as Enhanced Object Points [Stensrud, 1998] and Unified Modeling Language use cases. Our experience so far with use cases is that they still have a very wide range of interpretation, which makes it difficult for them to be used confidently as a sizing metric outside a relatively uniform group of applications and practitioners.

5.2 COPSEMO

The COnstructive Phased Schedule and Effort MOdel (COPSEMO) was initially developed as a base for the COnstructive RAD MOdel (CORADMO), described in a later section of this chapter. CORADMO required a distribution of schedule and effort over the life cycle phases as described in Chapter 1. COPSEMO also was needed to compensate for the inadequacy of the waterfall process model that is used in COCOMOII for both system level evolution and smaller, shorter development projects. While actually developed as part of the early CORADMO models, COPSEMO is now recognized as a separate, independent model that will be used as the basis for other COCOMOII model extensions.

The need to accommodate smaller, shorter projects seen in the 90's manifested itself in the growing application of COCOMO to business and information system that evolve at the system level, often with independently managed projects for each area of evolution. Also, the advent of the SEI's CMM and its application to ALL projects within an organization following the SEI's process improvement paradigms, increased the visibility of the numerous small development projects in government contractors such as Independent Research and Development (IRAD) or Contracted Research and Development (CRAD). These smaller, shorter duration projects require a new mathematical formula to calculate the duration of the project; COCOMOII’s duration calculations often would be wildly unreasonable for projects with under-two person years of effort.

The more modern lifecycle models like MBASE/RUP (Model-Based [System] Architecting and Software Engineering and Rational Unified Process), as described in Chapter 1, have differently defined phases outside of COCOMO's original main focus which is used to calculate effort, schedule and staffing. COCOMO's main focus is product design, programming, and integration and test in the waterfall lifecycle model, also called Elaboration and Construction in the MBASE/RUP lifecycle model. Phases outside COCOMO's original focus, Plans and Requirements and Operations and Maintenance in the waterfall lifecycle model, are called Inception and transition in the MBASE/RUP lifecycle model.

CORADMO has drivers that impact the Inception phase schedule and effort. Thus it became necessary to distribute or project the COCOMOII calculated effort and schedule over the MBASE/RUP phases. As mentioned in Chapter 1, there are no convenient algorithms for either the distribution of the COCOMOII effort and schedule over Elaboration and Construction , nor do they exist for the projection of COCOMOII calculated effort and schedule over Inception or transition. As a result, the current implementations of COPSEMO simply allow the users to specify to the percentage allocations for both effort and schedule for the four phases.

Sections 5.2.1 through 5.2.4 describe and illustrate the various aspects of COPSEMO: further explanation of the phase end points defined in Appendix A; an alternative cost-schedule relationship for schedule-intensive small projects; an overview of the model algorithms; and a description of the spreadsheet implementation with examples of use. Section 5.2.5 describes an alternative approach for exploring effort and schedule phase distributions: a system dynamic's model of the software development process.

5.2.1 Background

Significant variations in development life cycles have arisen over the twenty years since COCOMO was originally conceived. One of the more recent models for lifecycles is the MBASE model which shares significant features with the Rational Unified Process's model. At the same time, COCOMO is being asked to provide estimates for smaller and smaller projects, in both staff and duration, including those using Rapid Application Development (RAD) techniques. COCOMO was originally conceived for largish projects. However, the COCOMOII model is calibrated for projects down to 2000 lines of code. But, for that 2000 SLOC project, it estimates a 6.3 person-month effort (assuming all nominal ratings for the drivers) over 6.6 months with a staff of 1, which is clearly unreasonable for modern lifecycle model projects.

5.2.1.1 Development Life Cycles

COPSEMO uses the MBASE and Rational Unified Process Milestones described in Chapter 1. There are three milestones which separate the effort and schedule phases of COPSEMO: Life Cycle Objectives review (LCO), Life Cycle Architecture review (LCA), and Initial Operational Capability (IOC). There are also two milestones that serve as end-points at the beginning and end of the effort and schedule phases, respectively: Project Start (PS) and Product Release (PR).

One way of looking at these milestones is architecture centric and focused on the software development aspects of the system and project. While there are many aspects that must be considered at each of the milestones, the foregoing is the focus of the following discussion.

In this light, PS is the point where resources are explicitly allocated to a development effort and tracked from then on. LCO is the point in which a possible architecture for the project is picked. It may not necessarily be the architecture that is eventually used, but one that can satisfy the requirements and is judged buildable. LCA is when the architecture you actually use is finalized. Again, this may not be the architecture you picked at LCO, but will be the one used to construct the system. IOC is when the software system development is finished and is ready for deployment and final testing. Finally, at PR the system is fully operational, and ready for a fully supported release.

Between these five milestones are four phases: Inception, Elaboration, Construction, and Transition. Inception is going from PS to LCO, or, from initiation of the project to selecting a viable architecture. Inception is mostly “Requirements Capture” as you can see in the diagram, adapted from Rational Corporation [Rational, 1998], below. Requirements Capture is an activity similar to COCOMO’s “Requirements” activity; it is when the project’s needs and objectives are decided and used to drive the selection of an architecture. Notice, however, that this activity does not only lie in the Inception phase but also continues over into the next phase, Elaboration. The supporting activity of Management in this phase corresponds mainly to the "Plans" portion of the "Plans and Requirements" phase of the Waterfall lifecycle model although there is often a portion devoted to requirements negotiation with the clients or customer.

[Insert Figure 5.2]

Elaboration is going from LCO to LCA, or, from picking a possible architecture to deciding on the right one. The bulk of this phase is devoted to the activity “Analysis & Design.” Essentially, the architecture picked at LCO is investigated, in the light of evolving requirements and understanding of the problem, to see if it really is the one to be carried through into Construction , or whether a new or alternate architecture identified at LCO is the correct one. The architecture is “designed” to satisfy the requirements and “analyzed” to see if it does. Of course, to give the analysis context, the success criterion for the project may have to be evolved and re-evaluated. This is why the Requirements Capture activity is shown to continue into Elaboration. Notice also that the activity “Implementation” is started in the Elaboration phase. This is because to analyze the architecture it may be necessary to develop some preliminary implementation of the architecture to see how it works and if it satisfies all the identified needs. Alternatively, even if there is no change in architecture, prototype development (whether throw-away or retained) may go on during Elaboration to help identify risks and increase understanding of the requirements. Of course, these two types of development activity are also why the activity “Test” is shown to occur during this phase.