Software Estimation Procedure

        Click here to download the MS Word (232 KB)        

Software estimation is a process that should be used throughout the life cycle of a project. As the project proceeds through the life cycle, additional information is known about the project and reestimating should create a more accurate estimate. This procedure is followed before entering the following phases of the software development life cycle: Requirements Analysis, Preliminary Design, Detailed Design, Implementation, System Test, and whenever a significant change is accepted for the project.

This software estimation procedure includes the following tasks:

• Estimate Size
• Estimate Effort
• Estimate Schedule
• Inspect and Approve Estimate

This procedure uses a number of forms to support the estimation process. These forms are included in Appendix A. The forms are also available as an Excel spreadsheet, which automatically performs most of the calculations described in this procedure.

1. ESTIMATE SIZE

1.1  Responsible Personnel

Project manager, programmers, software engineers, and system analysts are responsible for determining the size of the software project.

1.2  Entrance Criteria

Software functional requirements have been defined.

1.3  Inputs

• Software functional requirements.
• Other project information based on the current life-cycle phase, such as software architectural concepts, design information, etc.
• Historical size data from past, completed, and similar projects. The unit of measure for the size data should be identical to that used to estimate this project.

1.4  Activities

1. The Project Manager determines whether the Wideband Delphi method will be used for this estimate. Record this decision and rationale on the Project Info Sheet. Use the Wideband Delphi method if any of the following conditions exist:
   • The contract is a fixed priced contract.
   • The requirements are less refined than expected at this stage of the project.
   • The project plans to use a new language, technology, or approach.
   • The cost and/or schedule are considered high risks.
   • No historical size data is available.
   • The Project Manager feels that the benefits of using the Wideband Delphi will be greater than the additional cost of using the method.
     
     Appendix B describes the steps to follow when using the Wideband Delphi method.
2. The Project Manager selects the size measure to be used for estimating. Record this decision and rationale on the Size Estimate Sheet (). The following size measures are recommended; any others require prior permission from the division's Software Engineering Process Group (SEPG):
   • Source lines of code, as defined by Appendix C
   • Function Points, as defined by (IFPUG 1994)
   • Predictive Object Points, as defined by (Minkiewicz 1997)
3. The Project Manager decomposes the project into estimating elements, such as subsystem, component, or unit level, by selecting the lowest level possible based on amount of data available. The Project Manager assigns size estimation responsibility for each estimating element. If the Wideband Delphi method is used, each member of the group independently estimates their assigned estimating elements.
4. If the selected size measure is function points, follow the IFPUG counting practices to estimate the number of function points in the application. Record the estimated adjusted function points on the Size Estimate Sheet. Historical size data from past projects is not needed for function point counting, so skip to Step 8.
5. If historical size data is available, each estimator performs the following for their assigned estimating elements:
   • Compiles size data about similar functions previously developed using historical size data
   • Identifies and records the similarities and differences between the existing functions and the new estimating elements
     
     Record this information on the Past Size Data Sheet. There should be one Past Size Data Sheet for each estimating element.
     
     Record the Lowest , Most Likely , and Highest possible size for each estimating element on the Size Estimation Sheet.
6. If historical size data is not available, the Project Manager records the following as a risk on the Estimation Risks Sheet:
• Risk Description: The software project estimate has a low level of confidence because it was estimated without the benefit of historical size data. No historical size data was available because {a new language is being used, no similar software has been developed here, etc.}.
7. If historical size data is not available, approximate the Lowest , Most Likely , and Highest possible size for each estimating element. Record this information on the Size Estimate Sheet.
8. If the Wideband Delphi method is being used, the group follows the procedure outlined in Appendix B to obtain a group consensus.
9. The Project Manager computes the project size and records it on the Size Estimate Sheet:
   
   For each element, i:
   
   
   
   For the overall project, where n is the number of estimating elements:
   
   
   
