Computing and SE II
Chapter 14: Software Project
Management
Er-Yu Ding
Software Institute, NJU
Main Contents
1. What is SPM (software project
management)?
2. Staffing
3. Project planning
4. Software Estimation
5. Project Scheduling and Tracking
6. Risk Management
management?
---Software project
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
1. What is software project
management?
of we
“software”
• When---The
we saymeans
software,
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
Program
and Program system
– program is complete by itself
product
– program is ready
to run by(1)
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?
and Program system
• ---Program
Program Product:
– product can product
be run, tested,
repaired, extended
(2)
–
–
–
–
–
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?
andProduct:
Program system
• ---Program
Program System
product
(3)system and
– all attributes
of program
– all attributes of program product
(multipliers may be
bigger if the
number of
components is
large)
1. What is software project
management?
Program
Program
system
• --Perhaps
the keyand
problem
is that when
we
should be thinking about program system
product
(4)
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?
means
“management”
• ---the
Any project
withofmore
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.
•
1. What is software project
management?
of SPM
General---Theories
theories of
Management
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”
Project
Management
Software
project
management
1. What is software project
management?
Actual ProcessProjects
• ---Elements
Resources
of Software
– Multiple People
– Schedule
– Budget
– Others
• Specific work to do
People
Resources Schedule
Budget
Specific work to do
Deliverables
– Life Cycle and Process
Model
• Deliverables
– Artifacts pieces
– Integral Product
• Project Plan
– Resources Plan
– Specific Work Plan
– Deliverables Plan
Project Plan
•
1. What is software project
management?
All activities to manage elements of Software Projects
---Broad sense SPM activities
Resources


Multiple People
Schedule
Budget

Others



Specific work to do


Life Cycle and Process Model
Process Management
Deliverables



Staffing
Tracking
Artifacts pieces
Integral Product
Project Plan



