Software Cost Estimation With Use Case Points – Environmental Factors

The environmental factors that describe your development team and environment are the second thing you assess when doing project cost estimation with use case points. Environmental factors primarily focus on the capabilities of your team, but also touch on your process.

Background

This is the third article in a series on applying use case points to create reliable software cost estimates. What makes use case points different is that they allow the project cost estimation to happen much earlier in the process. This cost estimation technique was developed by Gustav Karner for Rational Software Corporation in the mid 1990’s.

The introduction to software cost estimation is the right place to start if you came to this article first. The discussion of technical factor analysis was the previous article if you need a refresher.

Environmental Factors

Environmental factors are also called experience factors by some analysts. This reflects their primary focus on the capabilities of the team. The primary contributor to the success of a project is the capability of the team. This is reflected in the software cost estimate through the calculation of environmental factors. There are eight factors that are considered when applying use case points project cost estimation techniques.

Here are the eight factors of use case point estimation. Factors are listed as Name (multiplier) – Description.

1. Familiarity With The Project (1.5) – How much experience does your team have working in this domain? The domain of the project will be a reflection of what the software is intended to accomplish, not the implementation language. In other words, for an insurance compensation system written in java, you care about the team’s experience in the insurance compensation space – not how much java they’ve written. Higher levels of experience get a higher number.
2. Application Experience (0.5) – How much experience does your team have with the application. This will only be relevant when making changes to an existing application. Higher numbers represent more experience. For a new application, everyone’s experience will be 0.
3. Object Oriented Programming Experience (1) – How much experience does your team have at OO? It can be easy to forget that many people have no object oriented programming experience if you are used to having it. A user-centric or use-case-driven project will have an inherently OO structure in the implementation. Higher numbers represent more OO experience.
4. Lead Analyst Capability (0.5) – How knowledgeable and capable is the person responsible for the requirements? Bad requirements are the number one killer of projects – the Standish Group reports that 40% to 60% of defects come from bad requirements. Higher numbers represent increased skill and knowledge.
5. Motivation (1) – How motivated is your team? Higher numbers represent more motivation.
6. Stable Requirements (2) – Changes in requirements can cause increases in work. The way to avoid this is by planning for change and instituting a timing system for managing those changes. Most people don’t do this, and some rework will be unavoidable. Higher numbers represent more change (or a less effective system for managing change).
7. Part Time Staff (-1) – Note, the multiplier for this number is negative. Higher numbers reflect team members that are part time, outside consultants, and developers who are splitting their time across projects. Context switching and other intangible factors make these team members less efficient.
8. Difficult Programming Language (-1) – This multiplier is also negative. Harder languages represent higher numbers. We believe that difficulty is in the eye of the be-coder (groan). Java might be difficult for a fortran programmer. Think of it in terms of difficulty for your team, not abstract difficulty.

Calculating the Environmental Factor

The first step is to determine the value that characterizes each factor, from 0 to 5. Two things to note. Everyone will have a 0 value for application experience (#2) when creating a new application. Factors 7 and 8 are both negative numbers – so higher numbers have the reverse impact as with other factors.

First, determine the value from 0 to 5 for each factor. Then multiply by the multipliers and add them up. Remember that your values for part time staff and difficulty of programming language will be subtracted from the total. If you rated each value a “2”, then your total would be 9.

The environmental factor is EF = 1.4 – (0.03 * your total). The higher the sum you identified, the lower the environmental factor. This is different than calculating the technical factor, but it makes sense – the more experienced your developers are, the less effort they will spend on a given project.

Next Step

The next step is to perform the initial analysis of the use cases, determining the unadjusted use case points.