1. Chapter 26 Estimation for Software Projects
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

2. Software Project Planning
The overall goal of project planning is to establish a pragmatic strategy for controlling, tracking, and monitoring a complex technical project.
Why?
So the end result gets done on time, with quality!
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

3. Project Planning Task Set-I
Establish project scope
Determine feasibility
Analyze risks
Risk analysis.
Define required resources
Determine require human resources
Define reusable software resources
Identify environmental resources

4. Project Planning Task Set-II
Estimate cost and effort
Decompose the problem
Develop two or more estimates using size, function points, process tasks or use-cases
Reconcile the estimates
Develop a project schedule
Scheduling
Establish a meaningful task set
Define a task network
Use scheduling tools to develop a timeline chart
Define schedule tracking mechanisms

5. Estimation
Estimation of resources, cost, and schedule for a software engineering effort requires
experience
access to good historical information (metrics)
the courage to commit to quantitative predictions when qualitative information is all that exists
Estimation carries inherent risk and this risk leads to uncertainty

6. Write it Down! Project Scope Software Estimates Project Risks Plan
Schedule
Control strategy
Software
Project
Plan
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

7. To Understand Scope ... Understand the customers needs
understand the business context
understand the project boundaries
understand the customer’s motivation
understand the likely paths for change
understand that ...
Even when you understand,
nothing is guaranteed!
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

8. What is Scope? Software scope describes
the functions and features that are to be delivered to end-users
the data that are input and output
the “content” that is presented to users as a consequence of using the software
the performance, constraints, interfaces, and reliability that bound the system.
Scope is defined using one of two techniques:
A narrative description of software scope is developed after communication with all stakeholders.
A set of use-cases is developed by end-users.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

9. Resources
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

10. Project Estimation Project scope must be understood
Elaboration (decomposition) is necessary
Historical metrics are very helpful
At least two different techniques should be used
Uncertainty is inherent in the process
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

11. Estimation Techniques
Past (similar) project experience
Conventional estimation techniques
task breakdown and effort estimates
size (e.g., FP) estimates
Empirical models
Automated tools
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

12. Estimation Accuracy Predicated on …
the degree to which the planner has properly estimated the size of the product to be built
the ability to translate the size estimate into human effort, calendar time, and dollars (a function of the availability of reliable software metrics from past projects)
the degree to which the project plan reflects the abilities of the software team
the stability of product requirements and the environment that supports the software engineering effort.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

13. Functional Decomposition
Statement of
Scope
functional
decomposition
Perform a Grammatical “parse”
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

14. Conventional Methods: LOC/FP Approach
compute LOC/FP using estimates of information domain values
use historical data to build estimates for the project
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

15. LOC/KLOC LOC: lines of code
KLOC: kilo lines of code, or (lines of code) / 1000
Still regarded as most accurate way to measure labor costs
What are some uncertainties about measuring LOC?
Should comment lines count? Or blank lines for formatting?
How do we compare lines of assembly language vs. high-level language like C++ or Java?
How do you know how many LOC the system will contain when it’s not implemented or even designed yet?
How do you account for reuse of code?

16. Function-Oriented Metrics
Mainly used in business applications
The focus is on program functionality
A measure of the information domain + a subjective assessment of complexity
Most common are:
function points and
feature points (FP) .

17. Function Points
STEP 1: measure size in terms of the amount of functionality in a system. Function points are computed by first calculating an unadjusted function point count (UFC). Counts are made for the following categories
·External inputs – those items provided by the user that describe distinct application-oriented data (such as file names and menu selections)
·External outputs – those items provided to the user that generate distinct application-oriented data (such as reports and messages, rather than the individual components of these)
R.L. Probert
SEG3300 A&B W2004

18. Function Points(.)
· External inquiries – interactive inputs requiring a response
· External files – machine-readable interfaces to other systems
· Internal files – logical master files in the system
R.L. Probert
SEG3300 A&B W2004

19. Function Points
The function point metric is evaluated using the following tables:
Weighting Factor
Parameter
Count
Simple
Average
Complex
Weight
# of user inputs
* 3 4
6 =
# of user outputs
* 4 5
7 =
#of user inquiries
# of files
* 7 10
15 =
# of external interfaces
* 5 7
10 =
Total_weight =

20. Function Points
The following relationship is used to compute function points:

