Software Cost

Estimation

4/6/2017 1
2
Boss with spreadsheet…

3
 Fundamental estimation questions
 What is the size of the software to be
developed?
 How much effort is required to
complete an activity?
 How much calendar time is needed to
complete an activity?
 What is the total cost of an activity?
4
 Estimations and Scheduling

Effort Cost
Estimation Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling

5
 Software cost components
 Hardware and software costs.
 Travel and training costs.
 Effort costs:
 The dominant factor in most projects
 The salaries of engineers involved in the project
 Overheads:
 Costs of building, heating, lighting.
 Costs of networking and communications.
 Costs of shared facilities (e.g library, staff
restaurant, etc.).
 Rule of thumb: as much as the effort costs 6
Why overheads bloat up…

7
And how managers handle it…

8
Computing Overhead Expenses…

9
 Person Month
 Suppose a project is estimated to take 300
person-months to develop:

 Is one person working for 30 days same as 30

persons working for 1 day?

 No? why?

 How many hours is a man month:

 Default Value: 152 hours per month

 19 days at 8 hours per day. 10

How Sacrosanct Is Person Hours?

11
Person-month put to practice…

12
 Why Person-Month and not
Person-days or Person years?
 Modern Projects typically take a
few months to complete...

 Person-years is clearly unsuitable.

 Person-days would make monitoring

and estimation overhead large and
tedious. 13
14
 Mythical Man-Month
 Book: “The Mythical Man-Month”
 Author: Fred Brooks

 The classic book on the

human elements of
software project management.
 First two chapters provide some
excellent insights… 15
The Mythical Man-Month [Brooks, Chapter 2]
 Brooks: Failure to meet schedule is the
reason for most software project failures.
 What is the reason behind sched. slippage?
 We don’t know how to estimate (overly optimistic).
 We confuse effort with progress.
 Software managers give in to pressure to reduce
time estimates because they are uncertain of
their estimate.
 We don’t monitor schedule progress properly.
 We tend to handle schedule slips by adding people.
However, this tends to magnify the problem… 16
Delayed Schedule: Facing the Customer…

17
 Mythical Man-Month
 “Cost varies as product of men and
months, progress does not.”
 Hencethe man-month as a unit for
measuring the size of job is a dangerous
and deceptive myth.

 The myth of additional manpower

 BrooksLaw: “Adding manpower to a
late project makes it later” 18
Brooks Rule 2…

19
Reason for Rule 1

20
 Mythical Man-Month
 Optimism
 “All programmers are optimists”
 1st false assumption: “all will go well” or “each task
takes only as long as it „ought‟ to take”
 The Fix: Consider the larger probabilities
 Cost (overhead) of communication (and training)
 His formula: n(n-1)/2
 How long does a 12 month project take?
 1 person: 1 month
 2 persons = 7 months (2 man-months extra)
 3 persons = 5 months (e man-months extra)

 Fix: don‟t assume adding people will solve the problem

21
Don‟t Assume things would be Available When you Need it

22
23
 Mythical Man-Month
 Q: “How does a project get to be a year
late”?
 A: “One day at a time”
 Continued attention to meeting small individual
milestones is required at each level of
management.

 Other Fixes
 No “fuzzy” milestones
 Identify the “true status”
24
 Take corrective action
How Projects Become
Further Late…

25
26
 Brooks‟ Other ideas…
 The Second-system effect:
 The second system a team designs is the
most dangerous system they would ever
design…
 Tends to incorporate all the additions that
were thought of but not added due to the
inherent time constraints in the first
system.
 The team should be mindful that it is
susceptible to over-engineering. 27
 Costing and pricing
 Estimates are made to discover the
cost of producing a software system.
 However, there is no simple relationship
between the development cost and the
price charged to the customer.

 Broader organisational, economic,

political and business considerations
influence the price charged.
28
Political decisions in project costing…

29
 Cost Estimation Process

Effort
Requirements
Development Time
Estimation
Process Number of Personnel

Other Cost Drivers Cost

30
 Software pricing factors
Market A development organisation may quote a low price because it
opportunity wishes to move into a new segment of the soft ware market.
Accepting a low profit on one project may give the opportunity
of more profit later. The experience gained may allow new
products to be developed.
Cost estimate If an o rganisation is unsure of its cost estimate, it may increase
uncertainty its price by some contingency over and above its normal profit.
Contractual terms A c ustomer may be willing to allow the developer to retain
ownership of the source code and reuse it in other projects. The
price charged may then be less than if the soft ware source code
is handed over to the customer.
Requirements If the requirements are likely to change, an organisation may
volatility lower its price to win a contract. After the contract is awarded,
high prices can be charged fo r changes to the requirements.
Financial health Developers in financial difficulty may lower their price to gain
a contract. It is better to make a smaller than normal profit or
31
break even than to go out of business.
Giving Estimate to the Boss…

32
 Some problems with estimating
 Subjective nature of much of estimating:
 It may be difficult to produce evidence to support
your precise target
 Political pressures:
 Managers may wish to reduce estimated costs in order
to win support for acceptance of a project proposal
 Changing technologies:
 These bring uncertainties.
 Projects differ:
 Experience on one project may not be applicable to
another 33
Pitfalls of underestimating…

34
 Words of wisdom

 Unless a software project has

clear definitions of its key
milestones and realistic estimates
of the time and money it will take
to achieve them, there is no way
that a project manager can tell
whether the project is under
control or not…
35
36
 When are estimates required?
Project phase Estimates required
Initiation Time, cost and benefit estimates
in project definition.
Planning Time estimates in project
schedule.
Cost estimates in project budget.
Cost and benefit estimates in
business case.
Start of Time and cost estimates
project stages reconfirmed for the stage.
37
 The Software Estimation Story
 Software estimation, is a process of gradual
refinement.
 Can you build a 3-bedroom house for 50Lakhs?
 Can you build a health monitoring software 10Lakhs?
 Some organizations want cost estimates to be
presented upfront:
 Before they fund work on requirements definition.
 Experienced managers present an estimate by
taking various risks into account.
 Novices tend to underestimate and over-commit!
38
* Copyright 2007, The DSW Group Ltd.
38
 Estimate-Convergence Graph
Project Cost
(effort and size) Project
Schedule
4 1.6

2 1.25

1.5 1.15
1.25 1.1
1.0 1.0
0.8 0.9
0.67 0.85

0.5 0.8

0.25 0.6
Initial Approved Requirements Architecture Detailed Product
product product specification design design complete
39
definition definition specification specification
A Case of Poor Estimation…

40
 Over and under-estimating
 Parkinson‟s Law:  Weinberg‟s Zeroth
„Work expands to fill Law of reliability:
the time available‟ „a software project
 Underestimate: that does not have
 Advantage: No to meet a reliability
overspend requirement can
 Disadvantages: meet any other
System is usually requirement‟
unfinished
41
 Effect of Underestimation
 Research results confirm:

 Motivationand morale lowered with highly

aggressive target.

 Underestimation can lead to

abandonment of the project:

 Developersusually respond to highly

pressing deadlines with substandard
work. 42
Aggressive Schedules can Help…
But to a limited extent…

43
Basis for successful estimating
 Information about past projects
 Need to collect performance details
about past project: how big were they?
How much effort/time did they need?
 Need to be able to measure the
amount of work involved
 Traditional
size measurement for
software is „lines of code‟ – but known to
have problems 44
Off hand estimations…

45
 Which view is correct?
 Rough order of magnitude is good enough.
 Spending time on detailed estimating wastes money

 Time is everything; our survival depends on

getting there first!
 Cost accuracy is not an issue.

 The project is internal.

 We don‟t need to worry about cost.

 The uncertainty is so great:

 Spending time and money on estimates is a waste. 46
 Which view is correct?
 The project is so small, we don‟t need to
bother with estimates.
 Just do it.
 They used an internal estimate “for
strategic decisions”:
 Then we had to live with it.
 We were burned once.
 I want a detailed estimate of every task by
the people responsible. 47
When planning too much…

