4. INTRODUCTION
Estimation models uses empirically derived formulas to
predict the estimates.
Here we conduct a study on some completed projects.
From those observation we form some statistical
formulas.
We can use this formulas to estimate the cost of other
projects.
The structure of empirical estimation models is a
formula, derived from data collected from past software
projects.
5. THE STRUCTURE OF ESTIMATION
MODELS
The overall structure of such models takes the form –
Where,
A, B and C – empirically derived constants
E – effort in person-months
ev – estimation variable (LOC or FP)
C
v
e
B
A
E )
(
*
6. THE COCOMO II MODEL
Stands for COnstructive COst MOdel
Introduced by Barry Boehm in 1981
Became one of the well-known and widely-used
estimation models in the industry
It has evolved into a more comprehensive estimation
model called COCOMO II, with reuse property.
7. THE COCOMO II MODEL
COCOMO II is actually a 3 level hierarchy of estimation
models that address the following areas:
Application composition model - Used during the
early stages of software engineering process.
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.
8. THE COCOMO II MODEL
The COCOMO II models require sizing information
Three different sizing options are available as part of
the model hierarchy:
Object points (OP)
Function points (FP)
Lines of source code (LOC)
The COCOMO II application model uses object points
(OP)
9. THE COCOMO II MODEL
Object Point is an indirect software measure that is
computed using counts of no. of –
Screens
Reports
Components likely to be required to build the
application
Each of the above object instance is classified into one
of the three complexity levels – simple, medium or
difficult
11. THE COCOMO II MODEL
The object point count is then determined by
multiplying the original no. of object instances by the
weighting factor and summing to obtain a total object
point count
NOP = (object points) x [(1-%reuse)/100]
Where, NOP – new object points
PROD = NOP / OP person-month
Where, PROD – productivity rate
Estimated project effort = NOP / PROD
14. Example
The system includes:
6 screens: 2 simple + 3 medium + 1 difficult
3 reports: 2 medium + 1 difficult
2 3GL components
30 % of the objects could be supplied from
previously developed components
Productivity is high.
Calculate estimated effort.
17. THE SOFTWARE EQUATION
The software equation is a dynamic multivariable model
that assumes a specific distribution of effort over the life
of a software development project
The model has been derived from productivity data
collected for over 4000 contemporary software projects.
An estimation model form –
4
3
333
.
0
1
*
*
t
P
B
LOC
E
18. THE SOFTWARE EQUATION
Where,
E = effort in person-months/years
t = project duration in months/years
B = special skills factor
P = productivity parameter that reflects overall
process and management practices
Typical values –
P = 2000 (real-time embedded software)
P = 10,000 (telecommunication & system software)
P = 28,000 (business applications)
21. INTRODUCTION
It is often more cost effective to acquire rather than to
develop software
Managers have many acquisition options-
Software may be purchased (or licensed) off the
shelf
“Full-experience” or “partial-experience” software
components may be acquired and integrated to meet
specific needs
Software may be custom built by an outside
contractor to meet the purchaser’s specifications
22. INTRODUCTION
The make/buy decision can be made based on the
following conditions
Will the software product be available sooner than
internally developed software?
Will the cost of acquisition plus the cost of
customization be less than the cost of developing the
software internally?
Will the cost of outside support (e.g., a maintenance
contract) be less than the cost of internal support?
23. CREATING A DECISION TREE
Consider a decision tree for a software based system X
In this case, the software engineering organization can
Build system X from scratch
Reuse existing partial-experience components
construct the system
Buy an available software product and modify it to
meet local needs
Contract the software development to an outside
vendor
26. OUTSOURCING
Software engineering activities are contracted to a
third party who does the work at lower cost and,
hopefully, higher quality
The decision to outsource can be either strategic or
tactical
Strategic – business managers consider whether
significant portion of all software work can be
contracted to others
Tactical – a project manager determines whether part
or all of a project can be best accomplished by
subcontracting the software work