10. The Project Manager analyzes the size estimates to determine whether the range of estimates is larger than expected at this point of the life cycle:
    
    For each element, determine the range of the size estimate:
    
    
    Use Table 1 to determine the level of estimating risk associated with each element. The Project Manager records the following as a project risk for each Medium or High Risk element on the Estimation Risk Sheet:
• Risk Description: The software size estimate of estimating element {insert name of element} is considered a {medium or high} risk due to the unexpectedly large range of size estimates for the current project phase.
  
  Table 1 . Estimated Ranges of Size Estimates

Current Project Phase	Low or No Risk	Medium Risk	High Risk
Before Requirements Analysis	<= 50%	> 50% and < 200%	>= 200%
Requirements Analysis	<= 30%	> 30% and < 150%	>= 150%
Preliminary Design	<= 20%	> 20% and < 80%	>= 80%
Detailed Design	<= 10%	> 10% and < 50%	>= 50%
Implementation	<= 8%	> 8% and < 20%	>= 20%
System Test	<= 5%	> 5% and < 10%	>= 10%




11. The Project Manager determines whether any other risks are associated with the size estimate. If so, the Project Manager records the risks on the Estimation Risk Sheet.

1.5  Exit Criteria

The size estimate has been recorded on the Size Estimate Sheet.

1.6  Outputs

• Size estimate
• Project risks

2.  ESTIMATE EFFORT

2.1  Responsible Personnel

The Project Manager estimates the effort based on the estimated size.

2.2  Entrance Criteria

Size estimate has been completed.

2.3  Inputs

• Size estimate
• Description of the project's process
• Historical size and effort data from past, completed, and similar projects. The unit of measure for the size data should be identical to that used to estimate this project.

2.4  Activities

1. Review available historical data and select at least three projects that most closely resemble this project. The historical data for each selected project must include effort and project size, using the same kind of size measure that was used to estimate the size for this project. When selecting projects, consider the application domain, programming language, development process, size, and other factors that affect productivity. Record the names of the selected projects on the Past Effort Data Sheet.
   
2. Calculate the productivity of each of these projects and record on the Past Effort Data Sheet:
   
   for each project, i
   
   The effort includes the time for all labor activities directly related to the task. These activities normally include:
   • Engineering labor charges for System/Software Requirements Analysis, Design, Code, Test, and Integration
   • Documentation effort
   • Configuration Management
   • Software Quality Assurance (SQA)
   • Management effort directly related to the task
3. Calculate the average productivity of the selected projects. If there are more than three projects, calculate the standard deviation of the productivity of the selected projects. Record the average and standard deviation on the Past Effort Data Sheet.
   
   
   
4. Calculate the estimated total effort for this project, based on the average productivity. The size of the project should be based on the expected value obtained by consensus in the Estimate Size task.
   
   
   Record the information on the Effort Estimate Sheet.
   
5. If you calculated the standard deviation of the productivity, also calculate the 95% confidence range:
   
   
   Record the information on the Effort Estimate Sheet.
   
6. The Project Manager determines if any risks are associated with the effort estimate. If so, the Project Manager records the risks on the Estimation Risk Sheet.

2.5  Exit Criteria

Effort estimate has been recorded on the Effort Estimate Sheet (Figure 6).

2.6  Outputs

• Effort estimate
• Project risks

3  ESTIMATE SCHEDULE

3.1  Responsible Personnel

The Project Manager estimates the schedule from the estimated effort.

3.2  Entrance Criteria

Size and effort estimates have been completed.

3.3  Inputs

• Size and effort estimates

3.4  Activities

1. Estimate the number of hours needed for each life-cycle phase based on the percentage of the total life cycle for each phase (see Table 2 ).
   Table 2 . Percent of Effort by Phase



Phase	Percent of Effort
Requirements Analysis	6
Preliminary Design	8
Detailed Design	16
Implementation	40
System Test	20
Acceptance Testing	10


Source: [NASA 1990]

Record the information on the Schedule Estimate Sheet.


2. Estimate the number of full-time equivalent people on the project for each phase, based on historical data. Record the information on the Schedule Estimate Sheet (Figure 7).
   
