[ppt]powerpoint presentation - homepage | wiley · web viewproject risk assessment 9. project...

2PROJECT MANAGEMENT

Software Engineering Roadmap: Chapter 2 Focus

Plan

project

Integrate

& test system

Analyze

requirements

Design

Maintain

Test units

Implement

Corporate

practices

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Software Engineering Roadmap: Chapter 2 Focus

Development

process

- when to do what phase

- document: SPMP

Management structure

- hierarchical, peer,...

Risk identification

& retirement

Plan

project

Integrate

& test system

Analyze

requirements

Design

Maintain

Test units

Implement

Corporate

practices

Development

phases

Schedule

Cost estimate

SPMP


Learning Goals of This Chapter

Understand the term project managementOrganize teamsSpecify project management plansDefine and retire risksEstimate costs very early in the life cycleCreate high level projects schedulesWrite a Software Project Management Plan


1. Introduction to project management

The Variables of Project Management

Can somewhat vary the following factors.

1. The total cost of the project,

e.g., increase expenditures

2. The capabilities of the product,

e.g., subtract from a list of features

. . . . .


The Variables of Project Management

Can somewhat vary the following factors.

1. The total cost of the project,

e.g., increase expenditures

2. The capabilities of the product,

e.g., subtract from a list of features

3. The quality of the product,

e.g., increase the mean time between failure

4. The date on which the job is completed.

e.g., reduce the schedule by 20% e.g., postpone project's completion date one month


Bullseye Figure for Project Variables

cost

capability

duration

defect

density

Target :

$70K

Target :

30 wks

Target :

4 defects/Kloc

Target:

100%


Bullseye Figure for Project Variables

cost

capability

duration

defect

density

Target :

$70K

Actual:

100%

Target :

30 wks

Target :

4 defects/Kloc

this

project

Actual:

1 defect/Kloc

Actual:

20 wks

Actual:

$90K

Target:

100%


RoadMap for Project Management

1. Understand project content, scope, & time frame

2. Identify development process

(methods, tools, languages, documentation and support) -- section 4 of chapter 1

3. Determine organizational structure

(organizational elements involved) -- see section 3

4. Identify managerial process

(responsibilities of the participants) -- see section 3 of case study 1 at end of chapter

. . . . .


RoadMap for Project Management

1. Understand project content, scope, & time frame

2. Identify development process

(methods, tools, languages, documentation and support) -- section 4 of chapter 1

3. Determine organizational structure

(organizational elements involved) -- see section 3

4. Identify managerial process

(responsibilities of the participants) -- see section 3 of case study 1 at end of chapter

6. Develop staffing plan -- see section 3.5 of case study 1

5. Develop schedule

(times at which the work portions are to be performed) -- see section 6

7. Begin risk management -- see section 4

8. Identify documents to be produced -- see SQAP 4.2

9. Begin process itself -- described in chapters 3-10


2. Managing people

Plan and Execute Meetings

1.* Distribute start time, end time, and agenda with approximate times (see figure tbd)

list important items first

2.* Ensure strawman items prepared

3. Start on time

4. Have someone record action items

5. Have someone track time & prompt members

6. Get agreement on the agenda and timing

7. Watch timing throughout, and end on time

allow exceptions for important discussionstop excessive discussion; take off line

8. Keep discussion on the subject

9.** E-mail action items & decision summary.

* in advance of meeting actions members must perform ** after meeting


Specify Agendas

1. Get agreement on agenda & time allocation

2. Get volunteers to :

record decisions taken and action items

watch time and prompt members (see figure tbd)

3. Report progress on project schedule -- 10 mins

4. Discuss strawman artifact(s) -- x mins

5. Discuss risk retirement -- 10 mins

metrics and process improvement?

n. Review action items -- 5 mins


3. Options for organizing personnel

Optimal Size for Interaction (Approximate)

Number of people with whom developer must frequently interact

Developer communicates regularly with no one.

No communication time lost, but developer is too isolated and has no help.

Key:

= engineer

3

