Software Project Planning

SEN-269 : Software Engineering

Engr. Tazeen Muzammil
 Project Planning
The overall goal of project planning is to
provide a framework that enables the
manager to make reasonable estimates
of resources, cost and schedule.
Why?
So the end result gets done on time,
under budget and with quality!

2
 Project Planning Task
Establish project scope
Determine feasibility
Analyze risks (Done in previous lecture)
Define required resources
Determine require human resources
Define reusable software resources
Identify environmental resources
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 (Done in previous
lecture)

3
Software Sope

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

5
 Obtaining Information
Necessary for Scope
Understand the customers needs
Understand the business context
Understand the project boundaries
Understand the customer’s motivation
Understand the likely paths for change
Understand that ...
Even when you understand, nothing
is guaranteed!
6
 Feasibility
Once the scope has been identified,
then we ask the following questions:

Technology: Do we have the requisite

technology.
Finance: Do we have the requisite
finances/budget.
Resources: Do we have the requisite skilled
resources.

7
Resources

8
Resources

9
Estimation

10
 Estimation
Estimation of resources, cost, effort and schedule requires
experience
access to good historical information (metrics)
the courage to commit to quantitative predictions when qualitative
information is all that exists
Project scope must be understood
Elaboration (decomposition) is necessary
At least two different techniques should be used
Uncertainty is inherent in the process
Estimation should define
Best case scenario
Worst case scenario

11
Why Estimate Software?
30% of project never complete
100-200% cost overruns not uncommon
Average project exceeds cost by 90%; schedule
by 120%
15% of large project never deliver anything
Only 16.2% of projects are successful

12
 What are the
consequences?

Economic
Loss of contracts
Company failure
Technical
Dependency on software growing
Managerial
Change of personnel

13
 Estimation Techniques
Expert Judgment
Estimation by Analogy
Pricing to win
Decomposition Techniques (e.g. LOC,
FP Based )
Empirical models (e.g. COCOMO)
Automated EstimationTools

14
 Expert Judgement
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.
Pros:
Little or no historical data needed.
Suitable for new or unique projects.
Relatively cheap method; Accurate if experts have direct
experience of similar systems
Cons:
Very subjective.
Experts may introduce bias.
Larger number of experts will help to reduce bias
Qualification of experts may be questioned.

15
 Expert Judgement-Steps
• Gather a group of experts together,
• Describe overall program in enough detail so experts can
provide an estimate.
• Each member of the expert group then does an independent of
the resources needed.
• Estimates are gathered anonymously and compared,
• If there exists significant divergence among the estimates, the
estimates will be returned to the expert group,
• The expert group then discusses the estimates and the
divergence and works to resolve differences, and
• The expert group once again submits anonymous, independent
estimates which continues until a stable estimate results.

16
 Expert Judgement-
Example
Three software engineers are renown in the ERP
software development.

You hold interviews with each explaining the

requirements, sizing level, and development
process for your new system.
Each member of the group submits their opinion of
the final cost and the estimate converges to $50M.

17
 Estimation by Analogy
Estimates costs by comparing proposed programs with
similar, previously completed programs for which
historical data is available.
Actual costs of similar existing system are adjusted
for complexity, technical, or physical differences to
derive new cost estimates
Analogies are used early in a program cycle when
there is insufficient actual cost data to use as a
detailed approach
Compares similarities and differences
Focus is on main cost drivers.

18
 Estimation by Analogy
Pros:
Inexpensive
Easily changed
Based on actual experience (of the analogous system)
Cons:
Very Subjective
Large amount of uncertainty
Truly similar projects must exist and can be hard to find
Must have detailed technical knowledge of program and
analogous system
Needs systematically maintained cost database

19
 Estimation by Analogy-
Steps
Determine estimate needs/ground rules,
Define new system,
Breakout new system into subcomponents for analogy estimating,
Assess data availability of historical similar systems,
Collect historical system component technical and cost data,
Process/normalize data into constant year dollars (e.g., constant
FY2003$),
Develop factors based on prior system,
Example: Program Management is 10% of total development cost
Develop new system component costs.
Obtain complexity (and other translation) factors
Example: Historical database is for 4 million records and new
database will need to house 24 million records => complexity factor
of 6 (4*6 = 24) times the historical database cost
Apply factors to historical costs to obtain new system costs

20
 Estimation by Analogy-
Example
Your company is developing a new IT payroll system serving
5,000 people and containing 100,000 lines of C++ code.
Another company developed a similar 100,000 lines of code
system for $20M for only 2,000 people. Your software
engineers tell you that the new system is 25% more
complicated than the other system.
Other system development cost was $20M.

Estimated cost for new system = 1.25 * $20M = $25M

Plus 5,000/2,000, or 2.5 * $25M = $62.5M total cost

21
 Pricing to win
The project costs whatever the customer has to spend on it.
This approach may seem unethical and un-businesslike.
However, when detailed information is lacking it may be the only
appropriate strategy.
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
Advantages:
You get the contract.
Disadvantages:
The probability that the customer gets the system he or she
wants is small. Costs do not accurately reflect the work required.

