CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M24 Slide

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


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



CSE7315M24

The Plan within a plan

SoftwareDevelopment

Plan(formal

document)

software development plan

SoftwareStandards

andProcedures

WBS

PoliciesFacilities

Estimates

StaffingplanSchedule




CSE7315M24

Additional Plans We Will Cover

• Risk Management• Metrics• Training• Software Configuration

Management• Software Quality Assurance• Build/Integration




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


Slide 7

CSE7315M24

September 12, 2004

Risk Management Plan




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




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.




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




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




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.




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.




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




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




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.


Slide 17

CSE7315M24

September 12, 2004

Measurement Plans




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




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




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




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




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




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




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.


CSE7315M24

September 12, 2004

Training Plans



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



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




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




CSE7315M24

In Other Words …

• Like all plans, a training plan explains

WHO will do WHAT, WHEN

and HOW


and HOW



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



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




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



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


Slide 34

CSE7315M24

September 12, 2004

Configuration Management Plan




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)


and HOW


and HOW




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)




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




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– …




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


Slide 40

CSE7315M24

September 12, 2004

Quality Assurance Plan




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




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)


and HOW


and HOW




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




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


Slide 45

CSE7315M24

September 12, 2004

Build/Integration Plan




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




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




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



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



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



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




CSE7315M24

END OFMODULE 24

Documents

CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M24 Slide