1. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M07 - Version 8.01 SMU CSE 7315 Planning and Managing a Software Project Module 07 Software Development Plans Part 1

2. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 2 Objectives of This Module  To introduce the concept and role of a software development plan  To discuss the contents of a software development plan

3. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 3 Warning from Dilbert “There are two major steps to building a business plan: 1. Gather information 2. Ignore it” Adams, The Dilbert Principle “There are two major steps to building a business plan: 1. Gather information 2. Ignore it” Adams, The Dilbert Principle

4. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 4 Your plan consists of virtually everything you produce as a result of planning

5. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 5 “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

6. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 6 Your Plan is a document containing a selected group of the principal planning artifacts

7. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 7 “Software Development Plan” definition “ A document describing the principal plans for developing software ”

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

9. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 9 Why Create a Formal Software Development Plan?  To help you manage the project AND  To show others that you can manage the project

10. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 10 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

11. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 11 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?

12. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 12 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

13. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 13 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.

14. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 14 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

15. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 15 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

16. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 16 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 You don’t have to develop a new Plan from scratch for each project. You may have a Plan that fits many similar projects, or a Master Plan that you tailor for each project.

17. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 17 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

18. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M07 - Version 8.01 Where Does This Information Come From?

19. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 19 Job Analysis Initial Planning Plan Description Sources of Information  Most of the description information comes from analysis of the job and Initial Planning (covered in earlier modules in this course)

20. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 20  Risks are identified throughout the planning process  Risk management is addressed in a later module Sources of Information (continued) Manage Risks Define the Approach Generate Detailed Plans Understand the Need Execute and Monitor

21. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 21 Sources of Information (continued)  Other planning information comes from detailed planning......which will be covered in upcoming modules  and from planning for project execution... … which is covered in later modules

22. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 22 Tracing the SW Development Plans to the Source Documents  We will learn in future modules to trace the detailed plans to source documents. –We can 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

23. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 23 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

24. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M07 - Version 8.01 Detailed Review of the Contents of a Software Development Plan Product Information Project Information Process Information

25. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 25 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

26. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 26 Product Information - The Software  For each software item –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

27. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 27 We will discuss more about measurements and threshold values in later modules and other courses. Product Information - Risk Management and Measures  Key risks or performance goals  For each risk or performance goal (such as speed, memory size, etc), identify –Objectives, constraints and concerns –Measures you will use to monitor –Threshold values requiring management action

28. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 28 Anything that tells you whether the product is likely to meet its performance requirements or encounter significant risks Sample Product Measures  How fast the software is expected to run  Unused processing capacity  Memory size  I/O channel or network utilization

29. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 29 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

30. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 30 Project Information - Schedule  Lifecycle model, if any  Integrated master plan (at a summary level - major tasks to be performed)  Integrated master schedule –Major milestones and goals –Top level schedules for major tasks –Key reviews and milestones or gate points

31. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 31 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 (modules 9, 10)  Subcontract and co-contract relationships (if applicable)

32. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 32 Project Information - Risk Management and Measures  Key risks and project goals should be identified  For each risk or goal, indicate: –Objectives, constraints and concerns –Measures you will use to monitor the risks or other key project numbers –Threshold values requiring management action

33. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 33 Anything that tells you whether the project is likely to meet its cost, schedule, or other goals Sample Project Measures  What work tasks are complete (such as requirements defined, modules designed, units coded or tested, earned value) –Compare with plans  Expenditures of effort or funds –Compare with budgets  Unplanned turnover rates

34. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 34 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

35. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 35 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

36. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 36 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 may not be necessary to understand your plan

37. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 37 Process Information - Risk Management and Measures  Key risks and process goals should be identified  For each risk or goal, indicate: –Objectives, constraints and concerns –Measures you will use to monitor –Threshold values requiring management action  Some process measures are used to identify the causes of project and product problems

38. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 38 Anything that tells you whether the process is being followed correctly or is achieving its objectives Sample Process Measures  How well we are finding problems during inspections and reviews?  Defect levels and defect correction levels  Amount of rework due to errors  Are we following the process?  Is the process working as planned?

39. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 39 Typical Plan Appendices or Supplements  Project-specific standards, detailed procedures and methods –Often found in an SSPM (software standards and procedures manual)  Detailed schedules and estimates  Shoploads (how people’s time is allocated)  Specific assignments of people and resources to tasks  Details of SW engineering environment (SEE)

40. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M07 - Version 8.01 Additional Information on Specific Plan Contents... … will be discussed in more detail in module 08 and later modules of the course

41. Copyright 1995-2008, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M07 - Version 8.01 Maintaining an Effective Plan

42. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 42 Many Organizations Have Defined Standards for Software Development Plans  DOD-STD-2167a  Mil-STD-498  ISO/IEC 12207  Your industry  Your company  Your organization ...

43. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 43 Why Use a Standard Format for the Plan?  It tells you all the 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

44. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 44 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

45. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 45 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

46. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 46 You Learn More Every Day Plans need to reflect what you know today... … not what you didn’t know when you wrote the plan. Plans need to reflect what you know today... … not what you didn’t know when you wrote the plan. Build time in your schedule for periodic updates of your estimates and plans

47. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 47 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’s worth the trouble to coordinate changes and communicate them effectively Don’t change plans too frequently or people will not pay attention to changes

48. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 48 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

49. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 49 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

50. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 50 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

51. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 51 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  Plan changes must be communicated  A standard Plan is like a checklist to make sure you have included everything in your Plan

52. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 52 END OF MODULE 07

53. Copyright 1995-2008, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 8.01 53 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