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