Project Planning

Module 2
planning
 Most important management activity

Goals
 Look in to the future
 Identify the activities that need to be done to complete
the project successfully
 Plan the scheduling
 Resource allocation

Input - Requirement Specification

Output - project plan
Issues
 Cost Estimation
 Schedule and Milestones
 Personnel Plan
 Software Quality Assurance Plans
 Configuration Management Plans
 Project Monitoring Plans
 Risk Management
Cost Estimation
 Enable the client or developer to perform a cost-benefit
analysis
 Project monitoring and control
 Cost – software, hardware, human resources

Main Cost – Human Resources

Uncertainties in Cost Estimation
Cost Estimation Accuracy
Cost Estimation Models

 Can be viewed as a “function” that outputs the cost

estimate
 factors: Size of the project
Programmer ability
Experience of the developers
Complexity of the project
Reliability requirements (exponential)

Primary cost control factor – size of the project

Start with single variable estimate (SIZE)

EFFORT = a * SIZE b
a and b are constants

EFFORT = a * SIZE + b (Small Projects)

a and b can be calculated by Regression Analysis:

Basic idea is to fit a line through the data points in the
scatter plot so that the sum of squares of the distance
from the line of the points is minimized

E.g: Watson and Felix : 5.2(KDLOC) .91

Why Size Estimation???

Why not Cost Estimation???

COCOMO Model
 COnstructive COst MOdel (COCOMO)
 An empirical model based on project experience and
developed by Boehm
 Estimate total effort in terms of PMs of technical
project staff

 Basic Steps:
1. Obtain an initial estimate of the development effort from the estimate
of thousands of delivered lines of source code (KDLOC)
2. Determine a set of 15 multiplying factors from different attributes of
the project
3. Adjust the effort estimate by multiplying the initial estimate with all
the multiplying factors
Initial (Nominal) Estimate
Ei=a * (KDLOC) b

3 Types of Projects:

-Organic
- semidetached
- embedded
Project types in detail
 Organic: project has considerable experience
and requirements are less stringent
e.g. simple business system, simple inventory
management system, data processing systems

 Embedded: ambitious and novel projects

e.g. embedded avionic systems, real-time command
systems

 Semidetached : development of new OS, DBMS, complex

inventory management systems
Constants for different project types
Effort multipliers for different cost drivers

Back
 Determine EAF( Effort Adjustment Factor)

 Final effort
E = EAF * Ei
Phase-wise distribution of effort.

Back
Eg: Office automation

Table
Effort Estimation

 EAF = 1.15 * 1.06* 1.13 * 1.17 = 1.61

 Ei= 3.2 * 31.05 = 10.14 PM

 E = EAF * Ei
= 1.61 * 10.14 = 16.3 PM

Back
Contd...

Table
Back
Project Scheduling
 To determine the total duration of the project and duration
of the different phases

 Schedule is independent of person – month cost

 Acco. To Brooks ”…man and months are interchangeable

only for activities that require no communication among
men, like sowing wheat or reaping cotton. This is not even
approximately true of software…”

 “Adding manpower to a late project may make it later” –

Brook’s Law
Average Duration Estimation

 Schedule is modeled as depending on the total

effort
 In COCOMO Schedule Equation for an organic

type of software
M = 2.5 * E 0.38
Phase-wise distribution of schedule
Eg:

 Project duration, D = 2.5 * 16.30.38 = 7.23 Months

 System Design 0.19 * 7.23 = 1.37 M

Programming 0.623 * 7.23 = 4.5 M
Integration 0.1866 * 7.23 = 1.35 M

may be from Jan 1st to middle of Aug.

Back
Scheduling Techniques
 Gantt Chart
- calendar oriented chart
- simple and easy to understand
- used for small and medium sized projects
- start and end of each activity become milestones
- Do not depict the dependency relationships among activities
 PERT Chart
- graph based chart
- used to represent dependencies
- helps to identify ‘critical path’
Gantt chart for a simple compiler project
PERT chart for a simple compiler project
Staffing and Personnel Planning

 Average staff size = Total Effort / overall project duration

 Max. staff requirement during implementation and testing