22
Decomposition
Techniques

23
Decomposition Techniques
To obtain an estimation, we can decompose
the problem to be solved, or decompose the
process.
Decomposition should be done in such a
way that

1. size can be properly estimated,

2. cost or effort required for each component can
be accurately estimated,
3. the team's ability to handle the components is
well known, and

24
Problem-Based Estimation
1. Based on the software scope, decompose the
software into problem functions that can be
estimated individually.
2. Estimate LOC or FP of each function.
3. Make optimistic (sopt), most likely (sm), and
pessimistic (spess) estimates for each item.
Then compute the expected value:
EV (Expected Value) = (sopt + 4 sm + spess)/6
4. Apply baseline productivity metrics to
compute estimated cost or effort.

25
 Example
Problem Statement:
Take the Library management system case.
Software developed for library will accept data
from operator for issuing and returning books.
Issuing and returning will require some validity
checks. For issue it is required to check if the
member has already issued the maximum books
allowed. In case for return, if the member is
returning the book after the due date then fine
has to be calculated. All the interactions will be
through user interface. Other operations include
maintaining database and generating reports at
regular intervals.

26
 Example
Major software functions identified.
User interface
Database management
Report generation
For user interface
Sopt : 1800
Sm : 2000
Spess : 4000
For database management
Sopt : 4600 EV for user interface
Sm : 6900
Spess : 8600 EV = (1800 + 4*2000 + 4000) / 6
For report generation
Sopt : 1200 EV = 2300
Sm : 1600
Spess : 3200
EV for database management
EV = (4600 + 4*6900 + 8600) / 6
EV = 6800
EV for report generation
EV = (1200 + 4*1600 + 3200) / 6
EV = 1800
27
 Lines of code (LOC)
Given:
LOC Estimate = 33200 LOC
Productivity = 620 LOC/P-M(Person-Month)
Labor Rate = $ 8000 P-M

Effort = 54 P-M
Effort = LOC/Productivity
Cost per LOC = Labor Rate/Productivity

Cost per LOC = $ 13 P-M

Project Cost= LOC estimate * Cost per LOC

Project Cost= $ 431600

28
 LOC-Example
F u n ctio n s estim ated L O C L O C/p m $/L O C Co st E ffo rt (m o n th s)

UICF 2340 315 14 32,000 7.4

2DG A 5380 220 20 107,000 24.4

3DG A 6800 220 20 136,000 30.9

DS M 3350 240 18 60,000 13.9

CG DF 4950 200 22 109,000 24.7

P CF 2140 140 28 60,000 15.2

DAM 8400 300 18 151,000 28.0

T o tals 33,360 655,000 145.0

29
 Function Point
Five information domain characteristics are determined
and counts for each are provided and recorded in a table.
Number of user inputs
Number of user outputs
Number of user inquires
Number of files
Number of external interfaces
Once the data have been collected, a complexity value is
associated with each count. Each entry can be simple,
average or complex. Depending upon these complexity
values is calculated.

30
 Function
Function Point Formula:
Point
FP = Count Total * [0.65+0.01*Sum(Fi)]
Fi are complexity adjustment values based on response to questions(1-14) given
below. The constant values in the equation and the weighing factors that are
applied to information domain are determined empirically.
Rate each factor on a scale of 0 to 5
0 - No influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential
Count-total is sum of all FP entries.

31
 Fi
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational
environment?
6. Does the system require on-line entry?
7. Does the on-line data entry require the input transaction to be built
over multiple screens or operations?
8. Are the inputs, outputs, files, or inquiries complex
9. Is the internal processing complex?
10. Is the code designed to be reusable?
11. Are master files updated on-line?
12. Are conversion and installations included in the design?
13. Is the system designed for multiple installations in different
organizations?
14. Is the application designed to facilitate change and ease of use by
the user?

32
 Function Point
Once function points have been calculated, productivity,
quality, cost and documentation can be evaluated.
Productivity = FP / person-month
Quality = defects / FP
Documentation = pages of documentation / FP
Effort = FP Estimate/Productivity
Cost per FP = Labor rate/Productivity
Project Cost Estimate = FP * Cost per FP

33
Computing function-point
metrics

34
 Example (Same as LOC)
Information Domain Opt likely Pess est wt FP Account
Values Account

Number of Inputs 4 10 16 10 4 40

Number of Outputs 4 7 16 8 5 40

Number of Inquiries 5 12 19 12 4 48

Number of Files 3 6 9 6 10 60

Number of external 2 2 3 2 7 14
interfaces

Count Total
202 35
 Example
Complexity weighing factors are determined
and the following results are obtained.
Factor Value
Backup Recovery 4
Data Communication 1
Distributed processing 0
Perfomance Critical 3
Existing Operating Environment 2
On-line data entry 5
Input transaction over multiple screens 5

Master file updated online 3

