Computing and SE II

Chapter 14: Software Project Management

Er-Yu DingSoftware Institute, NJU

Main Contents

1. What is SPM (software project management)?

2. Staffing3. Project planning4. Software Estimation5. Project Scheduling and Tracking6. Risk Management

• As an engineering discipline, management is needed

• Concerned with activities involved in ensuring that software is delivered– on time– within the budget– high quality (in accordance with the requirements)

• Project management is needed because software development is always subject to budget and schedule constraints – Set by the development organisation or the customer

1. What is software project management?

---Software project management

1. What is software project management?

---The means of “software”• When we say software, we are not talking about programs, but about program system products

• We all know all about programs, but what about program system products?

• Fred Brooks explains the difference and shows the effort involved

1. What is software project management?

---Program and Program system product (1)

• Program– program is complete by itself– program is ready to run by author for planned

inputs on system on which it was developed, and probably under no other circumstances

• Product system– each program is a component in integrated

collection (system)– precisely defined interface to which all programs

in system must comply– each program must stick to reasonable resources– each program is tested with other programs;

number of combinations grows quadratically with each additional program

1. What is software project management?

---Program and Program system product (2)

• Program Product:– product can be run, tested, repaired, extended

by anyone, not just author– product runs on multiple platforms – product accommodates many sets of data– range and form of input to product must be

generalized– product must test for validity of input and

provide response to invalid inputs– must be product documentation for

maintainers and users

1. What is software project management?

---Program and Program system product (3)

• Program System Product:– all attributes of program system and– all attributes of program product

(multipliers may be bigger if the number of components is large)

1. What is software project management?

--- Program and Program system product (4)

• Perhaps the key problem is that when we should be thinking about program system product , we continue to think about programs, and all expectations are off by an order of magnitude.– ease vs. difficulties,– time,– costs,– …

• We see only the program and forget all the other junk that must be added to make it a program system product !

1. What is software project management?

---the means of “project”• Project– The objective of the project to build a program

system product is to make sure that all the necessary junk gets planned in.

• Projects have plans:– Resources

• Multiple People• Schedule• Budget• Others

– Specific work to do– Deliverables

1. What is software project management?

---the means of “management”• Any project with more than one person must be managed by definition

• The job of management is to make sure that the planned junk does not get left behind in the zeal to release the software when only the program in its heart has been written!– Allocate resources properly. – Communicate and facilitate communication.– Control leads to quality.– Deliver what you promise.

1. What is software project management?

---Theories of SPM• General theories of management and project management can be applied to SPM

• And there are some special theories for software project management– This is what we mean

when we say “SPM”

Software project

management

Project Management

Management

1. What is software project management?

---Elements of Software Projects• Resources– Multiple People– Schedule– Budget– Others

• Specific work to do– Life Cycle and Process

Model

• Deliverables– Artifacts pieces– Integral Product

• Project Plan– Resources Plan– Specific Work Plan– Deliverables Plan

Resources

Specific work to doDeliverables

PeopleSchedule Budget

Project Plan

Actual Process

1. What is software project management?

---Broad sense SPM activities• All activities to manage elements of Software Projects

StaffingTracking

Resources Multiple People Schedule Budget Others

Specific work to do Life Cycle and Process Model

Deliverables Artifacts pieces Integral Product

Project Plan Resources Plan Specific Work Plan Deliverables Plan

Process Management

Configuration ManagementQuality Assurance/Management

EstimationSchedulingRisk

Project Scope

Project Planning

Goal: Deliver high quality product, within budget and on time.

1. What is software project management?

---Narrow sense SPM activities• This is the means of SPM in this chapter• Surrounding Project Plan

– Project Planning– Software estimation– Project scheduling and tracking– Risk management– Staffing (optional)

• Narrow sense SPM is paralleled to– Software process management– Quality management– Software configuration management

• Notes: Project scope is mainly solved in Requirements Engineering

2. Staffing

• People are an organisation’s most important assets.

• The tasks of a manager are essentially people-oriented. Unless there is some understanding of people, management will be unsuccessful.

• Poor people management is an important contributor to project failure.“It’s always a people problem”

2. Staffing ---Staffing Activities

Selecting Staffs

Organizing TeamsManaging Groups

Arranging Work EnvironmentMotivating People

2. Staffing --- Selecting Staffs / Selecting

staff• An important project management

