Measurement N Estimation I

Measurement and Estimation
Measurement and MCS8301 - Software Engineering 1

Estimation I Management
Software Cost Estimation
z Purpose
• Estimating Software Cost and Effort
z Objectives:
• Algorithms and models for estimating different
aspect of Software
• Includes cost, effort, and size, and indirectly
schedule
• Shows
Sh the
th relation
l ti b between
t th
the above
b entities
titi
Purpose of Cost estimation
z To estimate how much software-engineering time will be
required to do some work.
• Elapsed time
• The difference in time from the start date to the end
date of a task or project.
• Development effort
• The amount of labour used in person-months or
person-days.
• To convert an estimate of development effort to an
amountt off money:
You multiply it by the weighted average cost
(burdened cost) of employing a software
engineer for a month (or a day).
Principles of effective Cost Estimation
z Principle 1: Divide and conquer.
• To make a better estimate,, you
y should divide the
project up into individual subsystems.
• Then divide each subsystem further into the activities

that will be required to develop it.
• Next, you make a series of detailed estimates for

each individual activity.
• And sum the results to arrive at the ggrand total

estimate for the project.
z Principle 2: Include all activities when making estimates.

• The time required for all development activities must
be taken into account.
• Including:
• Prototyping
• Design
• Inspecting
• Testing
• Debugging
• Writing user documentation
• Deployment.
D l t
z Principle 3: Base your estimates on past experience
combined with knowledge of the current project.
• If you are developing a project that has many
similarities with a past project:
• You can expect it to take a similar amount of work.
• Base
B your estimates
i on the
h personall jjudgement
d t off your
experts
or
• Use algorithmic models developed in the software
industry as a whole by analyzing a wide range of
projects.
projects
• They take into account various aspects of a project’s
size and complexity, and provide formulas to
compute anticipated cost.
z Principle 4: Be sure to account for differences when

