Chapter 4

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/new
 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
Moreover
 Software project is a unique endeavor
undertaken with a purpose
 A project has the following attributes:
o A project has a unique purpose
o A project is temporary
o A project is developed in increments
o A project requires resources
o A project involves uncertainty

7
Project Management
 Project management is the application of
knowledge, skills, tools and techniques to
project activities to meet requirements.
 A project management framework includes:
o Stakeholders- people involved
o Project management knowledge areas,
o Project management tools and techniques-
assist in carrying out the work

8
Project Management
 The knowledge area has 3 parts with 9
knowledge:
o Core functions:
- Scope, time, cost and quality
o Supporting functions:
- Human resource, communication, risk and
procurement management
o Integration management

9
Fundamentals-Organization

10
Responsibilities-Customer
 Giving requirements and requirement
clarifications
 Providing test data, acceptance criteria,
etc
 Accepting deliverables

11
Responsibilities-PM
 The PM plans and guides the project by:
- Initiating the project
- Understanding the project requirement
- Planning, estimation and scheduling of project
- Identifying the training needs, planning and executing them
- Moderating work products
- Reporting, monitoring, and reviewing status
- Resolving issues
- Maintaining action log
- Releasing deliverables
- Closing the project

12
Responsibilities-Dev’pt Team
 Understanding system requirements
 Defining requirements
 Performing design and implementation
 Delivering work products
 Reporting status and resolving issues

13
Responsibilities-CNFG Mgt Team

 Controlling configuration library

 Enforcing change control
 Holding custody of change requests
 Making customer release

14
Responsibilities-Risk Mgt Team
 Identifying potential risks
 Estimating the probability and impact of
each risk
 Constructing a risk plan

15
Project Planning
 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.
 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.
 Project Planning helps in
 Facilitating
communication
 Monitoring / measuring the project progress
 Provides overall documentation of planning decisions 16
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

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

18
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.). 19
 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
20
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
21
 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.

22
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

23
 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:
 Veryinaccurate if there are no experts!
 new methods and technologies may make estimating
based on experience inaccurate 24
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

25
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

26
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

27
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
28
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

29
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
30
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

31
 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
32
Factors affecting productivity

33
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 / PM) 34

Example
 Consider a software project to
be developed for CAD
Function Estimated
application. A view of system LOC
specification identified the
UI and control 2, 300
following major software facilities
functions with respective 2D geometric analysis 5, 300
estimated line of code 2D geometric analysis 6, 800
 Calculate the effort and cost of Database 3, 350
development of the software management

(take productivity = 320 Graphics display 4, 950

facility
Loc/PM and labor rate = 1000 Design analysis 8,400
birr/ M) function

35
FP estimation
 Identify the functionality of a system in terms of information
domain. It is a solution to the size measurement problem
 Special features:
 Independent to the language
 Estimate development effort in early phases
 Directly linked with requirement
 Based on uses external view of system
 Consider appropriate complexity measure for each information
domain. Therefore it is decomposed into the following:

36
Cont…
 External Input(EI): information entering to the system

 External Output(EO): information leaving the system

 Internal logical file(ILF): information held in the system
 External interface file(EIF): information held by other system that is
used by the system being analyzed
 External enquiry(EQ): request access the system
This five functions are basically divided into measure categories of
functions
 Transactional functional
 EI,EO and EQ
 Data functional
 ILF,EIF

37
Cont…
 Graphically

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

•To make more meaningful estimation, use

other factors into estimation.
• Technical complexity factor (TCF) = 14
0.65  0.01  Fi
(complexity adjustment factor/CAF)
i 1
• Where Fi is adjustment factor in 5 point scale (0-5).
• Then AFP = UFP X TCF(CAF)
• Then apply the formula stated in slide 25 above

39
Function point analysis
 E.g. given the following items and weights
fined AFP (adjusted function point) and cost
Item Simple Average Complex
 EI 3 4 6
 EO 4 5 7
 ILF 7 10 15
 EIF 5 7 10
 EQ 3 4 6
 We need to identify the number of elements,
accordingly;

40
FP Analysis : A simple example
External Input
3 simple/low X 3 = 9
 Now we need to find CAF=
4 average X 4 = 16 14
0.65  0.01  Fi
1 complex X 6 = 6
 Fi 1
are degree of influencei based on
External outputs
6 average X 5 = 30 responses to standard question.
2 complex X 7 = 14  Its rate is 0 to 5
Internal file
0 1 2 3 4 5
5 complex X 15 = 75
External inquiry noInf inct moderate avg signf esse
8 average X 4 = 32
External file
Next we need to prepare the question
3 average X 7 = 21
and their response, question could
4 complex X 10 = 40
be like ,…
Unadjusted function points(UFP) =
9+16+6+30+14+75+32+21+40=243