task is team selection.• Information on selection comes from:

– Information provided by the candidates.– Information gained by interviewing and

talking with candidates.– Recommendations and comments from

other people who know or who have worked with the candidates.

2. Staffing --- Selecting Staffs / Staff selection

factors 1

2. Staffing --- Selecting Staffs / Staff selection

factors 2

2. Staffing --- Selecting Staffs / Staffing

Profile• Projects do not typically have a ‘static team size’

• Who and how many varies as needed

Copyright: Rational Software 2002

2. Staffing --- Selecting Staffs / Roll-on &

Roll-off• PM must have a plan as to how & when• Roll-on

– Hiring or ‘reserving’ resources– Ramp-up time

• Learning project or company

• Roll-off– Knowledge transfer– Documentation– Cleanup

2. Staffing --- Selecting Staffs / Team

Leader• The MOI Model:– Motivation. The ability to encourage (by “push or

pull”) technical people to produce to their best ability.

– Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product.

– Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

2. Staffing --- Selecting Staffs / Providing

Leadership• Positional Power– Power derived from having a leadership

position– Not always effective

• Personal Power– Charisma or personal charm– Sometimes more effective than

positional power

2. Staffing --- Organizing Teams/ Software Teams

• The difficulty of the problem to be solved• The size of the resultant program(s) in lines of code or

function points• The time that the team will stay together (team lifetime)• The degree to which the problem can be modularized• The required quality and reliability of the system to be built• The rigidity of the delivery date• The degree of sociability (communication) required for the

project

The following factors must be considered when selectingThe following factors must be considered when selectinga software project team structure ...a software project team structure ...

• Closed paradigm—structures a team along a traditional hierarchy of authority

• Random paradigm—structures a team loosely and depends on individual initiative of the team members

• Open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm

• Synchronous paradigm—relies on the natural compartmentalization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves

2. Staffing --- Organizing Teams/ Organizational

Paradigms

2. Staffing --- Organizing Teams/ Team

Structures

• The physical workplace provision has an important effect on individual productivity and satisfaction– Room size– Furniture– Equipment– Temperature– Humidity– Brightness– Noise– …

2. Staffing --- Arranging Work Environment / Working

environments

2. Staffing --- Arranging Work Environment / Workspace

organisation• Workspaces should provide private spaces where people can work without interruption– Providing individual offices for staff has been

shown to increase productivity.

• However, teams working together also require spaces where formal and informal meetings can be held.

• Enough equipment supplied to support team work

2. Staffing --- Arranging Work Environment /

Office layout

Office

Office

Office

Office

Office

Office

Office

OfficeCommunalarea

Meetingroom

Window

Shareddocumentation

2. Staffing ---Motivating People

• An important role of a manager is to motivate the people working on a project.

• Motivation is a complex issue but it appears that their are different types of motivation factors

• People go to work because they are motivated by the people that they work with.

2. Staffing ---Motivating People /

Motivation Factors

2. Staffing ---Motivating People / Avoid Team

“Toxicity”• A frenzied work atmosphere in which team members waste energy and lose focus on the objectives of the work to be performed.

• High frustration caused by personal, business, or technological factors that cause friction among team members.

• “Fragmented or poorly coordinated procedures” or a poorly defined or improperly chosen process model that becomes a roadblock to accomplishment.

• Unclear definition of roles resulting in a lack of accountability and resultant finger-pointing.

• “Continuous and repeated exposure to failure” that leads to a loss of confidence and a lowering of morale.

2. Staffing ---Managing groups

• Most software engineering is a group activity– The development schedule for most non-trivial

software projects is such that they cannot be completed by one person working alone.

• “Schedule disaster, functional misfit and system bugs all arise because the left hand does not know what the right hand is doing”

• Teams working on a project must communicate with one another in as many ways as possible: informally, regular project meetings email and by a shared project (electronic) workbook.

2. Staffing ---Managing groups / Group

communications• Good communications are essential for effective group working.

• Information must be exchanged on the status of work, design decisions and changes to previous decisions.

• Good communications also strengthens group cohesion as it promotes understanding.

3. Project planning

• Probably the most time-consuming project management activity

• Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available

• Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget

3. Project planning ---Types of project plan

Plan DescriptionQuality plan Describes the quality procedures and

standards that will be used in a project.Validation plan Describes the approach, resources and

schedule used for system validation. Configurationmanagement plan

