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 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. 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.
Figure 11-11. 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;
- 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.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.