cse 7315 - sw project management / module 8 - software development plans part 2 copyright ©...

CSE7315M08

January 10, 2001

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

Software Project

Module 08Software Development Plans

Part 2

January 10, 2001

CSE 7315 - SW Project Management / Module 8 - Software Development Plans

Slide # 2

CSE7315M08

Objective of This Module

• To discuss some of the specific contents of a software development plan

Note that subsequent modules discuss other material that goes into a software development plan

January 10, 2001

Slide # 3

CSE7315M08

Outline

• Project Information– Methods and Tools– Facilities and Staffing

• Process Information– Software Development Process– Documentation Plans– Reviews and Audits

CSE7315M08

January 10, 2001

Selecting Methods and Tools

January 10, 2001

Slide # 5

CSE7315M08

Reliable,Proven

Tools andMethods

Innovative,Improved

Toolsand Methods

January 10, 2001

Slide # 6

CSE7315M08

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

January 10, 2001

Slide # 7

CSE7315M08

But Newer Tools and Methods 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

January 10, 2001

Slide # 8

CSE7315M08

Sometimes Your Customer or Program 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

January 10, 2001

Slide # 9

CSE7315M08

• Give the issues some thought• Do trade studies • Get input from previous users of

the new methods and tools• Consider using newer techniques

on small, prototype efforts before applying to major projects

Your Job is to Deliver the Software On Time and On Budget

January 10, 2001

Slide # 10

CSE7315M08

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?

January 10, 2001

Slide # 11

CSE7315M08

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

January 10, 2001

Slide # 12

CSE7315M08

A Typical Tool Chart in a Software Development Plan

Phase Tool Vendor Purpose

Design OOPlus Objectco OO Design

Coding J avaXBugout

Maxisof tWefi xit

ProgrammingDebugging

Testing Testgen Maxisof t Test Gen.

… … … …

CSE7315M08

January 10, 2001

Facilities and Staffing Plans

January 10, 2001

Slide # 14

CSE7315M08

You Must Plan Reasonable Staff Acquisition and Use

Patterns

1 2 3 4 5 6

Unrealistic

1 2 3 4 5 6

More Realistic

January 10, 2001

Slide # 15

CSE7315M08

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

January 10, 2001

Slide # 16

CSE7315M08

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

January 10, 2001

Slide # 17

CSE7315M08

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

CSE7315M08

January 10, 2001

Process Information

CSE7315M08

January 10, 2001

The Tailored Software Process

January 10, 2001

Slide # 20

CSE7315M08

Document the Process

• You should document the process so that everyone has the same roadmap of what to do– A generic model that your

organization can use as a starting point for tailoring

– Your specific, tailored process, so people on the program know what to do

January 10, 2001

Slide # 21

CSE7315M08

Software Process DefinitionConvert the steps of the software lifecycle model, identified during the environment analysis, into a detailed process

Integration & TestDesign CodingRequirements

Unit TestWrite

Test CodeWrite Code

CodeWalkthrough

Lifecycle (Top

Level of SW

Process)

More Detailed Software Process

January 10, 2001

Slide # 22

CSE7315M08

The Process Definition Concept

All Possible Software Lifecyclesand Processes

High Level Process(Software Lifecycle)

Specific Software Process

Define/tailor the process

Initial Planning

January 10, 2001

Slide # 23

CSE7315M08

Process Tailoring

• Start with a standard process or an otherwise-selected process model

• Delete unnecessary artifacts and tasks– e.g., for a prototype that is not deliverable,

delete formal tests or documents

• Change the scope of artifacts and tasks– e.g. incremental development lifecycle

might require delivering the design specs only once

– With a “clean room” process, reduce testing

January 10, 2001

Slide # 24

CSE7315M08

Risks of Tailoring• Deleting a task and failing to

determine who depends on its outputs• Deleting an artifact and failing to

determine who uses it and why• Deleting something because you don’t

know why it is there– If you don’t know why, you don’t know

what damage you may do by deleting– This is a difference between level 1 and

level 3 maturity

January 10, 2001

Slide # 25

CSE7315M08

Avoiding Risks in Process Tailoring

• Organizational process documentation should indicate – WHY a task is there and who depends on it– WHY an artifact is there and who needs it– List the risks of deleting or modifying a task

