cse 7315 - sw project management / module 6 – initial planning copyright © 1995-2001, dennis j....

CSE 7315 - SW Project Management / Module 6 – Initial Planning Copyright © 1995-2001, Dennis J. Frailey, All Rights Reserved

Slide 1CSE7315M06

January 10, 2001

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

Software Project

Module 06Initial Planning

January 10, 2001 CSE 7315 - SW Project Management /

Module 6 – Initial PlanningCopyright © 1995-2001, Dennis J. Frailey,

All Rights Reserved

Slide # 2CSE7315M06

Goals of This Module• To provide a framework for

planning a software project• To examine the initial activities

involved in planning a software project



All Rights Reserved

Slide # 3CSE7315M06

A Quote on Planning“Plans are nothing, planning is everything.”

-- Dwight Eisenhower

“Plans are nothing” because: -- they represent a best guess based on

incomplete knowledge -- they are obsolete as soon as they are

complete

This does not mean plans should not be used.



All Rights Reserved

Slide # 4CSE7315M06

Plans Provide a Framework• A consistent starting point for all

participants– What to do– How to work together– What to expect

• A basis for organizing– Who needs to be involved

• A basis for allocating resources• A basis for deciding whether or not to

go ahead



All Rights Reserved

Slide # 5CSE7315M06

Golf Analogy• The first shot is aimed at the pin• It usually moves you in the right direction,

but it seldom gets you all the way there• That’s why you need a second shot• And a third• And a fourth• ....

• And a few extra golf balls



All Rights Reserved

Slide # 6CSE7315M06

“Planning is Everything” Because ...

Planning forces you to understand the issuesKnowledge

Knowledge helps you make better decisionsExpected developmentsUnexpected problems

With knowledge, you know when NOT to follow the plan, and why



All Rights Reserved

Slide # 7CSE7315M06

A Model of theManagement Process

Plan

Monitor

DoAssess SoftwareDevelopment



All Rights Reserved

Slide # 8CSE7315M06

Software Development

Another Model

Management Process

. . .



All Rights Reserved

Slide # 9CSE7315M06

Another Model

Management

Risk Management

Software Development



All Rights Reserved

Slide # 10CSE7315M06

Another Model

SoftwareDevelopment

Risk Managemen

tManageme

nt



All Rights Reserved


A Model That Mirrors the Software Development

Process

Definethe Approach

GenerateDetailed Plans

Understandthe Need

Execute andMonitor



All Rights Reserved


Expanding the Model with a Focus on Planning and Risk

Note that the cycle continues throughout the software development process

Manage Risks

Definethe Approach


Understandthe Need

Execute and Monitor



All Rights Reserved


Relationship to Course Modules

Manage Risks (Modules 24-26)

Definethe Approach(Modules 6-8)

GenerateDetailed Plans(Modules 9-23)

Understandthe Need

(Module 6)

Execute and Monitor (Modules 27-38)



All Rights Reserved


Initial Planning

Manage Risks (Modules 24-26)

Definethe Approach(Modules 6-8)

GenerateDetailed Plans(Modules 9-23)

Understandthe Need

(Module 6)

Execute and Monitor (Modules 27-38)

INITIAL PLANNING



All Rights Reserved


What Is Initial Planning?Goal: to scope out the project and plan

its execution so you can properly manage the software lifecycle

• Do this as soon as you start– proposal, contract, or any other starting

point• Update at periodic milestones and

events during execution– Whenever you may need to revisit and

change the plans



All Rights Reserved


Understand the NeedRisk Management

Definethe Approach


Understandthe Need

Execute and Monitor

• Identify Customer Needs

• Markets• Problem

Statement• Requirements• Expectations

• Know the Customer• Sponsor• End User• Intermediaries

• Know the Commitments

• Identify Risks

This process step is primarily one of

communicating with the customers and

documenting the needs



All Rights Reserved


Who is the Customer?

Legal Dept

End User

Software Manager

System Engineer

Program Mgr

Champion



All Rights Reserved


Eventually, you want to Align the Goals

Goal

Goal

Goal

GoalGoal

Goal

GoalGoalGoalGoal

Goal



All Rights Reserved


Process Chart

Job aids

• Market Analysis

• Commitment• Statement of

Work• Statement of

Requirements

• Tests• Expectations• Risks

Management insight & decisions

Business plans and objectives

TrainingFacilities

• Customer Needs

or• RFP or• Draft

SOW or• Product

Ideas

Understandthe Need

Research



All Rights Reserved


Statement of Work (SOW)A document or other artifact that

states what work is to be performed and what products are to be delivered. It defines

the requirements for the project and the process.



All Rights Reserved


Statement of WorkMay Also Include ...

• When (schedule, delivery dates)• Costs (budgets, spending profile)• Applicable standards• Methods, tools or even processes