48
 Words of wisdom

“There is no way a cost estimation

technique can compensate for the
lack of definition or understanding
of the software job to be done.”

49
 Refining Estimates
 Reasons for Adjusting Estimates
 Interaction costs are hidden in estimates.
 Normal conditions do not apply.
 Things go wrong on projects.
 Changes in project scope and plans.
 Adjusting Estimates:
 Time and cost estimates of specific activities
are adjusted as the risks, resources, and
situation particulars become more clearly
50
defined.
A taxonomy of estimating methods

 Bottom-up - activity based, analytical

 Parametric or algorithmic models e.g.

function points

 Expert opinion - just guessing?

 Analogy - case-based, comparative

 Price to win
51
 Pricing to win
 The project costs whatever the
customer can spend on it.
 Advantages: You get the contract
 Disadvantages: Costs do not accurately
reflect the work required. Either:
 (1)
the customer does not get the desired
system or
 (2) the customer overpays. 52
 Pricing to win
 This approach may seem unethical and
unbusiness-like….
 However, when detailed information is
lacking it may be the only appropriate
strategy…
 Which is the most ethical approach?
 The project cost is agreed on the basis of an
outline proposal and the development is
constrained by that cost
 A detailed specification may be negotiated
or an evolutionary approach used for system
development
53
 Parameters to be Estimated
 Size is a fundamental measure of work
 Based on the estimated size, two
parameters are estimated:
 Effort Effort
Size
 Duration Duration

 Effort is measured in person-months:

 One person-month is the effort an
individual can typically put in a month.
54
What is size? A Measure of Work…
 Project size is a measure of the problem
complexity in terms of the effort and
time required to develop the product.
 Two metrics are popularly used to measure
project size:
 Source Lines of Code (SLOC)
 Function point (FP)
 SLOC is conceptually simple
 But, FP is now-a-days favoured over SLOC
Because of the many shortcomings of SLOC.
55

 Lines of code
 What's a line of code?
 Originally proposed when programs were
typed on cards with one line per card;
 What happens when statements in Java span
several lines or where there can be several
statements on one line?
 What programs should be counted as part
of the system? GUI? Built-in Class?
 Initially software development consisted
of only writing code… 56
 Lines of Code
 LOC ≡ Line of Code
 KLOC ≡
 Thousands of LOC

 KSLOC ≡
 Thousands of Source LOC

 NCKSLOC ≡
 New or Changed KSLOC 57
LOC: Few things counter intuitive…
 The lower the level of the language, the more
productive the programmer is:
 The same functionality takes more code to
implement in a lower-level language than in a high-
level language.

 The more verbose the programmer, the higher

the productivity:
 Measures of productivity based on lines of code
suggest that programmers who write verbose code
are more productive than programmers who write
compact code. 58
 Major Shortcomings of SLOC
 Difficult to estimate at start of a
project…
 Onlyway to estimate is to make a
guess…
 Only a code measure
 Programmer-dependent
 Does not consider code complexity 59
Further Difficulties With SLOC
 SLOC can become ambiguous due to
rapid changes in programming
methodologies, languages, and tools:
-Language advancements
-Automatic source code generation
-Custom software and reuse
- Object orientation
60
 Estimating techniques
Two commonly used techniques
for obtaining estimates are:
1. Weighted average estimating
2. Consensus estimating

61
 Weighted average estimates
•Weighted average estimating is also known as
sensitivity analysis estimating.
•Three estimates are obtained rather than one.
• Best case (O = Optimistic), worst case (P =
Pessimistic) and most likely (M = Median).
•This provides a more accurate estimate
than when only one estimate is used.
•These are then used in the following formula:

Estimated effort = (O + 4M + P ) / 6
62
 Consensus estimating
Steps in conducting a consensus estimating session:
 A briefing is provided to the estimating team on
the project.
 Each person is provided with a list of work
components to estimate.
 Each person independently estimates O, M and P
for each work component.
 The estimates are written up on the whiteboard.
 Each person discusses the basis and assumptions
for their estimates.
 A revised set of estimates is produced.
 Averages for the O, M and P values are
calculated. 63
 These values are used in the formula.
 Expert judgment
 One or more experts predict software
costs.
 Process iterates until some consensus is
reached.
 Advantages: Relatively simple estimation
method. Can be accurate if experts have
direct experience of similar systems
 Disadvantages: Very inaccurate if there
are no experts available!
64
 Expert Judgment Method: Steps
 Coordinator presents each expert with a specification
and an estimation form.
 Coordinator calls a group meeting in which the experts
discuss estimation issues with the coordinator and each
other.
 Experts fill out forms anonymously
 Coordinator prepares and distributes a summary of the
estimation on an iteration form.
 Coordinator calls a group meeting, specially focusing on
having the experts discuss points where their estimates
varied widely.
 Experts fill out forms, again anonymously, and steps 4 and
6 are iterated for as many rounds as appropriate. 65
 Expert Judgement: Cons
 Hard to quantify
 It is hard to document the factors used by the
experts or expert-group.
 Expert may be biased, optimistic, or pessimistic,
even though they have been decreased by the
group consensus.
 The expert judgment method always
complements the other cost estimating methods
such as algorithmic method.
66
 Expert judgement
 An expert is familiar with and
knowledgeable about the application
area and the technologies
 Particularly appropriate where existing
code is to be modified.
 Research shows that expert
judgement in practice tends to be
based on analogy… 67
 Stages
 Identify significant features of the
current project

 previous project(s) with similar features

 differences between the current and

previous projects

 possible reasons for error (risk)

 measures to reduce uncertainty

68
 Estimation by analogy
 The cost of a project is computed by
comparing the project to a similar project
in the same application domain:
 Advantages:
 May be accurate if project data available and
people/tools the same
 Disadvantages:
 Impossible if no comparable project has been
tackled.
 Needs systematically maintained cost database
69
Making Analogy Method Effective …
 Success of this method crucially depends on:
 “How best to describe projects?”

 A set of parameters may be used:

 The choice of parameters must be restricted to those
that are available at the point of prediction.

 Possibilities include:
 The type of application domain,
 The number of inputs, the number of distinct entities
referenced,
 the number of screens, and so forth. 70
 Estimating by analogy
Use effort
source cases from source as
An estimate
attribute values effort

attribute values effort target case

attribute values effort attribute values ?????

attribute values effort

attribute values effort

attribute values effort Select case

with closet attribute
values 71
 source selection
Source A
Source B

It-Is

Ot-Os
target

Number of outputs
Euclidean distance=sq root ((It - Is)2 +(Ot - Os)722 )
73
 Delphi Estimation
 A variation of basic expert judgment
technique
 Team of Experts and a coordinator.
 Experts carry out estimation independently:
 mention the rationale behind their estimation.
 coordinator notes down any extraordinary
rationale:
 circulates among experts.
 Experts re-estimate.
 Experts never meet each other
to discuss their viewpoints.
74
 74
Types of Estimation Techniques
 Though there are many techniques of
estimating, they can broadly be classified
into:
 Top-down
 Bottom-up
 What about:
 Algorithmic models?
 Expert opinion ?
 Analogy ?
 Price to win?
75
 Bottom-up versus top-down
 Bottom-up
 identify all tasks that have to be done – so quite
time-consuming
 use when you have no data about similar past
projects
 Top-down
 produce overall estimate based on project cost
drivers based on past project data
 divide overall estimate between jobs to be done
76
 Bottom-up estimating
1. Break the project activities into smaller
and smaller components
o Stop when you get to what one person can do in
one/two weeks

3. Estimate costs for the lowest level

activities

4. At each higher level calculate estimate by

adding estimates for lower levels
77
 Top-down estimates
Estimate  Produce overall
100 days
overall estimate using
project
effort driver(s)

 Distribute
proportions of
design code test
overall estimate to
30% 30% 40% components
i.e. i.e. i.e. 40 days
30 days 30 days

78
Top-down Example

79
 Algorithmic Models
 For project planning, we need:
 Effort (cost)
 Duration
 Hard to estimate effort (or cost) or
