1. Project Cost Estimation
Software Engineering Processes - II
Unit 2:
Project Cost Estimation

2. Before You Begin…
What are your expectations from this unit?

3. Unit Objectives Identify the methods for preparing initial estimates.
Describe software estimation problems.
Count function points for simple projects using function point analysis.
Estimate the cost of a project using COCOMO II.
Define the factors affecting total project cost.
Explain detailed costing and scheduling.
Describe project performance monitoring.

4. Project Cost Estimation
Estimation involves identifying the following factors:
Effort required to complete each activity
Calendar time required to complete each activity
Total cost of each activity
Begin the class by telling the students that in the previous unit, we learnt the methods to represent a project’s component activities, dependencies, and allocation of people. The next step is to estimate the time and cost involved with each of these activities. Make sure to define effort - it may not be evident to students that effort means the total person-time spent.

5. Project Cost Estimation (cont.)
Effort cost is mostly the dominant cost. This includes the salaries that an organization pays to the software engineers and the overhead costs, such as cost of heating and lighting the office space, cost of support staff, networking, communication, and other facilities such as library, canteen, and so on. Administrative cost, such as cost of document publication and shipping/mailing materials is typically a small proportion of project cost, but it does figure in as a part of travel and training cost.

6. Initial Project Estimates
Initial estimates, though not very accurate, serve the following objectives:
They define the project scope and associated risks.
They help the organization decide whether the project should be undertaken or not.
They serve as the basis for detailed estimates when the requirements are clearer.
You can explain that initial estimates are calculated based on the requirements identified in the proposal, statement of work (SOW) or request for proposal (RFP) document.
If the project is similar to another recent project or if the requirement document was made prior to the proposal, the estimates are more accurate.

7. Calculating Initial Project Estimates
Initial estimates can be calculated using the following methods:
Analogy: Actual cost and schedule of a similar project
Rules of thumb: Organizational guidelines based on past project database
Parametric models: Product properties such as LOC to predict cost and schedule
Parametric models should be used with caution while calculating initial project estimates because it is difficult to arrive at an accurate function point or LOC estimate without detailed requirements.

8. Class Activity -1
Make a list of questions that a project manager should answer to help him select the appropriate past projects that can be used as a basis for estimating cost of a new project.
You can ask the students to form groups of five and start listing the points.
The checklist could contain the following points:
Are the projects based on same technology as the proposed project?
Are the project requirements similar?
Are the contract terms of the same type?
What was project cost and schedule?
How do the actual and estimated costs finally compare?

9. Initial Estimation Problems
The following problems might occur while calculating the initial estimates:
Uncertain requirements: Requirements must be known with some degree of certainty to get accurate estimates.
Diseconomy of scale: A slight increase in the size of the product may require more than equal amount of increase in effort and time.
Brooks Law: Increase in the number of people does not necessarily reduce the time taken to complete a project.
Explain these points using the description given on pages of The Project Manager’s Guide to Software Engineering’s Best Practices.

10. Initial Estimation Problems (cont.)
Staff skills and experience: The necessary staff skills may not be available for the project, which may affect the schedule or cost.
Optimal staffing level: Staffing may not be uniform over the course of the project.
Risk allowance: Evaluation of the risks of the project, for which a 20 % margin is considered to be reasonable, may not be accurate.

11. Parametric Estimation Models
Parametric models have been developed by performing statistical analysis of many earlier projects.
They use various forms of input such as:
The expected size of product
Nature of the product
Organization capabilities
Project properties

12. COCOMO II
COCOMO II can be used to model a broader variety of project circumstances:
Early design : Can be applied to calculate the initial estimates when the design phase has not started. The requirements are known only from the agreement.
Post architecture: Can be applied when the requirements and early design phase are complete.

13. Early Design
The estimates produced at this stage are based on the standard formula for algorithmic models:
Effort = A*Sizeb*M
Based on his own large data set, Boehm proposes that A should be 2.94.
Size of the system is given in KSLOC, which is the number of thousands of lines of source code. Calculate function points and then use standard tables that relate software size to function points for different programming languages.
Exponent b varies from 1.1 to 1.24.
You can add that exponent B takes a value from 1.1 to 1.24 based on the following five factors. These factors are rated on six-point scale from very low to very high (5 to 0) :
Precedentedness – novelty of the project
Degree of flexibility
Degree of risk present in the architecture
Degree of cohesion of development team
Process maturity of organization

14. Early Design (cont.)
Multiplier M is based on a set of seven project characteristics that influence the estimate:
Product reliability and complexity (RCPX)
Reuse required (RUSE)
Support facilities (FCIL)
Personnel capability (PERS)
Platform difficulty (PDIF)
Personnel experience (PREX)
Schedule (SCED)
M = PERS* RCPX*RUSE*PDIF*PREX*FCIL*SCED
You can add that the value of these attributes are estimated on a six-point scale where 1 corresponds to low and 6 corresponds to high values.

