Detailed COCOMO

Detailed COCOMO

This is the most complicated version of the COCOMO model. It involves the following further steps:

●  The program is decomposed into particular products and components of products. Boehm calls this the three-level product hierarchy: system, subsystem, and module. The top level, the system level, is used to apply major overall project relations such as nominal effort and schedule equations, and to apply the nominal project effort and schedule breakdowns by phase. The lowest level, the module level, is described by the number of KLOC in the module and by the cost drivers that tend to vary at the lowest level. The second level, the subsystem level, is described by the remainder of the cost drivers that tend to vary from subsystem to subsystem but that tend to be the same for all the modules within a subsystem.

●  Cost drivers are analyzed separately for each component. Subsystems and modules inherit the system cost drivers. They are RELY, VIRT, TURN, MODP, TOOL, and SCED.
Modules inherit the subsystem cost drivers. They are DATA, TIME, STOR, ACAP, AEXP (these tend to be the same for all modules within a subsystem). The module cost drivers are KLOC, AAF, CPLX, PCAP, VEXP, and LEXP. AAF is new - it considers the adaptation of existing modules. More information is available earlier when modifying existing software - this data leads to more accurate estimations. Given that much software under construction is not totally new development and the reuse of existing modules is encouraged by newer methods (i.e., object-oriented), use of detailed COCOMO is often worth the extra effort. It should be noted that the cost of reuse is never zero. There is always effort expended to understand the existing code and to interface to it. The cost to rewrite a system may be less than to continue to maintain it (if it has suffered entropy of structure), but it will be more expensive than to build a "new" system of comparable size and complexity from scratch. Some believe that the economic breakeven point occurs when only 20% of the code is modified; reuse is not cost-effective above the breakeven point.

●  The project development activities are partitioned into phases. Boehm used four major phases: requirements (RQ), product design (PD), detailed design (DD), and coding and unit test (CUT) for development. Integration and testing (IT) and maintenance (MN) describe the entire life cycle. Phases may be used to partition systems, subsystems, and/or modules. Different effort multipliers are used for each phase. Different values of the cost driver multipliers are set for each of the three levels in the product hierarchy (system, subsystem, module) and each phase (RPD, DD, CUT, IT) within the hierarchies.

Scheduling Using COCOMO

After the size, and, from the size, the overall effort, have been estimated, then the activity of scheduling can begin. Scheduling includes refining the WBS, if necessary, and assigning staff members' responsibility for particular tasks. Scheduling also includes determining a start and end date for each task, as well as noting dependencies between and among tasks and promoting parallelism where possible. With dependencies, one task needs input from one or more others and therefore must wait for the other(s) to complete before it can begin; with parallelism, two or more tasks may be worked on at the same time. The two most widely used methods of graphically representing tasks, dependencies, parallelism, and time, are the Gantt chart and the Pert chart. Each is easily produced using an automated tool.

Tailoring of COCOMO

An organization may want to develop a specially calibrated version that will more accurately reflect its specific practices and capabilities. There are three different ways to recalibrate and tailor the intermediate COCOMO equations to local conditions, based on a local historical database for n projects: recalibrate the effort equation coefficient, tailor the mode (recalibrate the exponent and coefficient), and revise the cost drivers. We won't go into the formulas and details of recalibrating the models here, but the instructions may be found in Boehm's Software Engineering Economics.
One thing to note is that a database of at least five projects is required to accurately recalibrate the coefficient. A database of at least 10 projects is required to accurately recalibrate the exponent.

Advantages of COCOMO

The advantages of COCOMO include:

●  Actual data "backfitted" from many real programs can supply a set of COCOMO constants and
    adjustment factors that fit an organization well.
●  It is a repeatable process.
●  The method allows the addition of unique adjustment factors associated with an organization.
●  It is versatile enough to support different "modes" and "levels."
●  It works well on projects that are not dramatically different in size, complexity, or process.
●  It is highly calibrated, based on previous experience.
●  It is thoroughly documented.
●  It is easy to use.

Disadvantages of COCOMO

The disadvantages of COCOMO include:

●  It ignores requirements volatility (but an organization may add this as an extra adjustment factor in
    computing EAF).
●  It ignores documentation and other requirements.
●  It ignores customer attributes - skill, cooperation, knowledge, and responsiveness.
●  It oversimplifies the impact of security issues.
●  It ignores software safety issues.
●  It ignores the software development environment.
●  It ignores personnel turnover levels.
●  It ignores many hardware issues.
●  All the levels are dependent on the size estimate - the accuracy of the size drives the accuracy of
    effort, development time, staffing, and productivity estimates.
●  Experience-based estimation may be flawed because of obsolescence of the historical data used or
    because the estimators' memory of past projects is flawed.
●  It is dependent on the knowledge of cost drivers and/or the amount of time spent in each phase.

Other potential issues noted by Dr. Frailey include these:

●  The COCOMO model primarily represents development effort (from the planning phase through the implementation phase). Maintenance, rework, porting, and reuse are issues that don't fit cleanly into the same model. These activities may also be estimated using a variation of the basic model.

●  COCOMO assumes a very basic level of effort for configuration management and quality assurance, allowing about 5% of the total budget for both (based on typical commercial practice at the time COCOMO was established). It can take two to four times this much with modern software engineering practices and typical complexity of modern software products.

●  Your data may not match the data used to develop COCOMO - if not, your company must collect the data needed to correlate the model.

●  COCOMO assumes a basic waterfall process model: 30% design, 30% coding, and 40% integration and testing.

●  COCOMO excludes:

- Requirements development and specification, which is often not used in some commercial applications. Even though this portion of the estimate is normally viewed as the responsibility of a systems engineering or systems analysis function, it is often underscoped unless software engineers are invited to participate in the cost estimate. As shown in Figure 1, an increase of 20% is usually required for the requirements phase - even more when object-oriented methods are in use.

Phases Included by COCOMO

- Management (it does include line management but not overall management);
- Overhead costs;
- Travel and other incidental costs;
- System integration and test support;
- Field test support;
- Computers;
- Supplies;
- Office space.

Boehm originally divided effort as 30% design, 30% code and unit testing, and 40% integration and testing.

If you add 20% to the total for requirements analysis, it becomes 17% requirements analysis, 25% design, 25% code and unit testing, and 33% integration and testing.

Time is more heavily tilted toward requirements analysis and design, but specifics depend on the process being used. Typical numbers for time are 30% requirements, 30% design, 15% code, and 25% integration and testing.

Some Typical Barriers to Faster Schedule or Lower Cost

Common barriers to "faster, cheaper" goals include:

●  Lack of adequate equipment, software, tools, people, and so on;
●  Slow approval cycles;
●  Poor coordination with other disciplines, other companies, and so on;
●  Poorly educated customers and managers;
●  Irascible and irrational customers and managers;
●  Intentional barriers such as competitors.

Here's the bottom line: Keep data, especially estimates versus actuals (Figure 2). The more facts you have, the better off you will be during negotiations. Prepare to re-estimate early and often. Use a model and a modeling tool, where possible; consider environmental factors, and calibrate the model/tool to your organization.
Track Estimates Versus Actuals


life cycle, scheduling, gantt chart, pert chart, cost drivers, software products
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus