Chapter 2

Software Project Planning

1
Contents
 Introduction
 Project Planning
 Cost estimation
 COCOMO
 Schedule and staffing
 Risk Analysis and Management
 Software Quality Assurance Planning
 Project Monitoring Plans
 Project Management Plan
 Format for Project Plan
2
Software Engineering Projects
 Software projects are different from projects of other engineering
discipline. How?
 Software engineering projects may be:
 Evolutionary or maintenance projects
 Most projects are of this type
 Can be several different types

 Corrective projects

 Adaptive projects

 Enhancement projects

 Perfective projects / Reengineering

3
Software Engineering Projects…
 Projects that involve building on a framework
or a set of existing components.
 A framework is a software system especially
designed to be reused in different projects, or in
the various products of a product line.
 Green field projects
 The minority of projects
 Developers often enjoy such brand new, or green
field projects – they have a wider freedom to be
creative about design decision.

4
Software Engineering Projects…
 The goal of any software project is to produce a
software system that meet commitments on cost,
schedule, quality.
 Worldwide - many projects fail
 one-thirdare runaways with cost or schedule
overrun of more than 125%
 Major reasons for project runaways
 unclear objectives
 bad planning
 no project management methodology
 new technology
 insufficient staff

5
Software Engineering Projects…
 Project planning is crucial to the success of the Project:
 careful planning right from the beginning of the
project can help to avoid costly mistakes.
 Reluctance to Planning
 Takes too much time and cost
 Preventive action
 Long-term payoff is greater than short-term cost
 Too tedious (mental activity)
 “Thinker” and “doer”
 Ego (shoot from the hip)
 Not realistic
“If you fail to plan, you plan to fail.”
6
Project Planning
 Before the project can begin, the manager and the
software team must estimate
 the work to be done,
 the resources that will be required, and
 the time that will elapse from start to finish.
 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.
 Project Planning helps in
 Facilitating
communication
 Monitoring / measuring the project progress
 Provides overall documentation of planning decisions
7
Project Planning…
 Project Planning is an ongoing effort throughout the
Project Lifecycle.
 The major issues the project plan addresses are:
 Cost estimation
 Schedule and staffing
 Risk Analysis & Management
 Software Quality Assurance Planning
 Project Monitoring Plans
 Configuration Management Plan

8
 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?
 How much calendar time is needed to complete an
activity?
 What is the total cost of an activity?

9
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;
 Social and insurance costs.
 Effort costs must take overheads into account
 Costs of building, heating, lighting.
 Costs of networking and communications.
 Costs of support resources
 Costs of shared facilities (e.g library, staff restaurant,
etc.). 10
 Estimation Techniques
 Estimations techniques:
 Expert judgement
 Estimation by analogy
 Parkinson's Law
 Pricing to win
 Algorithmic cost modelling

 Each method has strengths and weaknesses

 Estimation should be based on several methods
 If these do not return approximately the same result,
there is insufficient information available
 Some action should be taken to find out more in order to
make more accurate estimates

11
Cost estimation Approaches
 Any of the cost estimations techniques can be
tackled using either Top-down or Bottom-up
approaches
 Top-down
 Startat the system level and assess the overall
system functionality and how this is delivered
through sub-systems
 Bottom-up
 Start at the component level and estimate the
effort required for each component. Add these
efforts to reach a final estimate
12
 Top-down estimation
 Usable without knowledge of the system
architecture and the components that might be
part of the system
 Takes into account costs such as integration,
configuration management and documentation
 Can underestimate the cost of solving difficult
low-level technical problems associated with
specific components such as interfaces to non
standard hardware.

13
Bottom-up estimation
 Usable when the architecture of the system is
known and components identified
 Accurate method if the system has been
designed in detail
 May underestimate costs of system level
activities such as integration and documentation
 Bottom-up estimation is more expensive

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.
 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
15
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

16
Parkinson's Law
 The project costs whatever resources are
available.
 work expands to fill the time available.
 The cost is determined by available resources rather
than by objective assessment.
 If the software has to be delivered in 12 months and 5
people are available, the effort required is estimated
to be 60 person-months.
 Advantages: No overspend
 Disadvantages: System is usually unfinished

17
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
 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

18
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
 Lineof Code (LOC)
 Function point (FP)
 Object point effort estimation
 Use case based (object oriented approach)
 COCOMO is one of algorithmic cost models
19
Project Characteristics
 Organic Mode
 developed in a familiar, stable environment,
 similar to the previously developed projects
 relatively small and requires little innovation

 Semidetached Mode
 intermediate between Organic and Embedded
 Embedded Mode
 tight,
inflexible constraints and interface requirements
 The product requires great innovation

20
Algorithmic cost modelling…
 Cost is estimated as a mathematical function
of product, project and process attributes
whose values are estimated by project
managers
 Effort = A × SizeB × M
 A is an organisation-dependent constant,
 B reflects the disproportionate effort for large projects
and
 M is a multiplier reflecting product, process and
people attributes
21
Algorithmic cost modelling…
 Most commonly used product attribute for cost
estimation is code size
 Most models are basically similar but with
different values for A, B and M

System a b

Organic 3.2 1.05

Semi-detached 3.0 1.12
Embedded 2.8 1.20

22
 Software productivity
 A measure of the rate at which individual
engineers involved in software development
produce software and associated
documentation.
 Essentially, we want to measure useful
functionality produced per time unit.
 Productivity may generally be increased at the
cost of quality
 It is not clear how productivity/quality metrics
are related
23
Factors affecting productivity

24
LOC based estimation
 Identify the basic functionalities/modules of the
system.
 Estimate each module/functionality based on
historical data.
 Compute three point average
 Size = (SO + 4SM +SP) / 6
 Then apply either of the following formula
 Effort = A × SizeB
Effort = Total size / productivity
 Note that
 Cost = effort X Labor rate

 Labor rate= X birr / time)

25
Example
 Consider a software project to
be developed for CAD
Function Estimated
application. A view of system LOC
specification identified the
UI and control facilities 2, 300
following major software
functions with respective 2D geometric analysis 5, 300
estimated line of code 2D geometric analysis 6, 800
 Calculate the effort and cost of
Database management 3, 350
development of the software
(take productivity = 320 Loc/PM Graphics display 4, 950
facility
and labor rate = 1000 birr/ M)
Design analysis function8,400

26
FP estimation
 Identify the functionality of a system in terms of
information domain.
 Consider appropriate complexity measure for each
information domain.
Item Simple Average Complex
 External Input 3 4 6
 External Output 4 5 7
 Internal file 7 10 15
 External file 5 7 10
 External inquiry 3 4 6

27
 FP estimation…
• Unadjusted function point is calculated using the
formula

• To make more meaningful estimation, use

other factors into estimation.
14
• Technical complexity factor (TCF) = 0.65 + 0.01 ∑ Fi
i =1

• Where Fi is adjustment factor in 5 point scale (0-5).

• Then FP = UFC X TCF
• Then apply the formula stated in slide 25 above

28
 FP Analysis : A simple example
External Input
3 simple X 3 = 9
4 average X 4 = 16
1 complex X 6 = 6
External outputs
6 average X 5 = 30
2 complex X 7 = 14
Internal file
5 complex X 15 = 75
External inquiry
8 average X 4 = 32
External file
3 average X 7 = 21
4 complex X 10 = 40
Unadjusted function points = 243
29
Function points
 FPs can be used to estimate LOC depending on the
average number of LOC per FP for a given language
 LOC = AVC * number of function points;
 AVC is a language-dependent factor varying from
200-300 for assemble language to 2-40 for a 4GL
C++ 36
C 128
Lisp 64
Spreadsheet 6
Pascal 98
Quickbasic 58

 Data varies from organization to organization: need of

collecting data!
30
 Object points
 Object points (alternatively named application
points) are an alternative function-related measure
to function points when 4GLs or similar languages
are used for development.
 Object points are NOT the same as object classes
 The number of object points in a program is a
weighted estimate of
 The number of separate screens that are displayed
 The number of reports that are produced by the system
 The number of modules that must be developed

31
Object point estimation
 Object points are easier to estimate from a