duration directly from a problem
description.
 Effort and Duration can be measured in
terms of certain project characteristics
that correlate with it:
 Called size 80
 Software Size
 What exactly is the size of a software
project?
 How do you measure it?

 Any characteristic of software that is

easily measured and correlates with
effort.
 SLOC

 Function point 81
 Algorithmic/Parametric models
 COCOMO (lines of code) and function
points examples of these
 A Problem with LOC based models
(COCOMO etc):
guess algorithm estimate

but what is desired is

system algorithm estimate

characteristic
82
 Top-Down Estimating: Pros
 It accounts for system-level activities
such as integration, documentation,
configuration management, etc.:
 Manyof these may be ignored in
bottom-up estimating methods.

 It requires minimal project details:

 It is usually faster, easier to implement.
83
 Top-Down Estimating: Cons
 It often does not identify the
difficult low-level problems:

 Tends to underestimate by overlooking

low-level components.

 It provides no detailed basis for

justifying decisions or estimates.

84
 Bottom-up Estimating: Pro
 It permits the software group to estimate
in an almost traditional fashion:

 And to handle estimate components for which

the group has a feel.

 It is more stable because the estimation

errors in the various components have a
chance to balance out.
85
 Bottom-up Estimating: Con
 It may overlook many of the system-level costs:
 Integration,

 configuration management,

 quality assurance, etc.

 It may be inaccurate because the necessary

information may not be available in the early
phase.

 It tends to be more time-consuming.

86
 Algorithmic Methods: Pro
 It is able to generate repeatable
estimations.
 It is easy to modify input data, refine and
customise formulas.
 It is efficient and able to support a family
of estimations or a sensitivity analysis.
 It can be meaningfully calibrated to
previous experience. 87
 Algorithmic Methods: Con
 It lacks means to deal with exceptional
conditions, such as:
 exceptional teamwork, exceptional match
between skill-levels and tasks, etc.

 Poor sizing inputs and inaccurate cost

driver rating will result in inaccurate
estimation.
 Some factors such as experience can not be
easily quantified. 88
 Model Calibration
 Many models are developed for specific
situations and are, by definition, calibrated to
that situation.
 Such models usually are not useful outside of
their particular environment.
 Calibration is needed to increase the accuracy of one
of these general models.
 Calibration is in a sense customising a generic model.

 Items that can be calibrated in a model include:

 product types, operating environments, labor rates
and factors, various relationships between functional
89
cost items, etc.
 Some recommendations
 Do not depend on a single cost or schedule estimate.
 Use several estimating techniques or cost models:
 Compare the results and determine the reasons for any large
variations.

 Document the assumptions made when making the

estimates.
 Monitor the project to detect when assumptions that
turn out to be wrong jeopardize the accuracy of the
estimate.
 Improve software process:
 Maintain a historical database 90
 Simplistic Model
 estimated effort = (system size)
/ productivity
What is wrong with the
 As example: simplistic model?

system size = lines of code

productivity = lines of code per day
 productivity = (system size) / effort
 based on past projects
91
 Example 1
Consider a transaction project of 38,000 lines of
code, what is the shortest time it will take to
develop? Productivity is about 400 SLOC/staff
month
Effort = (productivity)-1 (size)
= (1/.400 KSLOC/SM) (38 KSLOC)
= 2.5 (38) ≈ 100 SM
Min time = .75 T= (.75)(2.5)(SM)1/3
≈ 1.875(100)1/3
≈ 1.875 x 4.63 ≈ 9 months 92
 Parametric model for Size
Important example: Function Points
FPs originally used to estimate Lines of Code,
rather than effort

Number
of file types

„system
model size‟

Numbers of input
and output transaction types
93
 Parametric model for Effort

 Lines of code (or FPs etc) an input

System Estimated effort

size

Productivity
factors

94
 Parametric models for Size
 We shall now examine four
parametric models more closely :
1. Albrecht/IFPUG function points

2.Symons/Mark II function points

3.COSMIC function points

4.COCOMO81 and COCOMO II 95

 INTERNATIONAL FUNCTION POINT
USERS GROUP (IFPUG)
Purpose
• To promote and encourage use of Function Points
• To develop consistent and accurate counting guidelines

Benefits
• Networking with other counters
• IFPUG Counting Practices Manual
• Research projects
• Hotline
• Newsletter
• Certification

Extent of Usage:
• Member companies include all industry sectors 96
• Over 1200 members in more than 30 countries
 Albrecht/IFPUG function points
 Albrecht worked at IBM:
 Needed a way of measuring the relative
productivity of different programming
languages.
 Needed some way of measuring the size of an
application without counting lines of code.

 Identified five parameters:

 Counted occurrences of each type of
functionality in order to get an indication of the
size of an information system 97
Why IFPUG Thinks One Should Not Use LOC?

 Lines of code tend to reward profligate

design and penalize concise design
 There is no industry standards (ISO or
otherwise) for lines of code
 Lines of code cannot be used for
normalizing across platform, language or
by organization
 Some 4GL do not even use lines of code
 Lines of code can be misleading. 98
 How Do Function Points Overcome
LOC Problems?
 Function points are independent of the
language, tools, or methodologies used for
implementation
 Function points can be estimated early in
analysis and design
 Since function points are based on the
user‟s external view of the system:
 Non-technical users of the software have a
better understanding of what function points
are measuring 99
 Objectives of Function Point Counting
 Measure functionality that the user
requests and receives…
 Measure software development and
maintenance independently of technology
used for implementation…
 Simple enough to minimize the overhead
of the measurement process…
 A consistent measure among various
projects and organizations … 100
 When Should You Count Function Points?
 Early and often
 The sooner you can quantify what a project is
delivering, the sooner it is under control

 Under IFPUG 4.1, there are rules and guidelines:

 Make it possible to count function points once the
requirements have been finalized
 The estimate of size in function points can be refined
continuously through out the development cycle.

 Function points should be recounted throughout

the development process:
 Can measure scope creep and breakage 101
 FP Computation Steps
Count Data
Determine
Functions
Unadjusted
Function
Point
Count
Count
Identify Transactional
Counting Functions Calculate
Scope and Adjusted
Application Function
Determine
Boundary Value Point Count
Adjustment
Factor
102
 Function Point
Five key components are identified
 External Inputs
 External Outputs
 External Inquiries External External External
Input Inquiry Output
 Internal Logical Files
 External Interface Files
Internal
Logical
Files
External
Interface
Application
File
103
 USER
input output inquiry
type type type

Internal
Logical File
External
Interface File
input type
output type
inquiry type
Application Boundary Other Applications
104
Albrecht/IFPUG function points - continued
Five function types
1. Logical interface file (LIF) types
o Equates roughly to a data store in systems
analysis terms. Created and accessed by the
target system

2. External interface file types (EIF)

o Represents data is retrieved from a data store
which is actually maintained by a different
application. 105
 Albrecht/IFPUG function points - continued

3. External input (EI) types:

o Transactions which update internal computer files
4. External output (EO) types:
o Transactions which extract and display data from
internal computer files.
o Generally involves creating reports.
5. External inquiry (EQ) types:
o User initiated transactions which provide information
but do not update computer files.
o Normally the user inputs some data that guides the
system to the information the user needs. 106
 Function Point Parameters
External Input Count each unique user data or user control input type
(Inputs) that (i) enters the external boundary of the software
system being measured and (ii) adds or changes data in a
logical internal file.
External Input (Inputs)

External Output Count each unique user data or control output type that
(Outputs) leaves the external boundary of the software system
being measured.
Internal Logical Count each major logical group of user data or control
File (Files) information in the software system as a logical internal
file type. Include each logical file (e.g., each logical group
of data) that is generated, used, or maintained by the
software system.

External Interface Files passed or shared between software systems should

Files (Interfaces) be counted as external interface file types within each
system.
External Inquiry Count each unique input-output combination, where an
(Queries) input causes and generates an immediate output, as an
external inquiry type. 107
 Definition of External input