The Rayleigh curve
 Staffing in a project is continuous function (Putnam)
 Staffing pattern followed the Rayleigh curve
 in s/w development , there is build up and phase-out curve
for each of the different phases (Rayleigh curve)
The Rayleigh curve

 Staffing rate,

K = total manpower required

a = shape parameter

 Cumulative manpower
y = K (1 - e-at2 )
The Rayleigh curve

 a = 1/2td2,

 In SE, td corresponds closely to the total development time or

time taken to reach full operational capability

 Integrating this equation from t=0 to td , total development

effort D
approx. 40%
Method…

 Nominal Productivity, NP = size/Ei

 E m = (Size m / NP) * EAF

 P= PM/ M
Eg:

 NP = 3.0/ 10.14 = .29 KDL/ PM

Table1

Table2

Table3
A personnel plan for the example
Team Structure
1. Egoless Team
2. Chief Programmer Team
3. Controlled Decentralized Team
Egoless Team
 Consists of 10 or fewer programmers
 Goals are set by consensus (general agreement or
opinion)
 input from every member is taken for major decisions.
 Group leadership rotates among the group members.
 egoless teams are sometimes called democratic
teams.
 The structure results in many communication paths
between people
 lead to better decisions in difficult problems.
 Well suited for research-type projects that do not have
time constraints.
 not suitable for regular tasks that are not too complex
and that have time constraints.
Chief Programmer Team

 A chief programmer team has a hierarchy.

 consist of a chief programmer, who has a backup programmer, a
program librarian, and some programmers.
 The chief programmer is responsible for all major technical
decisions of the project.
 He does most of the design and he assigns coding of the different
parts of the design to the programmers
 The backup programmer helps the chief programmer make
technical decisions
 Program librarian – maintaining documentation and other
communication related work
 Reduces interpersonal communication
 Suits for projects with simple solutions and strict deadlines
Controlled Decentralized Team
 Project leader

 A group of Senior programmers

Egoless Team
 A group of Junior programmers

 Communication among different groups occurs only through senior

programmers
 senior programmers communicate with project leader
 Fewer communication path than democratic team
 Suits for large projects that are reasonably straight forward
 Not suited for simple projects and research type projects
Software configuration Management Plans

 To identify all the activities that must be performed

 Give guidelines for performing the activities

 Allocate resources for the activities

 Needs to specify the type of SCIs that will be selected and the
stages during the project where baselines should be established

 To identify the different members of the CCB

 Should include a plan for configuration accounting and auditing

Quality Assurance Plans (SQAP)

 To specify all the work products that need to be

produced during the project

 Activities that need to be performed for checking the

quality of each of the work products

 Tools and methods that may be used for the SQA

activities (reviews and audit)
Verification and validation
 Verification: a process of determining whether or not the
products of a given phase of software development fulfill
the specifications established during the previous phase
(proving, testing, reviews)

 Validation: a process of evaluating software at the end of

the software development to ensure compliance with the
software requirements (testing)
V&V
 Major activities: inspection (general activity), reviews and
testing (mainly on code)

 plan includes
#identify the V&V tasks and specifies how these tasks contribute
to the V&V goals
#methods to be used for performing the V&V activities
#responsibilities and milestones for each of these activities
#inputs and outputs for each V&V task
#criteria for evaluating the outputs
Software Verification and validation plan overview
Inspections and reviews
 IEEE defines inspection as “ a formal evaluation technique in
which software requirements, design, or code are examined
in detail by a person or a group other than the author to
detect faults, violations of development standards, and other
problems”[IEE87]

 IEEE standard for Software Reviews and Audits[IEE94]

specifies that it is a formal, peer evaluation of a software
element whose objective is to verify that the software element
satisfies its specifications and conforms to standards.
Purpose

 Defect Removal
 Productivity increase

 Provide information for project monitoring

 Reviews are of products not people

 Different from walkthrough