41
Cont…
 Do you want the system to have password and
password? essential, 5=f1
 Does the system requires to search? average,
3=f2…. Assume Fi total=20
 CAF=0.65+0.01(20)

AFP/S=243*CAF
 E=A*(S)power of B
 Cost=E*Labor rate

42
 Object points
 Object points (alternatively named application
points) are an alternative function-related measure
to function points when 4GLs(scripting) 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

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

44
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
 It also used calculate the staff size and productivity
45
The COCOMO model…
 Long history from initial version published in 1981
(COCOMO or sometimes called COCOMO-81)
through various instantiations to COCOMO II
(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 II takes into account different
approaches to software development, reuse, etc.
46
 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: little innovation
 the Intermediate Model: medium innovation
 and the Detailed Model: high innovation

47
 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)

KDSI/size: thousands of delivered source instructions

M: project complexity multipler -- initially 1.0
PM/Effort: person-months
TDEV: time (months) to develop
staff=E/TDEV 48
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.

49
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

50
Intermediate COCOMO Model
 Takes basic COCOMO as starting point
 Identifies personnel, product, computer and
project attributes which affect cost
 Multiplies basic cost by attribute multipliers which
may increase or decrease costs
 The Intermediate Model estimates the software
development effort by using fifteen cost driver
variables besides the size variable used in Basic
COCOMO

51
Four areas for drivers
 Personnel attributes  Computer attributes
Analyst capability  Execution time constraints
 Virtual machine experience
 Storage constraints
 Programmer capability
 Virtual machine volatility
 Programming language
 Computer turnaround time
experience
 Application experience
 Project attributes
 Modern programming
 Product attributes
practices
 Reliability requirement
 Software tools
 Database size
 Required development
 Product complexity
schedule

52
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: example
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)

EAF- effort adjustment factor, it is the product of each cost driver

53
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

54
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

55
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

56
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)
57
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

58
Reading assignment
 COCOMO II

59
Scheduling and
staffing

60
Introduction
 Software project scheduling is creating a network of software
engineering tasks enabling you to get the job done on time.
 Schedule is a calendar that links the tasks to be done with the
resources that will do them
 Preliminary objectives of schedule:
o Best time
o Least cost
o Least risk
 Secondary objectives of schedule:
o Evaluation of schedule alternatives
o Effective use of resources
o communications

61
Building Schedule
Allocate resources
o For each task in the WBS/work breakdown structure, one or
more resources must be assigned
o Choose person(s) for each task
o Take overhead into account when calculating duration of
each task
Identify dependencies
o Task has dependency if it involves an activity, resource or
work product which is subsequently required by another task
o Every dependency has a predecessor

62
Terminology
 Slack is the amount of time which any of the tasks
can be delayed without causing the due date of the
final task in the sequence to be delayed.
 Precedence:
 A task that must occur before another is said to have
precedence of the other
 Concurrence:
 Concurrent tasks are those that can occur at the same time
(in parallel)
 Lead & Lag Time
 Delays between activities
 Time required before or after a given task respectively
63
Terminology
 Slack & Float
 Float & Slack: synonymous terms
- The slack of an event is a measure of the
excess time and resources available in
achieving this event
- If a task has a slack, then it can be delayed
without affecting the project finish date

64
Scheduling….
 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

65
 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 vs deliverables
 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. 66
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

67
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.
68
Detailed Scheduling
 To reach a milestone, many lowest level tasks
have to be performed
 Lowest level tasks are those that can be done by a
person (in less than 2-3 days)
 In this scheduling
 the low level tasks is decided
 The time needed to complete each activity is estimated
and
 suitable resources are assigned
 Any activity to be done must get reflected in the
detailed schedule

69
Detailed Scheduling
 Is an iterative task - if cannot “fit” all tasks, must
revisit high level schedule
 Detailed schedule is not done completely in the
start - it evolves
 Detailed schedule can be done in CASE tools like
MS Project and spreadsheets
 Detailed Schedule is the most live document for
managing the project
 If plan changes the detailed scheduled is updated

70
Project Scheduling Technique
 Involves Identification of:
 The tasks
 dependencies among the tasks
 Duration of each task
 Start and finish date for each task
 Techniques:
 GantChart
 Network diagrams
 Program Evaluation and Review Technique (PERT): Event-
based
 Critical Path Method (CPM): Activity-based

71
Network diagrams
 Developed in the 1950’s
 A graphical representation of the tasks necessary to complete a
project
 Visualizes the flow of tasks & relationships
 Advantages;
- Show precedence well
- Ability to calculate critical path
- Ability to perform what if exercises
 Disadvantage:
- Default model assumes resources are limited
- Difficult to follow on large projects