An External Input (EI) processes data
that comes from outside the application‟s
boundary.

External Input
1.0
ON-LINE
UPDATE
ENTRY Transaction CUSTOMER
INFORMATION

Multi-Screen

CUSTOMER INFO FILE

108
Definition Of External Output
An External Output (EO) generates data
that is sent outside the application
boundary.
CUSTOMER INFO FILE

External Output
1.0

Category CATEGORIZE
END Summary CUSTOMER
USER INFO

109
 Definition Of An Inquiry
An External Inquiry (EQ) is an output that
results in data retrieval. The result
contains no derived data.
CUSTOMER INFO FILE

External Inquiry

1.0
END Selected DISPLAY
USER Customer CUSTOMER
Info INFO

110
 Definition Of An IL File
An Internal Logical File (ILF) is a user-
identifiable group of logically related data
that is maintained within the boundary of
the application.
END
USER
1.0
UPDATE
CUSTOMER
INFO
Customer Info

Updated Customer Info

CUSTOMER INFO FILE

Internal Logical 111File

Definition Of An External Interface File
 AnExternal Interface File (EIF) is a user-
identifiable group of data referenced by the
application, but maintained within the boundary of
another application.

External Interface File

ZIP CODE
TABLE

VALID ZIP 1.0

CODES
VALIDATE UPDATES
ZIP CODE &
UPDATES UPDATE
CUSTOMER
INFO
END
USER
CUSTOMER INFO FILE

112
 Example
 Place Purchase Order:
 Input data items:
Date, Supplier Number,
Product Code
Quantity Required
Date Required
 Output data items:
PO Number (system generated)
 Entities referenced:
Product, Purchase Order
Supplier, Purchase Order Item 113
 Calculating the System Size
 For each function count:
 Number of input data items ni
 Number of output data items no
 Number of entities read/updated ne

 Add these up for the whole system, giving:

 Number of input data items Ni
 Number of output data items No
 Number of entities read/updated Ne 114
 Function Point Counting
Requiremen inputs outputs entity accesses
t
A1 10 2 4
A2 10 3 6
A3 1 25 1
A4 10 10 9
A5 4 10 5
A6 26 9 2
A7 5 11 8
A8 14 4 5
A9 22 7 4
A10 6 6 4
A11 9 9 7
A12 3 24 5
Ni = 120 No = 120 Ne = 60 115
 Albrecht complexity multipliers
External Low Medium High
user types complexity complexity complexity
EI 3 4 6
EO 4 5 7
EQ 3 4 6
LIF 7 10 15
EIF 5 7 10

116
118
119
 Function Point: Refinement
14 General Systems Characteristics are evaluated and used
to compute a Value Adjustment Factor (VAF)

General System Characteristics

Data Communication On-Line Update
Distributed Data Processing Complex Processing
Performance Objectives Reusability
Heavily Used Configuration Conversion & Install Ease
Transaction Rate Operational Ease
On-Line Data Entry Multiple-Site Use
End-User Efficiency Facilitate Change

The final calculation is based upon the Unadjusted FP count X120VAF

 Degrees of Influence
 0 Not present, or no influence
 1 Incidental influence
 2 Moderate influence
 3 Average influence
 4 Significant influence
 5 Strong influence throughout
121
 Procedures to Determine the VAF
 Evaluate each of the 14 general system characteristics on a scale
from zero to five to determine the degree of influence (DI)

 Add the degrees of influence for all 14 general system

characteristics to produce the total degree of influence (TDI)

 Insert TDI into the following equation to produce the value

adjustment factor.

 VAF = (TDI * 0.01) + 0.65

 Example 1: The following value adjustment factor is calculated if

there are three degrees of influence for each of the 14 GSC
descriptions (3*14)

VAF = (42 * 0.01) + 0.65

VAF = 1.07
122
 Example 2
 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
TDI =30 (Total Degree of Influence)
123

 Example 1 cont…

 Function Points:

 FP=UFP*(0.65+0.01*TDI)=

55*(0.65+0.01*30)=52.25

124
 Example 3
A Payroll application has:
1. Transaction to input, amend and delete employee details – an
EI that is rated of medium complexity
2. A transaction that calculates pay details from timesheet data
that is input – an EI of high complexity
3. A transaction of medium complexity that prints out pay-to-
date details for each employee – EO
4. A file of payroll details for each employee – assessed as of
medium complexity LIF
5. A personnel file maintained by another system is accessed for
name and address details – a simple EIF
What would be the FP counts for these? 125
 FP counts
External Low Medium High
user comple comple comple
types xity xity xity

EI 3 4 6
1. Medium EI = 4 FPs EO 4 5 7
EQ 3 4 6
2. High complexity EI = 6 FPs LIF 7 10 15
EIF 5 7 10
3. Medium complexity EO=5 FPs
4. Medium complexity LIF 10 FPs
5. Simple EIF 5 FPs
Total 30 FPs
If previous projects delivered 5 FPs a day,
implementing the above should take 30/5 = 6
days 126
Exercise 1: Tic-Tac-Toe Computer Game
 As soon as either of the human player or
the computer wins,
 A message announcing the
winner should be displayed.
 If neither player manages to get three
consecutive marks along a straight line,
 And all the squares on the board are filled up,
 Then the game is drawn.
 The computer always tries to win a game.
127
 Exercise 2
 It is needed to develop an Alumni Repository
software for IIM, Ranchi. The software will
extract the details of students from the
existing academic software of IIM, Ranchi. It
will provide an online display of the Alumni
names. The details of the Alumni can be
entered by any one by double clicking on the
Alumni name. The details of Alumni would be
stored in a file. It should be possible to print
out a report detailing all alumni.

 Determine UFP. 128

 Exercise 3: Supermarket Prize Scheme
 A supermarket needs to develop the following software to
encourage regular customers.
 TO register, a customer needs to supply his/her residence address,
telephone number, and the driving license number.
 Each customer who registers for this scheme is assigned a unique
customer number (CN) by the computer.
 Based on the generated CN, a clerk manually prepares a customer
identity card after getting the market manager‟s signature on it.
 A customer can present his customer identity card to the check
out staff when he makes any purchase. In this case, the value of
his purchase is credited against his CN.
 At the end of each year, the supermarket intends to award
surprise gifts to 10 customers who make the highest total purchase
over the year. Also, it intends to award a 22 caret gold coin to
every customer whose purchase exceeded Rs.10,000/-.
 The entries against the CN are reset on the last day of every 129
year
after the prize winners‟ lists are generated.
 FP/SLOC Conversion

Language Median SLOC/function point

C 104
C++ 53
HTML 42
JAVA 59
Perl 60
J2EE 50
Visual Basic 42

130
 Function points Mark II
 Developed by Charles R. Symons

 „Software sizing and estimating - Mk

II FPA‟, Wiley & Sons, 1991.

 Builds on work by Albrecht

 Developed in parallel to IFPUG FPs

 A simpler and more usable method

131
 Function points Mk II cont…

 Simpler than FP  For each

 Widely used in UK transaction, count
 data items input (Ni)
#entities
accessed  data items output
(No)
 entity types
#input #output accessed (Ne)
items items

FP count = Ni * 0.58 + Ne * 1.66 + No * 0.26

132
 Function points for embedded systems
 Mark II and IFPUG function points were
designed for information systems:
 Dominated by input and output operations
 COSMIC FPs attempt to extend concept
to embedded systems.
 Embedded systems typically have no human
users
 Embedded software seen as being in a
particular „layer‟ in the system
 Communicates with other layers and also
other components at same level 133 133
 Layered software

Higher layers
Receives request Supplies service

Data reads/ Peer to peer

writes communication
Persistent
Software component peer
storage
component

Makes a request
Receives service
for a service

Lower layers
134
 COSMIC FPs
The following are counted:

 Entries: movement of data into software

component from a higher layer or a peer
component

 Exits: movements of data out

 Reads: data movement from persistent storage

 Writes: data movement to persistent storage

Each counts 1 „COSMIC functional size unit‟