to be usedA SOW is often used as the basis

for a contract because it indicates specific things to be

done



All Rights Reserved


Example SOW• Develop a spreadsheet program in the C+

+ language to run under Windows 2000• Deliver the following:– Source code– User’s guide– Load module of the spreadsheet– Operator’s guide– Installation guide



All Rights Reserved


Example SOWAdditional Contents

• Develop using workmanlike processes and methods [i.e., contractor’s choice but must be competent]

• Spreadsheet should meet the requirements contained in a separate specification

• Process used must be ISO9000 compliant



All Rights Reserved


Items Typically Found in a Contract but Not in a SOW

• Payments will be made as follows:– 10% at contract award– 40% at final design review– 40% at completion of qualification test– 10% after all defects found in first

month are fixed• Product must be delivered by June 30– 5% per month penalty after that date



All Rights Reserved


RequirementsStatement

Develop a spreadsheet tool that is better than Excel but looks and functions like it

SpecificationIn response to the “sort” command, the spreadsheet shall do the following:• ......• ......• ......



All Rights Reserved


Test Requirements

A document indicating how the product will be tested and what

constitutes acceptable performance



All Rights Reserved


Sample Test Requirements• The spreadsheet must pass the standard

spreadsheet test suite defined by TESTSRUS corporation

• The spreadsheet shall be run through each command and the screens will be inspected for proper color, speed, and readability

• The spreadsheet help command will be applied for each command listed in appendix 2 of the requirements statement and the resulting help information must be understandable by at least 80% of a panel of novice spreadsheet users ...



All Rights Reserved


Typical Requirements Flowdown

Transmission

System Analysis& Design

Allocated Requirement

s

Automobile

Drive Train ChassisEngine

100 pounds

torque ...

50 pounds

2000 pounds

500 pounds250 hp

...

Original Requirement

s

3000 pounds0-60mph in 9 sec



All Rights Reserved


Requirements Trace Mechanism

• Needed to connect the software requirements and design and to the original requirements as specified by a system designer or customer

Rqmt 2

Rqmt 3

Rqmt 1ElectricalRqmt aRqmt bRqmt cRqmt d

MechanicalRqmt aRqmt bRqmt cRqmt d

SoftwareRqmt aRqmt bRqmt cRqmt d

Allocation Process



All Rights Reserved


Possible Exam Questions Explain the difference between

a statement of work, a statement of requirements, and a list of acceptance tests

Explain the role of the requirements trace mechanism



All Rights Reserved


Typical Risks• See Appendix A for typical risks

from all initial planning activities discussed in this module



All Rights Reserved


Define the Approach

• Define the Key Project Elements

• Project Life Cycle• Organization• Schedules• Processes• etc.

• Identify Risks

Risk Management


Understandthe Need

Execute and Monitor

Definethe Approach

This planning step is where you design your project at the top level



All Rights Reserved


Process Chart

Define theApproach

• Project Lifecycle Model

• Integrated Master Plan & Schedule

• Organization Model

• Communication Model

• Initial SW Development Plan

• Risks

PEOPLE

MANAGEMENT APPROVAL

TRAININGFACILITIES

• Market Analysis

• Competitive Analysis

• SOW• Commitme

nt• Requireme

nts• Tests• Expectatio

ns• Prior

Phases• Risks

CONSENSUS



All Rights Reserved


Principal Outputs of Defining the ApproachProject Lifecycle Model

• The goal of the project• The phases of the project

lifecycle and where we are now• The goals of each phase, and• The characteristics of each phase

Prototype Demo Final Dev. InstallResearch ....Goal: build a working

prototype of the new database system

We are here



All Rights Reserved


Software Role in Developing the Project Lifecycle Model

• Ideal project– The project lifecycle model is defined by

project management.– The software manager must understand

and document the information for use in software planning.

• Typical project– The software manager must ask questions

and do research in order to get all of the information



All Rights Reserved


Prototype TaskObjective: Devise a prototype of the data base that utilizes the new object oriented data base engineEvaluation Criteria: Performance, response time, reliability, ...





Principal Outputs of Defining the ApproachIntegrated Master Plan (IMP)

A summary of the work to be done on the project:– All major project tasks– Significant accomplishments to be

attained in order to complete each task– Exit criteria for each task



All Rights Reserved


Software Role in Developing the Integrated Master Plan

• Ideal project– Participate in developing this plan– Make sure the top level software tasks are represented

properly– Document these for use in software planning.

• Typical project– May need to prod others to do their part in making this

plan



All Rights Reserved


Principal Outputs of Defining the ApproachIntegrated Master Schedule (IMS)

An overall project schedule that shows how the parts fit together– Task duration and timing– Key events and milestones– Expected dates – Dependencies among tasks

