Copyright , 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version 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... Contract aFollow ISO Standard 5432fSSPM Rqmts. Doc.3.4Use data compression A-2... CustomerMtg. on 3/5/95Code all software in C++1.2, SEE

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

Copyright , 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Copyright , 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

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

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

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

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

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

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

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

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

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

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

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

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

Copyright , Dennis J. Frailey CSE7315- Software Project Management CSE7315 M07 - Version References  Donaldson, Scott E. and Stanley G. Siegel, Cultivating Successful Software Development, Prentice-Hall, 1997, Chapter 2.  Department of Defense, Defense System Software Development, Dod-STD 2167A, 29 Feb. 1988, Department of Defense, Washington D.C.,  Reifer, Donald, Tutorial: Software Management, IEEE Computer Society