15. Post-Architecture
Post-architecture is based on the same formula (Effort = A*Sizeb*M) as early design, but the size estimates are now more accurate.
M is more accurate. More extensive set of 17 attributes instead of 7 are used to refine the effort computation, because more information is available about the software and the development process.
You can refer to Figure on page 633 of Software Engineering to explain these factors.

16. Function Point Analysis
A function point (FP) is a measure of the functionality of the software product, independent of the technology used.
The steps involved in calculating the FPs for a software application are:
Define the application boundary.
List all the external input values, output values, inquiries, internal logical files (ILFs) and external interface files (EIFs).
Group the listed items based on their complexity factor as low, medium, and high.
Consolidate the counts and apply the standard FPA weights.
You can use the details given on pages of The Project Manager’s Guide to Software Engineering’s Best Practices to explain FPA.
Explain the categorization process of functions as follows :
List all the inputs, outputs, inquiries, internal logical files, and external interface files. Add functions required to provide Help for using the application. Include database administration and data processing functions also.
Input values: All maintenance and transaction entry (data entry) functions are listed under this category. Add, Modify, and Delete functions of the same input should be treated as one function. Any other function, such as Authorization, should be counted separately.
Output values: All reports or ASCII dumps should be considered under this category. Similar reports with format differences, such as columns, grouping, and totals, should be counted separately. Output values also includes reports on screen and error messages.
Inquiries: All inquiry functions that enable viewing of output based on Input values given by the user can be listed as inquiries. Inquiries do not maintain any data files. The look-ups and searches on data should be considered as inquiries.
Internal logical files (ILFs): An ILF is a user-identifiable group of logically related data or control information maintained within the boundary of the application. ILFs, which can be mapped to physical business entities, are listed under this category. Only the ILFs that will be maintained by the application to deliver a function to the user should be counted. An ILF or an interface should be counted only once even if many processes in the application maintain it. Temporary tables and worktables should not be counted. Examples of ILFs include tables in a relational database, flat files, application control information, and LDAP data stores.
External interface files (EIFs): Functions that enable the software to communicate with external systems should be counted as EIFs. For example, file uploads and downloads, utilities to connect to other databases, and legacy systems are also listed as EIFs .

17. Function Point Analysis (cont.)
Consider the following application. The following table lists the weights and counts for the five categories of external and internal data based on their complexity.
Functions
Low
Medium
High
Count
Weight
Total
UFC
Input Values 4 3 12 8 32 1 6 50
Output Values 11 44 25 5
125 17 7
119
288
Inquiries 2 14
Interfaces 16 80 42
294 10
374
Internal Logical Files 28
196 70 15
105
371
Totals 59
332 84
529 26
236
1097
You can explain that the counts in each category are multiplied by the corresponding weights and the sum total is called the unadjusted function count (UFC) which is 1097 for this application.

18. Function Point Analysis (cont.)
Determine the Degree of Influence (DI) on a scale of 0-5 for each of the complexity factors given in the following table. Compute the sum as TDI.
Complexity Adjustment factors DI 1
Data communication 5 2
Distributed functions 3
Performance 4
Heavily utilized operational environment
Transaction rate 6
On-line data entry 7
Design for end-user efficiency 8
On-line master updates 9
Complex processing 10
Code reusability 11
Installation ease 12
Operational ease 13
Multiple sites 14
Ease of change 40
1. You need to judge the degree of influence of given application characteristics on a scale of 0-5, where 0 means no influence and 5 means strong influence. Calculate the total degree of influence by summing up all the given factors.
2.The Total Complexity Factor (TCF) = *40 = 1.05
Calculate final adjusted function point count as follows:
FP = UFC * TCF
FP = 1097 * 1.05 = 1152 (Rounded)
3. Compute the total effort by applying the rate of productivity in hours/FP. Productivity rates are compiled over a period of time by the organizations. If the organization has not maintained these figures, Industry standards can be referred and noted along with the estimate.
For example, if the application has to be developed in VB and Oracle for which the organization productivity rate is 20 FP/PM, Total Effort = 1152/20 = 57.6 Person Months = 60 PM (approximately.)
4. The function point count for an application can be converted into LOC as follows:
The average lines of code (ALOC) can vary from 128 LOC/FP for C, 23 LOC/FP for Oracle developer 2000 to 2-40 LOC/FP for a database programming language.
LOC for Oracle developer 2000 = 23*1152 = 26,496.

19. FPA – Best Practices
For large projects where the effort is more than person years, FPA estimates should be done by two persons independently. A discussion should follow to reconcile the differences.
A large application can be divided into several modules. Function point estimates should be calculated for each module separately and then compiled.

20. FPA – Best Practices (cont.)
Inter-module input values, output values and interfaces should be counted only once.
An organization wide common understanding of criteria, which define the input, output, inquiries, ILFs, and EIFs should exist.