or an artifact– Suggest tailoring approaches for specific

situations• e.g. “If you are doing non-deliverable software,

this formal inspection might be replaced by an informal walkthrough”

January 10, 2001

Slide # 26

CSE7315M08

Document YourTailoring Decisions

• Why each change was made• Additional risks that must be

monitored as a result of tailoring– Example: we removed the design

review due to short program schedule and good design defect experience on the previous project• we must monitor defects during coding to

validate that this did not cause trouble

January 10, 2001

Slide # 27

CSE7315M08

Example of Tailoring Documentation

Tailoring ChecklistStep Tailoring Rationale... ... ...Design Review Do Incrementally Iterative ProcessWalkthrough None NA... ... ...Artifact Tailoring Rationale... ... ...Design Spec Do On-Line More Accurate, Lower $Test Report Summary Only Non-deliverable SW... ... ...

CSE7315M08

January 10, 2001

See Appendix A ...

… for hints and suggestions on documenting a process

Also see SOW for SDP (assignment 5)

CSE7315M08

January 10, 2001

Documentation Plans

January 10, 2001

Slide # 30

CSE7315M08

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

January 10, 2001

Slide # 31

CSE7315M08

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

January 10, 2001

Slide # 32

CSE7315M08

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

January 10, 2001

Slide # 33

CSE7315M08

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

January 10, 2001

Slide # 34

CSE7315M08

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

January 10, 2001

Slide # 35

CSE7315M08

Documentation for Softwareis 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)

January 10, 2001

Slide # 36

CSE7315M08

Your Documentation Plan is Part of your SW Development

Plan• It should explain the artifacts to be

produced, their origins, and their uses• 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??

January 10, 2001

Slide # 37

CSE7315M08

Sample Table of Artifacts

Artif act Producedby

Used by Controlledby

Format

RqmtsSpec

AnalyzeSW Rqmts

DesignSW

SW SystemEngineering

SourceCode

Code SW TestSW

SW CM TextFiles

January 10, 2001

Slide # 38

CSE7315M08

Documentation is Part of the Configuration

Documentversion 3.5

Softwareversion 3.5

Documentversion 3.4

Softwareversion 3.4

You must keep them synchronized

January 10, 2001

Slide # 39

CSE7315M08

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 B for examples of software project artifacts

January 10, 2001

Slide # 40

CSE7315M08

Planning Reviews and Audits

January 10, 2001

Slide # 41

CSE7315M08

ReviewsPurpose:– To learn the status of the project

Performed by:– Managers or Peers

Method:– Practitioners report on the status and

plans of their projects, following specified formats and reporting on specific metrics

January 10, 2001

Slide # 42

CSE7315M08

Reviews (continued)

Typical Duration:– A few hours to several days

Achieves:– Uncovers problems (or, at least, symptoms)

Drawbacks:– Does not always identify solutions– May motivate hiding of problems• Avoid punishing the messenger if you want to

get an accurate message

January 10, 2001

Slide # 43

CSE7315M08

Advantages of Reviews

• Reviews are relatively inexpensive– Standardize how they are done so

people know exactly what to prepare– Make it easy to prepare for a review

by making normal work products a natural part of the review

• Reviews tend to get everyone back on the same track

January 10, 2001

Slide # 44

CSE7315M08

Three Categories of Reviews1) Phase or Milestone Reviews (Gates)– Held at major milestones– Ensures that the project is ready to move to

the next phase

2) Status Reviews– Held periodically, frequency driven by risk • Typically 1-week to 4-month intervals

– Ensures that everyone knows current status

3) Peer Reviews and Inspections– Designed to evaluate a specific development

artifact

January 10, 2001

Slide # 45

CSE7315M08

Phase or Milestone Reviews (Gates)

• Provide a forum to understand– the state of the project and product– at a point where the direction can be

altered or refined

• A quality control checkpoint for the project team and organization

• Typically attended by senior management and external organizations and maybe the customer

January 10, 2001

Slide # 46

CSE7315M08

Topics Covered in a Phase Review

• Major accomplishments and plans• Actions needed for phase completion• Variances from estimates and plans• Problems that are impacting quality,

cost and the schedule • High-risk areas that need attention• Problems or lessons learned that

could impact later phases

January 10, 2001

Slide # 47

CSE7315M08