Inspection Process
 Done by a group of people (author, reviewers or inspectors,
moderator (key person), recorder)

 Inspection includes - planning phase (product to be inspected is

identified, a moderator is assigned, objective of the inspection is stated, entry
criteria that must be satisfied by the product)

- execution phase
- post-inspection actions
Contd...

 Opening meeting is organized by the moderator

 Reviewers individually study the material thoroughly and use the

checklists to identify all possible defects

 Record all potential errors in the error log form

 Logs are submitted to the moderator

 Developer is also getting a copy

Contd…
 Next stage inspection meeting

 Meeting begins with producer discussing each of the issues

raised by the reviewers

 At the conclusion of the meeting, moderator produces a summary

of the inspection, which lists all defects found that need to be
addressed

 Authors have to address all the issues raised

 Moderator has to state whether there should be another review

after the rework is complete
Review process
Inspection benefits

 Improve quality and productivity

 Reduction in schedules
 Defects can be detected
 To monitor the quality and progress of the project
 Helpful for maintenance
 Improves the capability of people

Rate of inspection should be reasonable

Major cost of inspections is the time spent by the review

team members conducting the inspection
Project Monitoring Plans
 Time Sheets

 Reviews

 Cost-schedule-Milestone Graph

 Earned Value Method

 Unit Development folder

Time sheets
 Common method of keeping track of expenditures

 Records how much time different project members are

spending on the different identified activities in the
project

 time sheets can be filled daily or weekly

Reviews
 Helpful to provide information for project control
 Provide a definite and clearly defined milestone. Forces
the author to complete tasks before review!
 To determine how project is progressing compared to its
planned schedule
 Review reports Indicate in which part
programmers/analyst face difficulty.
 Review reports provide insight into the quality of the
software being produced and the types of errors being
detected
Cost-Schedule-Milestone Graph
 Represents planned cost of different milestones and
actual cost
 Progress can be easily monitored
Earned Value Method
 An effective method of monitoring the progress of a project
(particularly the phases after system design)

 Uses a Summary Task Planning Sheet (STPS)- Gantt chart

(milestones and tasks)

 Each milestone of a task is assigned an earned value, which is

the value that will be “earned” on completion of this milestone

 Total cost task = Σ(earned value) milestones

 Earned value aspect can be summarized in an earned value

summary report
…contd
 Need for accurate and consistent status
information
“Earned Value Analysis” is:
• an industry standard way to:
• measure a project’s progress,
• forecast its completion date and final cost,
and
• provide schedule and budget variances
along the way.
 It compares the PLANNED amount of work with
what has actually been COMPLETED, to
determine if COST , SCHEDULE, and WORK
ACCOMPLISHED are progressing as planned.
…contd

Some New Terms

BCWS - Budgeted Cost of Work
Scheduled

ACWP - Actual Cost of Work

Performed

BCWP - Budgeted Cost of Work

Performed
…contd
BCWS: “Budgeted Cost of Work Scheduled”
Planned cost of the total amount of work
scheduled to be performed by the
milestone date.

ACWP: “Actual Cost of Work Performed”

Cost incurred to accomplish the work that
has been done to date.

 BCWP: Budgeted Cost of Work Performed

The planned (not actual) cost to complete the
work that has been done.
Some Derived Metrics

SV: Schedule Variance (BCWP-BCWS)

A comparison of amount of work performed during a
given period of time to what was scheduled to be
performed.
A negative variance means the project is behind
schedule

CV: Cost Variance (BCWP-ACWP)

A comparison of the budgeted cost of work
performed with actual cost.
A negative variance means the project is over
budget.
Some More Derived Metrics

SPI: Schedule Performance Index

 SPI=BCWP/BCWS
 SPI<1 means project is behind schedule
CPI: Cost Performance Index
 CPI= BCWP/ACWP
 CPI<1 means project is over budget

CSI: Cost Schedule Index (CSI=CPI x SPI)

The further CSI is from 1.0, the less likely project
recovery becomes.
Earned Value Analysis
Earned Value
Cost