72
Network Diagram Example
 Given tasks, dependencies, duration draw network D.
No. Task Dependency Duration
1 A - 30
2 B A 60
3 C A 45
4 D B 60
5 E B 60
6 F C 15
7 G E 30
8 H, Fin D,F,G 0

73
Example
 Solution:
1. Calculate forward passes (ES & EF):
 to determine early start(ES) and early finish(EF) times for
each task
 LS is Latest and ES is Earliest Start time for activity (or source
node)
 LF is Latest and EF is Earliest Finish time
o work from left to right starting from node 1
 ESj = maxi {(ESi + time for activity ai,j )} , i and j are nodes
 ES for last node is “project deadline” or
o ES of node 1 is zero
o EF = ES + duration
o the ES for the next task is the largest of preceding EF times
o Duration of last node is zero

74
Example with Forward Passes

75
Example
2. Calculate backward passes(LF &LS):
 To determine late finish(LF) and Late
start(LS) for each task
o Start at the end node and work backward
o Set LF = EF; LS = ES for the last node
o LS of predecessor=LF-Duration
o LF of predecessor=minimum LS of its
successors
 Latest times calculated using “backward pass”
 What’s the latest time for each node, keeping the deadline?

76
Example with Backward Passes

77
Example
3. Calculate slack for each task as follows:
 Start and finish tasks have slack 0
 Tasks on critical path have slack 0
 For other activities:
- Slack = LF-EF or slack = LS-ES
N.B.
-Positive slack shows ahead of schedule
-Zero slack indicates on schedule
-Negative slack shows behind schedule

78
Critical Path
 The specific set of sequential tasks upon which the project
completion date depends or the longest full path.
 All projects have a Critical Path
 Tasks on critical path are critical tasks
 Accelerating non-critical tasks do not directly shorten the
schedule
 In the previous example, tasks A,B,E,G,H are critical and
ABEGH is the critical path and 180 is the critical time.
 Note: There can be more than one critical paths or the critical
path can change
 The process of determining and optimizing the critical path is
known as CPM(critical path model)

79
Exercise
Task Duration Dependency

T1 8 -

 Ex1 T2 15 -
T3 15 T1
T4 10 -
T5 10 T2,T4
T6 5 T1, T2
T7 20 T1
T8 25 T4
T9 15 T3,T6
T10 15 T5,T7
T11 7 T9
 Construct T12
the Network diagram
10 T11
 Determine critical path
 Determine slack time for each activity

80
Program Evaluation and Review
Technique(PERT)
 Developed in 1950 for large and complex projects
 Based on idea that estimates are uncertain
 Therefore uses duration ranges
 And the probability of falling to a given range
 Uses an “expected value” (or weighted average) to
determine durations
 Use the following methods to calculate the expected
durations, then use as input to your network diagram

81
PERT
 Start with 3 estimates
 Optimistic
 Would likely occur 1 time in 20
 Most likely
 Modal value of the distribution
 Pessimistic
 Would be exceeded only one time in 20

82
PERT
• Combined to estimate a task duration
p

NB: a==o, b==p

83
ex

84
85
86
S=LS-ES=0

87
CPM vs PERT
 Both use Network Diagrams
 CPM: deterministic
 PERT: probabilistic
 CPM: one estimate, PERT, three
estimates
 PERT is infrequently used

88
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

89
Gantt Chart example…

90
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

91
 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

92
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

93
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

94
Team structure…

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

Project Manager

Team Leader

Programmers

95
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

96
Risk Management Tasks

RISK IDENTIFICATION

RISK ASSESSMENT RISK ANALYSIS

RISK PRIORITIZATION
RISK
MANAGEMENT RISK MANAGEMENT
PLANNING

RISK CONTROL RISK RESOLUTION

RISK MONITORING

97
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
98
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

99
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

100
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

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

102
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

103
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 Configuration Management
process and guidelines strictly
104
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

105
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
106
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

107
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)

108
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
109
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

110
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

111
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

112
Cost-schedule milestone graph

113
Project Management Plan
 The project management plan (PMP) document is
the culmination of all planning activities undertaken
by project managers.
 It should not be confused with the detailed project
schedule.
 Detailed project schedule represents only the
schedule and assignment of activities.
 PMP shows what activities get done in the project

114
 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, …
115
Format for Project Plan - 1
 Title page
 Signature page
 Change history
 Preface
 Table of contents
 List of figures
 List of tables

116
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

117
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
118
Format for Project Plan - 4
 6- Technical process plans
 Process model
 Methods, tools
 Acceptance plan
 7- Supporting process plans
 Configuration management
 Verification/validation
 Quality assurance (reviews, audits, …)
 Subcontract
 Process improvement plan
 Annexes
 Index 119
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

120