21. Class Activity - 2
Compute the unadjusted function point count for a project that has the following functions:
User input values – 20 low, 12 medium complexity
Output values – 12 low, 12 medium and 6 high
Inquiries – 4 medium, 4 high
Files – 10 low, 12 medium
Interfaces – 0
You can divide the class in groups of two.

22. Phase Wise Effort Distribution
Recommended effort distribution across the definition, analysis, and development phases is referred to as rule. (traditional methods)
For object-oriented analysis, it is approximately for:
Analysis
High-level design
Low-level design
Construction
Module/integration testing
System testing
You can add that the effort distribution mainly depends on the size and complexity of the project and the project manager has to use his or her judgment to distribute efforts across phases.

23. Detailed Costing and Scheduling
Detailed costing and scheduling involves the following activities:
Reviewing the contract or SOW to determine overall project objectives and other nontechnical requirements, such as a visit to customer site for reviews is a nontechnical requirement.
Identifying dependencies on external data or events, such as data or reports from a legacy system.
Identifying all project deliverables other than the software application, such as operations manual, user training, and post-delivery on-site support.
You can use the details given on pages of The Project Manager’s Guide to Software Engineering’s Best Practices to explain this.

24. Detailed Costing and Scheduling (cont.)
Partitioning the requirements, deliverables, and activities into work packages.
Identifying dependencies among work packages and sequencing them in serial or in parallel.
Estimating the resources and schedule needed to deliver each package.
Estimating the budgets required by including labor, capital, and expenses.
Evaluating and refining the estimates and budget.
You can tell the students that for this activity, if the project is complex, a cost estimation team is formed, which may consist of the project manager, analyst, designer or architect, and one or two senior members of the development team.

25. Work Packages
A work package is a discrete task, performed to achieve the project objectives.
A work package specification should consist of:
Description of the task
Preconditions, such as SRS or architectural design
Postconditions, such as approved SRS
Related project objectives
Time, effort, and resources required to complete the work package

26. Example of a Work Package Specification
Activity number: 3.3.2
Activity name: ARCH-SS-XYZ
Activity description: Specify the architectural structure of subsystem XYZ
Project requirement: Deliverable prime software, WBS 5.6
Estimated duration: 5 weeks
Earned value status method: Incremental in 6 steps. See attached status plan
Resources needed:
Personnel: 2 senior telecom designers
Skill: Designers familiar with S2 protocol
Tools: 1 Sun workstation with IDE; 1 VT100/DEC 785
Travel: One 3-day design review in San Diego
Work/product/postconditions: Architectural specification of SS-XYZ
Test plan for subsystem XYZ
Baselined? Yes for both
Risks: Availability of senior designers
Preconditions: An approved architectural concept of the total system
Completion criteria: PDR sign-off for subsystem XY

27. Monitoring Project Performance
Weekly status report should contain:
Hours spent on the work package
Informal assessment of work package
Issues that can impact schedule, cost, and quality
Reasons for occurrence of these issues and strategies to counter the impact of these issues

28. Monitoring Project Performance (cont.)
To deal with schedule and cost variances, you can :
Scale back the requirements of one or more work packages
Break packages into parallel efforts
Apply more staff, if feasible
Evaluate change in tools and technology
You can explain these points by referring to page of The Project Manager's Guide to Software Engineering’s Best Practices.

29. Earned Value The earned value system is based on three metrics:
Budgeted cost of work scheduled (BCWS): Effort planned to be spent by a given date
Actual cost of work performed (ACWP): Effort actually spent as of the that date
Budgeted cost of work performed (BCWP): The planned effort needed to achieve the present level of work completion as of that date
You can explain that by using the three metrics, it is possible to evaluate how well the effort spent on work packages is following the project plan.

30. Just a Minute
If for a project, BCWP = ACWP and BCWS = BCWP, what can you conclude?
If both are equal, it means that the effort required to achieve the current status is same as the effort planned to achieve this status, and that the effort is expended as the planned schedule. So, the work package will complete on schedule and on budget.

31. Variances Cost Variance: CV = BCWP – ACWP
Schedule Variance: SV = BCWP – BCWS
Cost Performance Index: CPI = BCWP/ACWP
Schedule Performance Index: SPI = BCWP/BCWS
You can tell the students that the value of these variances are indicators of problems in the project which need further analysis.

32. Class Activity - 3
Can you identify the strengths and limitations of the earned value system?
Divide the class in groups of five students for this activity. Compare points from each group and present the final list to the whole class.
The limitations are :
The values of earned value metrics, especially the CPI and SPI, are not very accurate in the early phases of a work package.
When work is started, it may progress slightly less effectively than planned. The reason could be time taken for staff orientation.
The other problem is intrinsic to the formula for CPI = BCWP/ACWP. Initially, both ACWP and BCWP are small. Because ACWP is in the denominator, a small uncertainty in its value can result in high uncertainties in the value of CPI. So, it is not very reliable.
The metrics value becomes more accurate as the project progresses. But, by that time, half or even more than half of the project is over.

33. Summary
What was your key learning from the unit?