cse 7315 - sw project management / module 07 - software development plans copyright © 1995-2004,...

CSE 7315 - SW Project Management / Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Slide 1

CSE7315M07

Auygust 10, 2004

SMU CSE 7315 / NTU SE 584-NPlanning and Managing a

Software Project

Module 07Software Development Plans

Part 1

Auygust 10, 2004 CSE 7315 - SW Project Management /

Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,

All Rights Reserved

Slide # 2

CSE7315M07

Objectives of This Module

• To introduce the concept and role of a software development plan

• To discuss the contents of a software development plan



All Rights Reserved

Slide # 3

CSE7315M07

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



All Rights Reserved

Slide # 4

CSE7315M07

Your plan consists of virtually everything you produce as a result of

planning



All Rights Reserved

Slide # 5

CSE7315M07

“software development plan”definition

“The accumulation of all plans and related artifacts generated during the planning

process”Prototype

Final DesignBuild

Design

PrototypeFinal Design

Build

Design


Build

Design


Build

Design


Build

Design


Build

Design


Build

Design

CodeDesign Test

Build

DeliveryContract


Build

Design


Build

Design

technical interchanges

contract issues

legal issues



All Rights Reserved

Slide # 6

CSE7315M07

Your Plan is a document containing a selected group

of the principal planning artifacts



All Rights Reserved

Slide # 7

CSE7315M07

“Software Development Plan”

definition“A document describing

the principal plans for developing software”



All Rights Reserved

Slide # 8

CSE7315M07

The Plan within a plan

SoftwareDevelopment

Plan(formal

document)

software development plan

SoftwareStandards

andProcedures

WBS

PoliciesFacilities

Estimates

StaffingplanSchedule



All Rights Reserved

Slide # 9

CSE7315M07

Why Create a FormalSoftware Development Plan?

• To help you manage the project

AND

• To show others that you can manage the project



All Rights Reserved

Slide # 10

CSE7315M07

To Show that You CanManage 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



All Rights Reserved

Slide # 11

CSE7315M07

To Help YouManage 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?



All Rights Reserved

Slide # 12

CSE7315M07

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



All Rights Reserved

Slide # 13

CSE7315M07

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.



All Rights Reserved

Slide # 14

CSE7315M07

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



All Rights Reserved

Slide # 15

CSE7315M07

The exact content of the formal Plan will depend on specifics of your contract, organization,

project size, customer, management style, etc.

The Formal PlanShould 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



All Rights Reserved

Slide # 16

CSE7315M07

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.

You don’t have to develop a new Plan from scratch for each project. You may have a Plan

that fits many similar projects.



All Rights Reserved

Slide # 17

CSE7315M07

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



All Rights Reserved

Slide # 18

CSE7315M07

A Checklist for an SDP

Product Project Process

Description Summary Basic Details

Metrics &Risk Mgt

Basic Details Details

Other PlanI nformation

A smallamount

A modestamount

A largeamount


CSE7315M07

Auygust 10, 2004

Where Does This Information Come From?



All Rights Reserved

Slide # 20

CSE7315M07

JobAnalysis

InitialPlanning

PlanDescription

Sources of Information

• Most of the description information comes from analysis of the job and Initial Planning (covered in earlier modules in this course)



All Rights Reserved

Slide # 21

CSE7315M07

• Risks are identified throughout the planning process

• Risk management is addressed in a later module

Sources of Information(continued)

Manage Risks

Definethe Approach

GenerateDetailed Plans

Understandthe Need

Execute and Monitor



All Rights Reserved

Slide # 22

CSE7315M07

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



All Rights Reserved

Slide # 23

CSE7315M07

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 wellDocument Paragraph Description SDP

SOW 1.3.4 Design Software for Compiler 2.4.3

SOW 2.3.3 Travel for Design Reviews 1.7, A-3

...

Contract 7.13.2.a Follow ISO Standard 5432f SSPM

Rqmts. Doc. 3.4 Use data compression A-2

...

Customer Mtg. on 3/5/95 Code all software in C++ 1.2, SEE



All Rights Reserved

Slide # 24

CSE7315M07

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


CSE7315M07

Auygust 10, 2004

Detailed Review of the Contents of a Software

Development Plan

•Product Information

•Project Information

•Process Information



All Rights Reserved

Slide # 26

CSE7315M07

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



All Rights Reserved

Slide # 27

CSE7315M07

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



All Rights Reserved

Slide # 28

CSE7315M07

We will discuss more about measurements and threshold values in later modules and other

courses.

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



All Rights Reserved

Slide # 29

CSE7315M07

Anything that tells you whether the product is likely to meet its performance

requirements or encounter significant risks

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



All Rights Reserved

Slide # 30

CSE7315M07

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



All Rights Reserved

Slide # 31

CSE7315M07

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



All Rights Reserved

Slide # 32

CSE7315M07

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)



All Rights Reserved

Slide # 33

CSE7315M07

Project Information - Risk Management and

Measures• Key risks and project goals should

be identified• For each risk or goal, indicate:– Objectives, constraints and concerns– Mearures you will use to monitor – Threshold values requiring

management action



All Rights Reserved

Slide # 34

CSE7315M07

Anything that tells you whether the project is likely to meet its cost,

schedule, or other goals

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)– Compare with plans

• Expenditures of effort or funds– Compare with budgets

• Unplanned turnover rates



All Rights Reserved

Slide # 35

CSE7315M07

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



All Rights Reserved

Slide # 36

CSE7315M07

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



All Rights Reserved

Slide # 37

CSE7315M07

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



All Rights Reserved

Slide # 38

CSE7315M07

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



All Rights Reserved

Slide # 39

CSE7315M07

Anything that tells you whether the process is being followed correctly or is

achieving its objectives

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



All Rights Reserved

Slide # 40

CSE7315M07

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 • Specific assignments of people and

resources to tasks• Details of SW engineering environment

(SEE)


CSE7315M07

Auygust 10, 2004

Additional Information on Specific Plan Contents ...

… will be discussed in more detail in module 08 and later

modules of the course


CSE7315M07

Auygust 10, 2004

Maintaining an Effective Plan



All Rights Reserved

Slide # 43

CSE7315M07

Many Organizations Have Defined Standards for

Software Development Plans• DOD-STD-2167a• Mil-STD-498• ISO/IEC 12207• Your industry• Your company• Your organization• ...



All Rights Reserved

Slide # 44

CSE7315M07

Why Use a Standard Formatfor 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

Example: the standard formats for assignments in this course

help you know what to turn in and help me evaluate them efficiently



All Rights Reserved

Slide # 45

CSE7315M07

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



All Rights Reserved

Slide # 46

CSE7315M07

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.initialplan

Periodic Review and Update

Periodic Review and Update

revisedplan



All Rights Reserved

Slide # 47

CSE7315M07

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



All Rights Reserved

Slide # 48

CSE7315M07

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 too frequently or people will not take the time to pay attention to changes



All Rights Reserved

Slide # 49

CSE7315M07

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



All Rights Reserved

Slide # 50

CSE7315M07

Dealing with the Realities ofBureaucratic 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



All Rights Reserved

Slide # 51

CSE7315M07

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



All Rights Reserved

Slide # 52

CSE7315M07

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



All Rights Reserved

Slide # 54

CSE7315M07

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