(Cfsu) 135
 Function Point Pros and Cons
 Pros:  Cons:
 Labor intensive
 Language
independent  Extensive training
 Inexperience may
 Understandable
result in inaccuracy
by client
 Weighted to file
 Simple modeling manipulation and
 Hard to fudge transactions
 Errors may be
 Visible feature introduced by single
creep person, multiple
raters advised…
136
 Accurate Size Estimation

DEFINITION Situation Adjustments ESTIMATE

Schedule
PROJECT X PROJECT X RISK
REQUIREMENT COMPLEXITY
SIZE
Adjustments FACTORS
Adjustments Costs
Effort

FUNCTION POINT ANALYSIS

137
Accurate Size Estimation

138
 Object Points
 Object points has nothing to do with
object-oriented programming
 Number of object points is estimated
based on
 Number of separate screens displayed
 Number of reports that are produced
 Number of modules in the code
 Object points are simpler to estimated
and take the GUI into account 139
Productivity (Function points / staff month)
12
Productivity= f (size)
10
Bell Laboratories Capers Jones
8 data data

6
4
2
0 Function Points
20 40 80 160 320 640 1280 2560 5120 10240 20480 40960
140
 Bernstein‟s rule of thumb
Productivity per staff-month:
 50 NCSLOC for OS code (or real-time system)

 250-500 NCSLOC for intermediary applications

(high risk, on-line)

 500-1000 NCSLOC for normal applications (low

risk, on-line)

 10,000 – 20,000 NCSLOC for reused code

Reuse note: Sometimes, reusing code that does not provide the exact functionality
needed can be achieved by reformatting input/output. This decreases
performance but dramatically shortens development time. 141
 COCOMO
 COCOMO (CONSTRUCTIVE COST MODEL)
-First published by Dr. Barry Boehm, 1981

 Several interactive cost estimation

software packages available

 Derived from statistical regression

of data from a base of 63 past
projects (2000 - 512,000 DSIs)
142
 COCOMO 81
 Based on industry productivity standards -
database can be constantly updated
 Allows an organization to benchmark its
software development productivity
 Basic model:
effort = c x sizek
 C and k depend on the type of system: organic,
semi-detached, embedded
 Size is measured in „kloc‟ ie. Thousands of lines of
code 143
 COCOMO Mode & Model
 Three development environments
(modes)
 OrganicMode
 Semidetached Mode
 Embedded Mode

 Three increasingly complex models

 Basic Model
 Intermediate Model
 Detailed Model 144
 COCOMO Modes
 Organic Mode
 Developed in familiar, stable environment
 Product similar to previously developed product
 <50,000 DSIs (ex: accounting system)

 Semidetached Mode
 somewhere between Organic and Embedded

 Embedded Mode
 new product requiring a great deal of innovation
 inflexible constraints and interface requirements
(ex: real-time systems)
145
 Modes
Feature Organic Semidetached Embedded

Organizational Thorough Considerable General

understanding of
product and
objectives
Experience in Extensive Considerable Moderate
working with related
software systems

Need for software Basic Considerable Full

conformance with
pre-established
requirements

Need for software Basic Considerable Full

conformance with
external interface
specifications 146
 COCOMO Models
 Basic Model
 Used for early rough, estimates of project cost, performance,
and schedule

 Accuracy: within a factor of 2 of actuals 60% of time

 Intermediate Model
 Uses Effort Adjustment Factor (EAF) fm 15 cost drivers

 Doesn‟t account for 10 - 20 % of cost (trng, maint, Qual, etc)

 Accuracy: within 20% of actuals 68% of time

 Detailed Model
 Uses different Effort Multipliers for each phase of project
(Most project managers use intermediate model)
147
148
 Basic Effort Equation (COCOMO 81)

 Effort=A(size)exponent
 A is a constant based on the developmental
mode
 organic = 2.4
 semi = 3.0
 embedded = 3.6
 Size = 1000s Source Lines of Code (KSLOC)
 Exponent is constant for a given mode
 organic = 1.05
 semi = 1.12
embedded = 1.20
149

150
151
 The COCOMO constants
System type c k
Organic (broadly, 2.4 1.05
information systems)
Semi-detached 3.0 1.12
Embedded (broadly, 3.6 1.20
real-time)

k exponentiation – „to the power of…‟

adds disproportionately more effort to the larger
projects
takes account of bigger management overheads
152 152
 Basic Model:
Schedule Equation (COCOMO 81)
 Nominal Development time=
2.5*(Effort)exponent
 2.5 is constant for all modes
 Exponent based on mode
 organic = 0.38
 semi = 0.35
 embedded = 0.32 153
154
155
156
157
158
 Development Time
 Development time is roughly the same

for all the three categories of

products:
 Forexample, a 38 KLOC program can be
developed in approximately 9 months
 regardless of whether it is of organic, semi-
detached, or embedded type. How come?
 There is more scope for parallel activities
for system and application programs,
Compared to utility programs.
159

 Exercise
 Software package is required by a company
to mine existing customer data to select
prospective customers for a new launch.
 Estimated to be 30KLOC of effort
 Assume competent developers can be hired at
Rs50,000/- per month.
 However, commercial offering supporting
almost all of the required features costs Rs.
100,000/-
 Should the company buy or build? 160
 Buy/Build Decision
 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? 161
Buy or Build?

162
163
 Intermediate COCOMO
 Takes basic COCOMO as starting
point
 Identifies personnel, product,
computer and project attributes which
affect cost and development time.
 Multiplies basic cost by attribute
multipliers which may increase or
decrease costs 164
 Attributes
Personnel attributes
 Analyst capability
 Virtual machine experience
 Programmer capability
 Programming language experience
 Application experience
Product attributes
 Reliability requirement
 Database size
 Product complexity 165
 More Attributes
Computer attributes
 Execution time constraints
 Storage constraints
 Virtual machine volatility
 Computer turnaround time
Project attributes
 Modern programming practices
 Software tools
 Required development schedule 166
 COCOMO Models

7000
COCOMO Models
Organic
Semidetached
6000
Embedded
5000
Person-months

4000

3000

2000

1000

0
0 100 200 300 400 500 600
Thousands of lines of code 167
 Effort for
increasing LOC
3x 1.12
Duration for
increasing Effort*
2.5x 0.35

<1
exponent:
>1

168
 Intermediate Model
Effort Equation (COCOMO 81)
 Effort=EAF*A(size)exponent
 EAF (effort adjustment factor) is the
product of effort multipliers corresponding to
each cost driver rating
 A is a constant based on the developmental
mode
 organic = 3.2
 semi = 3.0

 embedded = 2.8

 Size = 1000s Delivered Source Instruction

(KDSI)
169
 Exponent is constant given mode
170
 COCOMO –cost drivers
Cost Driver Very Low Nominal High Very
low High
Required reliability 0.75 0.88 1.0 1.15 1.40
Database size 0.94 1.0 1.08 1.16
Product complexity 0.70 0.85 1.0 1.15 1.30
Execution time constraint 1.0 1.11 1.30
Memory constraint 1.0 1.06 1.21
Virtual machine volatility 0.87 1.0 1.15 1.30
Computer turnaround time 0.87 1.0 1.07 1.15
Analyst capability 1.46 1.19 1.0 0.86 0.71
Application experience 1.29 1.13 1.0 0.91 0.82
Programmer capability 1.42 1.17 1.0 0.86 0.70
Virtual machine experience 1.21 1.10 1.0 0.90
Programming language experience 1.14 1.07 1.0 0.95
Modern programming practices 1.24 1.10 1.0 0.91 0.82
Use of software tools 1.24 1.10 1.0 0.91 0.83
Development schedule 1.23 1.08 1.0 1.04 1.10171
172
 Using COCOMO development effort
multipliers
An example: for analyst capability:
 Assess capability as very low, low, nominal, high or
very high
 Extract multiplier:
very low 1.46
low 1.19
nominal 1.00
high 0.80
very high 0.71
 Adjust nominal estimate e.g. 32.6 x 0.80 = 26.8
