SE351a: Software Project & Process Management
Transcript of SE351a: Software Project & Process Management
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa
SE351a: Software Project & Process ManagementSE351a: Software Project & Process Management
W9 : Project Monitoring & Control
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 2
SE351 RoadmapSE351 Roadmap
Introduction to Software Project Management
Project Management
Software Development Life Cycles
Requirements Engineering
Software Process & Project Metrics
Software Project Planning
Project Monitoring & Control
• Risk Management
• Software Quality Assurance
• Software Configuration Management
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 3
Scope the Project State the problem or opportunity Establish the project goal Define the project objectives Identify the success criteria List assumptions, risks and obstacles
Develop Detailed Plans • Identify project activities • Estimate activity duration • Determine resource requirements • Construct & analyze project network • Prepare the project proposal Launch the Plan
Recruit and organize project team Establish team operating rules Level project resources Schedule work packages Document work packages
Monitor & Control ProgressEstablish progress reporting system Install change control process Define problem escalation process Monitor progress versus plan Revise project plan
Project Close-Out Obtain client acceptance Install project deliverables Complete project documentation Complete post-implementation audit Issue final project report
The Architecture of PMLC…
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 4
Project Management:Project Management:The Control panelThe Control panel
Cost ScheduleCost ScheduleC
umul
ativ
e C
ost
Cum
ulat
ive
Cos
t55 1010
Resource AllocationResource Allocation
Pers
onne
lPe
rson
nel
PERTPERTAssessmentAssessment
Expected DateExpected Date
Specifyoverallsystem
SpecifymoduleA
SpecifymoduleB
SpecifymoduleC
SpecifymoduleD
Checkspecifi-cations
DesignmoduleA
DesignmoduleB
DesignmoduleC
DesignmoduleD
Code/testmoduleA
Code/testmoduleB
Code/testmoduleC
Code/testmoduleD
Integrate/testsystem
Activity PlanActivity Plan
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 5
Project ControlProject Control
• Project control is an iterative process
with following actions
1) Determining Project Status
2) Comparing Status with Planning
3) Taking Corrective Actions
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 6
Monitoring PrinciplesMonitoring Principles
• Frequency to receive information
depends on the size and risk of the project
It is recommended to have
o weekly collection of information while it is still fresh
• The higher the level
the less frequent and detailed the reporting needs to be
o Team leaders may have to assess daily
especially for inexperienced staff
o Higher level managers may find weekly or monthly reporting appropriate
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 7
Project Reporting StructureProject Reporting Structure
Analyst/Designer
TeamLeader
Analyst/Designer
ProjectManager
TeamLeader
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 8
Reporting System: CharacteristicsReporting System: Characteristics
• Provides timely, complete, and accurate status information
• Easily understood
• Warns of pending problems in time to take actions
• Doesn’t add so much overhead
• Acceptable by the project team and senior management
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 9
Types of Project Status ReportsTypes of Project Status Reports
• Current Period Reports
The most recently completed period
Highlight activities completed and variance between scheduled and actualcompletion dates
• Cumulative Reports
Captures the history of the project from beginning to the end
• Variance Reports
Report differences between what was planned and what actually happened
Typical variables tracked are: schedule and cost
• Exception Reports
Reports variances from Plan, typically targeting senior management
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 10
Types of ReportingTypes of Reporting
Report Type Examples Comments
Written, formal, Job sheets, progress Normally weekly, regular reports using forms
Written, formal Exception reports, irregular change reports
Verbal, formal, Weekly or monthly Written minutes should regular progress meetings be kept
Verbal, formal, Milestone review Also includes writtenirregular meetings documentation
Verbal, informal, Walking around, Often providesad hoc social interactions early warning
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 11
Assessing ProgressAssessing Progress
• Progress assessment based on information collected
o information should be objective and tangible
Set a series of checkpoints in the initial project plan
Weekly, reports, milestones, ...
activities should be broken down into controllable tasks (work packages)
– with one to a few weeks duration
partial completion of an activity can be estimated with a series of productsseries of products
– e.g., number of screen layouts produced
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 12
Gathering MetricsGathering MetricsA ReminderA Reminder……
• An organization striving to get to SEI level 3 or higher
has to gather metrics
• The best time to obtain metric inputs is
while the project is underway
o Data is timely, not likely to be lost
o Errors in data collection can be corrected
• Current project metrics are an excellent indicator of
progress, budget and schedule control
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 13
Current Project Metrics: Current Project Metrics: ExamplesExamples
Description Description UnitsUnitsNumber of project staff People
Effort (by work package) Person-hours
Labor cost (by work package) $/person-month
Elapsed time to completion Days, weeks, months
Newly developed code FP/KLOC
Modified (existing code) FP/KLOC
Delivered code FP/KLOC
Number of defects Defects
Documentation Pages, figures
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 14
Project WBSelement
Description Hours thisweek
%Complete
Scheduledcompletion
Projectedcompletion
Time Sheet
Staff J. Smith Week ending 11/14/03
P21 2.1.12 Design A32.1.12 Design A3 28 90 90 11/8/03 11/12/03
P21 3.4.3 Code mod. C53.4.3 Code mod. C5 12 30 30 11/22/03 12/10/03
Weekly Time Sheet & Progress Review FormAn Example
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 15
Visualizing ProgressVisualizing Progress
• A manager needs to present data in way that has the greatest effect
Visualization gives a quick assessment tool for senior management
Public visualization of progress can be used as a staff motivating tool
o Good performers are recognized
o People behind schedule are motivated to catch up
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 16
Visualizing Progress Visualizing Progress Using a Gantt ChartUsing a Gantt Chart
W T F M T W T F M T W T F M T W T F M T W T12 13 14 15 16
Code & testmodule A
Code & testmodule B
Code & testmodule C
Code & testmodule D
Integrate & test system
Planned Time (Week Numbers)
Today
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 17
Visualizing Progress Visualizing Progress Using a Milestone ChartUsing a Milestone Chart
J. SmithCode & testmodule A
H. BrownCode & testmodule B
A. CamptonCode & testmodule C
D. GordonCode & testmodule D
H. BrownIntegrate & test system
13 14 15 16 17Planned Time (Week Numbers)
Today
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 18
The TrafficThe Traffic--Light Method: BottomLight Method: Bottom--UpUp
• Break the key elements into constituent elements (second level)
• Assess each of second level elements
Green –on targeton target
Amber –notnot on targeton target but recoverable
Red –notnot on targeton target and recoverable only with difficulty
• Review all second level assessments to
arrive at first level assessments, and
all first level assessments to produce an overall assessment
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 19
A Traffic Light AssessmentA Traffic Light Assessment
Week No.
+ Activity summary
Component
- Screen handling procedures
- File update procedures
- Compilation
- Test data runs
- Program documentation
13 14 15 16
Staff:
Ref: IoE/P/13 Activity: Code & test module C
A. Campton
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 20
Rules of Thumb for Effort MetricsRules of Thumb for Effort Metrics
• Software size metric
as a tool tracks the magnitude of the development effort
Trend shouldshould be fairly stable
o month-to-month estimates should notshould not vary by more than 5%5%
o Variations may indicate:
A better understanding of the requirements, or
Problems with the development process
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 21
Personnel MetricsPersonnel Metrics
300
200
100
0
-20Time
Total
Experienced
Planned
Actual
Unplanned losses
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 22
Rules of Thumb for Personnel MetricsRules of Thumb for Personnel Metrics
• Ratio of total to experienced personnel
a typical ratio is 3:1
o should never exceed 6:1
• The project front end should be leveraged with
more experienced personnel
• Understaffing is
an an early sign of schedule slipo You cancan’’t alwayst always catch up by adding more people later
it may even further delay work
• High turnover or loss of personnel is a sign of problems
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 23
Computer Resource MarginsComputer Resource Margins
80
60
40
20
0
Time
Planned Spare
% U
tiliz
a tio
n
CPUMemoryI/O
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 24
Computer Resource Metrics:Computer Resource Metrics:Rules of Thumb Rules of Thumb
• CPU and Memory utilization should allow for a 50% margin at delivery
• Resource utilization tends to increase with time
so plan for expansion
• For real-time systems performance
degrades quickly above 70% utilization
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 25
Requirements Changes MetricRequirements Changes Metric
2000
1500
1000
500
0Time
TotalReqmts
CumChanges
Req
uire
men
ts
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 26
Requirements Changes MetricsRequirements Changes Metrics
• Track open software action items (requirements lacking analytic justification)as well as requirements
action items should be closed within a specified period
• Use requirements traceability tool to track requirements status
• Requirements growth will impact planned resources
should be contained from start
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 27
Defects and Fixes MetricDefects and Fixes Metric
New Faults
ResolvedFaults
200
150
100
50
0Time
Def
ects
and
Fix
es
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 28
Test Program StatusTest Program Status
• Measure planned vs. actual tests
• Track software problem reports (SPRs)
Typical range is 5 - 30 SPRs per KLOC
Too manyToo many SPRs indicate poor quality
However, Too few SPRs may mean inadequate testing
Track number of days that SPRs remain openremain open
Track SPRs by priority
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 29
Cost MonitoringCost Monitoring
• Expenditure monitoring provides an indication of
effort that has gone into a project
Costs have to be compared with budgeted-costs
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 30C
umul
ativ
e C
ost (
$)
Time
BCWS
ACWP
BCWP
Earned Value AnalysisEarned Value Analysis
• The cumulative value of completed WPs
can be compared to the budgeted and actual cost to complete
o Gives a more accurate measure of schedule and budget progress
• Examine the variancebetween the project plan and the project status
• To perform EVA
use the SS--curvescurves with five cumulative variables:
o BCWS: Budgeted Cost of Work Scheduled
o BCWP: Budgeted Cost of Work Performed (earned valueearned value)
o ACWP: Actual Cost of Work Performed
o BAC: Budget at Completion
o EAC: Estimated budget at Completion
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 31
EVA: ParametersEVA: Parameters
EACEstimate at completion What do we nownow expect the total job to cost?
BACBudget at completion (total budget)What waswas the total job supposed to cost?
ACWPActual cost of work performed (actuals) How much did the "is done" work cost?
BCWPBudgeted cost of work performedHow much work is done?
What was the “is done” supposedsupposed to cost?
BCWSBudgeted cost of work scheduledHow much work should be done?
AcronymAnswerManagement Question
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 32
Types of VariancesTypes of Variances
• Cost VarianceCV = BCWP - ACWP
– CV < 0 Cost overrun– CVP = CV / BCWP %
• Schedule VarianceSV = BCWP - BCWS
– SV < 0 behind-schedule– SVP = SV / BCWS %
• Variance At CompletionVAC = BAC - EAC
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 33
Snippet of Cumulative &Weekly Costs: 4 Module Project
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Week Number
$25K/$5
$50K/$10
$75K/$15
$100K
Cumulative Cost /Weekly Cost
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 34
Smoothing Resource Requirements:Activities Rescheduling
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
No.
Pe r
s onn
elA
ctiv
ities
Week Number
1
2
3
4
5
2
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 35
The SThe S--Curve of Cumulative ExpenditureCurve of Cumulative Expenditure
Cum
ulat
ive
Cost
($)
SV = BCWP - BCWS
CV= BCWP - ACWP
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 36
Example:Example:Cost/Performance VarianceCost/Performance Variance
$500
Scheduled/BudgetedTo do $500 Work over 5 days in a 5-day windowBCWS = $500
5 days
$300
Scheduled SlippagePermits only 3days/300$ work to be performedBCWP = $300SV = - $200SVP=-40%
$200
5 days
$400
ACWP = $400CV = - $100CVP=-33.33%
$200
5 days
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 37
Estimate To CompletionEstimate To Completion
Cum
ulat
ive
Cos
t ($)
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 38
Comparing Status With PlanningComparing Status With Planning
• Variances can be addressed through o progress reviews
o schedule and technical meetings
o informal communications
• Analyze it to provide indicators of trends and problems
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 39
Performance EfficiencyPerformance Efficiency
• Schedule Performance IndexSPI = BCWP/BCWS
How close the project is to performing work o as it was actually scheduled
• Cost Performance IndexCPI = BCWP/ACWP
How close the project is to spending on the work performedo to what was planned to have spent
• Nominal: value for SPI and CPI is 1 Perfect Performance
• Problems: value of SPI and CPI less than 1 Poor performance
• Outstanding: value for SPI and CPI > 1 Exceptional Performance
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 40
Example:Example:Performance EfficiencyPerformance Efficiency
$500
Scheduled/BudgetedTo do $500 Work over 5 days in a 5-day windowBCWS = $500
$300
Scheduled SlippagePermits only 3days/300$ work to be performedBCWP = $300SV = - $200SVP=-40%SPI= 300/500 = 0.6
$400
ACWP = $400CV = - $100CVP=-33.33%CPI = 300/400= 0.75
$200$200
5 days 5 days 5 days
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 41
Performance EfficiencyPerformance Efficiency(Cont.)(Cont.)
• SPI & CPI are used for trend analysis
Trend analysis is an early warning system to take actions to alleviate unfavorable trends
• However, it requires 3-6 months moving averages to predict a trend
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 42
Other Useful indicatorsOther Useful indicators……
• To-Complete Performance Index:
TCPI = (BAC - BCWP(cumul))/(EAC - ACWP(cumul))
• Estimate at Completion:
EAC = ACWP(cumul) + PF*(BAC - BCWP(cumul))
where PF is ACWP/BCWP
• Schedule Variance in Time Units:
SV(tu) = SV(cumul)/BCWP(current tu)
• Percent Spent:
%Spent = ACWP(cumul)/BAC*100
• Percent Complete:
%Complete = BCWP(cumul)/BAC*100
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 43
Prioritized MonitoringPrioritized Monitoring
• Monitoring
consumes time
uses resources that might be put to better use
• Levels of monitoring can be set based on priorities
Critical path activities
Activities with less than a specified float
High risk activities
Activities using critical resources
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 44
Data AccumulationData Accumulation
SV
CV
BCWS
BCWP
ACWP
BUDGET
EACOR
GA
NIZ
ATI
ON
OR
GA
NIZ
ATI
ON
WBSWBS
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 45
Cost Data Collection & Reporting FlowCost Data Collection & Reporting Flow
BCWSBCWS
Inventory AccountInventory Account
StaffStaff
ActualsActuals
ACWPACWP
BCWPBCWP
MonthlyProject Efforts
MonthlyProject Efforts
Weekly LaborReports
Weekly LaborReports
VarianceReports
VarianceReports
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 46
Variance analysisVariance analysis
• A tool allows a manger to take actiontake actiono either, to correct the problem within the original budget
o or, to justify a new estimate
To do so, the following need to be addressed
1. What is the problem causing the variance?
2. What is the impact on
• time, cost, and performance?
• other efforts, if any?
3. What corrective actions are planned or under way?
4. What are the expected results of the corrective actions?
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 47
Cost Control & Report FlowCost Control & Report Flow
ReportsReportsExceptions
Reports(if necessary)
ExceptionsReports
(if necessary)
Functional Management
StaffTime Sheet
StaffTime Sheet
Actual% Complete
Project Management Office
Budgets &Target % Complete
Executive Management
Total Project Detailed Reports
ProjectSummary Reports
Functional Detail/Summary Reports
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 48
Reporting Procedure for VarianceReporting Procedure for Variance
• Variance Status Reporting should be concise
It yields fast feedback and response
Variance analysis
Diagnose the problem
Find the cure for the problem
o Two main constraints on rescheduling resources
The end date is fixed
Resources are constant (or limited)
Develop a plan to recover the problem
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 49
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 50
Responses to Variance ReportResponses to Variance Report
• Ignore itIf variance within boundaries
• Functional modificationVariance is marginal
• Re-planningMajor variance:
o redefine the project goals as work progresses
but within system specifications
• System redesignMajor variance and re-planning cannot be accomplished
o some specifications need to be sacrificed
to satisfy time and money constraints
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 51
ReRe--planningplanning
• A plan is a living document
A project can be re-planned
o After taking any necessary corrective actions
o With agreement from the customer
• Project plans need to be kept current
to reflect actual and agreed to conditions
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 52
Taking Corrective ActionsTaking Corrective Actions
• Schedule variances (SV) are essential, but
do not provide a complete schedule performance picture
nor do they consider the sequence of work activities
• We need to perform schedule analysis
to quantify
o how time delays, caused by technical or other problems, will affect all futureactivities and milestones
o how corrective action plans can reduce the scope of these effects
especially, performance on the critical path
24 Nov., 2004 SE351a, ECE UWO, (c) Hamada Ghenniwa 53
Getting the Project Back on TrackGetting the Project Back on Track
• Shorten the critical path?allocate additional resources (add people)
o Will adding people late in the program shorten or lengthen the time required to complete the remaining work?
increase level of existing resources (overtime)
allocate more efficient resources to critical activities
• Reconsider precedence requirementsAlter “normal” practice
Subdivide activitieso into components which can start immediately
Analyze resulting risk and quality
• Reallocate resourcesExamine earned value summary report:
Are there areas that are under planned expenditures?