21. Function Points
where Fi (i = 1 to 14) are complexity adjustment values based on the table below:
Reliable backup/recovery needed?
Any data communications needed?
Any distributed processing functions?
Performance critical?
Will system run in an existing heavily utilized operational environment?
Any on-line data entry?
Does on-line data entry need multiple screens/operations?

22. Function Points Are master files updated on-line?
Are inputs, outputs, queries complex?
Is internal processing complex?
Must code be reusable?
Are conversion and installation included in design?
Is multiple installations in different organizations needed in design?
Is the application to facilitate change and ease of use by user?

23. Function Points
Each of the Fi criteria are given a rating of 0 to 5 as:
No Influence = 0; Incidental = 1;
Moderate = 2 Average = 3;
Significant = Essential = 5

24. Function-Oriented Metrics
Once function points are calculated, they are used in a manner analogous to LOC as a measure of software productivity, quality and other attributes, e.g.:
productivity FP/person-month
quality faults/FP
cost $$/FP
documentation doc_pages/FP

25. Example
R.L. Probert
SEG3300 A&B W2004

26. Example (.)
R.L. Probert
SEG3300 A&B W2004

27. Example (..) Technical Complexity Factors:
1. Data Communication 3
2. Distributed Data Processing 0
3. Performance Criteria 4
4. Heavily Utilized Hardware 0
5. High Transaction Rates 3
6. Online Data Entry 3
7. Online Updating 3
8. End-user Efficiency 3
9. Complex Computations 0
10. Reusability 3
11. Ease of Installation 3
12. Ease of Operation 5
13. Portability 3
14. Maintainability 3
DI =30 (Degree of Influence)
R.L. Probert
SEG3300 A&B W2004

28. Example (…) Function Points
FP=UFP*( *DI)= 55*( *30)=52.25
That means the is FP=52.25
R.L. Probert
SEG3300 A&B W2004

29. Process-Based Estimation
Obtained from “process framework”
framework activities
application
functions
Effort required to accomplish
each framework activity for each application function
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

30. COCOMO 81 COCOMO stands for COnstructive COst MOdel
It is an open system First published by Dr Barry Bohem in 1981
Worked quite well for projects in the 80’s and early 90’s
Could estimate results within ~20% of the actual values 68% of the time

31. COCOMO 81
COCOMO has three different models (each one increasing with detail and accuracy):
Basic, applied early in a project
Intermediate, applied after requirements are specified.
Advanced, applied after design is complete

32. COCOMO COCOMO has three different modes:
Organic – “relatively small software teams develop software in a highly familiar, in-house environment” [Bohem]
Embedded – operate within tight constraints, product is strongly tied to “complex of hardware, software, regulations, and operational procedures” [Bohem]
Semi-detached – intermediate stage somewhere between organic and embedded. Usually up to 300 KDSI
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

33. COCOMO 81
COCOMO uses two equations to calculate effort in man months (MM) and the number on months estimated for project (TDEV)
MM is based on the number of thousand lines of delivered instructions/source (KDSI)
MM = a(KDSI)b * EAF
TDEV = c(MM)d
EAF is the Effort Adjustment Factor derived from the Cost Drivers, EAF for the basic model is 1
The values for a, b, c, and d differ depending on which mode you are using
The Intermediate Model estimates the software development effort by using fifteen cost driver variables besides the size variable used in Basic COCOMO.
Product Attributes
RELY:  Required Software Reliability The extent to which the software product must perform its intended functions satisfactorily over a period of time.
DATA:  Data Base Size The degree of the total amount of data to be assembled for the data base.
CPLX:  Software Product Complexity The level of complexity of the product to be developed.
Computer Attributes
TIME --- Execution Time Constraint The degree of the execution constraint imposed upon a software product.
STOR --- Main Storage Constraint The degree of main storage constraint imposed upon a software product.
VIRT --- Virtual Machine Volatility The level of the virtual machine underlying the product to be developed.
TURN --- Computer Turnaround Time The level of computer response time experienced by the project team developing the product.
Personnel Attributes
ACAP:  Analyst Capability The level of capability of the analysts working on a software product.
AEXP:  Applications Experience The level of applications experience of the project team developing the software product.
PCAP:  Programmer Capability The level of capability of the programmers working on the software product.
VEXP:  Virtual Machine Experience The level of virtual machine experience of the project team developing the product.
LEXP:  Programming Language Experience The level of programming language experience of the project team developing the product.
Project Attributes
MODP:  Use of Modern Programming Practices The degree to which modern programming practices (MPPs) are used in developing software product.
TOOL:  Use of Software Tools The degree to which software tools are used in developing the software product.
SCED:  Schedule Constraint The level of schedule constraint imposed upon the project team developing the software product.
Mode a b c d
Organic
2.4
1.05
2.5
0.38
Semi-detached
3.0
1.12
0.35
Embedded
3.6
1.20
0.32