specification than function points as they are
simply concerned with screens, reports and
programming language modules.
 They can therefore be estimated at a fairly early
point in the development process.
 At this stage, it is very difficult to estimate the
number of lines of code in a system.

32
The COCOMO model
 Constructive Cost Model (COCOMO), which is created by
Boehm in 1981, is an empirical model based on project
experience.

 Well-documented, ‘independent’ model which is not tied to a

specific software vendor.

 COCOMO predicts the effort and schedule for a software

product development based on inputs relating to the size of
the software and a number of cost drivers that affect
productivity

33
The COCOMO model…
 Long history from initial version published in 1981
(COCOMO or sometimes called COCOMO-81) through
various instantiations to COCOMO 2 (1997)
 COCOMO-81 is strictly geared toward traditional
development life cycle (water fall model applied to new
software projects) models and relies on lines of code
 COCOMO 2 takes into account different approaches to
software development, reuse, etc.

34
 The COCOMO model…
 Estimates total effort in terms of person-months
 Cost of development, management, support tasks
included but Secretarial staff is not included
 COCOMO -81has three different models that reflect the
complexity:
 the Basic Model
 the Intermediate Model
 and the Detailed Model

35
 Basic COCOMO Model
 Basic COCOMO model estimates the software
development effort using only a single predictor
variable (size in DSI) and three software
development modes
 Equations of basic COCOMO Model:
Mode Effort Schedule

1.05 0.38
Organic E=2.4*(KDSI) TDEV=2.5*(E)

1.12 0.35
Semidetached E=3.0*(KDSI) TDEV=2.5*(E)

1.20 0.32
Embedded E=3.6*(KDSI) TDEV=2.5*(E)
36
Basic COCOMO Model pros and cons
 Basic COCOMO is good for quick, early, rough
order of magnitude estimates of software costs
 Its accuracy is necessarily limited because of its
lack of factors which have a significant influence
on software costs:
 hardware constraints,
 personnel quality and experience,
 use of modern tool and techniques,
 other project attributes known to have significant
influence on software costs.

37
Basic COCOMO Model: An 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 = 3.0*(32) 1.12 = 146 man-months
 Schedule = 2.5*(146) 0.35 = 14 months
 Productivity = 32,000 DSI / 146 MM
= 219 DSI/MM
 Average Staffing = 146 MM /14 months
= 10 FSP

38
Intermediate COCOMO Model
 The Intermediate Model estimates the software
development effort by using fifteen cost driver
variables besides the size variable used in Basic
COCOMO
 Four areas for drivers
 Product: e.g., reliability requirements or inherent
complexity
 Computer: e.g., are there execution time or storage
constraints?
 Personnel: e.g., are the personnel experienced in the
application area or the programming language being
used?
 Project: e.g., are sophisticated software tools being
used?
39
Intermediate COCOMO
 Each of the fifteen cost driver can have
complexity of Very low, low, nominal (1.00 for
all attributes), high or very high.
 Equations of Intermediate COCOMO Model:
Mode Effort Schedule

1.05 0.38
Organic E=EAF*3.2*(KDSI) TDEV=2.5*(E)

1.12 0.35
Semi- E=EAF*3.0*(KDSI) TDEV=2.5*(E)
detached

1.20 0.32
Embedded E=EAF*2.8*(KDSI) TDEV=2.5*(E)
40
Intermediate COCOMO pros and cons
 The Intermediate Model can be applied across
the entire software product for easily and rough
cost estimation during the early stage
 or it can be applied at the software product
component level for more accurate cost
estimation in more detailed stages
 Its effort multipliers are phase-insensitive
 It can be very tedious to use on a product with
many components
 The Intermediate Model estimates are within 20%
of the actual 68% of the time
41
Intermediate Model: An Example
 Project A is to be a 32,000 DSI semi-detached
software. It is in a mission critical area, so the
reliability is high (RELY=high=1.15). Then we can
estimate:
 Effort = 1.15*3.0*(32)1.12 = 167 man-months
 Schedule = 2.5*(167)0.35 = 15 months
 Productivity = 32,000 DSI/167 MM
= 192 DSI/MM
 Average Staffing = 167 MM/15 months
