1. CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M24 Slide 1 September 12, 2004 SMU CSE 7315 / NTU SE 584-N Planning and Managing a Software Project Module 24 Additional Software Plans

2. CSE7315M24 Slide # 2 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Objective of This Module To review several additional parts of a software development plan

3. CSE7315M24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 5 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Additional Plans We Will Cover Risk Management Metrics Training Software Configuration Management Software Quality Assurance Build/Integration

6. CSE7315M24 Slide # 6 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M24 Slide 7 September 12, 2004 Risk Management Plan

8. CSE7315M24 Slide # 8 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 9 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 10 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 11 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 12 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 13 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 14 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Sample Description of a Risk Risk: high turnover of key staff Evidence: recent turnover rates are 22%, competition from growing companies in town Priority: Red (urgent) Likelihood is 75% Impact is high

15. CSE7315M24 Slide # 15 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 16 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Chart Showing Links to Measures RisksMeasures SizeTurn over Earn ed Value Mor ale Etc. Staffing  Etc. Memory  Etc. Schedule  Etc. Cost  Etc. RqmtsEtc.

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

18. CSE7315M24 Slide # 18 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

19. CSE7315M24 Slide # 19 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 20 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Table Showing When Data are Collected Phase Data/Measure Requir ements Alg Dev Prel Des Final Des Code/ Test Integrate Rqmts Stability  Memory Utilization  Staffing  Rqmts Tested 

21. CSE7315M24 Slide # 21 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

22. CSE7315M24 Slide # 22 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 23 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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 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. CSE7315M24 Slide # 24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M24 September 12, 2004 Training Plans

26. CSE7315M24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

27. CSE7315M24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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...

28. CSE7315M24 Slide # 28 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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.)

29. CSE7315M24 Slide # 29 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved In Other Words … Like all plans, a training plan explains WHO will do WHAT, WHEN and HOW

30. CSE7315M24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved A Typical Training Model

31. CSE7315M24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved A Typical Training Schedule

32. CSE7315M24 Slide # 32 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Typical Training Progress Graph Hours of Training Completed

33. CSE7315M24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

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

35. CSE7315M24 Slide # 35 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 36 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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)

37. CSE7315M24 Slide # 37 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

38. CSE7315M24 Slide # 38 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 39 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

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

41. CSE7315M24 Slide # 41 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

42. CSE7315M24 Slide # 42 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 43 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 44 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

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

46. CSE7315M24 Slide # 46 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 Slide # 47 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

48. CSE7315M24 Slide # 48 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

49. CSE7315M24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

50. CSE7315M24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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. CSE7315M24 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved 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

52. CSE7315M24 Slide # 52 September 12, 2004 CSE 7315 - SW Project Management / Module 24 - Additional Software Plans Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved END OF MODULE 24