1. Copyright 1995-2009, 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

38. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 9.01 38 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 –…

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

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

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

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

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

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

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

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

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

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

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

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

51. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M24 - Version 9.01 51 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, Software Management, 7 th Edition, IEEE Computer Society Press / Wiley, ISBN-13: 978-0471775621

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