= 11 FSP

42
Detailed COCOMO Model
 How is it Different?
 Phase-sensitive Effort Multipliers
The effort multipliers for every cost drivers are
different during the software development
phases
 Module-Subsystem-System Hierarchy
The software product is estimated in the three
level hierarchical decomposition. The fifteen
cost drivers are related to module or subsystem
level

43
Equations of Detailed COCOMO Model
 Detailed Model uses the same equations for
estimations as the Intermediate Model
 Detailed Model uses a very complex procedure to
calculate estimation. The procedure uses the DSIs
for subsystems and modules, and module level and
subsystem level effort multipliers as inputs
Mode Effort Schedule

1.05 0.38
Organic E=EAF*3.2*(KDSI) TDEV=2.5*(E)

1.12 0.35
Semi- E=EAF*3.0*(KDSI) TDEV=2.5*(E)
detached

1.20 0.32
Embedded E=EAF*2.8*(KDSI) TDEV=2.5*(E)
44
Detailed COCOMO Model pros & cons
 The Detailed Model can estimate the staffing, cost,
and duration of each of the development phases,
subsystems, modules
 It allows you to experiment with different
development strategies, to find the plan that best
suits your needs and resources
 Requires substantially more time and effort to
calculate estimates than previous models
 Detailed Model estimates are within 20% of the
actual 70% of the time

45
 COCOMO II levels
 COCOMO II is tuned to modern software life cycles
 It is a 3 level model that allows increasingly detailed
estimates to be prepared as development progresses
 Early prototyping level
 Estimates based on object points and a simple formula is
used for effort estimation
 Early design level
 Estimates based on function points that are then
translated to LOC
 Post-architecture level
 Estimates based on lines of source code
46
COCOMO II Model Stages

47
Early prototyping level
 Supports prototyping projects and projects where
there is extensive reuse
 Based on standard estimates of developer
productivity in object points/month and takes CASE
tool use into account
 Formula is: PM = ( NOP × (1 - %reuse/100)) / PROD
 PM is the effort in person-months, NOP is the number of object
points and PROD is the productivity, and %reuse percentage of
reuse

48
Early design level
 Estimates can be made after the requirements
have been agreed
 Based on standard formula for algorithmic models
 PM = A × SizeB × M + PMm where
 M=PERS × RCPX × RUSE × PDIF × PREX × FCIL ×
SCED
 PMm = (ASLOC × (AT/100)) / ATPROD
 A = 2.5 in initial calibration, Size in KLOC, B varies from 1.1
to 1.24 depending on novelty of the project, development
flexibility, risk management approaches and the process
maturity
49
 Multipliers
 Multipliers reflect the capability of the developers, the
non-functional requirements, the familiarity with the
development platform, etc.
 RCPX - product reliability and complexity
 RUSE - the reuse required
 PDIF - platform difficulty
 PREX - personnel experience
 PERS - personnel capability
 SCED - required schedule
 FCIL - the team support facilities
 PM reflects the amount of automatically generated code
 ASLOC – Automatically generated SLOC
 ATPROD – Productivity level of this type of code production
50
 Post-architecture level
 Uses the same formula as the early design model
but with 17 rather than 7 associated multipliers.
 Involves actual software construction and software
maintenance
 Estimate of size is adjusted to take into account
 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.
51
Estimation accuracy
 The size of a software system can only be
known accurately when it is finished
 Several factors influence the final size
 Use of COTS and components
 Programming language
 Distribution of system

 As the development process progresses then

the size estimate becomes more accurate

52
Estimate uncertainty…
4x

2x

x Code
Feasibility Requirements Design Delivery

0.5x

0.25x

53
Schedule and staffing
 Software project scheduling is creating a network of
software engineering tasks enabling you to get the job done
on time.
 Responsibility is assigned for each task, progress is
tracked, and the network is adapted to changes in the
process as they occur.
 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

54
 Project Schedule
• The scheduling process:

Identify Identify activity Estimate resources Allocate people Create project

activities dependencies for activities to activities charts

Software Activity charts

requirements and bar charts

 Milestone is end-point ( e.g. report) of software

