1. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 1 CHAPTER 8 DETAILED PLANNING - The Software Development Plan NOTICE: This material is copyrighted and may be copied or downloaded ONCE ONLY by students who are registered in this course at Southern Methodist University or National Technological University.

2. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 2 Detailed Planning - Processes 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

3. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 3 Warning from Dilbert “There are two major steps to building a business plan: 1. Gather information 2. Ignore it” Adams, The Dilbert Principle

4. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 4 Contents of a Software Development Plan Documenting and Communicating the Plan

5. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 5 Your plan consists of virtually everything you produce as a result of planning

6. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 6 “software development plan” definition “The accumulation of all plans and related artifacts generated during the planning process” Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design Prototype Final Design Build Design CodeDesignTest Build DeliveryContract Prototype Final Design Build Design Prototype Final Design Build Design technical interchanges contract issues legal issues

7. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 7 Your Plan is a document containing a selected group of the principal planning artifacts

8. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 8 “Software Development Plan” definition “ A document describing the principal plans for developing software ”

9. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 9 The Plan within a plan Software Development Plan (formal document) software development plan Software Standards and Procedures WBS Policies Facilities Estimates Staffing plan Schedule

10. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 10 Why Create a Formal Software Development Plan? To help you manage the project AND To show others that you can manage the project

11. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 11 To Show that You Can Manage the Project... The Plan demonstrates that sufficient planning has been done The Plan shows that you understand the project, the problem, the risks, the criteria for completion, the methods for developing software, and the customer expectations

12. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 12 To Help You Manage the Project... The Plan forces you to answer questions that might otherwise be left unanswered How will we set up our software library? How will we track progress on the data base development?

13. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 13 To Help You Manage... The Plan communicates your plans to concerned parties - your staff, other organizations, subcontractors It provides a common framework from which all participants can make their individual plans

14. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 14 To Help You Manage... The Plan documents assumptions, contractual understandings, mutual agreements, etc. It helps you to remember what you planned It helps you manage risks by recording your rationale, backup plans, expectations, etc.

15. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 15 Don’t Overdo the Formal Plan The Formal Plan should contain … … a guide to the software development approach … a guide to your management approach... information that is not likely to change frequently during the project … information that is necessary to evaluate and understand your plan

16. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 16 The exact content of the formal plan will depend on specifics of your contract, organization, project size, customer, management style, etc. The Formal Plan Should Not Contain... … detailed information about the product’s technical characteristics, architecture, or design approach … detailed schedules, cost estimates, etc. … excessive detail about the process and methods you will use, especially if it is likely to change often

17. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 17 The Formal Plan is like the Textbook for your Project You learn from it You use it to teach new employees all about the project You refer to it from time to time But most people do not use it on a daily basis

18. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 18 The Formal Plan Should Cover... … a little about the product – A summary that shows its characteristics, components, and performance goals … more about the project – Focusing on organization, structure, and management … a lot about the process – In detail, including all aspects of how software will be developed and managed

19. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 19 A Checklist for an SDP

20. 20 Where Does This Information Come From?

21. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 21 Job Analysis Initial Planning Plan Description Sources of Information Most of the Description information comes from Job Analysis and Initial Planning (earlier chapters in this course)

22. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 22 Risks are identified throughout the planning process Risk management is addressed in a later chapter Analyze Job Manage Risks Execute, Measure, Manage Productivity and Quality Generate Detailed Plans Generate Initial Plans Sources of Information (continued)

23. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 23 Sources of Information (continued) Other planning information comes from detailed planning... –...which was covered in earlier chapters and from planning for project execution – This is covered in this chapter, later chapters and other courses

24. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 24 Tracing the SW Development Plans to the Source Documents We trace the WBS and estimates to source documents. – Why not trace to the plans as well DocumentParagraphDescriptionSDP SOW1.3.4Design Software for Compiler2.4.3 SOW2.3.3Travel for Design Reviews1.7, A-3... Contract7.13.2.aFollow ISO Standard 5432fSSPM Rqmts. Doc.3.4Use data compression A-2... CustomerMtg. on 3/5/95Code all software in C++1.2, SEE

25. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 25 Advantages of a Trace to the Software Development Plan You can easily show how your plan relates to the job to be done You can justify plan components by tracing to project requirements You can assure that you have planned all major tasks of the project

