1. Estimation for Software Projects

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!

3. Project Planning Task Set-I
Establish project scope
Determine feasibility
Analyze risks
Risk analysis is considered in detail Later.
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 is considered in detail Later.
Establish a meaningful task set
Define a task network
Use scheduling tools to develop a timeline chart
Define schedule tracking mechanisms

5. Estimation
“Good estimating approaches and solid historical data offer the best hope that reality will win out over impossible demands.”
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
Project complexity, project size, and the degree of structural uncertainty all affect the reliability of estimates.

6. 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.

7. Resources

8. Software Project Estimation
To achieve reliable cost and effort estimates, a number of options arise:
Delay estimation until late in the project (obviously, we can achieve 100 percent accurate estimates after the project is complete!).
Base estimates on similar projects that have already been completed.
Use relatively simple decomposition techniques to generate project cost and effort estimates.
Use one or more empirical models for software cost and effort estimation.

9. Estimation Techniques
Past (similar) project experience
Conventional estimation techniques
Task breakdown and effort estimates
Size (e.g., FP) estimates
Empirical models
Automated tools

10. Decomposition Techniques Software Sizing
The accuracy of a software project estimate is predicated on a number of things:
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.

11. Putnam and Myers [Put92] suggest four different approaches to the sizing problem: 
“Fuzzy logic” sizing. This approach uses the approximate reasoning techniques that are the cornerstone of fuzzy logic. To apply this approach, the planner must identify the type of application, establish its magnitude on a qualitative scale, and then refine the magnitude within the original range.
Function point sizing. The planner develops estimates of the information domain characteristics.
Standard component sizing. Software is composed of a number of different “standard component” that are generic to a particular application area. For example, the standard components for an information system are subsystems, modules, screens, reports, interactive programs, batch programs, files, LOC, and object-level instructions. The project planner estimates the number of occurrences of each standard component and then uses historical project data to estimate the delivered size per standard components.
Change sizing. This approach is used when a project encompasses the use of existing software that must be modified in some way as part of a project. The planner estimates the number and type (e.g., reuse, adding code, changing code, deleting code) of modifications that must be accomplished.

12. Problem-Based Estimation
lines of code and function points were described as measures from which productivity metrics can be computed. LOC and FP data are used in two ways during software project estimation:
(1) as estimation variables to “size” each element of the software and
(2) as baseline metrics collected from past projects and used in conjunction with estimation variables to develop cost and effort projections.

13. Conventional Methods:LOC/FP Approach
Compute LOC/FP using estimates of information domain values
Use historical data to build estimates for the project

14. An Example of LOC-Based Estimation
Function
Estimated LOC
User interface and control facilities (UICF)
2,300
Two-dimensional geometric analysis (2DGA)
5,300
Three-dimensional geometric analysis (3DGA)
6,800
Database management (DBM)
3,350
Computer graphics display facilities (CGDF)
4,950
Peripheral control function (PCF)
2,100
Design analysis modules (DAM)
8,400
Estimated lines of code
33,200
Estimation table for the LOC methods

15. An Example of FP-Based Estimation
Estimation table for the LOC methods
Factor
Backup and recovery
Value 4
Data communications 2
Distributed processing
Performance critical
Existing operating environment 3
Online data entry
Input transaction over multiple screens 5
Master files updated online
Information domain values complex
Internal processing complex
Code designed for reuse
Conversion/installation in design
Multiple installations
Application designed for change
Value adjustment factor
1.17
Est. FP
Information domain value
Opt.
Likely
Pess.
count
Weight
Number of external inputs 20 24 30 4 97
Number of external outputs 12 15 22 16 5 78
Number of external inquiries 28 88
Number of internal logical files 10 42
Number of external interface files 2 3 7
Count total 320

16. Empirical Estimation Models
General form:
effort = tuning coefficient * size
exponent
usually derived
as person-months
of effort required
either a constant or
a number derived based
on complexity of project
usually LOC but
may also be
function point
empirically
derived

17. The Structure of Estimation Models

18. 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.

19. screens (at the user interface), reports, and
Like all estimation models for software, the COCOMO II models require sizing information. Three different sizing options are available as part of the model hierarchy: object points, function points, and lines of source code.
Object type
Complexity weight
Simple
Medium
Difficult
Screen 1 2 3
Report 5 8
3GL component 10
Complexity weighting for object types.
The COCOMO II application composition model uses object points and is illustrated in the following paragraphs. It should be noted that other, more sophisticated estimation models (using FP and KLOC) are also available as part of COCOMO II.
Like function points, the object point is an indirect software measure that is computed using counts of the number of
screens (at the user interface),
reports, and
components likely to be required to build the application.
Each object instance (e.g., a screen or report) is classified into one of three complexity levels (i.e., simple, medium, or difficult) using criteria suggested by Boehm [Boe96].

20. The Software Equation A dynamic multivariable model
E = [LOC x B0.333/P3] 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”
Typical values might be P=2000 for development of real-time embedded software, P=10,000 for telecommunication and systems software, and P=28,000 for business systems applications.

21. You should note that the software equation has two independent parameters:
(1) an estimate of size (in LOC) and (2) an indication of project duration in calendar months or years.

22. Estimation for WebApp Projects
WebApp projects often adopt the agile process model. Roetzheim [Roe00] suggests the following approach when adapting function points for WebApp estimation:
Inputs are each input screen or form (for example, CGI or Java), each maintenance screen, and if you use a tab notebook metaphor anywhere, each tab.
Outputs are each static Web page, each dynamic Web page script (for example, ASP, ISAPI, or other DHTML script), and each report (whether Web based or administrative in nature).
Tables are each logical table in the database plus, if you are using XML to store data in a file, each XML object (or collection of XML attributes).
Interfaces retain their definition as logical files (for example, unique record formats) into our out-of-the-system boundaries.
Queries are each externally published or use a message-oriented interface. A typical example is DCOM or COM external references.
Mendes and her colleagues [Men01] suggest that the volume of a WebApp is best determined by collecting measures (called “predictor variables”) associated with the application (e.g., page count, media count, function count), its Web page characteristics (e.g., page complexity, linking complexity, graphic complexity), media characteristics (e.g., media duration), and functional characteristics (e.g., code length, reused code length).

23. The Make-Buy Decision

24. Computing Expected Cost
(path probability) x (estimated path cost) i
For example, the expected cost to build is:
expected cost = 0.30 ($380K) ($450K)
similarly,
expected cost = $382K
expected cost = $267K
expected cost = $410K
build
reuse
buy
contr
expected cost =
= $429 K

25. Thanks…