cse 7315 - sw project management / module 24 - additional software plans copyright © 1995-2004,...
TRANSCRIPT
CSE 7315 - SW Project Management / Module 24 - Additional Software PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
Slide 1
CSE7315M24
September 12, 2004
SMU CSE 7315 / NTU SE 584-NPlanning and Managing a
Software Project
Module 24Additional Software Plans
Slide # 2 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Objective of This Module
• To review several additional parts of a software development plan
September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Detailed Planning Process
EstimateSize
EstimateEffort and
Cost
EstimateSchedule
Evaluate
Source InformationStatement of Work
RequirementsConstraintsStandardsProcesses
Historyetc.
WBS Size
Effort &Cost
Schedule
OKCompleteDetailedPlanning
Revise &Negotiate
Not OK
September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
The Plan within a plan
SoftwareDevelopment
Plan(formal
document)
software development plan
SoftwareStandards
andProcedures
WBS
PoliciesFacilities
Estimates
StaffingplanSchedule
Slide # 5 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Additional Plans We Will Cover
• Risk Management• Metrics• Training• Software Configuration
Management• Software Quality Assurance• Build/Integration
Slide # 6 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Other Additional Plans That May Be Applicable
• Reuse• Maintenance• Installation• Subcontract
Management• Process
Improvement• Inspections
• Hardware Maintenance
• Security• Staffing• Qualification• Verification
and Validation• Customer
Support
CSE 7315 - SW Project Management / Module 24 - Additional Software PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
Slide 7
CSE7315M24
September 12, 2004
Risk Management Plan
Slide # 8 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Risk Management Plan
• A documented plan that communicates the risks and the plans for managing them to everyone concerned
• It also helps everyone know what to do during a crisis
• The plan should be reviewed and updated from time to time
Slide # 9 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Goals of a Risk Management Plan
• To show all concerned that you …… understand the risks of the project… know how to manage those risks… have taken appropriate actions to
mitigate risks… have plans in place to monitor those
risks
The purpose of the risk management plan is not to deny that you have risks, to avoid mentioning
important risks, or to belittle the importance of key project risks.
The purpose of the risk management plan is not to deny that you have risks, to avoid mentioning
important risks, or to belittle the importance of key project risks.
Slide # 10 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Contents of aRisk Management Plan
• The risk management process to be used during execution of the project
• Results of initial risk analysis– Analysis and priorities– Key risks identified– Actions taken to mitigate key risks
• Minimize impact• Reduce likelihood
• Monitoring and abatement plans
Slide # 11 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Sample Process Description• We will hold a monthly meeting
attended by … at which we will– Review actions from previous meetings– Review the status of the top 10 risks– Re-prioritize the risks– Assign actions as required
• Roles during this meeting– Record keeper– Facilitator– Etc.
• We will revisit the plan and consider an update every … months
Explain WHO will do WHAT,
WHEN and HOW
Explain WHO will do WHAT,
WHEN and HOW
Slide # 12 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Sample Chart ShowingRisk Analysis and
PrioritizationRisk Likelihood Cost Weighted Cost
Late Hardware 75.00% 100,000 75,000
Sub-Contractor Failure 20.00% 250,000 50,000
Memory Size 50.00% 50,000 25,000
Test Equipment Delay 30.00% 40,000 12,000
Requirements Changes 99.00% 5,000 4,950
Building hit by plane 0.0001% 50,000,000 50
Be sure to explain WHY each risk is important – provide EVIDENCE that it is as likely or as
expensive as indicated.
Be sure to explain WHY each risk is important – provide EVIDENCE that it is as likely or as
expensive as indicated.
Slide # 13 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Sample Risk Occurrence Chart
Risk Likelihood
J F M A M J …
Turnover
Low Low Med
Med Hi Hi Etc.
Memory too small
Low Low Low Med Med Med Etc.
Space too small
Hi Hi Hi Med Med Med Etc.
Etc. Etc. Etc. Etc. Etc. Etc. Etc. Etc.A chart like this helps you know when to expect certain risks to be more likely.
A chart like this helps you know when to expect certain risks to be more likely.
Slide # 14 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Sample Description of a Risk
Risk: high turnover of key staffEvidence: • recent turnover rates are 22%, • competition from growing
companies in townPriority: Red (urgent)• Likelihood is 75%• Impact is high
Slide # 15 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Sample Description of a Risk (continued)
Mitigation Plans and Actions: • Increased salaries 15%• Giving employees a bonus for successful
completion on timeMonitoring:• Will monitor project turnover rate monthly
and take action if exceeds 10%Contingency plans:• Increased hiring rates, use of contract
labor
Slide # 16 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Chart Showing Links to Measures
Risks MeasuresSize Turn
overEarned Value
Morale
Etc. Etc. Etc. Etc.
Staffing Etc. Etc. Etc. Etc.
Memory Etc. Etc. Etc. Etc.
Schedule
Etc. Etc. Etc. Etc.
Cost Etc. Etc. Etc. Etc.
Rqmts Etc. Etc. Etc. Etc.
CSE 7315 - SW Project Management / Module 24 - Additional Software PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
Slide 17
CSE7315M24
September 12, 2004
Measurement Plans
Slide # 18 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Measures and Risks Are Discussed in Several Places
• In each section of the plan, you should summarize the risks and measures relevant to that section of the plan– So people reading just that section
know which ones apply
• The risk plan discusses which measures are used for monitoring of each risk
Slide # 19 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
The Measurement Plan
• Provides more detail about measures– Description of each measure
• How it is measured, units, standards, etc.
– When and how it is collected– When and how it is stored– How the data are displayed/graphed
and interpreted Explain WHO will do WHAT, WHEN and HOW
Explain WHO will do WHAT, WHEN and HOW
Slide # 20 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Table Showing When Data are Collected
Phase
Data
/Measu
re
Requirements
Alg Dev
PrelDes
FinalDes
Code/Test
Integrate
Rqmts Stability
Memory Utilization
Staffing Rqmts Tested
Slide # 21 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Description of Data Collection and Analysis Process
• Measurements are stored in a data base ….
• Data are collected at least monthly using a standard, web-based template …
• Data analysis meeting occurs 1 week before monthly management review
• Management reviews measurements at monthly status reviews
Slide # 22 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Sample Measure Description
Name: Requirements StabilityPurpose: To show how much the
requirements are changing and help decide if they are stable enough to enter the next phase
Basic Data Collected:R – total number of requirementsN – new requirementsC – changed requirementsD – deleted requirements
Slide # 23 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Sample Measure Description(continued)
Formula: S = (N+C+D) / R (stability)R’ = Next month’s R value = R + N – D
Target Values:S should be no worst than:25% during preliminary design and10% during detailed design and3% during code and test
R should not change by more than 10% without a re-estimate and re-plan of the project
Slide # 24 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Sample Measure Description(continued)
Typical Graph and How it is Interpreted: Requirements Stability
0
0.02
0.04
0.06
0.08
0.1
0.12
1 2 3 4 5 6
Collection Week
Sta
ble
Req
uir
emen
t %
Actual
Plan
• Actual line represents actual stability value
• Plan line represents original plan
• If actual deviates by more than 10%, a re-plan should be considered
In the above example, the stability exceeds plan but not by enough to force a re-plan. The steady increase
in degree of deviation should be examined.
CSE 7315 - SW Project Management / Module 24 - Additional Software PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
September 12, 2004
Training Plans
September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Well Trained Staff are More Productive
• But training is an investment• And it is usually considered an overhead
expense, thus can be considered a “bad” thing
• You may need to justify it• Plan training to make sure the investment
is worthwhile– The right training– At the right time– For the right people
September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Many Kinds of Training May be Required
• Software processes and policies• Project management and estimation• Required standards• Role of SQA and SCM on project• Requirements analysis procedures• Use of new tools and methods• Code inspection techniques• ...
Slide # 28 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
A Training Plan May Contain …
… a training model, which indicates by role and time period what training is needed for people working on the project
… a training schedule, which indicates when specific training is planned and who is expected to take it
… a description of how training progress will be monitored (measures, graphs, reports, etc.)
Slide # 29 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
In Other Words …
• Like all plans, a training plan explains
WHO will do WHAT, WHEN
and HOW
WHO will do WHAT, WHEN
and HOW
September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
A Typical Training Model
Role Training Needed WhenNeeded
Manager Project Manag’t Month 0
Analyst OO Analysis Tool Month 1
Designer OO Design Method Month 4
OO Design Tool Month 5
Tester Test Tool Use Month 8
September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
A Typical Training Schedule
Who What When Scheduled
J oe Smith Project Management 101 May 1
J une J ones OO Analysis Methods J une 22
Pete Wilson OO Analysis Methods J une 22
OO Analysis Tool J une 29
Omar Zinth Test Methods 100 November 12
Slide # 32 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Typical Training Progress Graph
0
50
100
150
200
250
300
350
400
J an Feb Mar Apr May J un
Plan
Actual
Plan Total
Actual Total
Hours of Training Completed
September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
• I have taught software project management to many people who learned they needed it the hard way
• And to very few who took the course before they needed it
• I have taught software project management to many people who learned they needed it the hard way
• And to very few who took the course before they needed it
Plan Time and Budget for Training
• It is often easy to overlook these• And then you lack time or money to
do it when you need it
CSE 7315 - SW Project Management / Module 24 - Additional Software PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
Slide 34
CSE7315M24
September 12, 2004
Configuration Management Plan
Slide # 35 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
The CM Plan Serves To Describe
… the process and procedures for configuration management
… the roles and who is assigned to each role
… how decisions will be made… what tools will be used… what training is required… how libraries will be maintained
(see upcoming course modules on configuration management)
WHO will do WHAT, WHEN
and HOW
WHO will do WHAT, WHEN
and HOW
Slide # 36 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Process and Procedures Info
• Naming conventions • Mechanisms for creating new
components• How changes are made, tracked, and
documented• How control is assigned to components• How changes are authorized and
implemented• Etc. (see course modules on
configuration management)
Slide # 37 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Roles and Responsibilities (example)
• Configuration Manager: member of CM staff responsible for creating libraries, controlling all changes, implementing all changes, and testing all changes to make sure they work
• Module Owner: typically a software developer assigned to the design of the module. Responsible for assuring technical correctness and integrity of the module and all changes to it
Slide # 38 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Roles and Responsibilities (example) (continued)
• Configuration Control Board: Composed of the following individuals:– Software lead (chair)– Configuration manager (facilitator)– Technical leads for each software item– Lead architect of the softwareMakes all decisions about:– Whether to make a given change– Whether to accept a change after it is
implemented– …
Slide # 39 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Software Development Library
• This is the repository for official, “controlled” versions of the software and its components
• There can be working sections, released sections, etc.
• The key is to decide how this will be handled and describe it in the plan so that everyone knows how it will work
CSE 7315 - SW Project Management / Module 24 - Additional Software PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
Slide 40
CSE7315M24
September 12, 2004
Quality Assurance Plan
Slide # 41 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
The Quality Assurance Plan …
• Describes how quality will be built into the software– Inspections, walkthroughs, tests,
evaluations, audits, reviews, verifications and validations, etc.
• Quality assurance has two purposes:– To provide control over the quality of
the product– To provide visibility into the quality of
the product
Slide # 42 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
QA Plan Must Include
… the process and procedures for quality assurance functions of various kinds
… the roles and who is assigned to each role
… how decisions will be made, especially when there are disagreements
… what tools will be used… what training is required… how records will be maintained(see upcoming course modules on quality
assurance)
WHO will do WHAT, WHEN
and HOW
WHO will do WHAT, WHEN
and HOW
Slide # 43 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Sample Table Showing Inspection Process RolesStep of Inspection Process Responsibility
Correct or otherwise resolve all defects noted in the meeting
Author / owner
Verify defect resolutions Moderator
Generate inspection report and keep records
Moderator
Report closure of action items to project or software mgt.
Recorder
Slide # 44 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Some Important Questions Related to Quality Assurance
• Who is responsible for what?– Inspections, testing, collecting data,
etc.– For example, who does testing?
• How will conflicts be resolved?– Independent reporting chains– Resolutions must be resolved at a
level high enough that the individual has authority and control over the affected impact / financial implications
CSE 7315 - SW Project Management / Module 24 - Additional Software PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
Slide 45
CSE7315M24
September 12, 2004
Build/Integration Plan
Slide # 46 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Software is Often Built Up as Several Iterations or Builds
• Each “build” may implement a portion of the requirements
• The number, content, and sequence of builds is an important part of schedule planning
• Often, the builds are decided on the basis of master schedule issues– Parts of the system may not all be
available when desired
Slide # 47 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Thinking Through the Integration and Build
Sequence is an Important Part of Planning
• Don’t wait until the end to do this– Planning this often shows you important
facts about sequencing and scheduling– Such as things you can schedule sooner
and things you cannot schedule until late• You may need to motivate others who
don’t like to think about this until the parts are complete
Slide # 48 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Project X
Typical Build Plan (simplified)
Software Build 1
• Run time system
• I/O
• Basic system utility functions
Hardware Build 1
• Processor board
• ROM and RAM
• Simulated I/O
Software Build 2
• Data base
• User interface
• Tier 1 applications
Hardware Build 2
• Storage drives
• Tier 1 special hardware
Software Build 3
• Cleanup
•Tier 2 apps
Hardware Build 3
• Built-in test
•Tier 2 hardware
September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Module Summary
• The Software Development Plan serves many roles– Communicates your plans– Helps you plan– Shows you know how to manage the
project
• The formal Plan is supplemented by many other plan elements
September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
Module Summary (continued)
• Planning forces you to think• Documenting your plan helps you
avoid glossing over issues that need to be pinned down
• Plans must be maintained and used• Plans changes must be communicated• A standard plan is like a checklist to
make sure you have included everything in your plan
September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
References
• Donaldson, Scott E. and Stanley G. Siegel, Cultivating Successful Software Development, Prentice-Hall, 1997, Chapter 2.
• Department of Defense, Defense System Software Development, Dod-STD 2167A, 29 Feb. 1988, Department of Defense, Washington D.C., 20201.
• Reifer, Donald, Tutorial: Software Management, IEEE Computer Society
Slide # 52 September 12, 2004
CSE 7315 - SW Project Management / Module 24 - Additional Software Plans
Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved
CSE7315M24
END OFMODULE 24