Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M24 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project Module 24 Additional Software Plans

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Objective of This Module  To review several additional parts of a software development plan

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Detailed Planning Process Estimate Size Estimate Effort and Cost Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBSSize Effort & Cost Schedule OK Complete Detailed Planning Revise & Negotiate Not OK

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version The Plan within a plan Software Development Plan (formal document) software development plan Software Standards and Procedures WBS Policies Facilities Estimates Staffing plan Schedule

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Additional Plans We Will Cover  Risk Management  Metrics  Training  Software Configuration Management  Software Quality Assurance  Build/Integration

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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

Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M24 - Version 9.01 Risk Management Plan

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Contents of a Risk 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Sample Chart Showing Risk Analysis and Prioritization Be sure to explain WHY each risk is important – provide EVIDENCE that it is as likely or as expensive as indicated.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Sample Risk Occurrence Chart RiskLikelihood JFMAMJ… TurnoverLow Med Hi Etc. Memory too small Low Med Etc. Space too small Hi Med Etc. A chart like this helps you know when to expect certain risks to be more likely.

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Sample Description of a Risk Risk: high turnover of key staff Evidence:  recent turnover rates are 22%,  competition from growing companies in town Analysis: Priority is Red (urgent)  Likelihood is 75%  Impact is high

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Sample Description of a Risk (continued) Mitigation Plans and Actions:  Increased salaries 15%  Giving employees a bonus for successful completion on time Monitoring:  Will monitor project turnover rate monthly and take action if exceeds 10% Contingency plans:  Increased hiring rates, use of contract labor

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Chart Showing Links to Measures RisksMeasures SizeTurnoverEarned Value MoraleEtc Staffing  Etc Memory  Etc Schedule  Etc Cost  Etc RqmtsEtc

Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M24 - Version 9.01 Measurement Plans

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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 –No need for details, just what the risks are, why they are risks, and what will be measured to monitor those risks  The risk plan discusses further details, such as risk analysis, prioritization, mitigation, contingencies, and details of which measures are used for monitoring of each risk

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Table Showing When Data are Collected Phase Data/Measure Require ments Alg Dev Prel Des Final Des Code/ Test Integrate Rqmts Stability  Memory Utilization  Staffing  Rqmts Tested 

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Description of Data Collection and Analysis Process Example Description:  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 analysis results at monthly status reviews

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Sample Measure Description Name: Requirements Stability Purpose: 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 requirements N – new requirements C – changed requirements D – deleted requirements

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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 worse than: 25% during preliminary design and 10% during detailed design and 3% during code and test R should not change by more than 10% without a re-estimate and re-plan of the project

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Sample Measure Description (continued) Typical Graph and How it is Interpreted: 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.

Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M24 - Version 9.01 Training Plans

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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  So you may need to justify training  Plan your project training to make sure the investment is worthwhile –The right training –At the right time –For the right people

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Many Kinds of Training May be Required  Software processes and policies  Project management and estimation  Required standards  Role of support staff (such as QA or CM) on project  Requirements analysis procedures  Use of new tools and methods  Code inspection techniques ...

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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 training measure – something to monitor training progress (describe what you will measure, what graphs will be used, what reports will be made, etc.)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version In Other Words …  Like all plans, a training plan explains WHO will do WHAT, WHEN and HOW

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version A Typical Training Model

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version A Typical Training Schedule

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Typical Training Progress Graph Hours of Training Completed

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Your Plan Must Provide 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

Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M24 - Version 9.01 Configuration Management Plan

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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 upcoming course modules on configuration management)

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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:  A software developer assigned to the design of the module. Responsible for assuring technical correctness and integrity of the module and all changes to the module

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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 software  Makes all decisions about: –Whether to make a given change –Whether to accept a change after it is implemented –…

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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.  An important part of configuration management planning is to decide how this will be handled and describe it in the plan so that everyone knows how it will work  Usually the library is maintained within a data base or a configuration management tool

Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M24 - Version 9.01 Quality Assurance Plan

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version The Quality Assurance Plan …  Describes how quality will be built into the software –Inspections, walkthroughs, tests, evaluations, audits, reviews, verifications and validations, etc. –Note that some of the above may be described in the process section of the plan or in a separate test plan  Quality assurance has two purposes: –To provide control over the quality of the product –To provide visibility into the quality of the product

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Sample Table Showing Inspection Process Roles Step of Inspection ProcessResponsibility Correct or otherwise resolve all defects noted in the meeting Author / owner Verify defect resolutionsModerator Generate inspection report and keep records Moderator Report closure of action items to project or software mgt. Recorder

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Some Important Questions Related to Quality Assurance  Who (by role) 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

Copyright , Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M24 - Version 9.01 Build/Integration Plan

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Thinking Through the Integration and Build Sequence is an Important Part of Planning  Don’t wait until the end to do this –Planning builds 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version Project X Typical Build Plan (simplified example) 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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  The plan should indicate who does what, when and how

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 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.,  Reifer, Donald, Software Management, 7 th Edition, IEEE Computer Society Press / Wiley, ISBN-13:

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version END OF MODULE 24