Effectiveness per developer


Optimal Size for Interaction (Approximate)

Number of people with whom developer must frequently interact

Developer communicates regularly with eleven people.

Communication time outweighs benefits of interaction

Developer communicates regularly with no one.

No communication time lost, but developer is too isolated and has no help.

Key:

= engineer

Approximate

optimal range

3

7

Effectiveness per developer


Hierarchical Project Management Organizations

Larger Projects:

Smaller Projects:

No separate Marketing?

No separate QA organization?

Subdivide QA into testing, ?

Subdivide Engineering into

system engineering, ?


72.bin

Horizontal Project Management Organizations

Gil Warner

Team leader

Ian Corliss

Team member

Nel Tremont

Team member

Fran Smith

Team member

Team facilitator?


Organize a Team

1. Select team leader: responsibilities:

ensure all project aspects activefill all gaps

3. Designate leader roles & document responsibilities

team leader: proposes and maintains SPMP

configuration management leader:... SCMP

quality assurance leader: ... SQAP, STP

requirements management leader:... SRS

design leader: ... SDD

implementation leader: ... code base

2. Leaders responsibilities:

propose a strawman artifact (e.g. SRS, design)seek team enhancement & acceptanceensure designated artifact maintained & observedmaintain corresponding metrics if applicable

4. Designate a backup for each leader as per


Peer Organizations for Larger Projects

Team of leaders


Table 2.1 Matrixed organization

Table 2.1 Matrixed organization

4. Identifying and retiring risks

The Four Risk Activities

(1) Identification

Mindset: try to continually identify risks

(2) Retirement planning

(3) Prioritization

(4) Retirement or mitigation


Risk Sources Ordered by Importance (Keil, Cule, Lyytinen, Schmidt)

1. Lack of top management commitment

2. Failure to gain user commitment

3. Misunderstanding of requirements

4. Inadequate user involvement

5. Failure to manage end-user expectations

6. Changing scope and/or objectives

7. .

Sources of Risk

In identifying the sources of project risk , you can first include all of the sources of uncertainty mentioned earlier in this chapter, such as misapprehension of scope and changes in requirements. Some of these cant properly be laid to rest until they are actually attempted, but crucial parts can be attacked early on. For example, with persistent communication, the core of the customers scope expectations can be discerned at this point.

The figure lists several sources of risk. One of these is tools such as design automation. Tool vendors can go out of business, discontinue support for the tool versions etc. (Indeed, this is one reason that computer-aided software engineering tools did not catch on in the 1980s.) The mobility of software personnel is another source of risk.

The Risk Management Mindset

Project

finish

Project

start

Identification

Retirement

2. Java skills not high enough.

1. May not be possible to superimpose images adequately.

1. Retirement by conquest: Demonstrate image super- imposition

Risk 1

Risk 2

Risk 1

Project

finish

Risk 2

2. Retirement by avoidance: Use C++

Project

start

Graphics reproduced with permission from Corel.


Table 2.2 A way to compute risk priorities


Table 2.3 Sample Risk Analysis for Encounter Case Study


Identify and Retire Risks

1.* Each team member spends 10 mins. exploring his or her greatest fears for the projects success

2.* Each member specifies these risks in concrete language, weights them, writes retirement plans, (see format above) & e-mails to the team leader

3.* Team leader integrates and prioritizes results

4.M Group spends 10 mins. seeking additional risks

5.M Team spends 10 mins. finalizing the risk table

Designates responsible risk retirement engineers

6.** Responsible engineers do risk retirement work

7.M Team reviews risks for 10 mins. at weekly meetings

responsible engineers report progressteam discusses newly perceived risks and adds them

*:in advance of first meeting M: at meeting **: between meetings

5. Choosing development toolsand support

Potential CASE Tool Components

To support project managementschedulework breakdownTo support configuration managementFor managing requirements

For drawing designsfunctionalobject-orienteduse-case-basedTracing toolsrequirements to designsdesigns to codeTo support testing To support maintenance



