Upload
emory-hart
View
222
Download
3
Embed Size (px)
Citation preview
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
All Rights Reserved
Slide # 4
CSE7315M07
Your plan consists of virtually everything you produce as a result of
planning
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
PrototypeFinal Design
Build
Design
PrototypeFinal Design
Build
Design
PrototypeFinal Design
Build
Design
PrototypeFinal Design
Build
Design
PrototypeFinal Design
Build
Design
CodeDesign Test
Build
DeliveryContract
PrototypeFinal Design
Build
Design
PrototypeFinal Design
Build
Design
technical interchanges
contract issues
legal issues
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
All Rights Reserved
Slide # 6
CSE7315M07
Your Plan is a document containing a selected group
of the principal planning artifacts
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
All Rights Reserved
Slide # 7
CSE7315M07
“Software Development Plan”
definition“A document describing
the principal plans for developing software”
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
All Rights Reserved
Slide # 8
CSE7315M07
The Plan within a plan
SoftwareDevelopment
Plan(formal
document)
software development plan
SoftwareStandards
andProcedures
WBS
PoliciesFacilities
Estimates
StaffingplanSchedule
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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?
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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.
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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.
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
CSE 7315 - SW Project Management / Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Slide 19
CSE7315M07
Auygust 10, 2004
Where Does This Information Come From?
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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)
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
CSE 7315 - SW Project Management / Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Slide 25
CSE7315M07
Auygust 10, 2004
Detailed Review of the Contents of a Software
Development Plan
•Product Information
•Project Information
•Process Information
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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)
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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)
CSE 7315 - SW Project Management / Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Slide 41
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
CSE 7315 - SW Project Management / Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Slide 42
CSE7315M07
Auygust 10, 2004
Maintaining an Effective Plan
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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• ...
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
All Rights Reserved
Slide # 53
CSE7315M07
END OFMODULE 07
Auygust 10, 2004 CSE 7315 - SW Project Management /
Module 07 - Software Development PlansCopyright © 1995-2004, Dennis J. Frailey,
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