173
staff months
 Example 2
 Need to produce 10,000 LOC = 10
KLOC.
 Small project, familiar development
 Use organic model:
 Person-months=2.4(10)1.05 =26.9 Person-months

 Development-time = 2.5(26.9).38 =8.7 Months

 Average People = 26.9 PM/8.7 Months = 3

People
174
 Example 2 cont…
 We also know that:
 Analyst, 1.19
 application, 1.13
 programmer capability is low. 1.17

 Yet the programming experience is high - .95

 Adjustment factor 1.19*1.13*1.17*.95 = 1.49
 PM = 26.9*1.49 = 40 Person-months
 Development time = 10.2 Months
 People = 3.9 People 175
 COCOMO 81: Example 3
 Project is a flight control system (mission
critical) with 319,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 176
 Intermediate Model Example
Highly complex intermediate organic project
with high tool use:
Estimate 3000 DSIs Effort=EAF*A(KDSI)exp1

CPLX = 1.3 (VH)

MTDEV= 2.5*(Effort)exp2
TOOL = 1.10 (L)
EAF = 1.3*1.10 = 1.43
Effort = 1.43 * 3.2 * 31.05 = 14.5 man months
MTDEV = 2.5 * 14.50.38 = 6.9 months
Staff required = 14.5/6.9 = 2.1 people
177
 Example 4
 Embedded software system on microcomputer
hardware.
 Basic COCOMO predicts a 45 person-month
effort requirement
 Attributes = RELY (1.15), STOR (1.21), TIME
(1.10), TOOL (1.10)
 Intermediate COCOMO predicts
 45 * 1.15 * 1.21 * 1.10 *1.10 = 76 person-
months.
 Assume total cost of person month = 50,000.
 Total cost = 76 * 50,000 = Rs.38,00, 000 178
Boehm: “A project can not be done in less than
75% of theoretical time”

Time
Ttheoretical

75% * Ttheoretical

Linear
increase
Staff-month
Impossible design

But, how can I estimate staff months?

Ttheoretical = 2.5 * 3√staff-months

179
 Exercise 5
Use the Basic COCOMO model to estimate
efforts and duration of an embedded
software development project with size of
55 KLOC.
1. How many workers should be hired for this
project?
Embedded: a=3.6 b=1.2, c= 2.5, d = .32

2. If the project must be completed within 15

months, how many additional workers should be
180
hired?
 Solution
1. How many workers should be hired for this project?
Embedded: a=3.6 b=1.2, c= 2.5, d = .32
Efforts= 3.6*(55)1.2 = 441.3 pm
Duration = 2.5 * (441.3).32 = 17.54 months
Number of workers needed: 441.3/17.54 = 25.1

2. If the project must be completed within 15

months, how many additional workers should be hired?
Number of workers required for 15 month completion:
441/15=29.4
Additional workers: 29.4 – 25.1 = 4.3 rounded to 5
181
182
183
 Drawbacks
 For better accuracy:
 COCOMO has to be calibrated to an
organizations‟ environment.

 Very sensitive to parameter change:

 Over
a person-year difference in a 10
KLOC project with minor adjustments

 Broad brush model that can generate

significant errors 184
185
187
 Cocomo 81:
Limitations as years progressed
 Software reuse
 Application generation programs
 Object oriented approaches
 Application engineering (reuse,
applications translation)
 Need for rapid development 188
189
190
 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). 191
 COCOMO 2 models
 COCOMO 2 incorporates a range of sub-models:
 Produces increasingly accurate estimates.
 The sub-models in COCOMO 2 are:
 Application composition model. Used when software is
composed from existing parts.
 Early design model. Used when requirements are
available but design has not yet started.
 Reuse model. Used to compute the effort of
integrating reusable components.
 Post-architecture model. Used once the system
architecture has been designed and more information
about the system is available.
192
193
 4x COCOMO II Model Stages

2x Early Design
(13 parameters)
1.5x
1.25x
Relative
Size Range x

0.8x
Post-Architecture
0.67x (23 parameters)

0.5x Applications
Composition
(3 parameters)
0.25x Product Detail
Concept of Rqts. Design Design Accepted
Operation Spec. Spec. Spec. Software

Feasibility Plans Product Detail Devel.

and Design Design and Test
Rqts.
194
Phases and Milestones
 COCOMO 2
COCOMO 81 DSI - “Delivered Source Instructions”
COCOMO II SLOC - “Source Lines Of Code”
•The original COCOMO 81 model was defined in
terms of Delivered Source Instructions, which are
very similar to SLOC.
•The major difference between DSI and SLOC is
that a single Source Line of Code may be several
physical lines.
•For example, an "if-then-else" statement would
be counted as one SLOC, but might be counted as
several DSI. 195
 COCOMO II
 The core model is:
pm = A(size)(sf) ×(em1) ×(em2) ×(em3)….
where pm = person months,
 A = 2.94,
 size is number of thousands of lines of
code,
 sf is the scale factor
 em is an effort multiplier 196
 Application composition model
 Applicable to prototyping projects and projects
where there is extensive reuse.
 Based on standard estimates of developer
productivity in application (object)
points/month.
 Takes CASE tool use into account.
 Formula is
 PM = ( NAP (1 - %reuse/100 ) ) / PROD
 PM is the effort in person-months, NAP is the
number of application points and PROD is the
productivity. 197
 Application Composition Model
 Suitable for software built around
graphical user interface (GUI) and
modern GUI-builder tools
 Uses object points as a size metric
 extension of function points
 countof the screens, reports, and
modules, weighted by a three-level
factor (simple, medium, difficult)
198
 Application-point
productivity
Developer‟s
experience
Very Low Nominal High Very
and low high
capability

ICASE
maturity and
Very Low Nominal High Very
capability low high

PROD
(NAP/month)
4 7 13 25 50

199
 The Scale Drivers (Exponents)
•An important factors contributing to a project's
duration and cost are the Scale Drivers.
•The Scale Drivers determine the exponent used in
the Effort Equation.
•Scale Drivers have replaced the Development
Modes of COCOMO 81.
•The 5 Scale Drivers are:
 Precedentedness
 Development Flexibility
 Architecture / Risk Resolution
 Team Cohesion
 Process Maturity 200
Early Design and Post-Architecture Model

( ) [Size]
Environment (Process ScaleFactors)
·Effort =
Multipliers

Environment: Product, Platform, People, Project

Factors
Size: Reuse and volatility effects
Process: Constraint, Risk/Architecture, Team,
Maturity Factors

· Schedule = (Multiplier )[Effort]

(Process Scale Factors)

201
 COCOMO 2 Scaling Exponent Approach
• Nominal person-months = A*(size)B
• B = 0.91 + 0.01 (scale factor ratings)
- B ranges from 0.91 to 1.23
- 5 scale factors; 6 rating levels each

• Scale factors:
- Precedentedness (PREC)
- Development flexibility (FLEX)
- Architecture/ risk resolution (RESL)
- Team cohesion (TEAM)
- Process maturity (PMAT, derived from SEI CMM) 202
 Project Scale Factors
 

=  B  
PM 2.94 (Size) EM


 

estimated i  
 
 

B =0.91
. +0.01SF
i
Scale Factors Very Low Low Nominal High Very High Extra High
(Wi)
PREC thoroughly largely somewhat generally largely familiar throughly
unprecedented unprecedented unprecedented familiar familiar
FLEX rigorous occasional some general some general goals
relaxation relaxation conformity conformity
RESL little (20%) some (40%) often (60%) generally mostly (90%) full (100%)
(75%)
TEAM very difficult some difficult basically largely highly seamless
interactions interactions cooperative cooperative cooperative interactions
interactions 203
PMAT weighted sum of 18 KPA achievement levels
 The reuse model
 Reuse costs:
 overhead for assessing, selecting and
assimilating component
 small modifications generate disproportional
large costs

 Takes into account:

 black-box code that is reused without change
 Code that has to be adapted to integrate it
with new code.
204
 The reuse model
 There are two versions:
 Black-box reuse where code is not