Example of Build vs. Buy Decision-making: Game Graphics engine

Build costBuy cost Comments

(in thousands) multi-year costs not accounted for

Supplies $ 0$40 Purchase Ajax engine

First-person perspective $ 5$ 0 Ajax has this feature

3-D $10$ 1 Customize Ajax application

Light reflection $15$10 Customize Ajax application

______ _________________

TOTALS$30$51

Build, do not buy


Table 2.4 Example of method for deciding language choice


6. Creating schedules: high level planning

High Level Task Chart with Fixed Delivery Date:Order of Completion

Month 1

1

2

3

4

Month 2

1

2

3

4

Month 3

1

2

3

4

Month 4

1

2

3

4

Month 5

1

2

3

4

Milestones

(1*) Delivery

Begin system testing

Iteration 1

Iteration 2

(6)

(4)

(3) Freeze requirements

Risk identification & retirement

(5)

* Indicated the order in which the parts of this table were built

SCMP complete

SQAP complete

SPMP rel. 1 complete

(2)

Prep. for maintenance


Create an Initial Schedule

1. Indicate the milestones your must observe

usually includes delivery date

2. Back these up to introduce the milestones you need

e.g., begin system testing well before delivery

3. Designate a time at which all requirements frozen

The remaining steps depend on the process used. We will assume an iterative process.

4. Show first iteration: establishes minimal capability

usually: keep it very modest, even trivial, in capabilitybenefit: exercises the development process itself

5. Show task of identifying & retiring risks

starting from project inception

6. Show unassigned time (e.g., week) near middle?

7. Complete the schedule


Level Labor Allocation for Fixed Labor Total

Month 1

1

2

3

4

Month 2

1

2

3

4

Month 3

1

2

3

4

Month 4

1

2

3

4

Month 5

1

2

3

4

Milestones

Release to production

Complete testing

Iteration 1

Iteration 2

Freeze requirements

Risk ID & retire

2

2

2

3

2

2

3

2

2

2

1

1

1

4

4

4

3

3

4

4

4

4

4

4

3

3

4

4

4

4

3

3

4

4

4

4

4

4

4

4

4

4

4

4

4

Given team size:

To be assigned

4

Hal

vacation

Karen

vacation


7. Integrating legacy applications

Legacy System Integration

Resulting system

Legacy

system

New

features

New

application

Add new features (typically using same language)

or Change features (e.g., port to new environment)

Build new application

that uses legacy system

(possibly using different language)

Legacy

system

Repairs


8. Estimating costs: early calculations

Range of cost estimates after conceptualization phase,based on actual cost of $1

Integration/Test

Design

Implementation

Requirements

analysis

$1

25c

$4

$1

$1

$1

$1

Conceptual-

ization

phase

Range of cost estimates after requirements analysis phase

Range of Errors in Estimating Eventual Cost


Typical Cost Estimation Roadmap

1A. Use comparisons with past jobs to estimate cost & duration directly or to estimate lines of code.

and / or

1B. Use function point method to estimate lines of code

1B.1 Compute un-adjusted function points.

1B.2 Apply adjustment process.

2. Use lines of code estimates to compute labor and duration using COCOMO formulas.


Function Point Computation for a Single Function (IFPUG)

Function

External Inputs (EI)

External Inquiries (EIN)

External Outputs (EO)

file

External Logical Files (ELF)

file

file

Internal Logical Files (ILF)*

* Internal logical grouping of user data into files

Logical

group of

user data

Logical

group of

user data

Logical

group of

user data

Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process)

Ext. inputs EI 3 or 4 or ... 6 = ___

Ext. outputs EO 4 or 5 or ... 7 = ___

PARAMETER simple complex

countTotal

Function Point Computations (IFPUG) (Unadjusted -- to be followed by applying adjustment process)

Ext. inputs EI 3 or 4 or ... 6 = ___

Ext. outputs EO 4 or 5 or ... 7 = ___

Ext. inquiries EIN 3 or 4 or ... 6 = ___

