Management (it does include line management but not overall management) īoehm originally divided effort as 30% design, 30% code and unit testing, and 40% integration and testing. As shown in Figure 11-11, an increase of 20% is generally needed for the requirements phase-even more when object-oriented methods are in use. Even though this portion of the estimate is commonly 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. Requirements development and specification, which is often not used in some commercial applications. ® COCOMO assumes a basic waterfall process model: 30% design, 30% coding, and 40% integration and testing. ® Your data may not match the data used to develop COCOMO-if not, your company must collect the data needed to correlate the model. It can take two to four times this much with modern software engineering practices and typical complexity of modern software products. ® 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). These activities may also be estimated using a variation of the basic model.

Maintenance, rework, porting, and reuse are issues that don't fit cleanly into the same model. ® The COCOMO model primarily represents development effort (from the planning phase through the implementation phase). ® It is dependent on the knowledge of cost drivers and/or the amount of time spent in each phase. ® Experience-based estimation may be flawed because of obsolescence of the historical data used or because the estimators' memory of past projects is flawed. ® 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. ® It ignores the software development environment.

® It oversimplifies the impact of security issues. ® It ignores customer attributes-skill, cooperation, knowledge, and responsiveness. ® It ignores documentation and other requirements. ® It ignores requirements volatility (but an organization may add this as an extra adjustment factor in computing EAF).

Cocomo model and its variations