modified. An effort estimate (PM) is
computed.
 White-box reuse where code is modified.
 A size estimate equivalent to the number
of lines of new source code is computed.
 This then adjusts the size estimate for
new code. 205
 Reuse model estimates
 1. For generated (reused) code:
 PM = (ASLOC * AT/100)/ATPROD
 ASLOC is the number of lines of generated code
 AT is the percentage of code automatically generated.
 ATPROD is the productivity of engineers in integrating this
code.

 2 When code has to be understood and integrated:

 ESLOC = ASLOC * (1-AT/100) * AAM.
 ASLOC and AT as before.
 AAM is the adaptation adjustment multiplier computed from
the costs of changing the reused code, the costs of
understanding how to integrate the code and the costs of reuse
206
decision making.
 Post-architecture level
 Uses the same formula as the early design
model:
 but with 17 rather than 7 associated multipliers.
 The code size is estimated as:
 Number of lines of new code to be developed;
 Estimate of equivalent number of lines of new
code computed using the reuse model;
 An estimate of the number of lines of code that
have to be modified according to requirements
changes.
207
 COCOMO II Scale factor
Based on five factors which appear to be particularly
sensitive to system size
1. Precedentedness (PREC). Degree to which there
are past examples that can be consulted
2. Development flexibility (FLEX). Degree of
flexibility that exists when implementing the project
3. Architecture/risk resolution (RESL). Degree of
uncertainty about requirements
4. Team cohesion (TEAM).
5. Process maturity (PMAT) could be assessed by
CMMI 208
 Precedentedness (PREC) and Development
Flexibility (FLEX)
Feature Very Low Nominal / Extra
High High
Precedentedness
Organizational understanding of product General Considerable Thorough
objectives
Experience in working with related Moderate Considerable Extensive
software Systems
Concurrent development of associated new Extensive Moderate Some
hardware and operational procedures

Need for innovative data processing Considerable Some Minimal

architectures, algorithms

Development Flexibility
Need for software conformance with Full Considerable Basic
preestablished requirements
Need for software conformance with Full Considerable Basic
external interface specifications
Premium on early completion High Medium Low
209
Architecture / Risk Resolution (RESL)

210
Team Cohesion (TEAM)

211
 COCOMO II Scale factor values
Driver Very Low Nom- High Very Extra
low inal high high

PREC 6.20 4.96 3.72 2.48 1.24 0.00

FLEX 5.07 4.05 3.04 2.03 1.01 0.00

RESL 7.07 5.65 4.24 2.83 1.41 0.00

TEAM 5.48 4.38 3.29 2.19 1.10 0.00

PMAT 7.80 6.24 4.68 3.12 1.56 0.00

212
 Example Usage of scale factor
 A software development team is developing an
application:
 It is very similar to previous ones it has developed.
 A very precise software engineering document
lays down very strict requirements.
 PREC is very high (score 1.24).
 FLEX is very low (score 5.07).
 The good news is that requirements are unlikely
to change:
 RESL is high with a score 2.83
 The team is tightly knit (high score of 2.19), but
processes are informal: 213
 Scale factor calculation
The formula for sf is
sf = B + 0.01 × Σ scale factor values
i.e. sf = 0.91 + 0.01
× (1.24 + 5.07 + 2.83 + 2.19 + 6.24)
= 1.0857
If system contained 10 kloc then estimate would be
2.94 x 101.0857 = 35.8 person months
Using exponentiation („to the power of‟)
adds disproportionately more to the
estimates for larger applications 214
 Scale Factor: Example 2
 Depends on 5 scale factors, sum/100 is added to
0.91
 A company takes on a project in a new domain.
The client would not be participating during
development and has not allowed time for risk
analysis. The company has a CMM level 2 rating.
 Precedenteness - new project (4)
 Development flexibility - no client involvement - Very
high (1)
 Architecture/risk resolution - No risk analysis - V. Low
.(5)
 Team cohesion - new team - nominal (3)
 Process maturity - some control - nominal (3)
Scale factor is therefore 1.17.
215

 Effort multipliers
In addition to the scale factor:
 effort multipliers are also assessed:
RCPX Product reliability and complexity
RUSE Reuse required
PDIF Platform difficulty
PERS Personnel capability
FCIL Facilities available
SCED Schedule pressure 216
 Effort multipliers
Extra Very Low Nom- High Very Extra
low low inal high high
RCPX 0.49 0.60 0.83 1.00 1.33 1.91 2.72

RUSE 0.95 1.00 1.07 1.15 1.24

PDIF 0.87 1.00 1.29 1.81 2.61

PERS 2.12 1.62 1.26 1.00 0.83 0.63 0.50

PREX 1.59 1.33 1.12 1.00 0.87 0.74 0.62

FCIL 1.43 1.30 1.10 1.00 0.87 0.73 0.62

SCED 1.43 1.14 1.00 1.00 1.00

217 217
 Example
 A new project to be developed is similar in most
characteristics to those that an organization has been
dealing for some time
 except
 the software to be produced is exceptionally
complex and will be used in a safety critical system.
 The software will interface with a new operating
system that is currently in beta status.
 To deal with this the team allocated to the job are
regarded as exceptionally good, but do not have a
lot of experience on this type of software. 218
 Example -continued
RCPX very high 1.91
PDIF very high 1.81
PERS extra high 0.50
PREX nominal 1.00
All other factors are nominal
Say estimate is 35.8 person months
With effort multipliers this becomes 35.8
x 1.91 x 1.81 x 0.5 = 61.9 person months
219
 COCOMO II Effort Equation

Example: A project with all Nominal Cost

Drivers and Scale Drivers would have an EAF
of 1.00 and exponent, E, of 1.0997.

Assuming that the project is projected to

consist of 8,000 source lines ofcode,
COCOMO II estimates that 28.9 Person-
Months of effort is required to complete it:

Effort = 2.94 * (1.0) * (8)1.0997 = 28.9

Person-Months
220
221
 Importance of Calibration
 Proper calibration is very important
 The original COCOMO II.1997:
 Estimates within 20% of the actual values
46% of the time.
 This was based on 83 data points.
 The recalibration for COCOMO II.1998:
 Estimates within 30% of the actual values
75% of the time.
 This was based on 161 data points. 222
 Project duration and staffing
 As well as effort estimation, managers must
estimate the calendar time required to
complete a project and when staff will be
required.
 Calendar time can be estimated using COCOMO 2
formula
 TDEV = 3 ´ (PM)(0.33+0.2*(B-1.01))
 PM is the effort computation and B is the exponent
computed (B is 1 for the early prototyping model).
 The time required is independent of the number of
people working on the project. 223
 Staffing requirements
 Staff required can‟t be computed by diving
the development time by the required
schedule.
 The number of people working on a project
varies depending on the phase of the
project.
 The more people who work on the project,
the more total effort is usually required.
 A very rapid build-up of people often
correlates with schedule slippage.
224
 Staffing Level Estimation
 Number of personnel required during
any development project:
 not constant.

 Norden in 1958 analyzed many R&D

projects, and observed:
 Rayleigh curve represents the number
of full-time personnel required at any
time.
225
225
 Rayleigh Curve
 Rayleigh curve is
specified by two Rayleigh Curve
parameters:
 td the time at which Effort
the curve reaches
its maximum
td
 K the total area
under the curve. Time

 L=f(K, td)
226
 Staffing
 Norden was one of the first to investigate
staffing pattern:
 Considered general research and development (R&D)
type of projects.
 Norden concluded:
 Staffing pattern for any R&D project can be
approximated by the Rayleigh distribution curve

Manpower
TD
Time
227
 Putnam‟s Work
 In 1976, Putnam studied the problem
of staffing of software projects:
 observed that the level of effort
required in software development
efforts has a similar envelope.
 found that the Rayleigh-Norden curve
 relates the number of delivered lines of
code to effort and development time.
228
228
 Putnam‟s Work (CONT.)

 Putnam analyzed a large number of

army projects, and derived the
expression:
L=CkK1/3td4/3
 K is the effort expended and L is the