Such a schedule is typically very large



All Rights Reserved


PrototypeFinal Design

BuildDesign


BuildDesign


BuildDesign


BuildDesign

The Key is to Show How The Whole Project Interacts


BuildDesign


BuildDesign


BuildDesign

CodeDesign Test

Build

DeliveryContract


BuildDesign


BuildDesign

The tasks in the IMS should be the same top-

level tasks that are included in the IMP



All Rights Reserved


Warning from Dilbert“For large projects, team leaders

use sophisticated project management software to keep track of who’s doing what. The software collects the lies and guesses of the project team and organizes them

into instantly outdated charts that are too boring to look at closely.

This is called ‘planning.’” Adams, The Dilbert Principle



All Rights Reserved


Software Role in Developing the Integrated Master Schedule

• Ideal project– Participate in developing this schedule, – Make sure the top level software tasks are represented

properly, and – Document these for use in software planning.

• Typical project– May need to prod others to do their part in making this

schedule



All Rights Reserved


Principal Outputs of Defining the ApproachOrganization Model

A picture of how the project is organized .. the organizational breakdown structure or OBS – Who reports to whom on this project (*)– The overall responsibility of each

project entity– How the different entities depend on

and interface each other(*) Not necessarily the same as who reports to whom overall



All Rights Reserved


Organizational Breakdown Structure

Manager

ChiefEngineer

ContractAdministration

SupportManagerAccounting

ElectricalDesign

Manager

MechanicalDesign

Manager

SoftwareDevelopment

Manager

Team forProduct n

Team forProduct 1 ..

..

Software Manager’s Primary Responsibility



All Rights Reserved


A Team-Oriented Organizational Breakdown

StructureCustomerInterface

ProductEngineering

ContractAdministration

SupportEngineering

Accounting

Team forProduct 2

Team forProduct n

Team forProduct 1

..

..

Engineering Team

Program Management Team

Software Manager’s Responsibility

(may need to convince PM to have an overall sw

manager)



All Rights Reserved


A Typical Organizational Problem

Company B

Project

B’s Specialty

Company A

OtherA’s Specialty

Other

JointResponsibility

May need to besure there is a

workablerelationship



All Rights Reserved


Software ResponsibilitiesMake sure you know whom you

depend on and who depends on you.– Develop an interdependency

checklist to show all “independent” activities on which software depends or that software depends on

– The purpose of this is to make you and others aware of how software is affected by other parts of the project



All Rights Reserved


Software Depends on ...Software Depends On:Item Due Must have byEmulator Build 3/5 4/1Keyboard Prototype 5/316/15Numeric Keypad SW 6/307/1These are the items you must track

closely, as they can endanger your schedule



All Rights Reserved


Software Impacts ...Software Impacts:Item Due LatestKeyboard Final 7/5 8/1Design

These are items you must also track closely, as your slips can

endanger them and perhaps the whole project



All Rights Reserved


Principal Outputs of Defining the ApproachCommunication Model

This can be thought of as a more detailed model of the organization, focusing on how things will really happen:– The individuals and organizations involved – Who has what responsibility and authority– How communication will occur



All Rights Reserved


More from Dilbert ...

“The real objective of business communication is to advance your career. That objective is

generally at odds with the notion of ‘clear transfer of information’”

Adams, The Dilbert Principle



All Rights Reserved


Communication Model TasksIdentify the key functions of each entity and the entities

they must communicate with

Functional Responsibility Chart - SW Engineering

Function Communicates With Contact Individual

Design Customer Rep Colonel Pete SmithEnd User Rep. PFC B. BaileySystem Engineering Brad ManlyTest Engineering Jane Workhard

Coding Customer Rep Colonel Pete SmithField Test Rep Captain Joe DangerHardware Engineering Dolores Dooright

etc.



All Rights Reserved


Identify Interfaces and Authority

WHY DO THIS? - To identify missing interfaces - To reduce misunderstandings

From To Description/AuthorityTech Supervisor End User Technical Design Info No Contractual Commitments Legal Department SubcontractorLegal Contracts No Technical Commitments etc.

During the “heat of battle” is not the time to resolve such

issues



All Rights Reserved


Principal Outputs of Defining the ApproachSoftware Process and Other Initial Parts of the Software

Development Plan

These will be discussed in modules 7 and 8



All Rights Reserved


Note• These are initial estimates• These are not detailed plans• The purpose is to let you scope out

the extent of the project:– What is to be done– By whom– When– With what information and tools and

people



All Rights Reserved


These Are All Developed Together

These analyses

occur concurrently and they feed each

other

MasterSchedule

CommunicationOrganization

SoftwareDevelopment

Plan

ProjectLifecycle

MasterPlan



All Rights Reserved