extrapolating from other projects.
• Different software developers
• Different development processes and maturity levels
• Different types of customers and users
• Different schedule demands
• Different technology
• Different technical complexity of the requirements
• Different domains
• Different levels of requirement stability
z Principle 5: Anticipate the worst case and plan for
contingencies.
• Develop the most critical use cases first
• If the project runs into difficulty, then the critical
features are more likely to have been completed
• Make three estimates:
• Optimistic (O)
( )
• Imagining a case of everything going perfectly
• Likely (L)
• Allowing for typical things going wrong
• Pessimistic
• Accounting for everything that could go wrong
z Principle 6: Combine multiple independent estimates
estimates.
• Use several different techniques and compare the
results.
• If there are discrepancies, analyze your calculations
to discover what factors are causing the differences.
• Use
U th the Delphi
D l hi Technique
T h i ( bt i th
(obtain the opinion
i i off
experts without necessarily bringing them face to
face).
• Several individuals initially make cost estimates in
private.
• They then share their estimates to discover the
discrepancies.
• Each individual repeatedly
p y adjusts
j his or her
estimates until a consensus is reached.
z Principle 7: Revise and refine estimates as

work progresses
• As
A you add dd more d
details
t il tto th
the project.
j t
• As the requirements changes occur.

• As the risk management process
uncovers new problems
problems.
Estimation
z Schedule and Cost
• Development Effort required for the project
• Size determines how much effort is required.
• Resources (which have impact on the cost)
z Schedules can be “stretched”
stretched or “compressed”
compressed by
changing the resource allocation.
z Manpower and months are not fully interchange-

able Why?
able.
Cost Estimation
z Cost estimation is related to effort estimation and is necessary for
scheduling/planning.
• 100 -200% cost overruns are not uncommon in the industry
industry.
• 15% of large projects never deliver.
z Classic Methods for Cost Estimation
• Theoretical (Models based on theory)
• Empirical (Based on previous data)
z Advanced Methods for Cost Estimation
• Artificial Intelligence (AI)
• Component-Based Reuse (CBR)
• Web
W b Development
D l t Techniques
T h i (W
(Web
bBBased
dMMethods)
th d )
Consequences of Wrong Estimation
• Economic Consequences
• e.g.
e g wasted budget on non-delivered
non delivered projects
• Technical Consequences
q
• Example is low quality especially in the last tasks.
• Last tasks like testing, documentation, and training
can be very important.
• Managerial/Organizational Consequences
• Over-pressured staff
• Crisis
C i i mentality
t lit
Meta-Model
z A generic cost estimation model using NASA data
z Following the procedure,

procedure each organization can
come up with its own “model” with proper set of
“factors”
z Based on an “empirical” method, i.e. use of

previous
i d
data
t tto estimate
ti t new projects
j t
• algorithmic, analogy, experts, …
z “Theoretical” methods use global assumptions
and basic formulae
Model Format
z Background or base equation
• Gives a primary effort estimation based on “size”
size
of the project.
z Project factors (e.g. Cost Drivers in COCOMO)

• Causes the difference between primary estimate
and actual project effort in database projects
((documented set of p projects
j completed.)
p )
z Use the model to p

predict the effort.

Background Equation
z Measures of size
• Total and new lines of code and modules
• Combination (developed lines of code)
z Measures of effort
• Man-hours
Man hours and man-months
man months (all activities)
z Form of the equation
• Development Effort Î 1.1 E=a*S+b
• Development Effort Î 2. E = a * Sb
• Development Effort Î 3.3 E = a * Sb + c
z Calculating the equation parameters which can
be from empirical records or otherwise.
Project Factors
z Choosing a set of factors
z Grouping and compressing this data
z Isolating the important factors and groups
z Incorporating the factors to predict

deviation from base-line
Groups of Factors
z Methodology
• Tree charts
• Top down design
• Design formalisms
• Formal documentation
• Code reading
• Chief programmer teams
• Formal test plans
• Unit development folders
• Formal
F l training
t i i
Groups of Factors
z Complexity
• Customer interface
• Customer-initiated design changes
• Application process
• Program flow
• Internal communication
• External communication
• Database
Groups of Factors
z Experience
• Programmer qualifications
• Programmer experience with machine
• Programmer
g experience
p with language
g g
• Programmer experience with application

• Team previously worked together
Incorporating Factors
z Compare the estimated and actual efforts
z Use statistical methods (e.g.

(e g forward multiple
regression - measuring the degree to which
p
one independent variable correlates to the
dependent variable to find the effect of
factors
z Considering only Methodology and

Complexity groups,
groups and breaking them into
Low and High binary attributes we can
estimated development effort as:
Effort = SizeA * 10B
Applying the Model
z Estimate the size of the project code
z Estimate the effort using base-line (the model

based on baseline (minimum) characteristics.
z Estimate factors (methodology, complexity,

experience etc)
z Compute the factors-incorporated estimate

(improvement of the baseline estimate)
z Should expect 10 to 20% error (just an estimate!!!)

Some Estimation Methods issues
z Parkinson's Law
• The project costs whatever resources are available
• Advantages:
• No overspend
• Disadvantages:
• System is usually unfinished
z Algorithmic Cost Modelling
• Cost is estimated as a mathematical function of product,
project and process attributes whose values are estimated
by project managers
• The function is derived from a study of historical costing
data
• Most commonly used product attribute for cost estimation is
LOC (code size)
• Most models are basically similar but with different attribute
values.
Some Estimation Methods issues cont’d
z Expert Judgment
• One or more experts in both software development and the
application domain use their experience to predict software costs.
Process iterates until some consensus is reached.
• Advantages:
• Relatively cheap estimation method. Can be accurate if
experts have direct experience of similar systems
• Disadvantages:
Di d
• Very inaccurate if there are no experts!
z Pricing
P i i to
t win
i
• The project costs whatever the customer has to spend on it
• Advantages:
• You
Y gett the
th contract
t t
• Disadvantages:
• The probability that the customer gets the system he or she
wants is small.
small
• Costs do not accurately reflect the work required
Cost-Estimation Techniques

Software Cost Estimation Accuracy

Algorithmic Models
z Allow you to systematically estimate development

effort.
effort
• Based on an estimate of some other factor that
you can measure
measure, or that is easier to estimate:
• The number of use cases
• The number of distinct requirements
• The number of classes in the domain model
• The number of widgets (add ons) in the
prototype user interface
• An estimate of the number of lines of code
Al
Algorithmic
ith i Models
M d l
• A typical algorithmic model uses a formula

like the following:
•COst
CO t COnstructive
CO t ti MOdel
MOd l (COCOMO):
(COCOMO)
Effort E = a + bNc
•Functions Points (FP):

Size S = W1F1 + W2F2 +W3F3 + …

COCOMO
z COnstructive
CO t ti COstCO t MOdel
MOd l
z Basic (gives an initial estimate of man-months and
development
de e op e time) e)
• Early stages of Project
• MMNOM = a * KDSI b ; (Time in man-months)
• TDEV = c * MMDEV d (Development Schedule)
z Intermediate (gives a more detailed estimate for small
and medium sized projects)
• Main development phases
• Cost drivers
z Detailed (which gives a more detailed estimates for
large projects).
• Effect of different factors on individual phases.
Intermediate COCOMO
z Step-1: Nominal effort (MM) estimation as a

function of KDSI
z Step-2: Determine effort multipliers from cost

driver attributes
z Step-3: Estimate development efforts
z Step-4: Use additional factors to determine cost,

schedule activity distribution
schedule, distribution, …
Development Mode for Model
z Organic
g ((Stable and in-house familiar p
projects,
j , unconstrained))
• MMNOM = 3.2 * KDSI 1.05
• TDEV = 2.5 * MMDEV 0.38
z Semidetached (Intermediate between Organic and Embedded Mode)
• MMNOM = 3.0 * KDSI 1.12
• TDEV = 2.5 * MMDEV 0.35
z Embedded (More ambitious, unique and constrained projects)
• MMNOM = 2.8 * KDSI 1.20
• TDEV = 2.5 * MMDEV 0.32
z The coefficients used are adjusted for each to cater for the aggregate effect
of the cost of factors.
z The different factors allow for the estimates to be tailored to different

environments.
Development Effort Multipliers
Boehm recommends using the 15 Cost Factors above to evaluate each Project
with each factor being assessed as being Very Low, Low, Nominal, High, Very
Hi h or E
High Extra
t Hi
Highh (plus
( l definitions)
d fi iti ) and
d associated
i t d with
ith multiplying
lti l i ffactor.
t

The Rayleigh-Putnam Curve
z Uses a negative
U ti exponentialti l curve as an indicator
i di t off cumulative
l ti
staff-power distribution over time during a project.
z Technology constant
constant, CC, combines the effect of using tools,
tools
languages, methodology, quality assurance procedures.
standards etc. It is determined on the basis of historical data
(past p
(p projects).
j )
z C is determined from project size, area under effort curve, and

project duration.

The Rayleigh-Putnam Curve cont’d
z Rating: C = 2000 -- poor, C = 8000 -- good, C

= 11000 it is excellent
excellent.
z Effort and productivity change when

development
p time varies between 2 and 3
years:

Difficulties of Software Cost Estimation
z Complexity
• Not enough
g effort for estimation
z Infrequency
• Lack of experience
z Underestimation bias
• Human nature
z Goals not estimates
• Higher
Hi h managementt
CBR in Effort Estimation
z Case-Based Reasoning (CBR) uses analogical

problem solving
• Retrieving solutions to a target problem from
similar source problems in memory
• Mapping the source elements to target space
• No
N strong
t th
theoretical
ti l model
d l
• Ill-defined, incomplete, and inconsistent
domain rules
• Appropriate for software estimation
Adjustment Rule
z Example from Rule Base:

IF
Staff size of source is small
AND
Staff size of target is large
THEN
Increase the effort estimation by 20%

COCOMO-2
z Problems with original COCOMO
• Business software
• COTS and re-use
• Incremental development
• Object-Oriented Programming (OOP)
z COCOMO-2 defines three stages

• Prototyping
• Design
• Post
Post-architecture
architecture

COCOMO 2 Si
COCOMO-2 Sizing
ing
z Object Points
• Stage 1
z Unadjusted Function Points
• Stages 2 and 3
z Source lines of code
• Stages
St 2 and
d3
New Cost Drivers
z Team cohesion
z Personnel continuity
z Software developed for reuse
z Architecture and risk resolution
z Software process maturity (somewhat
replacing use of modern programming
practices)
z Documentation match to life cycle needs
z Multi-site development (somewhat replacing
turnaround time).
time)
Other Differences
z Non-linear re-use modeling
z Sca g
Scaling
• Scaling factors instead of models
z FP to SLOC conversion
z Size-dependent productivity range

Scaling
z o =A×S
Effort eB
Size
• B > 1: diseconomies of scale (Dis-economies of scale occur
when a business grows so large that the costs per unit
increase.))
• B = 1: linear
• B < 1: economies of scale
• COCOMO has fixed values for B
• In Ada-COCOMO B varies between 1.04 to 1.24 depending on
project’s progress in reducing diseconomies of scale via risk
elimination solid architecture
elimination, architecture, stable requirements
requirements, and
process maturity.
z COCOMO-2
COCOMO 2
• B = 1.01 + 0.01 × Σ Wi
• Precedentedness, flexibility, risk resolution, team cohesion,
and process maturity.
Variations of COCOMO Model
z Estimation without the cost drivers in person-per-

months
z Estimation with cost drivers in person-per-months

person per months
z The intermediate model is more accurate than the

basic model.


Measurement N Estimation I

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Measurement N Estimation I

Încărcat de

Drepturi de autor:

Formate disponibile

Measurement and Estimation

Measurement and MCS8301 - Software Engineering 1

• Then divide each subsystem further into the activities

• Next, you make a series of detailed estimates for

• And sum the results to arrive at the ggrand total

z Principle 2: Include all activities when making estimates.

z Principle 4: Be sure to account for differences when

z Principle 7: Revise and refine estimates as

• As the requirements changes occur.

z Manpower and months are not fully interchange-

z Following the procedure,

z Based on an “empirical” method, i.e. use of

z Project factors (e.g. Cost Drivers in COCOMO)

z Use the model to p

Measurement and MCS8301 - Software Engineering 15

z Choosing a set of factors

z Grouping and compressing this data

z Isolating the important factors and groups

z Incorporating the factors to predict

• Programmer experience with application

z Use statistical methods (e.g.

z Considering only Methodology and

z Estimate the size of the project code

z Estimate the effort using base-line (the model

z Estimate factors (methodology, complexity,

z Compute the factors-incorporated estimate

z Should expect 10 to 20% error (just an estimate!!!)

Measurement and MCS8301 - Software Engineering 25

Measurement and MCS8301 - Software Engineering 26

z Allow you to systematically estimate development

• A typical algorithmic model uses a formula

•Functions Points (FP):

Measurement and MCS8301 - Software Engineering 28

z Step-1: Nominal effort (MM) estimation as a

z Step-2: Determine effort multipliers from cost

z Step-3: Estimate development efforts

z Step-4: Use additional factors to determine cost,

z The different factors allow for the estimates to be tailored to different

Measurement and MCS8301 - Software Engineering 32

z C is determined from project size, area under effort curve, and

Measurement and MCS8301 - Software Engineering 33

z Rating: C = 2000 -- poor, C = 8000 -- good, C

z Effort and productivity change when

Measurement and MCS8301 - Software Engineering 34

z Case-Based Reasoning (CBR) uses analogical

z Example from Rule Base:

Measurement and MCS8301 - Software Engineering 37

z COCOMO-2 defines three stages

Measurement and MCS8301 - Software Engineering 38

Measurement and MCS8301 - Software Engineering 41

z Estimation without the cost drivers in person-per-

z Estimation with cost drivers in person-per-months

z The intermediate model is more accurate than the

Measurement and MCS8301 - Software Engineering 43

S-ar putea să vă placă și