Status Reviews• A team progress review• Provide a forum to identify and raise

issues and problems (technical and schedule) as early as possible

• Focused on near-term issues and actions (perhaps sensitive ones)

• Typically attended mostly by the people working directly on the software project

January 10, 2001

Slide # 48

CSE7315M08

Topics Covered in aStatus Review

• Accomplishments since previous review• The original plan vs actual performance• The critical path of the project• High-risk areas that need attention • Problems that are impacting quality, cost

and the schedule • Status of action items (open & closed)

January 10, 2001

Slide # 49

CSE7315M08

Topics Covered in a Status Review - For the Next Period

• The plan– Possibly revised during the review

• New action items– Assignments– Dates due– Who will track to closure

January 10, 2001

Slide # 50

CSE7315M08

Peer Reviews and Inspections

• Provide a way to evaluate specific artifacts– designs, code, test code, etc.

• Typically attended only by peers of the person whose work is being evaluated

January 10, 2001

Slide # 51

CSE7315M08

Why Only Peers?

• This approach is designed to foster free and open discussion– The supervisor’s presence tends to

inhibit open discussion, often in ways that are not evident to participants

• Often a facilitator or quality assurance representative will participate– To keep everyone focused and to

record findings and action items

January 10, 2001

Slide # 52

CSE7315M08

Issues Regarding Peer Reviews & Inspections

• You must foster a culture where people actively participate in the reviews and inspections of others– Include this in how you evaluate them– Include time in the schedule– Don’t count their work done until they

have participated in others’ peer reviews

• There are many methods available– Select methods that fit your team

CSE7315M08

January 10, 2001

Audits

January 10, 2001

Slide # 54

CSE7315M08

AuditsPurpose:– To study a project in detail and find

problems that may not be evident

Performed by:– Independent technical experts, often

outsiders

Method:– Experts question practitioners and

examine artifacts of their process to determine what is happening

January 10, 2001

Slide # 55

CSE7315M08

Audits (continued)Typical Duration:– Several days to several weeks

Achieves:– Uncovers problems not seen by insiders– Informs staff that management cares about

the results

Advantages:– Tends to uncover real problems– Tends to confirm or disprove suspected

problems

January 10, 2001

Slide # 56

CSE7315M08

You don’ttrust us!

Drawbacks of Audits

• More expensive than reviews• Do not usually identify solutions• May motivate hiding of problems• Can generate hostility and lack of

cooperation or de-motivation• Outsiders often do not

understand subtle issues– even if they do, they are not

always believed

January 10, 2001

Slide # 57

CSE7315M08

When and How to Plan for Audits

• Use audits at points when verification and validation are important– Such as before shipping a product or

after making substantial progress

• Use audits sparingly, but regularly– An audit should not be viewed as a sign

that you suspect trouble– It should be treated as a normal part of

doing a high quality job• Like a regular medical checkup

January 10, 2001

Slide # 58

CSE7315M08

Get the Practitioners Involved• Have the practitioners identify the

right times for audits– Use them as a way to validate their

work– Remind them that athletes and artists

rely on coaches and critics

• Have practitioners participate in audits of other projects– Let periodic audits become part of the

culture

• Don’t punish people for problems found during audits

January 10, 2001

Slide # 59

CSE7315M08

Summary• There are many possible topics to

be covered in a software development Plan

• We have covered some of the more common ones here

• But there may be many others• Base your Plan on what your project

January 10, 2001

Slide # 60

CSE7315M08

END OFMODULE 08

CSE7315M08

January 10, 2001

Appendix A

Examples and Considerations for Defining a Process

January 10, 2001

Slide # 62

CSE7315M08

Examples of Process Definitions

A computer program documents a process for a computer to carry out

» declarations define inputs and outputs

» executable statements define activities and tasks

» ordering of statements, sequence and control statements define the relationships

FUNCTION X(A,B)REAL A; INTEGER BIF A < 2.3 THEN B = B + 1ELSE B = 0ENDIFRETURN

January 10, 2001

Slide # 63

CSE7315M08

Flow Charts» Boxes define tasks» arcs and diamonds define relationships,

sequencing» circles sometimes show external inputs and

outputs, although flowcharts are deficient in showing internal artifacts

January 10, 2001

Slide # 64

CSE7315M08

Data Flow Diagrams