process activity
 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.
 Deliverables are usually milestones but
milestones need not be deliverables.
55
Overall Schedule
 Depends heavily on the effort estimate
 For an effort estimate, some flexibility exists
depending on resources assigned
 E.g.a 56 PM project can be done in 8 months (7
people) or 7 months (8 people)
 Stretching a schedule is easy; compressing is
hard and expensive

56
Overall Scheduling...
 One method is to estimate schedule S (in
months) as a function of effort in PMs
 Can determine the function through analysis of
past data; the function is non linear
 COCOMO:
S = 2.5 E 0.38 (organic)
 S = 2.5 E 0.35 (semidetached)
 S = 2.5 E 0.32 (Embedded)
 Often this schedule is checked (schedule
reasonableness) and corrected for the specific
project
 One checking method – square root check 57
Determining Overall Schedule
from past data
Effort in person-days

400

350
Schedule (Days)

300

250

200

150

100

50

0
0 200 400 600 800 1000 1200 1400 1600 1800

The equation of the project is schedule = 23.46 (effort)0.313

58
Determining Milestones
 With effort and overall schedule decided,
average project resources are fixed
 Manpower ramp-up in a project decides the
milestones
 Manpower ramp-up in a project follows a
Rayleigh curve - like a normal curve
 i.e.assigning a few people at the start, having the
peak team during the coding phase, and then leaving
a few people for testing
 In reality manpower build-up is a step function

59
Manpower Ramp-up

PTS

D e s ig n B u ild Test

60
Milestones
 With manpower ramp-up and effort distribution,
milestones can be decided
 Effort distribution and schedule distribution in phases
are different
 Generally, the build has larger effort but not
correspondingly large schedule
 COCOMO specifies distribution of overall schedule.
Design – 19%, programming – 62%, integration – 18%

61
Detailed Scheduling
 To reach a milestone, many tasks have to be
performed
 Lowest level tasks - those that can be done by a
person (in less than 2-3 days)
 Scheduling - decide the tasks, assign them while
preserving high-level schedule
 Is an iterative task - if cannot “fit” all tasks, must
revisit high level schedule

62
Detailed Scheduling
 Detailed schedule is not done completely in the
start - it evolves
 Can use MS Project for keeping it
 Detailed Schedule is the most live document for
managing the project
 Any activity to be done must get reflected in the
detailed schedule

63
Project Scheduling Technique
 Involves Identification of:
 The tasks
 dependencies among the tasks
 Duration of each task
 Start and finish date for each task
 Techniques:
 Gant Chart
 Precedence Networks
 Program Evaluation and Review Technique (PERT): Event-
based
 Critical Path Method (CPM): Activity-based
64
Gantt Chart
 Gantt or Bar chart used more frequently than others
 Suitable for projects with less than 25 activities
 Graphical display of start/end times
 Shows overlapping activities easily
 CPM or PERT are translated to Gantt sometimes
 For estimation of resource and budget vs. time
 Developed in 1917 by Henry L. Gantt

65
Gantt Chart example
Engineer

Jane

Anne

Jane

Fred

Mary

Anne

Jim

Fred

Jane

Anne

Fred

Fred

66
Gantt Chart example…
4
/7 11
/7 1
8/7 2
5/7 1
/8 8
/8 1
5/8 2
2/8 2
9/8 5
/9 1
2/9 1
9/9
S
tart
T4
T
1
T2
M
1
T
7
T
3
M5
T8
M
3
M
2
T
6
T
5
M
4
T
9
M
7
T
10
M
6
T
11
M
8
T
12
F
in
ish
67
Gantt Chart example…
Staff allocation chart
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

Mary T5

68
PERT
 Based on graph theory (nodes and links)-acyclic
directed graph
 Shows dependencies among tasks
 PERT shows 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.

69
 PERT
14/7 /03 15 da ys
15 da ys
M1 T3
8 days T9
T1 5 days 4/8/03 25/8/03
25/7 /03
4/7 /03 T6 M4 M6
M3
star t 20 days 7 days
15 days
T7 T11
T2
25/7 /03 11/8/03 5/9/03
10 da ys 10 days
M2 M7 M8
T4 T5 15 da ys
T10 10 days
18/7 /03
T12
M5
25 days
T8 Finish
19/9/03

