5.5 Other Project Influences

5.5 Other Project Influences

I've mentioned the Cocomo II estimating model several times in this chapter. As discussed in Chapter 4, I have reservations about subjectivity creeping into the use of Cocomo II's adjustment factors. However, my reservations stem from concerns about "usage failure" more than concerns about "method failure." The Cocomo II project has done a much better job than other studies of rigorously isolating the impacts of specific factors on project outcomes. Most studies combine multiple factors intentionally or unintentionally. A study might examine the impact of software process improvement, but it might not isolate the impact of switching from one programming language to another, or of consolidating staff from two locations to one location. The Cocomo II project has conducted the most statistically rigorous analysis of specific factors that I've seen. So, although I prefer other methods for estimation, I do recommend studying Cocomo II's adjustment factors to gain an understanding of the significance of different software project influences.

Table 5-4 lists the Cocomo II ratings factors for Cocomo's 17 Effort Multipliers (EMs). The Very Low column represents the amount you would adjust an effort estimate for the best (or worst) influence of that factor. For example, if a team had very low "Applications (Business Area) Experience," you would multiply your nominal Cocomo II effort estimate by 1.22. If the team had very high experience, you would multiply the estimate by 0.81 instead.

Table 5-4: Cocomo II Adjustment Factors

	Ratings
Factor	Very Low	Low	Nominal	High	Very High	Extra High	Influence
Applications (Business Area) Experience	1.22	1.10	1.00	0.88	0.81		1.51
Database Size		0.90	1.00	1.14	1.28		1.42
Developed for Reuse		0.95	1.00	1.07	1.15	1.24	1.31
Extent of Documentation Required	0.81	0.91	1.00	1.11	1.23		1.52
Language and Tools Experience	1.20	1.09	1.00	0.91	0.84		1.43
Multisite Development	1.22	1.09	1.00	0.93	0.86	0.78	1.56
Personnel Continuity (turnover)	1.29	1.12	1.00	0.90	0.81		1.59
Platform Experience	1.19	1.09	1.00	0.91	0.85		1.40
Platform Volatility		0.87	1.00	1.15	1.30		1.49
Product Complexity	0.73	0.87	1.00	1.17	1.34	1.74	2.38
Programmer Capability (general)	1.34	1.15	1.00	0.88	0.76		1.76
Required Software Reliability	0.82	0.92	1.00	1.10	1.26		1.54
Requirements Analyst Capability	1.42	1.19	1.00	0.85	0.71		2.00
Storage Constraint			1.00	1.05	1.17	1.46	1.46
Time Constraint			1.00	1.11	1.29	1.63	1.63
Use of Software Tools	1.17	1.09	1.00	0.90	0.78		1.50

The Influence column on the far right of the table shows the degree of influence that each factor, in isolation, has on the overall effort estimate. The Applications (Business Area) Experience factor has an influence of 1.51, which means that a project performed by a team with very low skills in that area will require 1.51 times as much total effort as a project performed by a team with very high skills in that area. (Influence is computed by dividing the largest value by the smallest value. For example, 1.51 is 1.22/0.8.)

Figure 5-7 presents another view of the impact of the Cocomo II factors, in which the factors are arranged from most significant influence to least significant influence.

Figure 5-7: Cocomo II factors arranged in order of significance. The relative lengths of the bars represent the sensitivity of the estimate to the different factors.

Figure 5-8 shows the same factors represented in terms of their potential to increase total effort (the gray bars) versus decrease effort (the blue bars).

Figure 5-8: Cocomo II factors arranged by potential to increase total effort (gray bars) and potential to decrease total effort (blue bars).

I've listed some observations about these factors in Table 5-5 in alphabetical order.

Table 5-5: Cocomo II Adjustment Factors

Cocomo II Factor	Influence	Observation
Applications (Business Area) Experience	1.51	Teams that aren't familiar with the project's business area need significantly more time. This shouldn't be a surprise.
Architecture and Risk Resolution	1.38 [*]	The more actively the project attacks risks, the lower the effort and cost will be. This is one of the few Cocomo II factors that is controllable by the project manager.
Database Size	1.42	Large, complex databases require more effort project-wide. Total influence is moderate.
Developed for Reuse	1.31	Software that is developed with the goal of later reuse can increase costs as much as 31%. This doesn't say whether the initiative actually succeeds. Industry experience has been that forward-looking reuse programs often fail.
Extent of Documentation Required	1.52	Too much documentation can negatively affect the whole project. Impact is moderately high.
Language and Tools Experience	1.43	Teams that have experience with the programming language and/or tool set work moderately more productively than teams that are climbing a learning curve. This is not a surprise.
Multi-Site Development	1.56	Projects conducted by a team spread across multiple sites around the globe will take 56% more effort than projects that are conducted by a team co-located at one facility. Projects that are conducted at multiple sites, including out-sourced or offshore projects, need to take this effect seriously.
Personnel Continuity (turnover)	1.59	Project turnover is expensive—in the top one-third of influential factors.
Platform Experience	1.40	Experience with the underlying technology platform affects overall project performance moderately.
Platform Volatility	1.49	If the platform is unstable, development can take moderately longer. Projects should weigh this factor in their decision about when to adopt a new technology. This is one reason that systems projects tend to take longer than applications projects.
Precedentedness	1.33[*]	Refers to how "precedented" (we usually say "unprecedented") the application is. Familiar systems are easier to create than unfamiliar systems.
Process Maturity	1.43[*]	Projects that use more sophisticated development processes take less effort than projects that use unsophisticated processes. Cocomo II uses an adaptation of the CMM process maturity model to apply this criterion to a specific project.
Product Complexity	2.38	Product complexity (software complexity) is the single most significant adjustment factor in the Cocomo II model. Product complexity is largely determined by the type of software you're building.
Programmer Capability (general)	1.76	The skill of the programmers has an impact of a factor of almost 2 on overall project results.
Required Reliability	1.54	More reliable systems take longer. This is one reason (though not the only reason) that embedded systems and life-critical systems tend to take more effort than other projects of similar sizes. In most cases, your marketplace determines how reliable your software must be. You don't usually have much latitude to change this.
Requirements Analyst Capability	2.00	The single largest personnel factor—good requirements capability—makes a factor of 2 difference in the effort for the entire project. Competency in this area has the potential to reduce a project's overall effort from nominal more than any other factor.
Requirements Flexibility	1.26[*]	Projects that allow the development team latitude in how they interpret requirements take less effort than projects that insist on rigid, literal interpretations of all requirements.
Storage Constraint	1.46	Working on a platform on which you're butting up against storage limitations moderately increases project effort.
Team Cohesion	129[*]	Teams with highly cooperative interactions develop software more efficiently than teams with more contentious interactions.
Time Constraint	1.63	Minimizing response time increases effort across the board. This is one reason that systems projects and real-time projects tend to consume more effort than other projects of similar sizes.
Use of Software Tools	1.50	Advanced tool sets can reduce effort significantly.
[*]Exact effect depends on project size. Effect listed is for a project size of 100,000 LOC. These factors are discussed in the next section.

As I hinted earlier, studying the Cocomo II adjustment factors to gain insight into your project's strengths and weaknesses is a high-leverage activity. For the estimate itself, using historical data from your past or current projects tends to be easier and more accurate than tweaking Cocomo's 22 adjustment factors.

Chapter 8 will discuss the ins and outs of collecting and using historical data.