Ext. logical files ELF ... 5 or 7 or ... 10 = ___

Int. logical files ILF ... 7 or 10 or ... 15 = ___

PARAMETER simple complex

countTotal

Unadjusted Function Point Computation for First Encounter Functions:Set up Player Character


Sheet1

Unadjusted function point estimate for initial version of Encounter

SimpleMediumComplexSub-Total

countfactorcountfactorcountfactortotals

Ext. inputs13141613

comments:NameReady/moveQualities

Ext. outputs0405070

Ext. inquiries030406025

Int. logical files170100157

comments:Data about the user's character

Ext. interface files15070105


2. Encounter foreign characterSimpleMediumComplexSub-Total

factorfactorfactortotals

Ext. inputs0304060

Ext. outputs1405074

comments:Report on results





-- comments on aboveData about the user's character

Total unadjusted function points for two functions:41

Sheet2

Sheet3

Unadjusted Function Point Computation for Second Encounter Functions: Encounter Foreign Character


Sheet1

Unadjusted function point estimate for initial version of Encounter



Ext. inputs0304060

Ext. outputs1405074







2. Encounter foreign characterSimpleMediumComplexSub-Total


Ext. inputs0304060

Ext. outputs1405074








Sheet2

Sheet3

General Characteristics for FP Adjustment 1-7

1. Requires backup/recovery?0-2

2. Data communications required?0-1

3. Distributed processing functions? 0

. . . . .

0

incidental average essential

1

2

3

4

5

Case

study

none moderate significant


1. Requires backup/recovery?0-2

2. Data communications required?0-1

3. Distributed processing functions? 0

4. Performance critical?3-4

5. Run on existing heavily utilized environmt.?0-1

6. Requires on-line data entry? 5

7. Multiple screens for input? .... continued4-5

0


1

2

3

4

5

Case

study



8. Master fields updated on-line?3-4

9. Inputs, outputs, inquiries of files complex? 1-2

10. Internal processing complex?1-4

. . . .

0

1

2

3

4

5


Case

study



8. Master fields updated on-line?3-4

9. Inputs, outputs, inquiries of files complex? 1-2

10. Internal processing complex?1-3

11. Code designed for re-use?2-4

12. Conversion and installation included?0-2

13. Multiple installation in different orgs.?1-3

14. Must facilitate change & ease-of-use

by user?4-5

0

1

2

3

4

5


Case

study


Computation of Adjusted Function Points (IFPUG)

(Adjusted) Function points =

[ Unadjusted function points ] r

[ 0.65 + 0.01 r ( total general characteristics ) ]

Unadjusted Function Point Scores for Video Store Example


Sheet1

Unadjusted function point estimate for Video Store Example



Ext. inputs23140610

-- explanation:Name, ph. #Video data

Ext. outputs0415075

-- explanation:Amount due


-- explanation:Availability


-- explanation:Customers; Videos


Sheet2

Sheet3

FP Adjustment Factors for Video Example

1. Requires backup/recovery?.4

2. Data communications required ?....0

3. Distributed processing functions ?.0

4. Performance critical ?..3

5. Run on existing heavily utilized environment ?.1

6. Requires on-line data entry ?..5 . . . .

0

1

2

3

4

5

none incidental moderate average significant essential

FP Adjustment Factors for Video Example

1. Requires backup/recovery?.4

2. Data communications required ?....0

3. Distributed processing functions ?.0

4. Performance critical ?..3

5. Run on existing heavily utilized environment ?.1

6. Requires on-line data entry ?..5

7. Multiple screens for input ?.3

8. Master fields updated on-line ?..5

9. Inputs, outputs, inquiries of files complex ?..2

10. Internal processing complex ?.1

11. Code designed for re-use ?...3

12. Conversion and installation included ?..3

13. Multiple installation in different orgs. ?.3

14. Must facilitate change & ease-of-use by user ?..2

0

1

2

3

4

5

none incidental moderate average significant essential

Total

35

9. Estimating effort and duration from lines of code