70
Critical path
 Zero for those on critical path
 S = LS - ES or S = LF – EF
 LS is Latest and ES is Earliest Start time for activity (or source node)
 LF is Latest and EF is Earliest Finish time
 Earliest times calculated using “forward pass”
 ESj = maxi {(ESi + time for activity ai,j )} , i and j are nodes
 ES for last node is “project deadline”
 Latest times calculated using “backward pass”
 What’s the latest time for each node, keeping the deadline?

 Question: For the activity network in slide 70

 Determine critical path
 Determine slack time for each activity

71
 Team Structure
 Team organization has an effect on product
quality and productivity.
 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

72
Team Structure…
 Three ways of organizing a development team
1. Egoless team structure (Democratic
decomposition):
 Equal responsibility of team members
 Decision is by consensus (equal contribution)
 Has many communication paths
Analyst
 Good for projects which have long
Tester
duration and for complex projects Programmer

librarian

Designer
73
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

74
Team structure…

3. Controlled decentralized
 Combines the benefits of DD nd CC team
structure
 Input from different members
 Relatively small communication path

Project Manager

Team Leader

Programmers

75
Risk Analysis and Management
 Any project can fail - reasons
 Managerial (e.g. schedule and budget overrun)
 Technical (doesn’t deliver what is expected)

 A project may fail due to unforeseen events - risk

management aims to tackle this.
 Risk: any condition or event whose occurrence is not
certain but which can cause the project to fail
 Cost risk
 Performance risk
 Schedule risk

76
Risk Management Tasks

R IS K ID E N T IF IC A T IO N

R IS K A S S E S S M E N T R IS K A N A L Y S IS

R IS K P R IO R IT IZ A T IO N
R IS K
M ANAGEM ENT R IS K M A N A G E M E N T
P L A N N IN G

R IS K C O N T R O L R IS K R E S O L U T IO N

R IS K M O N IT O R IN G

77
Risk Identification
 To identify possible risks to a project, i.e. to those
events that might occur and which might cause the
project to fail
 No “algorithm” possible, done by “what ifs”, checklists,
past experience, etc
 Top Risk Examples
 Shortage of technically trained manpower
 Too many requirement changes
 Unclear requirements
 Not meeting performance requirements
 Unrealistic schedules
 Insufficient business knowledge
 Working on new technology

78
Risk Prioritization
 The number of risks might be large
 Must prioritize them to focus attention on the
“high risk” areas
 For prioritization, impact of each risk must be
understood
 In addition, probability of the risk occurring
should also be understood
 Risk exposure (RE) = probability of risk
occurring * risk impact
 RE is the expected value of loss for a risk

79
Risk Prioritization ...
 Prioritization can be done based on risk
exposure value
 Plans can be made to handle high RE risks
 A Simple approach to Risk Prioritization
 Classify risk occurrence probabilities as: Low,
Medium, High
 Classify risk impact as: Low, Medium, High
 Identify those that are HH, or HM/MH
 Focus on these for risk mitigation
 Will work for most small and medium sized projects

80
Risk Control
 Can the risk be avoided?
 E.g.if new hardware is a risk, it can be avoided by
working with proven hardware
 For others, risk mitigation steps need to be
planned and executed
 Actions taken in the project such that if the risk
materializes, its impact is minimal
 Involves extra cost

81
Risk Mitigation Example
 Too many requirement changes
 Convince client that changes in requirements
will have an impact on the schedule
 Define a procedure for requirement changes
 Maintain cumulative impact of changes and
make it visible to client
 Negotiate payment on actual effort.

82
Example…
 Unrealistic schedules
 Negotiate for better schedule
 Identify parallel tasks
 Have resources ready early
 Identify areas that can be automated
 If the critical path is not within the schedule, negotiate
with the client
 Negotiate payment on actual effort

83
Example…
 Manpower attrition
 Ensure that multiple resources are assigned