Describes the configuration managementprocedures and structures to be used.

Maintenance plan Predicts the maintenance requirements ofthe system, maintenance costs and effortrequired.

Staff development plan. Describes how the skills and experience ofthe project team members will bedeveloped.

3. Project planning --- Project planning process

Establish the project constraints Make initial assessments of the project parameters Define project milestones and deliverableswhile project has not been completed or cancelled loop

Draw up project scheduleInitiate activities according to schedule

Wait ( for a while ) Review project progress Revise estimates of project parameters Update the project schedule Re-negotiate project constraints and deliverables if ( problems arise ) then Initiate technical review and possible revision end ifend loop

3. Project planning --- Project plan structure

• Introduction• Project organisation• Risk analysis• Hardware and software resource

requirements• Work breakdown• Project schedule• Monitoring and reporting mechanisms

3. Project planning--- Plan Contents

SoftwareSoftwareProjectProject

PlanPlan

Project ScopeProject ScopeEstimatesEstimatesRisksRisksScheduleSchedule

4. Software Estimation

• Estimation of resources, cost, and schedule for a software engineering effort requires – experience– access to good historical information

(metrics– the courage to commit to quantitative

predictions when qualitative information is all that exists

• Estimation carries inherent risk and this risk leads to uncertainty

4. Software Estimation--- Creating an Estimate…

• Estimating the Software Development Effort

– Estimating Size– Productivity factors

Cost Estimation Technique Efforts

4. Software Estimation--- Estimating Size

• Three main factors1.Units of measure

• LOC: Lines Of Code• FP: Function Points

2.Software included in the measurement3.Amount of reused code

• Reused code is generally counted differently than newly written code

• Must track code Added, Changed and Deleted from the reused code

• The lower level the language, the more productive the programmer– The same functionality takes more code to

implement in a lower-level language than in a high-level language

• The more verbose the programmer, the higher the productivity– Measures of productivity based on lines of code

suggest that programmers who write verbose code are more productive than programmers who write compact code

4. Software Estimation--- Units of Measure / Lines of

code

• Based on a combination of program characteristics– external inputs and outputs– user interactions– external interfaces– files used by the system

• A weight is associated with each of these• The function point count is computed by

multiplying each raw count by the weight and summing all values

4. Software Estimation--- Units of Measure / Function

points

• Function point count modified by complexity of the project

• FPs can be used to estimate LOC depending on the average number of LOC per FP for a given language– LOC = AVC * number of function points – AVC is a language-dependent factor varying from

200-300 for assemble language to 2-40 for a 4GL

• FPs are very subjective. They depend on the estimator. – Automatic function-point counting is impossible

4. Software Estimation--- Units of Measure / Lines of code VS

function points

4. Software Estimation--- Units of Measure / Lines of code VS

function points• Lines of code– Developers’ technical view– If have enough details, lines of code are

more accurate• The most accurate estimation is lines of code

when projects finished

• Function points– Users’ functional view– In the initial phase, function points are

more appropriate than lines of code when only high-level characteristics available

• A measure of the rate at which individual engineers involved in software development produce software and associated documentation

• Not quality-oriented although quality assurance is a factor in productivity assessment

• Essentially, we want to measure useful functionality produced per time unit

4. Software Estimation--- Productivity Factors

• Size related measures based on some output from the software process. This may be lines of delivered source code, object code instructions, etc.

• Function-related measures based on an estimate of the functionality of the delivered software. Function-points are the best known of this type of measure

4. Software Estimation--- Productivity Factors / Productivity

measures

4. Software Estimation--- Productivity Factors / Factors affecting

productivity

4. Software Estimation--- Cost estimation techniques

• One or more experts in both software development and the application domain use their experience to predict software costs. Process iterates until some consensus is reached.

• Advantages: Relatively cheap estimation method. Can be accurate if experts have direct experience of similar systems

• Disadvantages: Very inaccurate if there are no experts!

4. Software Estimation--- Cost estimation techniques / Expert

judgement

• The cost of a project is computed by comparing the project to a similar project in the same application domain

• Advantages: Accurate if project data available

• Disadvantages: Impossible if no comparable project has been tackled. Needs systematically maintained cost database

4. Software Estimation--- Cost estimation techniques /

Estimation by analogy

• The project costs whatever resources are available. The cost is determined by available resources rather than by objective assessment. If the software has to be delivered in 12 months and five people are available, the effort required is estimated to be 60 person-months

• Advantages: No overspend• Disadvantages: System is usually unfinished

4. Software Estimation--- Cost estimation techniques /

Parkinson's Law

• The project costs whatever the customer has to spend on it

• Advantages: You get the contract• Disadvantages: The probability that

the customer gets the system he or she wants is small. Costs do not accurately reflect the work required

4. Software Estimation--- Cost estimation techniques / Pricing

to win

4. Software Estimation--- Cost estimation techniques / Algorithmic

cost modelling• A formulaic approach based on historical cost information and which is generally based on the size of the software

• Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers

4. Software Estimation--- Cost estimation techniques / Algorithmic

cost modelling• Conventional Methods– Efforts = Size / Productivity

• Process-Based Estimation– Step 1: Identify the tasks

• Tasks are recorded in a Work Breakdown Structure (WBS)– Step 2: Estimate the efforts required per task– Step 3: Efforts = ∑(effort per task)

• Estimation with Use-Cases– Steps 1: Separating use cases into different kinds of

groups– Step 2: Estimate the sizes for each group– Step 3: Efforts = ∑(size per group) / Productivity

• Empirical Estimation Models

4. Software Estimation--- Algorithmic cost modelling / Conventional Methods

Average productivity for systems of this type = 620 LOC/pm.

Burdened labor rate =$8000 per month, the cost per line of code is approximately $13.

Based on the LOC estimate and the historical productivity data, the total estimated project cost is $431,000 and the estimated effort is 54 person-months.

Example: LOC Approach

Example: FP Approach

The estimated number of FP is derived:

FPestimated = count-total × [0.65 + 0.01 × ∑ (Fi)]

FPestimated = 375

organizational average productivity = 6.5 FP/pm. burdened labor rate = $8000 per month, the cost per FP is approximately $1230. Based on the FP estimate and the historical productivity data, the total estimated project cost is $461,000 and the estimated effort is 58 person-months.

4. Software Estimation--- Algorithmic cost modelling / Conventional Methods

4. Software Estimation--- Algorithmic cost modelling / Process-Based

EstimationActivity

Task

Function

UICF2DGA3DGA

DSMPCF

CGDF

DAM

Totals

% effort

CC PlanningRisk

Analysis EngineeringConstruction

Release TotalsCE

analysis design code test

0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00

1% 1% 1% 8% 45% 10% 36%

CC = customer communication CE = customer evaluation

0.500.750.500.500.500.25

2.504.004.003.003.002.00

0.400.601.001.000.750.50

5.002.003.001.501.501.50

8.407.358.506.005.754.25

0.50 2.00 0.50 2.00 5.00

n/an/an/an/an/an/an/a

Based on an average burdened labor rate of $8,000 per month, the total estimated project cost is $368,000 and the estimated effort is 46 person-months.

4. Software Estimation--- Algorithmic cost modelling / Estimation

with Use-Casesuse cases scenarios pages Ź scenarios pages LOC LOC estimate

e subsystem 6 10 6 Ź 12 5 560 3,366subsystem group 10 20 8 Ź 16 8 3100 31,233e subsystem group 5 6 5 Ź 10 6 1650 7,970

Ź Ź Ź Źstimate Ź Ź Ź Ź 42,568

User interface subsystem Engineering subsystem group Infrastructure subsystem group

Total LOC estimate

Using 620 LOC/pm as the average productivity for systems of this type and a burdened labor rate of $8000 per month, the cost per line of code is approximately $13. Based on the use-case estimate and the historical productivity data, the total estimated project cost is $552,000 and the estimated effort is 68 person-months.

4. Software Estimation--- Cost estimation techniques / Empirical

Estimation Models

4. Software Estimation--- Cost estimation techniques / Empirical

Estimation Models• COCOMO II is actually a hierarchy of estimation models that address the following areas:

• Application composition model. Used during the early stages of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount.

• Early design stage model. Used once requirements have been stabilized and basic software architecture has been established.

• Post-architecture-stage model. Used during the construction of the software.

4. Software Estimation--- COCOMO-II

• Algorithmic methods– Effort = f(x1, x2, …, xn)– where {x1, x2, …, xn} denote the cost

factors.• Linear models

• Power function models

– S=Size(x1, x2, …, xn)• Multiplicative models

4. Software Estimation--- COCOMO-II / Cost factors

• Product factors: required reliability; product complexity; database size used; required reusability; documentation match to life-cycle needs;

• Computer factors: execution time constraint; main storage constraint; computer turnaround constraints; platform volatility;

• Personnel factors: analyst capability; application experience; programming capability; platform experience; language and tool experience; personnel continuity;

• Project factors: multisite development; use of software tool; required development schedule.

4. Software Estimation--- The Make-Buy Decision

system Xsystem Xreusereuse

simple (0.30)simple (0.30)

difficult (0.70)difficult (0.70)

minorminor changeschanges

(0.40)(0.40)

majormajorchangeschanges

(0.60)(0.60)

simple (0.20)simple (0.20)

complex (0.80)complex (0.80)

majormajor changeschanges (0.30)(0.30)

minorminor changeschanges

(0.70)(0.70)

$380,000$380,000

$450,000$450,000

$275,000$275,000

$310,000$310,000

$490,000$490,000

$210,000$210,000

$400,000$400,000

buybuy

contractcontract

without changes (0.60)without changes (0.60)

with changes (0.40)with changes (0.40)

$350,000$350,000

$500,000$500,000

buildbuild

4. Software Estimation--- Computing Expected Cost

(path probability) x (estimated path cost) i i

For example, the expected cost to build is:

expected cost = 0.30 ($380K) + 0.70 ($450K)

similarly,

expected cost = $382K

expected cost = $267K

expected cost = $410K

build

reusebuy

contr

expected cost =

= $429 K

4. Software Estimation--- Estimation accuracy

• The size of a software system can only be known accurately when it is finished

• Several factors influence the final size– Use of “off the shelf” components– Programming language– Distribution of system

• As the development process progresses then the size estimate becomes more accurate

4. Software Estimation--- Estimate uncertainty

x

2x

4x

0.5x

0.25x

Feasibility Requirements Design CodeDelivery

Actualperson-months

x = estimated person-months

Estimate uncertainty:As the project progressesthe probablilty of a difference in actual to estimate decreases

5. Project Scheduling and Tracking

---Project scheduling• Split project into tasks and estimate time and

resources required to complete each task.• Organize tasks concurrently to make optimal

use of workforce.• Minimize task dependencies to avoid delays

caused by one task waiting for another to complete.

• Dependent on project managers intuition and experience.

5. Project Scheduling and Tracking

--- The project scheduling principles (Process)• compartmentalization—define distinct tasks

• interdependency—indicate task interrelationship • effort validation—be sure resources are available• defined responsibilities—people must be assigned• defined outcomes—each task must have an output• defined milestones—review for quality

5. Project Scheduling and Tracking

--- Bar charts and activity networks

• Graphical notations used to illustrate the project schedule.

• Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two.

• Activity charts show task dependencies and the the critical path.

• Bar charts show schedule against calendar time.

5. Project Scheduling and Tracking

--- Task durations and dependencies

Activity Duration (days) Dependencies

T1 8

T2 15

T3 15 T1 (M1)

T4 10

T5 10 T2, T4 (M2)

T6 5 T1, T2 (M3)

T7 20 T1 (M1)

T8 25 T4 (M5)

T9 15 T3, T6 (M4)

T10 15 T5, T7 (M7)

T11 7 T9 (M6)

T12 10 T11 (M8)

5. Project Scheduling and Tracking

--- Activity network

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/03

8 days

14/7/03 15 days

4/8/03

15 days

25/8/03

7 days

5/9/03

10 days

19/9/03

15 days

11/8/03

25 days

10 days

20 days

5 days25/7/03

15 days

25/7/03

18/7/03

10 days

T1

M1 T3T9

M6

T11

M8

T12

M4

5. Project Scheduling and Tracking

--- Activity timelineI.1.1 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement definedI.1.2 Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI definedI.1.3 Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition completeI.1.4 Isolate software elements Milestone: Software elements definedI.1.5 Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identifiedI.1.6 Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessedI.1.7 Make quick estimate of sizeI.1.8 Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete

week 1 week 2 week 3 week 4Work tasks week 5

5. Project Scheduling and Tracking

--- Staff allocation4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T8 T11

T12

T1

T3

T9

T2

T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

40-50%40-50%

30-40%30-40%

• “front end” activities– customer

communication– analysis– design– review and modification

• construction activities– coding or code

generation

• testing and installation– unit, integration– white-box, black box– regression

15-20%15-20%

5. Project Scheduling and Tracking

---Effort Allocation

• conduct periodic project status meetings in which each team member reports progress and problems.

• evaluate the results of all reviews conducted throughout the software engineering process.

• determine whether formal project milestones (diamonds in previous slide) have been accomplished by the scheduled date.

• compare actual start-date to planned start-date for each project task listed in the resource table

• meet informally with practitioners to obtain their subjective assessment of progress to date and problems on the horizon.

• use earned value analysis to assess progress quantitatively.

5. Project Scheduling and Tracking

---Schedule Tracking

6. Risk Management--- Risk & Uncertainty

• A risk is: “an uncertain event or condition that, if it occurs, will have a positive or negative effect on a project objective”

• Uncertainty = lack of knowledge about future events

• Risk = uncertainty that matters

6. Risk Management--- Reactive Risk Management

• Project team reacts to risks when they occur

• Mitigation—plan for additional resources in anticipation of fire fighting

• Fix on failure—resource are found and applied when the risk strikes

• Crisis management—failure does not respond to applied resources and project is in jeopardy

6. Risk Management--- Proactive Risk Management

• formal risk analysis is performed• organization corrects the root causes of

risk

RISK

controlcontrol

identifyidentify

analyzeanalyze

planplan

tracktrack

6. Risk Management--- Risk Identification

• Product size—risks associated with the overall size of the software to be built or modified.

• Business impact—risks associated with constraints imposed by management or the marketplace.

• Customer characteristics—risks associated with the sophistication of the customer and the developer's ability to communicate with the customer in a timely manner.

• Process definition—risks associated with the degree to which the software process has been defined and is followed by the development organization.

• Development environment—risks associated with the availability and quality of the tools to be used to build the product.

• Technology to be built—risks associated with the complexity of the system to be built and the "newness" of the technology that is packaged by the system.

• Staff size and experience—risks associated with the overall technical and project experience of the software engineers who will do the work.

6. Risk Management--- Risk analysis

• Assess probability and seriousness of each risk.

• Probability may be very low, low, moderate, high or very high.

• Risk effects might be catastrophic, serious, tolerable or insignificant.

6. Risk Management--- Risk analysis / Risk Projection• Risk projection, also called risk estimation,

attempts to rate each risk in two ways– the likelihood or probability that the risk is real – the consequences of the problems associated with

the risk, should it occur. • The are four risk projection steps:

– establish a scale that reflects the perceived likelihood of a risk

– delineate the consequences of the risk– estimate the impact of the risk on the project and the

product,– note the overall accuracy of the risk projection so that

there will be no misunderstandings.

6. Risk Management--- Risk analysis: An example

Risk Probability Effects

Organisational financial problems force reductions inthe project budget.

Low Catastrophic

It is impossible to recruit staff with the skills requiredfor the project.

High Catastrophic

Key staff are ill at critical times in the project. Moderate Serious

Software components that should be reused containdefects which limit their functionality.

Moderate Serious

Changes to requirements that require major designrework are proposed.

Moderate Serious

The organisation is restructured so that differentmanagement are responsible for the project.

High Serious

6. Risk Management--- Risk planning

• Consider each risk and develop a strategy to manage that risk.– Avoidance strategies

• The probability that the risk will arise is reduced;

– Minimisation strategies• The impact of the risk on the project or

product will be reduced;

– Contingency plans• If the risk arises, contingency plans are plans

to deal with that risk;

Project: Embedded software for XYZ systemRisk type: schedule riskPriority (1 low ... 5 critical): 4Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component delivery may be delayedProbability: 60 %Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testingMonitoring approach: Scheduled milestone reviews with hardware groupContingency plan: Modification of testing strategy to accommodate delay using software simulationEstimated resources: 6 additional person months beginning 7-1-96

6. Risk Management--- Risk planning / Recording Risk

Information

6. Risk Management--- Risk tracking and controlling

• Assess each identified risks regularly to decide whether or not it is becoming less or more probable.

• Also assess whether the effects of the risk have changed.

• Each key risk should be discussed at management progress meetings.

Conclusions

1. What is SPM (software project management)?

2. Staffing3. Project planning4. Software Estimation5. Project Scheduling and Tracking6. Risk Management

The End

• Recommend paper– 《 software project management 》

• Next Lecture– Software Process Management