3. The Project Manager determines whether any risks are associated with the schedule estimate. If so, the Project Manager records the risks on the Estimation Risk Sheet.

3.5  Exit Criteria

The schedule estimate has been recorded on the Schedule Estimate Sheet.

This estimate of the schedule does not replace detailed schedule planning, which considers the order in which the software components are to be developed, specific staffing assignments, and other required project activities.

3.6  Outputs

• Schedule estimate
• Project risks

4  INSPECT and APPROVE ESTIMATE

This purpose of this task is to improve the quality of the estimate and get management commitment for the estimate. The objectives of the inspection and approval of the estimate are:

• Verify the methods used for deriving the size, schedule, and cost estimates.
• Ensure that the assumptions and input data used to develop the estimates are correct.
• Ensure that the estimate is reasonable and accurate given the input data.
• Confirm and record the official estimates for the project.

4.1  Responsible Personnel

The Project manager, management representative, SQA engineer, software estimators, and software engineers are responsible for inspecting and approving the estimate.

4.2  Entrance Criteria

The software estimate has been completed.

4.3  Inputs

• Software estimate

4.4  Activities

1. Use the Inspection Process to inspect the estimate. The inspection meeting is attended by the personnel that developed the estimate, at least one other software engineer from the project that is being estimated (if one has been assigned), a software engineer with experience on a similar project, a management representative, and the assigned SQA engineer.
   Consider the following factors while evaluating the estimate (PSM 1998):
   • Have risks been appropriately identified and documented?
   • Are the numbers used for historical data correct?
   • Are the models used correctly?
   • Are the assumptions reasonable? Have they changed since the last estimate?
   • Are the anticipated base productivity rates consistent with prior experience?
   • Are aggressive goals supported by realistic strategies?
   • Have any alternative estimation methods been applied for comparison?
2. Software estimators, the project manager, SQA, and the management representative sign the estimate after the inspection is complete and all estimation related defects have been resolved.
3. Record the approved estimate in the Software Development Plan and Software Estimate File (SEF). The SEF should contain copies of all estimates, memos, and other data that relate to the project's estimate.
4. Forward the approved estimate to the SEPG.
5. Record the number of hours that have been used to perform this procedure. Include time spent by all estimators, inspectors, and others.

4.5  Exit Criteria

Software estimates have been reviewed and approved by the software estimators, project manager, SQA and the management representative.

4.6  Outputs

• Approved project estimate
• Project risks

Appendix A: Software Estimation Forms

Note: These forms are also available within an Excel spreadsheet. Most of the calculations described in the estimation procedure are performed by the spreadsheet.

Project Info Sheet
Project Name:
Brief description of project:
Date of previous estimate (approval date):
Current life-cycle phase:
Programming languages used:
Development platform:
Target platform:
Will Wideband Delphi method be used to estimate size?
Rationale for decision:

Figure 1 . Project Info Sheet

Size Estimate Sheet
Estimator's Name:
Date:
Size measure used:
Estimating Element	Lowest	Most Likely	Highest	EVi	SDi	Range i	SD i squared (computed)
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
				0	0	0%	0
Project Size:				0	0

Figure 2 . Size Estimate Sheet

 

Past Size Data Sheet
Estimator's Name:
Date:
Estimating Element:
Enter information about similar elements from completed projects
Name of project:
Name of element:
Description of functionality:
Similarities to estimating element:
Differences from estimating element:
Size of element:
Name of project:
Name of element:
Description of functionality:
Similarities to estimating element:
Differences from estimating element:
Size of element:
Name of project:
Name of element:
Description of functionality:
Similarities to estimating element:
Differences from estimating element:
Size of element:
Name of project:
Name of element:
Description of functionality:
Similarities to estimating element:
Differences from estimating element:
Size of element:
Add more rows as needed.

Figure 3 . Past Size Data Sheet

Estimation Risks Sheet
Risk Identifier	Risk Description	Likelihood of Occurrence	Cost of Occurrence