Information domain values complex 3
Internal processing complex 2
Code design for reuse 0
Conversion/Installation in design 1
Multiple installations 3
Application designed for change 5
Sum ( Fi ) 37

36
 Example
Estimated number of FP :
FPestimated = count-total * [0.65 + .01 * sum(Fi) ]
FPestimated = 206
From historical data, productivity is 55.5 FP/person-month and development
cost is $8000 per month.
Productivity = FP/ person-month
person-month = FP/Productivity
= 202/55.5
= 3.64 person-month
Total Cost = Development cost * person-month
= 8000 * 3.64
=$29100
Cost per FP = Cost/FP
= 29100/202
= $144.2per FP

37
 Function Point-Example
Given Productivity = 6.5 FP/P-M
Labor Rate = $8000/P-M
measurement parameter count weight

number of user inputs 40 x 4 = 160

number of user outputs 25 x 5 = 125

number of user inquiries 12 x 4 = 48

number of files 4 x 7 = 28
0.25 p-m / FP = 120 p-m
number of ext.interfaces 4 x 7 = 28

algorithms 60 x 3 = 180

count-total 569

complexity multiplier .84

feature points 478

38
Process-based estimation
Most commonly-used technique for project
estimation
Project is broken down into a relatively
small set of tasks and the effort required
to accomplish each task is estimated
Begins with a delineation of software
functions obtained from the project scope
Process-based estimation
A series of framework activities must
be performed for each function
Representative framework activities:
Customer communication
Planning / risk analysis
Engineering
Construction / release
Functions and activities may be shown
together as a table:
 Process-based estimation table
Activity CC Planning Risk Engineering Release CE Totals
analysis

Function Anal. Design Code Test

UICF 0.75 2.50 0.40 5.00 n/a 8.65

2DGA 0.75 4.00 0.60 2.00 n/a 7.35

3DGA 0.50 4.00 0.60 2.00 n/a 7.10

CGDF 0.50 4.00 1.00 3.00 n/a 8.50

DBM 0.50 3.00 1.00 1.50 n/a 6.00

PCF 0.25 2.00 0.75 1.50 n/a 4.50

DAM 0.50 2.00 0.50 2.00 n/a 5.00

Totals .25 .25 .25 3.50 17.50 4.25 15.00 34.80

% effort 1% 1% 1% 7% 45% 12% 40%

Process-based estimation
Once functions and activities are melded,
the planner estimates the effort (person-
months) required to accomplish each
activity per function
Average labor rates are then applied to the
estimated efforts (may vary per task)
Cost and effort for each function and
activity (row and column totals) are
computed as the last step
 Empirical Estimation
Models
An estimation model provides empirically
derived formulas to predict effort as a
function of LOC or FP.
The data used to support these models are
derived from a limited sample. Thus no
model is appropriate for all classes of
software.

43
 Empirical models

Examples of Commercially Available Models

COCOMO
The Software Equation
COSTXPERT
SLIM
SEER
Costar, REVIC, etc.

44
 Structure of Estimation
Model

E = A + B XC

where A, B, and C are empirically

derived constants, E is the effort in
person months, and X is the
estimation variable, either in LOC or
FP.

45
 COCOMO
COCOMO, COnstructive COst MOdel is static single-variable model.
Barry Boehm introduced COCOMO models. There is a hierarchy of
these models.
Model 1:
Basic COCOMO model is static single-valued model that computes software
development effort (and cost) as a function of program size expressed in estimated
lines of code.
Model 2:
Intermediate COCOMO model computes software development effort as a function of
program size and a set of "cost drivers" that include subjective assessments of
product, hardware, personnel, and project attributes.
Model 3:
Advanced COCOMO model incorporates all characteristics of the intermediate version
with an assessment of the cost driver's impact on each step, like analysis, design,
etc.
COCOMO can be applied to the following software project's categories.

46
Three Software Project's
Categories
Organic -- a relatively small simple project in which
small teams with good application experience work
to a set of less than rigid requirements.

Semi-detached -- an intermediate project in which

teams with mixed experience must meet a mix of
rigid and less than rigid requirements.

Embedded -- a project that must meet tight

hardware, software, and operational constraints.

47
 COCOMO
The COnstructive COst MOdel
It is LOC-based.
Formula:
E = a(KLOC)b
T = cEd
where E is the effort required in person-months, T is the
required development time in chronological months, KLOC is
the estimated size of software in thousand lines of delivered
source code. The constants a, b, c, and d are listed below:

48
 The Software Equation

A dynamic multivariable model

E = [LOC x B0.333 /P]3 x (1/t4)
where
E = effort in person-months or person-years
t = project duration in months or years
B = “special skills factor”
P = “productivity parameter”

49
 Automated Estimation
Tools
The automated estimation tools allow the planner to
estimate cost and effort and to perform what if analysis for
important project variables such as delivery date or staffing.
Six generic functions:
1. Sizing of project deliverables
2. Selecting project activities
3. Predicting staffing levels
4. Predicting software effort
5. Predicting software cost
6. Predicting software schedules

50