Chapter 4: Software Project
Planning
Tadele M.
Contents
Introduction
Project Planning
Issues in project planning
Cost estimation
Cost estimation Techniques
Software size estimation techniques
Schedule and staffing
Risk Analysis and Management
Software Quality Assurance Planning
Project Monitoring Plans
Configuration Management Plan
2
Introduction
A project is a temporary endeavor undertaken to create a unique
product or service.
IT Projects have a terrible track record
A 1995 Standish Group study (CHAOS) found that only 16.2% of
IT projects were successful and over 31% were canceled before
completion, costing over $81 B in the U.S. alone.
Running any types of software projects needs planning because bad
planning is one of the reasons for many project failures.
3 “If you fail to plan, you plan to fail.”
Project planning
Project planning is a discipline for stating how to complete a
project within a certain timeframe, usually with defined stages,
and with designated resources.
The objective of project planning is to create a plan to meet the
commitments of the project,
i.e. create a path that, if followed, will lead to a successful
project.
What has to be planned?
the work to be done
the resources that will be required
the time that will elapse from start to finish.
The risk to be incurred
4
Project planning…
The major issues the project plan addresses are:
Schedule and staffing
Cost estimation
Risk Analysis & Management
Software Quality Assurance Planning
Project Monitoring Plans
Configuration Management Plan
5
Schedule and staffing
Software project scheduling is creating a network of software
engineering tasks enabling you to get the job done on time.
A project Schedule is at two levels - overall schedule and
detailed schedule
Overall schedule comprises of major milestones and final date
Detailed schedule is the assignment of lowest level tasks to resources
Milestone vs. deliverables
Milestone is end-point ( e.g. report) of software process activity
A conceptual change or moment
Deliverable is a project result that is delivered to the customer usually at
the end of some major project phase such as specification, design, etc.
represent something tangible – a concrete product or service
Deliverables are usually milestones but milestones need not be
deliverables.
6
Project Schedule
Project scheduling involves
Identifying tasks and
Determining dependencies among the tasks
Duration of each task
Start and finish date for each task
Project scheduling techniques
Precedence Networks : Program Evaluation and Review Technique (PERT)
Gant Chart
7
PERT Chart
It is based on graph theory (nodes and links)-acyclic directed
graph.
It shows:
dependencies among tasks
critical path ( a path which indicates the minimum time required
to finish the project or the longest path).
All activities which don’t lay on the critical path can be delayed
for some time (slack time) with out having any effect on overall
project schedule.
8
Scheduling with activity time
Activity Immediate Completion
predecessors Time (week)
A - 5
B - 6
C A 4
D A 3
E A 1
F E 4
G D,F 14
H B,C 12
I G,H 2
Total …… 51
This information indicates that the total time required to complete
activities is 51 weeks. However, we can see from the network that several
of the activities can be conducted simultaneously (A and B, for example).
9
Earliest start & earliest finish time
We are interested in the longest path through the network,
i.e., the critical path.
Starting at the network’s origin (node 1) and using a
starting time of 0, we compute an earliest start (ES) and
earliest finish (EF) time for each activity in the network.
The expression EF = ES + t can be used to find the earliest
finish time for a given activity.
For example, for activity A, ES = 0 and t = 5; thus the
earliest finish time for activity A is
EF = 0 + 5 = 5
10
Arc with ES & EF time
EF = earliest finish time
ES = earliest start time
Activity
1
t = expected activity
time
11
Network with ES & EF time
D[5,8] 5
2 3
7
4
1 6
Earliest start time rule:
The earliest start time for an activity leaving a particular node is equal to
the largest of the earliest finish times for all activities entering the node.
Forward pass calculation
12
Activity, duration, ES, EF, LS, LF
EF = earliest finish time
ES = earliest start time
Activity
2
LF = latest finish time
LS = latest start time
13
Latest start & latest finish time
To find the critical path we need a backward pass calculation.
Starting at the completion point (node 7) and using a latest
finish time (LF) of 26 for activity I, we trace back through the
network computing a latest start (LS) and latest finish time
for each activity
The expression LS = LF – t can be used to calculate latest start
time for each activity. For example, for activity I, LF = 26 and t
= 2, thus the latest start time for activity I is
LS = 26 – 2 = 24
14
Network with LS & LF time
D[5,8] 5
2 3[7,10]
7
4
1 6
Latest finish time rule:
The latest finish time for an activity entering a particular node is equal to
the smallest of the latest start times for all activities leaving the node.
15
Slack or Free Time or Float
Slack is the length of time an activity can be delayed without affecting the
completion date for the entire project.
For example, slack for C = 3 weeks, i.e Activity C can be delayed up to 3
weeks
3
(start anywhere between weeks 5 and 8).
2
ES LS EF EF
5 8 9 12
LF-EF = 12 –9 =3
LS-ES = 8 – 5 = 3
LF-ES-t = 12-5-4 = 3
16
Activity schedule for our example
Activity Earliest Latest Earliest Latest Slack Critical
start (ES) start (LS) finish (EF) finish (LF) (LS-ES) path
A 0 0 5 5 0 Yes
B 0 6 6 12 6
C 5 8 9 12 3
D 5 7 8 10 2
E 5 5 6 6 0 Yes
F 6 6 10 10 0 Yes
G 10 10 24 24 0 Yes
H 9 12 21 24 3
I 24 24 26 26 0 Yes
17
Project planning…
The major issues the project plan addresses are:
Schedule and staffing
Cost estimation
Risk Analysis & Management
Software Quality Assurance Planning
Project Monitoring Plans
Configuration Management Plan
18
Network with LS & LF time
D[5,8] 5
2 3[7,10]
7
4
1 6
Latest finish time rule:
The latest finish time for an activity entering a particular node is equal to
the smallest of the latest start times for all activities leaving the node.
19
Gantt Chart
Graphical display of start/end times
Shows overlapping activities easily
CPM or PERT are translated to Gantt sometimes
Gantt or Bar chart used more frequently than others
Suitable for projects
with less than 25
activities
Developed by Henry L.
Gantt
20
Cost Estimation
Predicting the resources required for a software development
process.
Highly subjective and depends on experience.
Some of the questions that would be addressed in cost
estimation are:
How much effort is required to complete an activity?
What is the total cost of an activity?
Software Cost components are
Hardware and software costs.
Travel and training costs.
Effort costs (the dominant factor in most projects)
Others like building, heating, lighting...
21
Cost estimation Approaches
• There are two approaches for cost estimation
Analogous or top-down: use the actual cost of a
previous, similar project as the basis for the new estimate
Bottom-up: estimate individual work items and sum them
to get a total estimate
22
Estimation Techniques
• Cost can be estimated using the following techniques:
• Expert judgement
• Estimation by analogy
• Parkinson's Law
• Pricing to win
• Algorithmic cost modelling
23
Estimation Techniques…
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.
Advantages:
Relatively cheap estimation method.
Can be accurate if experts have direct experience of similar systems
Disadvantages:
Very inaccurate if there are no experts!
New methods and technologies may make estimating based on
experience inaccurate.
24
Estimation Techniques…
Estimation by analogy
The cost of a project is computed by comparing the project to a similar
project in the same application domain
Advantages: Accurate if project data available
Disadvantages:
Impossible if no comparable project has been tackled.
Needs systematically maintained cost database
........................................................................................
Parkinson's Law
The project costs whatever resources are available: work expands to fill
the time available.
25
Estimation Techniques…
• Pricing to win
– The project costs whatever the customer has to spend on it i.e. the
estimated effort depends on the customer’s budget and not on the
software functionality.
• Algorithmic cost modelling
– Some formula based on empirical studies are derived and adjusted
according to the type of project (Organic, semidetached, embedded ).
– This estimation is generally based on the size of the software.
– Size of software is measured by Line of code(LOC), Function
Point(FP), Use case , etc.
26
What is COCOMO?
The Constructive Cost Model (COCOMO) is an algorithmic
software cost estimation model developed by Barry Boehm
1981.
Basic COCOMO computes software development effort (and
cost) as a function of program size. Program size is expressed in
estimated thousands of lines of code (KLOC).
COCOMO applies to three classes of software projects:
27
Classes of Software
Organic projects - "small" teams with "good" experience
working with "less than rigid" requirements
Semi-detached projects - "medium" teams with mixed
experience working with a mix of rigid and less than rigid
requirements
Embedded projects - developed within a set of "tight"
constraints (hardware, software, operational, ...)
28
Basic Equations
The basic COCOMO equations take the form
E = a(KLOC)b ……………...…………....man-months
TDev = c(E)d ………………………………… months
People required = E / TDev .....................................count
E: Effort applied
TDev: Development time
People required or average staffing
KLOC or KDSI
The coefficients a, b, c and d are given in the following
table.
Coefficients for the three classes of
software
Software Project a b c d
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
…ctd
Software Project Effort Schedule
Organic E=2.4(KLOC)1.05 Tdev=2.5(E)0.38
Semi-detached E=3.0(KLOC)1.12 Tdev=2.5(E)0.35
Embedded E=3.6(KLOC)1.20 Tdev=2.5(E)0.32
Example
We have determined our project fits the characteristics of Semi
Detached mode. We estimate our project will have 32,000 Delivered
Source Instructions. Using the formulas, we can estimate:
Effort = a(KLOC)b =3.0*(32) 1.12 = 146 man-months
Schedule or TDEV = c(E)d =2.5*(146) 0.35 = 14 months
Average Staffing =E / TDev = 146 MM /14 months
= 10 Men
Productivity =LOC/E = 32,000 DSI / 146 MM
= 219 DSI/MM
Staffing - Staff allocation chart
In addition to considering scheduling, as a project manager you
must also consider resource allocation and, in particular the
allocation of staff to a project activities.
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10
Jim T7
M ary T5
33
Staffing -Team Structure
Team organization has an effect on product quality and productivity,
so it needs to be planned.
Main points to consider for organizing development teams
Type of the project (difficulty of the problem)
The degree to which the problem can be modularized
The rigidity of delivery of data
Team size
Three ways of organizing a development team are
1. Egoless team structure (Democratic decomposition): Analyst
Equal responsibility of team members:
Tester
Programmer
Decision is by consensus
librarian
Has many communication paths
Designer
Good for projects which have long duration and for complex projects
34
Team Structure…
2. Chief Programmer (controlled centralized)
Hierarchical structure for effective management
Contribution of the members only for the task of the group
Less (vertical) communication path
Among programmers there exists horizontal communication
Suitable for small non-difficult projects and projects with tight schedule
3. Controlled decentralized
Combines the benefits of DD and CC team structure
Input from different members
Project Manager
Relatively small communication path
Team Leader
Programmers
35
36
Risk Analysis and Management
• Risk: any condition or event whose occurrence is not certain but
which can cause the project to fail.
• Any project can fail and reasons may be
– Managerial (e.g. schedule and budget overrun)
– Technical (doesn’t deliver what is expected)
• A project fails due to unforeseen events - risk management aims
to tackle this.
• Risk Analysis and management involves
• Risk Assessment (Risk identification, Risk Analysis, & Risk
Prioritization)
• Risk Control (Risk Resolution/mitigation & Risk Control)
37
Software Quality Assurance Plan
Software Quality is conformance to
Explicitly stated functional and performance requirements
Explicitly stated development standards
Implicit characteristics of all professional developed software
Quality can be defined in many ways
Current industry standard - delivered defect density (e.g. #defects/KLOC)
Defect - something that causes software to behave in an inconsistent manner
38
Project Monitoring Plans
Project monitoring includes monitoring progress/status,
Cost/effort, Personnel, resources.
Monitoring requires measurements (effort, size, schedule, and
defects) and methods for interpreting them.
Monitoring plan has to plan for all the tasks related to
monitoring.
Project monitoring also involves project tracking so as to get
visibility in project execution so corrective actions can be taken
when needed to ensure project succeeds.
The Gantt chart is one of the most popular ways to track your
project's progress
39
Configuration Management Plan
When you build computer software, change happens.
And because it happens, you need to control it effectively.
Software configuration management (SCM) is a set of activities
that are designed to control change by
identifying the work products that are likely to change,
establishing relationships among them,
defining mechanisms for managing different versions of these
work products,
controlling changes that are imposed, and
auditing and reporting on the changes that are made.
40