34. COCOMO 81 A simple example:
Project is a flight control system (mission critical) with 310,000 DSI in embedded mode
Reliability must be very high (RELY=1.40).  So we can calculate:
Effort = 1.40*3.6*(319)1.20 = 5093 MM
Schedule = 2.5*(5093)0.32 = 38.4 months
Average Staffing = 5093 MM/38.4 months = 133 FSP

35. COCOMO II Main objectives of COCOMO II:
To develop a software cost and schedule estimation model tuned to the life cycle practices of the 1990’s and 2000’s
To develop software cost database and tool support capabilities for continuous model improvement
From “Cost Models for Future Software Life Cycle Processes: COCOMO 2.0," Annals of Software Engineering, (1995).

36. COCOMO-II
COCOMO II is actually a hierarchy of estimation models that address the following areas:
Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount.
Early design stage model. Used once requirements have been stabilized and basic software architecture has been established.
Post-architecture-stage model. Used during the construction of the software.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

37. COCOMO II Differences
The exponent value b in the effort equation is replaced with a variable value based on five scale factors rather then constants
Size of project can be listed as object points, function points or source lines of code (SLOC).
EAF is calculated from seventeen cost drivers better suited for today's methods, COCOMO81 has fifteen
A breakage rating has been added to address volatility of system
9. Does COCOMO II replace traditional COCOMO?
You should use COCOMO II for most of your new projects.
COCOMO 81 is still the best approach for some software projects. If you're using a fairly traditional approach, and using a 3GL (third generation language), such as C, Fortran, or Cobol, the original COCOMO will give you good results.  If your development tools and processes haven't changed much in recent years, COCOMO 81 might be the right model for you.
If you're using more modern tools, a new development process model, a 4GL language, or tools like Visual Basic, Delphi, or Power Builder, you might find that COCOMO II makes more sense.
When in doubt, try to model your project using both the traditional COCOMO and COCOMO II.

38. The Software Equation A dynamic multivariable model
E = [LOC x B0.333/P]3 x (1/t4)
where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter”
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

39. Estimation for OO Projects-I
Develop estimates using effort decomposition, FP analysis, and any other method that is applicable for conventional applications.
Using object-oriented requirements modeling (Chapter 6), develop use-cases and determine a count.
From the analysis model, determine the number of key classes (called analysis classes in Chapter 6).
Categorize the type of interface for the application and develop a multiplier for support classes:
Interface type Multiplier
No GUI
Text-based user interface
GUI
Complex GUI
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

40. Estimation for OO Projects-II
Multiply the number of key classes (step 3) by the multiplier to obtain an estimate for the number of support classes.
Multiply the total number of classes (key + support) by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class.
Cross check the class-based estimate by multiplying the average number of work-units per use-case
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

41. Estimation for Agile Projects
Each user scenario (a mini-use-case) is considered separately for estimation purposes.
The scenario is decomposed into the set of software engineering tasks that will be required to develop it.
Each task is estimated separately. Note: estimation can be based on historical data, an empirical model, or “experience.”
Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some other volume-oriented measure (e.g., use-case count).
Estimates for each task are summed to create an estimate for the scenario.
Alternatively, the volume estimate for the scenario is translated into effort using historical data.
The effort estimates for all scenarios that are to be implemented for a given software increment are summed to develop the effort estimate for the increment.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

42. The Make-Buy Decision
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

43. Computing Expected Cost
(path probability) x (estimated path cost) i i
For example, the expected cost to build is:
expected cost = 0.30 ($380K) ($450K)
build
= $429 K
similarly,
expected cost = $382K
reuse
expected cost = $267K
buy
expected cost = $410K
contr
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.