Figure 4. Estimation Risks Sheet

 

Past Effort Data Sheet
Estimator's Name:
Date:
Size measure used:
Enter information about similar, completed projects:
Name of project:
Description of functionality:
Similarities to project being estimated:
Differences from project being estimated:
Size of project:
Total effort of project (staff hours):
Productivity:	0.00
Name of project:
Description of functionality:
Similarities to project being estimated:
Differences from project being estimated:
Size of project:
Total effort of project (staff hours):
Productivity:	0.00
Name of project:
Description of functionality:
Similarities to project being estimated:
Differences from project being estimated:
Size of project:
Total effort of project (staff hours):
Productivity:	0.00
Name of project:
Description of functionality:
Similarities to project being estimated:
Differences from project being estimated:
Size of project:
Total effort of project (staff hours):
Productivity:	0.00
Name of project:
Description of functionality:
Similarities to project being estimated:
Differences from project being estimated:
Size of project:
Total effort of project (staff hours):
Productivity:	0.00
Overall productivity:
prod EV :	0.00
prod SD :	0.000

Figure 5. Past Effort Data Sheet

Effort Estimate Sheet
Estimator's Name:
Date:
effortEV:	0
effortMIN:	0
effortMAX:	0

Figure 6. Effort Estimate Sheet

Schedule Estimate Sheet
Estimator's Name:
Date:
Phase	Percent of Effort	Project Effort (staff hours)	Estimated full-time equivalent staff available	Project Schedule (hours)
Requirements Analysis	6%	0		0
Preliminary Design	8%	0		0
Detailed Design	16%	0		0
Implementation	40%	0		0
System Test	20%	0		0
Acceptance Testing	10%	0		0
Total	100%	0		0

Figure 7. Schedule Estimate Sheet

Appendix B: Wideband Delphi method

Follow these instructions when the Wideband Delphi method is used to estimate the size of a project.

1. The Project Manager selects three to seven people with experience on similar projects to estimate the size of this project. The Project Leader holds a meeting with all estimators and discusses the following items:
   • Description of this project, including a description of each element of the project to estimate
   • Review of the estimation procedure
   • Size measure to be used for estimate
   • Date and time when the first round of estimating forms are due
   • Date and time of the first consensus meeting
2. Each estimator independently estimates the project size, as described in Section 1.4 . Record the information on the Past Size Data and Size Estimate forms. These forms are returned to the Project Manager at or before the due date.
3. For this round the Project Manager creates a report that is a composite of each person's estimates. Names and any other information that will disclose an individual's identity are removed from the estimates.
4. The Project Manager holds a consensus meeting that is attended by all size estimators. The objective of this meeting is to discuss the estimates and their rationales. At the end of the meeting, the group determines whether the estimates have sufficient convergence or whether another round of estimating is required. If another round is needed, the Project Manager announces the following:
   • Date and time when the next round of estimating forms are due
   • Date and time of the next consensus meeting
5. The rounds continue from step 2, until consensus is achieved.

Appendix C:  Source Lines of Code Defintion

Source lines of codes may be defined in many ways. Table 3 provides the definition of SLOC that is used within the Consortium. It is based on a checklist from (Park 1992).

When a line or statement contains more than one type, classify it as the type with the highest precedence. Order of precedence is in ascending order.

Table 3 . Source Lines of Code Definition

	Includes	Excludes