on key project areas
 Have team building sessions
 Rotate jobs among team members
 Keep backup resources in the project
 Maintain documentation of individual’s work
 Follow the CM process and guidelines strictly

84
Risk Mitigation Plan
 Risk mitigation involves steps that are to be
performed (hence has extra cost)
 It is not a paper plan - these steps should be
scheduled and executed
 These are different from the steps one would
take if the risk materializes - they are performed
only if needed
 Risks must be revisited periodically

85
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
86
Defect Injection and Removal
 Software development is labor intensive
 Defects are injected at any stage
 As quality goal is low delivered defect density,
these defects have to be removed
 Done primarily by quality control (QC) activities
of reviews and testing

87
Quality Plan
 The quality plan drives the quality activities in
the project
 Level of plan depends on models available
 Must define QC tasks that have to be performed
in the project
 Can specify defect levels for each QC tasks (if
models and data available)

88
Project Monitoring Plans
 Project monitoring includes Progress/status,
Cost / effort, Personnel, resources
 A plan is a mere document that can guide - It
must be executed
 To ensure execution goes as per plan, it must be
monitored and controlled
 Monitoring requires measurements
 And methods for interpreting them
 Monitoring plan has to plan for all the tasks
related to monitoring
89
Measurements
 Must plan for measurements in a project
 Without planning, measurements will not be
done
 Main measurements – effort, size, schedule,
and defects
 Effort– as this is the main resource; often tracked
through effort reporting tools
 Defects – as they determine quality; often defect
logging and tracking systems used
 During planning – what will be measured, how,
tool support, and data management

90
Project Tracking
 Goal: To get visibility in project execution so
corrective actions can be taken when needed to
ensure project succeeds
 Different types of monitoring done at projects;
measurements provide data for it
 Activity-level monitoring
 Each activity in detailed schedule is getting done
 Often done daily by managers
 A task done marked 100%; tools can determine status
of higher level tasks

91
Tracking…
 Status reports
 Generally done weekly to take stock
 Summary of activities completed, pending
 Issues to be resolved
 Milestone analysis
A bigger review at milestones
 Actual vs estimated for effort and schedule is done
 Risks are revisited
 Changes to product and their impact may be analyzed
 Cost-schedule milestone graph is another way of
doing this

92
Cost-schedule milestone graph

93
Project Management Plan
 The project management plan (PMP) contains
outcome of all planning activities - focuses on
overall project management
 Besides PMP, a project schedule is needed
 Reflectswhat activities get done in the project
 Microsoft project (MSP) can be used for this
 Based on project planning; is essential for day-to-day
management

94
 PMP Structure - Example
 Project overview - customer, start and end date, overall
effort, overall value, main contact persons, project
milestones, development environment..
 Project planning - process and tailoring, requirements
change mgmt, effort estimation, quality goals and plan,
risk management plan, ..
 Project tracking - data collection, analysis frequency,
escalation procedures, status reporting, customer
complaints, …
 Project team, its organization, roles and responsibility,
…

95
Format for Project Plan - 1
 Title page
 Signature page
 Change history
 Preface
 Table of contents
 List of figures
 List of tables

96
Format for Project Plan - 2
 1- Overview
 Summary
 Purpose, scope, objectives
 Assumptions and constraints

 Deliverables

 Schedule and budget summary

 Evolution of plan
 2- References
 3- Definitions

97
Format for Project Plan - 3
 4- Project organization
 External interface
 Internal structure
 Roles and responsibilities
 5- Managerial process plans
 Estimation (cost, schedule)
 Work (activities, resource and budget
allocation)
 Control (quality, metrics, …)
 Risk management
98
Format for Project Plan - 4
 6- Technical process plans
 Processmodel
 Methods, tools
 Acceptance plan
 7- Supporting process plans
 Configuration management
 Verification/validation
 Quality assurance (reviews, audits, …)
 Subcontract
 Process improvement plan
 Annexes
 Index 99
Summary
 Project planning forms the foundation of project
management
 Key aspects: effort and schedule estimation, quality
planning, risk management., …
 Outputs of all can be documented in a PMP, which
carries all relevant info about project
 Besides PMP, a detailed project schedule
maintains tasks to be done in the project

100