size in KLOC.
 td is the time to develop the software.
 Ck is the state of technology constant
 reflects factors that affect programmer229
229
productivity.
 Putnam‟s Work (CONT.)

 Ck=2 for poor development environment

 no methodology, poor documentation, and
review, etc.

 Ck=8 for good software development

environment
 software engineering principles used

 Ck=11 for an excellent environment

230 230
 Rayleigh Curve
 Very small number of engineers are
needed at the beginning of a
project
 carry out planning and specification.
 As the project progresses:
 more detailed work is required,
 number of engineers slowly increases
and reaches a peak. 231
231
 Rayleigh Curve
 Putnam observed that:
 thetime at which the Rayleigh curve
reaches its maximum value
 corresponds to system testing and
product release.
 After system testing,
 the number of project staff falls till
product installation and delivery. 232
 Rayleigh Curve
 From the Rayleigh curve observe
that:
 approximately 40% of the area
under the Rayleigh curve is to the
left of td
 and 60% to the right.
233
 Putnam‟s Model

Lines of code: SS

Person years invested: K

Time to develop: td
Technology coefficient: Ck
234
 Putnam‟s Model
Lines of code: S S = Ck K t1/ 3 4 / 3
d

3
 SS 
Person years invested: K =  
4/3 
 Ck t d 
3/ 4
 SS 
Time to develop: td =  
1/ 3 
 Ck K  235
 Putnam‟s Work
 Putnam adapted the Rayleigh-Norden
curve:
 Related the number of delivered lines of
code to the effort and the time required to
develop the product.
 Studied the effect of schedule compression:

236
 Effort Applied vs. Delivery Time
 There is a nonlinear relationship between effort
applied and delivery time (Putnam-Norden-
Rayleigh Curve)‫‏‬
 Effort increases rapidly as the delivery time is
reduced
Effort
cost
Impossible
region
E theoretical

E optimal

t minimum t theoretical t optimal

237
Development time
 Effect of Schedule Change on
Cost
 Using the Putnam's expression for L,
K=L3/Ck3td4
Or, K=C1/td4
 For the same product size, C1=L3/Ck3 is
a constant.
 Or, K1/K2 = td24/td14
238
 Effect of Schedule Change on
Cost (CONT.)

 Observe:
A relatively small compression in delivery
schedule
 can result in substantial penalty on human
effort.

 Also, observe:
 benefitscan be gained by using fewer
people over a somewhat longer time span.
239
239
 Example
 If the estimated development time is
1 year, then in order to develop the
product in 6 months,
 thetotal effort and hence the cost
increases 16 times.
 In other words,
 The relationship between effort and the
chronological delivery time is highly
nonlinear. 240
 Putnam‟s Model
Example:
given SS=100,000
C=10,040
td = varies
compute K

td K
1 988 person-month
1.5 195 person-month
2 62 person-month
241
 Effect of Schedule Change on
Cost (CONT.)
 Putnam model indicates extreme
penalty for schedule compression
 andextreme reward for expanding the
schedule.
 Putnam estimation model works
reasonably well for very large systems,
 butseriously overestimates the effort
for medium and small systems. 242
242
 Effect of Schedule Change on
Cost (CONT.)
 Boehm observed:
 “Thereis a limit beyond which the
schedule of a software project cannot
be reduced by buying any more
personnel or equipment.”

 This
limit occurs roughly at 75% of the
nominal time estimate.
243
 Effect of Schedule Change on Cost
(CONT.)

 If a project manager accepts a customer

demand to compress the development time
by more than 25%
 very unlikely to succeed.
 every project has only a limited amount of
parallel activities
 sequential activities cannot be speeded up by
hiring any number of additional engineers.
 many engineers have to sit idle. 244
244
 Jensen Model
 Jensen model is very similar to
Putnam model.
 attemptsto soften the effect of
schedule compression on effort
 makesit applicable to smaller and
medium sized projects.
245 245
 Jensen Model
 Less sensitive to schedule compression
than Putnam
 makes it applicable to smaller and
medium sized projects.
S = Cte * T * K1/2

 Cte is the effective technology constant,

 td is the time to develop the software, and
 K is the effort needed to develop the software.
246
 Capers Jones‟ Estimating Rules
of Thumb
 Empirical rules:
 Formulated based on observations
 No scientific basis
 Because of their simplicity,:
 These rules are handy to use for making
off-hand estimates.
 Give an insight into many aspects of a
project for which no formal
methodologies exist yet. 247
 Capers Jones‟ Rules
 Rule 1: SLOC-function point equivalence:
 One function point = 125 SLOC for C
programs.
 Rule 2: Project duration estimation:
 Function points raised to the power 0.4
predicts the approximate development time in
calendar months.
 Rule 3: Rate of requirements creep:
 User requirements creep in at an average
rate of 2% per month from the design
through coding phases.
248
 Capers Jones‟ Rules
 Rule 4: Defect removal efficiency:
 Each software review, inspection, or test
step will find and remove 30% of the bugs
that are present.

 Rule 5: Project manpower estimation:

 The size of the software (in function points)
divided by 150 predicts the approximate
number of personnel required for developing
the application.
249
 Capers‟ Jones Rules
 Rule 6: Number of personnel for maintenance
 Function points divided by 500 predicts the
approximate number of personnel required for
regular maintenance activities.

 Rule 7: Software development effort

estimation:
 The approximate number of staff months of
effort required to develop a software is given
by the software development time multiplied
with the number of personnel required.
250
 Capers‟ Jones Rules
 Rule 8: Raising the number of
function points to 1.2 power predicts
the approximate number of test cases
created.
 Assume each test case will be executed
about 4 times

251
 Capers‟ Jones Rules
 Rule 9: Raising the number of
function points to the 1.25 power
predicts the approximate defect
potential for new software projects
 Defect potential is sum of bugs (errors)
in requirements, design, coding, user-
documentation + bad fixes or secondary
errors introduced fixes prior errors.
 For enhancements: raise to 1.27 power
252
 Estimations Still Very Inexact…
 Conventional cost models have been
described as:
“within 20% of actuals, 70% of the
time.”
 This is scary to investors and
stakeholders:
 Asvery seldom are variations of
estimates „for the better‟. 253
254
 Some conclusions: how to
review estimates
Ask the following questions about an
estimate
 What are the task size drivers?
 What productivity rates have been used?
 Is there an example of a previous project
of about the same size?
 Are there examples of where the
productivity rates used have actually been
found?
255
 IEEE 1058.1-1987 SPMP
Table of Contents
1. Introduction
1.1 Project overview
1.2 Project deliverables
1.3 Evolution of the SPMP
1.4 Reference materials
1.5 Definitions and acronyms
2. Project organization
2.1 Process model
2.2 Organizational structure 5. Work packages, schedule &
2.3 Organizational boundaries
and interfaces
2.4 Project responsibilities
3. Managerial process
3.1 Managerial objectives &
priorities
3.2 Assumptions, dependencies
& constraints
3.3 Risk management
3.4 Monitoring & controlling
mechanisms
3.5 Staffing plan
4. Technical process
4.1 Methods, tools & techniques
4.2 Software documentation
4.3 Project support functions
budget
5.1 Work packages
5.2 Dependencies
5.3 Resource requirements
5.4 Budget & resource allocation
5.5 Schedule 256
 Organization of SPMP Document
 Introduction (Objectives,Major Functions,Performance
Issues,Management and Technical Constraints)

 Project Estimates (Historical Data,Estimation Techniques,Effort, Cost,

and Project Duration Estimates)

 Project Resources Plan (People,Hardware and

Software,Special Resources)

 Schedules (Work Breakdown Structure,Task Network, Gantt Chart

Representation,PERT Chart Representation)

 Risk Management Plan (Risk Analysis,Risk Identification,Risk

Estimation, Abatement Procedures)

 Project Tracking and Control Plan

 Miscellaneous Plans(Process Tailoring,Quality Assurance)
257
Any Questions…

258
Further Questions?

259