26. 26 Detailed Review of the Contents of a Software Development Plan Product Information Project Information Process Information

27. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 27 Product Information - The Application and the System A summary description of the application and the system, such as: – Scenarios describing system use – An overview of the architecture, including the major components – Processors and their functions – Brief discussions of the technologies involved or any unusual aspects – Summary of any key performance objectives and system constraints

28. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 28 Product Information - The Software For each software product – Its type and characteristics – Its function, in relation to the other software and the rest of the system – Its architecture, including the major software components and interfaces – Processor(s) and other system elements the software will use – Programming language(s) – Rough size estimate

29. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 29 We will discuss more about metrics and threshold values in later chapters and other courses. Product Information - Risk Management and Metrics Key risks or performance goals For each risk or performance goal (such as speed, memory size, etc), identify – Objectives, constraints and concerns – Metrics you will use to monitor – Threshold values requiring management action

30. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 30 Anything that tells you whether the product is likely to meet its performance requirements or encounter significant risks Sample Product Metrics How fast the software is expected to run Unused processing capacity Memory size I/O channel or network utilization

31. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 31 Project Information - General The nature of the project – Type of contract, if any – Source of funding – Reporting structure – Interfaces with customer Logistics – Location(s) of organizations – Facilities you will use – Security considerations, if any

32. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 32 Project Information - Organization Organizational Breakdown Structure – Key roles and responsibilities – Reporting structures within the project – Key relationships and communication paths – Skills required for key roles Work Breakdown Structure Subcontract and Co-Contract relationships (if applicable)

33. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 33 Project Information -Schedule Master project schedule – Lifecycle model, if any – Major milestones and goals – Top level schedules for major subprojects – Key review and gate points Schedules for major subprojects – Phases and goals – Key dependencies – Reporting points

34. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 34 Project Information - Risk Management and Metrics Key risks and project goals should be identified For each risk or goal, indicate: – Objectives, constraints and concerns – Metrics you will use to monitor – Threshold values requiring management action

35. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 35 Anything that tells you whether the project is likely to meet its cost, schedule, or other goals Sample Project Metrics What work tasks are complete (such as requirements defined, modules designed, units coded or tested) – Compare with plans Expenditures of effort or funds – Compare with budgets Unplanned turnover rates

36. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 36 Process Information This forms the bulk of the content of a formal software development plan. Typical information includes: Methods and processes for software development, evaluation and testing Milestones and reviews Subcontractor management methods Tools to be used

37. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 37 Additional Process Information Reuse plans and approaches Process improvement techniques Risk analysis and management techniques Structure and procedures of software development libraries Processes for support activities such as quality assurance and configuration management

38. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 38 Process Information is Identified Throughout the Project Much of it can be established during planning, at least at a high level But many of the details are typically not fully worked out until the project is underway And such details are not necessary to understand your plan

39. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 39 Typical Plan Supplements Project-specific standards, detailed procedures and methods – Often found in an SSPM (software standards and procedures manual) Detailed schedules Shoploads Specific assignments of people and resources to tasks Details of SW Engineering Environment (SEE)

40. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 40 Process Information - Risk Management and Metrics Key risks and process goals should be identified For each risk or goal, indicate: – Objectives, constraints and concerns – Metrics you will use to monitor – Threshold values requiring management action Some process metrics are used to identify the causes of project and product problems

41. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 41 Anything that tells you whether the process is being followed correctly or is achieving its objectives Sample Process Metrics How well we are finding problems during inspections and reviews Defect levels and defect correction levels Amount of rework due to errors

42. 42 Selecting Methods and Tools

43. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 43 Reliable, Proven Tools and Methods Innovative, Improved Tools and Methods vs

44. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 44 Programmers usually want the Latest and Greatest They want to keep up to date in a field that changes rapidly They want to improve how they do their jobs They expect the newest tools and methods to give them higher performance and greater job satisfaction

45. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 45 But Newer Can Mean Higher Risk New tools and methods may not integrate well with other tools and methods used on the project Training is necessary It takes time to learn a new tool or method Mistakes are inevitable Proficiency is not instant

46. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 46 Sometimes your Customer or Manager May Intervene They may insist on a new and risky approach because they heard good things about it Or they may resist using more recent but well established techniques because of fear of the unfamiliar

47. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 47 Give the issues some thought Do trade studies Get input from previous users of the new methods and tools Consider using the newer techniques on small, prototype efforts before applying to major projects Your Job is to Deliver the Software On Time and On Budget

48. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 48 Pragmatic Issues Cost & availability of tools and methods Long term viability of vendors Availability of support What computers the tools run on Compatibility with other tools & methods What training is required How long you will need to maintain the software you are developing – will the tools still be available?

49. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 49 The Plan Should Document... The tools and methods to be used for each step of the process Purpose of each tool and method Where the tools will be acquired (especially if they are proprietary) Brief rationale for each tool and method – Can refer to trade studies and such

50. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 50 A Typical Tool Chart in a Software Development Plan

51. 51 Facilities and Staffing Plans

52. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 52 You Must Plan Reasonable Staff Acquisition and Use Patterns

53. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 53 Your job is to remove obstacles to their effectiveness... … not to have them take burdens off of you! People Cost Money -- Make Them Productive! Adequate training Adequate facilities Avoid excessive interruptions

54. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 54 Make Sure the Facilities Fit the Job to be Done Enough computers, copiers, etc. Enough work space Reliable networks and utilities People who work closely together should be located closely together

55. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 55 The Software Development Plan... … should describe the facilities needed and planned (at a high level) … and the overall staffing plans – Numbers – Skills required … and the plans for managing any risks related to these – Backup staffing plans – Alternate facilities options

56. 56 Training Plans

57. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 57 Well Trained Staff are More Productive But training is an investment And it is usually considered an overhead expense, thus a bad thing You may need to justify it But you also need to plan it to make sure the investment is worthwhile – The right training – At the right time – For the right people

58. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 58 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...

59. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 59 A Typical Training Plan

60. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 60 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

61. 61 Maintaining an Effective Plan

62. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 62 Many Organizations Have Defined Standards for Software Development Plans DOD-STD-2167a Mil-STD-498 ISO/IEC 12207 Your industry Your company Your organization...

63. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 63 Why Use a Standard Format for the Plan? It tells you all right questions It helps others know where to look for the answers Example: the standard formats for assignments in this course help you know what to turn in and help me evaluate them efficiently

64. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 64 Drawbacks of a Standard Format for the Plan May be overly restrictive May not fit new approaches or concepts May encourage “boilerplate” mentality when developing or using plans

65. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 65 The Plan is Static -- Planning is Dynamic You rarely follow the plan exactly as written As you progress, you learn more Keeping the plan up to date keeps everyone synchronized and reduces the chances of miscommunication, etc. Initial Planning etc. initial plan Periodic Review and Update revised plan

66. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 66 You Learn More Every Day Plans need to reflect what you know today... … not what you didn’t know when you wrote the plan.

67. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 67 Be Sure to Coordinate and Communicate Plan Changes Some software managers change their plans without notifying affected parties This can lead to chaos So it is worth the trouble to coordinate changes and communicate them effectively Don’t change too frequently or people will not take the time to pay attention to changes

68. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 68 Beware of Bureaucrats It is a good idea to have an approval process for plan changes But some customers or managers have instituted a slow, burdensome bureaucracy for approval of plan changes that impedes effective plan updates People who must approve changes to the plan

69. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 69 Dealing with the Realities of Bureaucratic Change Approvals Avoid excessive detail in the Plan – put it in a supplement Incorporate plans for changing the Plan Maintain “Duplicate” plans – Formal, approved plan (high level) – Working, dynamic plan (more specific) Establish trust with customers by keeping commitments

70. 70 What Should be Documented in the Plan or the plan

71. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 71 Artifacts vs Documents An artifact is anything produced by a process A document is a particular kind of artifact, consisting of a permanent, human readable record, generally in paper or word processor form

72. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 72 Sample Non-document Artifacts Object Code Requirements Model The Design of the System In order to comprehend all that the process does, you need to define it in terms of artifacts, not just documents

73. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 73 Some Artifacts are Not Suitable for Paper Documents Many artifacts change dynamically – Designs – Some Plans – Test Results – etc. Others are not suitable for paper or human-readable form – Object Code – CASE Tool internal artifacts

74. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 74 Limitations of Paper Documents Paper documents represent a “snapshot”, at a point in time If the documented item is frequently changing, the paper document is soon out of date and incorrect Creation, storage and maintenance of paper documents can be expensive and may not contribute to the project goals

75. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 75 Advantages of Paper Documents Permanence may be a benefit – Assures consistency when there are multiple users – Documents typically outlast the project, thus providing historical information that might benefit future projects – (in some cases, it might be seen as archaeological!) Documents are human readable – Documentation forces one to clarify intent in a way that other humans can read it

76. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 76 Documentation for Software is like Documentation for Plans During development, it is a snapshot of status Because requirements and designs are always being revised, specifications must be treated as having very short “half life” Many contemporary software development organizations generate specifications and such “on line” and keep it dynamic (no printed versions)

77. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 77 Your Documentation Plan is Part of your SW Development Plan It should explain the artifacts to be produced And what form they will appear in – Paper documents (in what format?) – Computer files (how they can be read and edited) And how they will be maintained – Who controls changes??

78. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 78 Documentation is Part of the Configuration Document version 3.5 Software version 3.5 Document version 3.4 Software version 3.4 You must keep them synchronized

79. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 79 What Artifacts are Produced by a Project? Artifacts that are needed for later project phases need to be updated when new software versions or releases are produced See Appendix for examples of software project artifacts

80. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 80 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

81. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 81 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

82. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 82 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

83. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 83 END OF CHAPTER 8

84. 84 Appendix Artifacts Typically Generated during Software Development

85. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 85 We will Examine the Process in terms of Artifacts We will describe some of the most commonly used artifacts, may of which are generally produced as paper or electronic documents These will be sort of generic -- inspired by the DOD standards and the IEEE standards Student exercise - consider which artifacts are best represented as paper documents and which are better represented in non-paper form.

86. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 86 Artifacts Commonly Used during Software Development Possible Inputs to Software Development -- Statement of Work - what work is supposed to be done and what deliverables are expected - the requirements for the project and the process -- System Requirements - what is the system supposed to do (functions, performance, standards met, etc.) - the requirements for the product

87. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 87 Artifacts Commonly Used during Software Development (continued) Possible Inputs to Software Development -- System Design Specification - what are the parts of the system, how do they interact, and what requirements are allocated to each -- System Test Requirements - how the system will test or verify that it meets its requirements

88. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 88 Notes 1) Often in a complex system, you have separate design specifications for different parts 2) In that case, you need some document that ties it all together (in DoD contracts, this is called the “system/segment design document” or SSDD)

89. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 89 Notes (continued) 3) This “tie it together” document is redundant but important -- sort of like the WBS is redundant but important for understanding all of the work to be done

90. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 90 Artifacts (continued) Artifacts Produced by Software Requirements Analysis -- SW Requirements Specification - what the software is supposed to do -- Interface Requirements - how the software is supposed to interface with everything else – Hardware – Users – Operators – Other Software

91. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 91 Artifacts (continued) Artifacts Produced by Software Requirements Analysis -- Software Test Requirements -- Algorithm Descriptions (for embedded and scientific applications)

92. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 92 Artifacts (continued) Artifacts Produced by Software Design -- Software Design Description – Usually a separate one for each product or major part of the software -- Interface Design Description – How the parts fit together and interface with each other – How the software interfaces with the outside world

93. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 93 Artifacts (continued) Artifacts Produced by Software Design -- Software Test Plan – Test cases and methods to be used -- Software Development Files – Informal notes by designers on alternatives tried, rationale for specific decisions, etc.

94. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 94 Artifacts (continued) Artifacts Produced by Implementation -- Software – Source Code, Source Listings, Object Code, etc. -- Test Procedures and Code – Source and object code of Tests and Test Data – Procedures for carrying out the Tests

95. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 95 Artifacts (continued) Artifacts Produced by Implementation -- Test Reports – Results of tests, showing what actually happened -- End User Documentation – User’s guides, operator’s guides, etc. Consider doing early and making these part of the requirements specification

96. January 20, 2000 CSE 7315 - SW Project Management / Chapter 8 - Detailed Planning - The Software Dev. Plan Copyright © 1995-2000, Dennis J. Frailey, All Rights Reserved Slide # 96 Artifacts (continued) Artifacts Produced by Software Integration -- More Test Procedures and Code -- More Test Reports -- Installation Guides -- Maintenance Documentation -- Support Documentation -- etc.