DesignWalkthrough

Design

Specification

DesignSoftware

errors

CMLibrary

» Boxes and circles define tasks» arcs and data boxes define artifacts, data flow» ordering defines relationships, dependencies

(Note parallelism)

January 10, 2001

Slide # 65

CSE7315M08

Considerations forProcess Documentation

• Who will use the process description?– You may need several different

formats for different classes of users

• Highly formal process descriptions (e.g., petri-nets) tend to be poor for practitioners but good for doing analysis of processes

January 10, 2001

Slide # 66

CSE7315M08

Considerations forProcess Documentation

• Who will use the process description?– You may need several different formats

for different classes of users

This is probably the single most important consideration when deciding

how to document a process.

January 10, 2001

Slide # 67

CSE7315M08

Considerations (continued)• What supplementary information is

needed? Some common information includes:– A data dictionary to supplement a data

flow diagram– An artifact trace to show the complete

history of each specific artifact– An input/output cross reference to

show where each input comes from and where each output is used

January 10, 2001

Slide # 68

CSE7315M08

Considerations (continued)• Processes tend to be large and complex–At the detail level, you need to discuss

subsets and views of the process–This is like using “cross sections” of a large,

complex molecule to understand its chemistry–Consider highlighting the parts of the

process that are under discussion–Or consider using different colors for parts of

the process that different groups are responsible for

January 10, 2001

Slide # 69

CSE7315M08

Considerations (continued)

• Give examples of process documentation in proposals, plans, etc.• Processes focus on WHAT, not

HOW–You may need to supplement with

“how to” details for practitioners

CSE7315M08

January 10, 2001

Appendix B

Artifacts Typically Generated during Software Development

January 10, 2001

Slide # 71

CSE7315M08

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

January 10, 2001

Slide # 72

CSE7315M08

Artifacts Commonly Used during Software DevelopmentPossible 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

January 10, 2001

Slide # 73

CSE7315M08

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

January 10, 2001

Slide # 74

CSE7315M08

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)

January 10, 2001

Slide # 75

CSE7315M08

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

January 10, 2001

Slide # 76

CSE7315M08

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

January 10, 2001

Slide # 77

CSE7315M08

Artifacts (continued)Artifacts Produced by Software

Requirements Analysis -- Software Test Requirements -- Algorithm Descriptions (for

embedded and scientific applications)

January 10, 2001

Slide # 78

CSE7315M08

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

January 10, 2001

Slide # 79

CSE7315M08

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.

January 10, 2001

Slide # 80

CSE7315M08

Artifacts (continued)Artifacts Produced by Implementation

-- Software– Source Code, Source Listings, Object Code,

-- Test Procedures and Code– Source and object code of Tests and Test

Data– Procedures for carrying out the Tests

January 10, 2001

Slide # 81

CSE7315M08

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

January 10, 2001

Slide # 82

CSE7315M08

Artifacts Produced by Software Integration

-- More Test Procedures and Code -- More Test Reports -- Installation Guides -- Maintenance Documentation -- Support Documentation -- etc.

cse 7315 - sw project management / module 8 - software development plans part 2 copyright ©...

Documents

january 20, 2000 cse 7315 - sw project management / chapter...

cse 8314 - sw measurement and quality engineering copyright ...

cse 7315 - sw project management / module 30 - managing with...

copyright 1995-2008, dennis j. frailey cse7315 – software...

computer science in the early years dennis j. frailey purdue...

february 15, 2004 software risk management copyright ©...

copyright 1995-2009, dennis j. frailey cse7315 – software...

copyright 2003-2013, dennis j. frailey software engineering...

january 20, 2000 cse 7315 - sw project management / chapter...

cse 7315 - sw project management / module 20 - more effort...

cse 7315 - sw project management / module 07 - software...

february 2, 2000 cse 7315 - sw project management / chapter...

ut dallas measuring software quality · copyright 2017,...

cse 7315 - sw project management / module 35 - software...

cse 7315 - sw project management / module 14 - size...

january 20, 2000 cse 7315 - sw project management / chapter...

dennis j. frailey may 28, 2009 djfrailey@raytheon...

cse 7315 - sw project management / module 26 - risk...

copyright © 1995-2004, dennis j. frailey, all rights...

cse 7315 - sw project management / module 31 - software...