£1,400,00
0 Forecast At
It is about half way through the project.
Today we were supposed to have Completion
completed exactly half the deliverables. (FAC)
£1,200,00
0 In fact, we have only completed 40%
We were supposed to have spent Budget At
£1,000,00 £525,000 by now, but we’ve spent Completion
£675,000 - so are we £150,000 over (BAC)
0
budget?

£800,000

Actual Cost of Work Performed (ACWP)

£600,000 Cost
Variance
(CV) Schedule Budgeted Cost of Work Scheduled (BCWS)
Variance
(SV)
£400,000 Budgeted Cost of Work Performed (BCWP)

Actual

£200,000

Plan / Budget

0% 40% 50% 100%

Work Packages / Deliverables Completed
Other Derived Values
• BAC: Budget At Completion
• Sum of all budges (BCWS). Your
original budget.
• EAC: Estimate At Completion
• Forecast total cost at completion
• EAC = ((BAC – BCWP)/CPI) + ACWP
• Unfinished work divided by CPI added
to sunk cost
• If CPI < 1, EAC will be > BAC
• CR: Critical Ratio
• SPI x CPI
• 1: everything on track
• > .9 and < 1.2 ok
Unit Development folder
 UDF has been used to counter the ‘90% syndrome’
 Also known as programmer’s notebook
 Contains the plan, progress, and all documentation related to the
development of a program unit
 UDF is established after the system design phase, when tasks are
distributed among programmers
 A Unit could be a module, a procedure, or a collection of such
modules
 Forces programmer to identify intermediate milestones
 provides a single place for collecting all the documentation for a unit
 Provides an orderly and consistent approach for the development of
a unit
 Provides better management and visibility of the progress in a unit’s
development
Risk Management

 Risk is the possibility that the defined goals are not met

 Helpful for identifying and managing the risks

Risk Management Overview
 Area that tries to ensure that the impact of risks on cost,
quality, and schedule is minimal
 Dealing with the possibility and actual occurrence of those
events that are not “regular” or commonly expected
 Risk Management begins where normal project
management ends
 Identify the undesirable events that can occur, the
possibility of their occurring, and the loss if an undesirable
event does occur (risk assessment)
 Strategies can be formulated for either reducing the
probability of risk or reducing its effect (risk control)
Risk Management Activities

Risk Management

Back
Risk Assessment

 Identify, analyze and prioritize the tasks

 Though risk assessment should be done throughout the project, i
is most needed in the starting phases of software projects

 Risks
Cost Risk : degree of uncertainty associated with
budgets and outlays for the project and its impact
on the project
Performance Risk : possibility that the system will be
unable to deliver all or some of the anticipated
benefits or will not perform according to the
requirements
Schedule Risk : degree of uncertainty associated with
Top-10 risk items and techniques for managing them
Risk Analysis

 Models

 Decision Analysis : study the probability and outcome of possible

decisions

 Network Analysis: understanding task dependencies to decide

critical activities and the probability and cost of these activities
which are not being completed on time

 Quality Factor analysis: analyze risks on various quality factors

like reliability and usability

 Performance Analysis: evaluate the performance through

simulation
Risk Exposure (RE)

 One approach to prioritization

 Expected value of the loss due to a particular risk

 RE = Prob(UO) * Loss(UO)
Prob(UO) - probability of the risk materializing
Loss(UO) - total loss incurred due to the
unsatisfactory outcome

 RE high: High chance of risk

Risk control

 Risk control starts with risk management planning

Five components

1) why the risk is important and why it should be managed

2) what should be delivered regarding risk management
3) who is responsible for performing the different risk
management
4) how will the risk be abated (reduced) or the approach be taken
5) how many resources are needed Figure
Contd…

 Take actions that will avoid the risk

 Risk reductions: prototyping

 Implementation of risk management plan – risk resolution

(actual elimination or reduction)

 Risk monitoring :checklists

***THE END***
Inspection package – code reviews

 Program source listing

 Pertinent portions of design or specification document

 Pertinent parts of common definitions that are used by the code

 Any system constraints

 Blank copies of all forms and reports

 Checklists to be used for review

Back