Meaning of the COCOMO Formulas (Boehm)

Applies to design through integration & test.

*Effort = total person-months required.

(2) Duration for

increasing Effort*

( y b 2.5x 0.35 )

(1) Effort* for

increasing LOC

( y b 3x 1.12 )

exponent:

< 1

> 1

Basic COCOMO Formulae (Boehm)

Effort in Person-months

= aKLOC b

Duration = c Effort d

Software Project a b c d

Organic2.41.05 2.5 0.38

Semidetached3.01.12 2.5 0.35

Embedded3.61.20 2.5 0.32

Due to Boehm [Bo]

Computing COCOMO Case Study Models


Chart1

121722141219

171129101715

102114171020

Jan

Feb

Mar

Apr

May

Jun

Sheet1

aKbapprox.

EffortaK^b

LO2.44.21.0510

HI2.43001.051000

cPdapprox.

DurationcP^d

LO2.5100.386

HI2.510000.3835

Estimate Cost and Duration Very Early in Project

1. Use the function point method to estimate lines of code

2. Use Boehms formulas to estimate labor required

3. Use the labor estimate and Boehms formula to estimate duration


10. The Team Software Process

TSP Launch Issues to Settle(Humphrey)

Process to be used Quality goalsManner of tracking quality goalsHow team will make decisions What to do if quality goals not attainedfallback positions What to do if plan not approved fallback positions Define team rolesAssign team roles


To Be Produced at Launches (Humphrey)

1. Written team goals

2. Defined team roles

3. Process development plan

4. Quality plan

5. Projects support plan

computers, software, personnel etc.

6. Overall development plan and schedule

7. Detailed plans for each engineer

8. Project risk assessment

9. Project status report

TSPi Cycle Structure (Humphrey)

1

2

3

4

5

6

7

8

9

0

1

2

3

4

5

1. strategy

2. plan

3. requirements

4. design

5. implementation

6. test

7. postmortem

Milestones

Delivery

1. strat.

Iteration 1

Iteration 2

1. strategy.

Cycle 1 launch

Week

1

Cycle 2 launch

Cycle 3 launch

1

1

1

1

1

Iteration 3


11. The Software Project Management Plan

IEEE 1058.1-1987 SPMP Table of Contents

1. Introduction

1.1 Project overview

1.2 Project deliverables

1.3 Evolution of the SPMP

1.4 Reference materials

1.5 Definitions and acronyms 2. Project organization

2.1 Process model

2.2 Organizational structure

2.3 Organizational boundaries

and interfaces

2.4 Project responsibilities

3. Managerial process

3.1 Managerial objectives &

priorities

. . . .

IEEE 1058.1-1987 SPMP Table of Contents

1. Introduction

1.1 Project overview

1.2 Project deliverables

1.3 Evolution of the SPMP

1.4 Reference materials

1.5 Definitions and acronyms 2. Project organization

2.1 Process model

2.2 Organizational structure

2.3 Organizational boundaries

and interfaces

2.4 Project responsibilities

3. Managerial process

3.1 Managerial objectives &

priorities

3.2 Assumptions, dependencies

& constraints

3.3 Risk management

3.4 Monitoring & controlling

mechanisms

3.5 Staffing plan

4. Technical process

4.1 Methods, tools & techniques

4.2 Software documentation

4.3 Project support functions

5. Work packages, schedule &

budget

5.1 Work packages

5.2 Dependencies

5.3 Resource requirements

5.4 Budget & resource allocation

5.5 Schedule

12. Quality in project management

Table 2.5 Defects by Phase


Five Process Metric Examples

1.Number of defects per KLOC detected within x weeks of delivery

2.Variance in schedule on each phase

actual duration - projected duration projected duration

3.Variance in cost actual cost - projected cost

projected cost

4.Total design time / total programming time

should be at least 50% (Humphry)

5.Defect injection and detection rates per phase

e.g. 1 defect per class in detailed design phase

Compare each of the following with company norms averaged over similar processes.


IEEE 739-1989 Software Quality Assurance Plans Table of Contents Part 2 of 2