Statement type
1. Executable	4
2. Nonexecutable
3. Declarations	4
4. Compiler directives	4
5. Comments:
6. On their own lines		4
7. On lines with source code		4
8. Banners and nonblank spacers		4
9. Blank (empty) comments		4
10. Blank lines		4
How produced
1. Programmed	4
2. Generated with source code generators		4
3. Converted with automated translators	4
4. Copied or reused without change	4
5. Modified	4
6. Removed		4
Origin
1. New work: no prior existence	4
2. Prior work: taken or adapted from:
3. A previous version, build, or release		4
4. Commercial off-the-shelf software (COTS), other than libraries		4
5. Government-furnished software (GFS), other than reuse libraries		4
6. Another product		4
7. A vendor-supplied language support library (unmodified)		4
8. A vendor-supplied operating system or utility (unmodified)		4
9. A local or modified language support library or operating system		4
10. Other commercial library		4
11. A reuse library (software designed for reuse)		4
12. Other software component or library		4
Usage
1. In or as part of the primary product	4
2. External to or in support of the primary product		4
Delivery
1. Delivered:
2. Delivered as source	4
3. Delivered in compiled or executable form, but not as source	4
4. Not delivered:
5. Under configuration control		4
6. Not under configuration control		4
Functionality
1. Operative	4
2. Inoperative (dead, bypassed, unused, unreferenced, or inaccessible):
3. Functional (intentional dead code, reactivated for special purposes)	4
4. Nonfunctional (unintentionally present)		4
Replications
1. Master source statements (originals)	4
2. Physical replicates of master statements, stored in the master code	4
3. Copies inserted, instantiated, or expanded when compiling or linking		4
4. Postproduction replicates, as in distributed, redundant, or reparameterized systems		4
Clarifications (general)
1. Nulls, continues, and no-ops	4
2. Empty statements, e.g. ";;" and lone semicolons on separate lines		4
3. Statements that instantiate generics	4
4. Begin...end and {...} pairs used as executable statements	4
5. Begin...end and {...} pairs that delimit (sub)program bodies	4
6. Logical expressions used as test conditions		4
7. Expression evaluations used as subprograms arguments		4
8. End symbols that terminate executable statements		4
9. End symbols that terminate declarations or (sub)program bodies		4
10. Then, else, and otherwise symbols		4
11. Else if statements	4
12. Keywords like procedure division, interface, and implementation	4
13. Labels (branching destinations) on lines by themselves		4
Clarifications (language specific)
Ada
1. End symbols that terminate declarations or (sub)program bodies		4
2. Block statements, e.g. begin...end	4
3. With and use clauses	4
4. When (the keyword preceding executable statements)		4
5. Exception (the keyword, used as a frame header)	4
6. Pragmas	4
Assembly
1. Macro calls	4
2. Macro expansions		4
C and C++
1. Null statement, e.g. ";" by itself to indicate an empty body		4
2. Expression statements (expressions terminated by semicolons)	4
3. Expression separated by semicolons, as in a "for" statement	4
4. Block statements, e.g. {...} with no terminating semicolon	4
5. ";" on a line by itself when part of a declaration		4
6. ";" on a line by itself when part of an executable statement		4
7. Conditionally compiled statements (#if, #ifdef, #ifndef)	4
8. Preprocessor statements other than #if, #ifdef, and #ifndef	4
CMS-2
1. Keywords like SYS-PROC and SYS-DD	4
COBOL
1. "PROCEDURE DIVISION", "END DECLARATIVES", etc.	4
FORTRAN
1. END statements	4
2. Format statements	4
3. Entry statements	4
PASCAL
1. Executable statements not terminated by semicolons	4
2. Keywords like INTERFACE and IMPLEMENTATION	4
3. FORWARD declarations	4

 

References

IFPUG 1994	Function Point Counting Practices Manual Release 4.0, Westerville , Ohio : International Function Point Users Group.
Minkiewicz 1997	Estimating Size for Object-Oriented Software , Arlene F. Minkiewicz, PRICE Systems, L.L.C.
NASA 1990	Manager's Handbook for Software Development Revision 1, National Aeronautics and Space Administration: Greenbelt , Maryland ; available from http://sel.gsfc.nasa.gov/website/documents/online-doc/84-101.pdf
Park 1992	Software Size Measurement: A Framework for Counting Source Statements, CMU/SEI-92-TR-20. Pittsburgh , Pennsylvania : Software Engineering Institute, Carnegie Mellon University .
PSM 1998	Practical Software Measurement, Version 3.1, available from http://www.psmsc.com

 

 

Top