Resources Plan
Specific Work Plan
Deliverables Plan
Configuration Management
Quality Assurance/Management
Project Planning
Estimation
Scheduling
Risk
Project Scope
Goal: Deliver high quality product, within budget and on time.
1. What is software project
management?
This is the---Narrow
means of SPM
in this SPM
chapteractivities
sense
•
• 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
“It’s always a people problem”
failure.
2. Staffing
---Staffing Activities
Selecting Staffs
Managing Groups
Organizing Teams
Motivating People
Arranging Work Environment
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
A pp li c at ion dom ai n ex pe rie nc eF or a project to de ve lop a su cce ssf ul sys te m , th e
d eve lop ers m ust un de rstan d th e a pp lic a tio n dom ai n . It is
essen tial tha t som e m em be rs of a d ev el o pm en t tea m h av e
some dom ai n ex pe rie nc e .
P la tfor m ex p erie n ce
T h is m ay be sig nifica n t if lo w- le v el prog ram m ing is
in vo lv ed . O th e rw ise, n o t usu al ly a crit ica l at tribu te .
P ro gramm in g
la ng ua g e e x pe rien c e
T h is is no rm ally o nly sign ifica n t fo r sh ort du ra tio n project s
w he re the re is n ot en ou gh tim e to le ar n a ne w lan g ua ge.
W hile lea rning a lan gu age it se lf is no t d ifficu lt, it ta k es
sev eral mo nths to b ec om e p rof ici e nt in using th e ass oc iate d
librarie s an d com po ne n ts.
P ro blem so lv in g ab ilit y
T h is is ve ry imp orta n t fo r softw are en ginee rs w ho
co nstan tly ha v e to sol v e tec h nical prob le ms . H o w e ve r, it is
alm os t im poss ib le to ju dg e w it h ou t kn ow in g the w o rk o f
th e p oten tia l te am m em be r.
2. Staffing
--- Selecting Staffs / Staff selection
factors 2
E d uca tio na l
b ack gr ou nd
T h is m ay pro vide a n ind ic a to r of th e b asic fu nd am en ta ls th at the
ca n dida te sh ou ld kn ow an d of the ir ab ili ty to lea rn . T h is fac tor
b eco m es in cr e asin gly irreleva n t as en gine e rs g ai n ex pe rien c e
ac ros s a ran ge of pro jec ts .
C omm un ica tio n
ab il ity
T h is is imp orta n t b eca us e of th e n ee d for projec t sta ff to
com m u nica te o ra lly an d in w ritin g w ith o th er en gin ee rs , ma na g ers
an d c ustom ers .
A da p ta b ilit y
A da p ta b ilit y m ay b e ju dg ed by lo ok in g at the differen t typ es of
ex pe rie nc e th at can d id at es ha v e h ad . T h is is a n imp orta n t a ttri bu te
as it ind ic a te s a n a bi lity to lea rn.
A ttitu de
P ro je ct staff sh ou ld h ave a p ositiv e attitu de to th e ir w ork a nd
sho uld be w ill ing to lea rn n ew skill s. Th is is an im por ta n t attrib ute
b ut ofte n v er y d ifficu lt to assess.
P ers on al ity
T h is is an im por ta n t a ttrib ute b ut diffic ult to a ssess . C a nd id a te s
m ust be rea son ab ly co mp at ible w ith o th er te a m m em be rs . N o
p ar tic u la r typ e o f pe rs on al ity is m or e o r less su it e d to softw are
en ginee ri ng .
•
2. Staffing
--- Selecting Staffs / Staffing
Projects do not
typically
have
a
‘static
Profile
team size’
• Who and how many varies as needed
Copyright: Rational Software 2002
2. Staffing
--- Selecting Staffs / Roll-on &
PM must have a plan as to how & when
Roll-off
•
• Roll-on
– Hiring or ‘reserving’ resources
– Ramp-up time
• Learning project or company
• Roll-off
– Knowledge transfer
– Documentation
– Cleanup
•
2. Staffing
--- Selecting Staffs / Team
The MOI Model:
Leader
– 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 following factors must be considered when selecting
a software project team structure ...
• 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
2. Staffing
--- Organizing Teams/ Organizational
• Closed paradigm—structures
a team along a
Paradigms
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/ Team
Structures
2. Staffing
--- Arranging Work Environment / Working
environments
• 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 / Workspace
• Workspacesorganisation
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
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
A frenzied work atmosphere
in which team members
“Toxicity”
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
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
Quality plan
Validation plan
Configuration
management plan
Maintenance plan
Staff development plan.
Description
Describes the quality
procedures and
standards that will be used in a project.
Describes
the approach, resources and
schedule used for system validation.
Describes the configuration management
procedures and structures to be used.
Predicts the
maintenance requirements of
the system, maintenance costs and
effort
required.
Describes how the skills and
experience of
the project team
members will be
developed.
3. Project planning
--- Project planning process
Esta blish the p ro je ct co nstrain ts
Make initia l a ss ess men ts of the pro ject pa rame ters
Define project mile sto nes an d de liverable s
while proje ct h as n ot be en co mp leted or ca ncelle d
Dra w u p proje ct sch ed ule
Initiate activitie s accordin g to s ch ed ule
Wait ( fo r a wh ile )
Revie w p roje ct p ro gress
Revis e es tima tes o f project pa ra me ters
Upda te the project sch edu le
Re-neg otiate project cons tra ints a nd d eliverab les
if ( p ro blems aris e ) then
Initiate te chnica l revie w a nd p os sible revision
end if
end loop
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
Project Scope
Estimates
Risks
Schedule
Software
Project
Plan
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
Cost
– Estimating Size Estimation
Technique
– Productivity factors
Efforts
4. Software Estimation
--- Estimating Size
• Three main factors
1.Units of measure
• LOC: Lines Of Code
• FP: Function Points
2.Software included in the
measurement
3.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
•
4. Software Estimation
--- Units of Measure / Lines of
The lower level the
language, the more
code
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 / Function
• Based on a combination
pointsof 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 / Lines of code VS
function
points by
• Function point
count modified
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
• 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
4. Software Estimation
--- Productivity Factors
• 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
4. Software Estimation
--- Productivity Factors / Productivity
measuresbased on some
• Size related measures
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 / Factors affecting
productivity
4. Software Estimation
--- Cost estimation techniques
4. Software Estimation
--- Cost estimation techniques / Expert
• One or morejudgement
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
4. Software Estimation
--- Cost estimation techniques /
by is
analogy
• The costEstimation
of a project
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
4. Software Estimation
--- Cost estimation techniques /
Parkinson's
Law resources
• The project
costs whatever
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 personmonths
• Advantages: No overspend
4. Software Estimation
--- Cost estimation techniques / Pricing
to whatever
win
• The project costs
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 / 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
Example: LOC Approach
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.
4. Software Estimation
--- Algorithmic cost modelling / Conventional Methods
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 / Process-Based
A ctivity
CC
P la n n in g
R is k
A n a ly s is
Task
C o n s t ru c t io n
R e le a s e
Estimation
E n g in e e rin g
analy s is
des ign
c ode
te s t
5.00
2.00
CE
Totals
n/a
n/a
n/a
8.40
Function
U IC F
0.50
2.50
0.40
2D GA
3D GA
C GD F
0.75
0.50
0.50
4.00
4.00
3.00
0.60
1.00
1.00
D SM
PC F
D AM
0.50
0.25
0.75
0.50
0.50
3.00
2.00
2.00
4.50
Totals
0.25
0.25
0.25
3.50
20.50
% effort
1%
1%
1%
8%
45%
0.50
10%
3.00
1.50
1.50
1.50
2.00
16.50
n/a
n/a
n/a
n/a
7.35
8.50
6.00
5.75
4.25
5.00
46.00
36%
C C = custom er com m unication C E = custom er evaluation
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-Cases
use cases
subsystem
User interfaceesubsystem
Engineering subsystem
subsystemgroup
group
Infrastructure esubsystem
subsystemgroup
group
Total LOC estimate
stimate
6
10
5
scenarios
pages
10
20
6
6
8
5
Ź scenarios
pages
LOC
LOC estimate
Ź
Ź
Ź
12
16
10
5
8
6
560
3100
1650
3,366
31,233
7,970
Ź
Ź
Ź
Ź
Ź
Ź
Ź
Ź
42,568
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
• COCOMO IIEstimation
is actually Models
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
4. Software Estimation
--- The Make-Buy Decision
4. Software Estimation
--Computing Expected Cost
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)
build
= $429 K
similarly,
expected cost
= $382K
reuse
expected cost buy = $267K
expected cost contr = $410K
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
Estimate uncertainty:
As the project progresses
the probablilty of a difference in
actual to estimate decreases
4x
2x
Actual
personmonths
x
F easi bi li ty R equ irem en ts
0 .5x
0 .25 x
x = estimated person-months
Des ig n
C o de
Del iv ery
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.
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
T1
Duration (days)
8
Dependencies
T2
15
T3
15
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)
T1 (M1)
5. Project Scheduling and Tracking
--- Activity network
1 4 /7 /0 3
1 5 da y s
M1
T3
1 5 da y s
8 da y s
T9
5 da y s
T1
2 5 /8/0 3
4 /8/0 3
2 5 /7 /0 3
M6
M4
T6
4 /7 /0 3
M3
star t
7 da y s
2 0 da y s
15 da y s
T 11
T7
T2
5 /9/0 3
11 /8/0 3
2 5 /7 /0 3
10 da y s
10 da y s
M2
T4
M7
T5
T 10
1 8 /7 /0 3
M8
1 5 da y s
1 0 da ys
T 12
M5
2 5 da y s
Finish
T8
1 9 /9/0 3
5. Project Scheduling and Tracking
--- Activity timeline
5. Project Scheduling and Tracking
--- Staff allocation
4/7
Fr ed
1 1/7
18/7
2 5/7
1/8
8/8
15/8
2 2/8
2 9/8
5/9
T4
T8
T 11
T 12
Jane
T1
T3
T9
Anne
T2
T6
Jim
Mar y
T7
T5
T 10
1 2/9
19/9
5. Project Scheduling and
Tracking
---Effort
Allocation
• “front end” activities
40-50%
15-20%
– customer
communication
– analysis
– design
– review and
modification
• construction
activities
30-40%
– coding or code
generation
• testing and
installation
•
•
•
•
•
5. Project Scheduling and
Tracking
conduct---Schedule
periodic project status
meetings in
Tracking
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.
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
6. Risk Management
--- Proactive Risk Management
• formal risk analysis is performed
• organization corrects the root causes of risk
control
track
RISK
plan
analyze
identify
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
R isk
P ro b ab ilit y
E ff ec ts
O rgan isa ti ona l f in a nc ial p rob lem s fo rce reduc ti ons i n
the pro jec t budge t.
L ow
C a ta str oph ic
It is im pos sib le to rec ruit st aff w it h the sk ill s re qu ired
for t he p ro jec t.
H igh
C a ta str oph ic
Key staff a re i ll a t c rit ic al tim es in the p rojec t.
Mod e ra te
S eri ous
S of tw a re co m ponen ts tha t shou ld b e reus e d con tain
de fec ts wh ich li m it the ir f unc tion al ity .
Mod e ra te
S eri ous
Ch a nges to requ irem en ts th at requ ire m ajor de si gn
rewo rk a re propo sed.
Mod e ra te
S eri ous
T he o rgan isat ion i s re str uc tur e d so tha t d iff er e nt
m anage me nt are respons ible fo r th e p rojec t.
H igh
S eri ous
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;
6. Risk Management
--- Risk planning / Recording Risk
Information
Project: Embedded software for XYZ system
Risk type: schedule risk
Priority (1 low ... 5 critical): 4
Risk factor: Project completion will depend on tests which require
hardware component under development. Hardware component
delivery may be delayed
Probability: 60 %
Impact: Project completion will be delayed for each day that
hardware is unavailable for use in software testing
Monitoring approach:
Scheduled milestone reviews with hardware group
Contingency plan:
Modification of testing strategy to accommodate delay using
software simulation
Estimated resources: 6 additional person months beginning 7-1-96
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. Staffing
3. Project planning
4. Software Estimation
5. Project Scheduling and Tracking
6. Risk Management
The End
• Recommend paper
– 《software project management》
• Next Lecture
– Software Process Management