7. Test

-- can reference Software Test Documentation

8. Problem reporting & corrective action

9. Tools, techniques and methodologies

-- can reference SPMP

10. Code control

-- reference SCMP

11. Media control

12. Supplier control

13. Records collection, maintenance & retention

14. Training

15. Risk Management

-- can reference SPMP

Gather Process Metrics

1. Identify & define metrics team will use by phase; include ... time spent on 1. research, 2. execution, 3. review

size (e.g. lines of code)

# defects detected per unit (e.g., lines of code)

include source

quality self-assessment of each on scale of 1-10

maintain bell-shaped distribution

2. Document these in the SQAP

3. Accumulate historical data by phase

4. Decide where the metric data will be placed

as the project progresses SQAP? SPMP? Appendix?

5. Designate engineers to manage collection by phase

QA leader or phase leaders (e.g., design leader)

6. Schedule reviews of data for lessons learned

Specify when and how to feed back improvement


Table 2.6 Project Metric Collection for phases


13. Process improvement and the Capability Maturity Model

Table 2.7 Example of Process Comparison


Feed Back Process/Project Improvement

1. Decompose the process or sub-process being measured into Preparation, Execution and Review

include Research if learning about the procedure

2. Note time taken, assess degree of quality for each part on a 1-10 scale, count defects

try to enforce a curve

3. Compute quality / (percent time taken)

4. Compare teams performance against existing data, if available

5. Use data to improve next sub-process

note poorest values first e.g., low quality/(percent time)


Table 2.8 Measuring Team Phase Performance


14. Miscellaneous tools and techniques for project management Model

Remote Team Options

Same office area

+ ideal for group communication

- labor rates sub-optimal

Same city, different offices

communication fair

Same country, different cities

- communication difficult

+ common culture

Multi-country

- communication most difficult

- culture issues problematical

+ labor rates optimal



Non-Extreme vs Extreme Programming

Limited customer contactCentral up-front designBuild for the future tooComplex implementationTasks assignedDevelopers in isolationInfrequent integrationLimited communication

Customer on teamOpen evolving designEvolve; just in timeRadical simplicityTasks self-chosenPair programmingContinuous integrationContinual communication

Adapted from Andserson, A., et al, "At Chrysler, Objects Pay", Distributed Computing, October 1998

Triage in Project Management

Among top items in importance? if so, place it in do at once categoryotherwise Could we ignore without substantially affecting project? if so, place it in last to do categoryotherwise


Triage in Project Management

Among top items in importance? if so, place it in do at once categoryotherwise Could we ignore without substantially affecting project? if so, place it in last to do categoryotherwise (do not spend decision time on this)place in middle category


16. Summary of the project management process

Summary

Project management: silver bullet?People aspects co-equal technicalSpecify SPMPDefine and retire risksEstimate costs with several methodsexpect to revisit and refineuse ranges at this stageSchedule project with appropriate detailMaintain a balance among cost, schedule, quality and functionality



SPMP for the Encounter video game

Gaming Industries Consolidated

President

VP Engineering

VP Marketing

. . .

IV&V

Encounter

Game 123

. . .

SQA

Game Lab

. . .

Software

Engineering

Labs


Table 2.9 Encounter Project Responsibilties


Program Monitoring & Control


Sheet1

LeaderFacilitatorMarketingQAGame labRisk

Responsibiltyliaisonliaisonliaisonretirement

Report at weekly meetingXXXX

Circulate weekly report3*

Circulate biweekly report4*

Circulate monthly report1*2*

*Report formats

1see CI 34: "monthly project status form"

2see CI 87: "monthly marketing status form"

3see CI 344: "weekly QA status form"

4see CI 48: "biweekly game lab result form"

Table 2.11 Encounter Staffing Plan


Work BreakdownStructureExcluding Secretarial

Month 1

1

2

3

4

Month 2

1

2

3

4

Month 3

1

2

3

4

Month 4

1

2

3

4

Month 5

1