Past, Present and Future• Once you determine the overall project lifecycle

and phase structure, you should apply these techniques in the following fashion:

- Prior Phase Gather History and Lessons Learned- This Phase Develop Plans in Detail- Next Phase General Plans- Next Phase Sketch Out Plans

If you are using a non-sequential lifecycle, this needs to be modified

accordingly



All Rights Reserved


Fitting the Project LifecyclePhase 2 Phase 3Phase 1

When you are in

phase 2

When you are in

phase 1

etc.

Complete, Detailed

Plans

Sketchy Plans

History, Lessons Learned

General Plans

General Plans

Complete, Detailed

Plans



All Rights Reserved


Possible Exam Question

Explain the activities and the results of initial planning. Describe at least two outputs of initial planning and, for

each, give an example, explain why it is needed, and explain how it is generated



All Rights Reserved


Summary of Module• Base your initial plan on the

scope of the project– What are the project goals and what

kind of software has to be developed?

– What other parts do you depend on and what depends on you?

– What are the key roles and responsibilities of people and orgizations?


Slide 61CSE7315M06

January 10, 2001

Appendix A

Typical Risks from Initial Planning



All Rights Reserved


Typical Risks - Understand the Need

• Cannot decide what to do or what to deliver

• Requirements are too vague• Tests not stated or not understood• Technology may not be adequate• Schedules may not be feasible• Costs may be prohibitive or uncertain• Domain knowledge may be lacking– I.E., we don’t know how to do it– Need to go outside for information



All Rights Reserved


Typical Risks - Define the Approach

• The goals and requirements are unclear or conflicting– Estimates will be inaccurate

• Too many design ideas too soon– Focus on needs, requirements, and

problems• Vague details– especially for near-term tasks

… continued



All Rights Reserved


Typical Risks (continued)• Unrealistic optimism– Are we really this far along?– Can we really do it?

• Unrealistic pessimism– Leads to perennial research

• Evaluation criteria are vague– Can lead to incomplete testing or

failure to meet expectations… continued



All Rights Reserved


Typical Risks (continued)• Expectations of senior managers or

customer sponsors are inconsistent with reality– Must be negotiated to achieve consensus

• Expectations of technical staff are too conservative– Potential for “analysis paralysis”– See above

… continued



All Rights Reserved


Typical Risks (continued)• Unknowns in all areas• External dependencies– Some not identified– Some not under good control– Some involve unclear responsibility

• Unknown risks for individual parts of the project– Eg: is the keyboard emulator a high

risk item?… continued



All Rights Reserved


Typical Risks (continued)• Breakdown into subprojects is

inaccurate or vague or unsuitable– Eg: key, high risk task under control

of inexperienced staff• Dependencies not communicated

to affected parties• Legal issues -- who owns this code?– Especially if code is reused

… continued



All Rights Reserved


Typical Risks (continued)• Inadequate control of internal

dependencies– “We trust our own organization, so we

don’t need to manage it”• Boundaries determined by political

factors– Incompetent subcontractors– Irrational division of work

… continued



All Rights Reserved


Typical Risks (continued)

• Structure of some organization is unclear– Who does Joe Smith report to?– Two people both claim responsibility for testing

• Functions and responsibilities are unclear– Who is responsible for approving contract

changes?– Who has authority to increase the budget?

… continued



All Rights Reserved


Typical Risks (continued)• Responsibility and authority not defined• Responsibility shared (= responsibility

not defined)• Critical interfaces are missing– “We have not identified who should provide

technical info on the stabilizer module”• Potential for unauthorized commitments• Potential for failure to perform

important functions


Slide 71CSE7315M06

January 10, 2001

Appendix B

Defining the Approach for a Small Project



All Rights Reserved


Project Lifecycle

DevelopFinal Product MaintainDevelop

Prototype

18 mos

10 yrs

Software Passes Formal

Tests

6 mos

Customer Retires

Customer Likes Behavior

Schedule

Subgoals & Milestones



All Rights Reserved


Risks Identified• Professor’s ideas are vague (this is

why you chose a prototype phase)• Details of implementation are unclear

(another reason for the prototype)• PC may be inadequate• Professor is too cheap to pay for the

work– Have early milestones and deliverables

with specific payments required


Slide 76CSE7315M06

January 10, 2001

Appendix C

Considerations for U.S. Government Contracts



All Rights Reserved


Commonly Used Documents in US Government Contracts

• SSS (System/Segment Spec)– System Requirements

• SSDD (System/Segment Design Document)– Allocation of Requirements & Requirements Trace

Matrix• SRS (SW Requirements Spec)– Detailed specifications for those requirements

allocated to the software• IRS (I/F Requirements Spec)– Detailed specifications for the interfaces between

software products and the rest of the system