2

3

4

Milestones

Delivery

Complete testing

Iteration 1

Iteration 2

Freeze requirements

Risk I&R

SCMP

SQAP

SPMP rel. 1

E. Braude 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

J. Pruitt 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

F. Tryfill 1 1 1 1 1 1 1 1 1 1 1 1 1

H. Furnass 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

K. Peters 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Tasks

TOTAL 5.5 5.5 5.5 5.5 5.5 5.5 5.5 5.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 3.5 3.5

F. Smith (tech support) .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5


Table 2.12 Very Rough Estimate of Application Size Prior to Requirements Analysis


High Level Task Chart with Fixed Delivery Date:Order of Completion

Month 1

1

2

3

4

Month 2

1

2

3

4

Month 3

1

2

3

4

Month 4

1

2

3

4

Month 5

1

2

3

4

Milestones

(1*) Delivery

Begin system testing

Iteration 1

Iteration 2

(6)

(4)

(3) Freeze requirements

Risk identification & retirement

(5)

* Indicated the order in which the parts of this table were built

SCMP complete

SQAP complete

SPMP rel. 1 complete

(2)

Prep. for maintenance


Software quality assurance planPart 2 of 2

Problem Reporting Form

1. Defect Number: 2. Proposer: 3. Documents / sections affected:__________ Source code affected*: 4. package(s)_______ 5. class(es) ____6. method(s) ______ 7.Severity: ____8. Type: _____

9. Phase injected**: Req Arch Dtld.Dsg Code Int

10. Detailed description: ___________________ 11. Resolution: ____ 12. Status closed / open:__ Sign-off: 13. Description and plan inspected: __ 14. Resolution code and test plan inspected: ___ 15. Change approved for incorporation: ______

* for source code defects **earliest phase with the defect


Sources of Risk

In identifying the sources of project risk , you can first include all of the sources of uncertainty mentioned earlier in this chapter, such as misapprehension of scope and changes in requirements. Some of these cant properly be laid to rest until they are actually attempted, but crucial parts can be attacked early on. For example, with persistent communication, the core of the customers scope expectations can be discerned at this point.

The figure lists several sources of risk. One of these is tools such as design automation. Tool vendors can go out of business, discontinue support for the tool versions etc. (Indeed, this is one reason that computer-aided software engineering tools did not catch on in the 1980s.) The mobility of software personnel is another source of risk.



Ext. inputs 13141613

comments:NameReady/moveQualities

Ext. outputs0405070

Ext. inquiries 030406025

Int. logical files 170100157


Ext. interface files 15070105


2. Encounter foreign character SimpleMediumComplexSub-Total


Ext. inputs 0304060

Ext. outputs1405074










Ext. inputs 0304060

Ext. outputs1405074







2. Encounter foreign character SimpleMediumComplexSub-Total


Ext. inputs 0304060

Ext. outputs1405074








Unadjusted function point estimate for Video Store Example



Ext. inputs 23140610

-- explanation:Name, ph. #Video data

Ext. outputs0415075

-- explanation:Amount due


-- explanation:Availability


-- explanation:Customers; Videos


aKb

approx.

Effort

aK^b

LO

2.44.21.05

10

HI

2.43001.05

1000

cPd

approx.

Duration

cP^d

LO

2.5100.38

6

HI

2.510000.38

35

Lyle Herbert

Marketing

Eric Adams

Software engineer

Fran Sarris

Software engineer

Hal Kelly

Software engineer

Fred Mordell

Development

Vern Krupp

Technical specialist

Quinn Parker

QA

April Smith

Manager

LeaderFacilitatorMarketingQAGame labRisk

Responsibiltyliaisonliaisonliaisonretirement

Report at weekly meetingXXXX

Circulate weekly report3*

Circulate biweekly report4*

Circulate monthly report1*2*

*Report formats

1see CI 34: "monthly project status form"

2see CI 87: "monthly marketing status form"

3see CI 344: "weekly QA status form"

4see CI 48: "biweekly game lab result form"