Chapter 4
Project Management
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 1
Project management

Organising, planning and scheduling
software projects
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 2
Objectives




To introduce software project management and
to describe its distinctive characteristics
To discuss project planning and the planning
process
To show how graphical schedule representations
are used by project management
To discuss the notion of risks and the risk
management process
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 3
Topics covered




Management activities
Project planning
Project scheduling
Risk management
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 4
Software project management


Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software
Project management is needed because
software development is always subject to
budget and schedule constraints that are set by
the organisation developing the software
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 5
Software management distinctions





The product is intangible
The product is uniquely flexible
Software engineering is not recognized as an
engineering discipline with the sane status as
mechanical, electrical engineering, etc.
The software development process is not
standardised
Many software projects are 'one-off' projects
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 6
Management activities






Proposal writing
Project planning and scheduling
Project costing
Project monitoring and reviews
Personnel selection and evaluation
Report writing and presentations
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 7
Management commonalities



These activities are not peculiar to software
management
Many techniques of engineering project
management are equally applicable to software
project management
Technically complex engineering systems tend to
suffer from the same problems as software
systems
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 8
Project staffing

May not be possible to appoint the ideal people
to work on a project
•
•
•

Project budget may not allow for the use of highly-paid staff
Staff with the appropriate experience may not be available
An organisation may wish to develop employee skills on a
software project
Managers have to work within these constraints
especially when (as is currently the case) there
is an international shortage of skilled IT staff
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 9
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 10
Types of project plan
Plan
Quality plan
Validation plan
Configuration
management plan
Maintenance plan
Staff development plan.
©Ian Sommerville 2000
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.
Software Engineering, 6th edition. Chapter 4
Slide 11
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
loop
Slide 12
Project plan structure







Introduction
Project organisation
Risk analysis
Hardware and software resource requirements
Work breakdown
Project schedule
Monitoring and reporting mechanisms
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 13
Activity organization




Activities in a project should be organised to
produce tangible outputs for management to
judge progress
Milestones are the end-point of a process activity
Deliverables are project results delivered to
customers
The waterfall process allows for the
straightforward definition of progress milestones
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 14
Milestones in the RE process
ACT IVIT I E S
F easi bi li ty
s tu dy
Requ ir em ent s
anal y si s
P ro toty pe
d evelo pm en t
Des ig n
s tu dy
Requ ir em ent s
s pecifi cat io n
F easi bi li ty
repo rt
Requ ir em ent s
d efi ni ti on
Evalu ati on
report
Archi tect ural
d es ig n
Requ ir em ent s
s pecifi cat io n
M I L ES T O N E S
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 15
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 16
The project scheduling
process
Iden ti fy
acti vi ti es
Iden ti fy acti vi ty
d ep end enci es
Es ti m at e resou rces
for acti vi ti es
Al l ocate peo pl e
t o act iv it ies
S o ftw are
requ irem en ts
©Ian Sommerville 2000
C reate pro ject
chart s
Act iv it y chart s
and b ar chart s
Software Engineering, 6th edition. Chapter 4
Slide 17
Scheduling problems




Estimating the difficulty of problems and hence
the cost of developing a solution is hard
Productivity is not proportional to the number of
people working on a task
Adding people to a late project makes it later
because of communication overheads
The unexpected always happens. Always allow
contingency in planning
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 18
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 19
Task durations and
dependencies
T ask
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
©Ian Sommerville 2000
D ur atio n (da ys)
8
15
15
10
10
5
20
25
15
15
7
10
D ep en de nc i es
T1 M
( 1)
T2, T
4 (M 2)
T1, T
2 (M 3)
T1 M
( 1)
T4 M
( 5)
T3, T
6 (M 4)
T5, T
7 (M 7)
T9 M
( 6)
T 1 1 (M 8)
Software Engineering, 6th edition. Chapter 4
Slide 20
Activity network
1 5 d ay s
1 4/ 7/ 99
M1
8 day s
T9
T1
2 5/ 7/ 99
4/ 7/ 99
s tart
1 5 d ay s
T3
5 d ays
4/ 8/ 99
2 5/ 8/ 99
T6
M4
M6
M3
7 day s
2 0 d ay s
1 5 d ay s
T7
T2
2 5/ 7/ 99
1 0 d ay s
M2
T4
T1 1
1 0 d ay s
M7
T5
5/ 9/ 99
1 1/ 8/ 99
T1 0
1 8/ 7/ 99
M8
1 5 d ay s
10 days
T1 2
M5
2 5 d ay s
T8
F i ni sh
1 9/ 9/ 99
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 21
Activity timeline
4 /7
11 /7
1 8 /7
2 5 /7
1 /8
8 /8
1 5 /8
2 2 /8
2 9 /8
5 /9
1 2 /9
1 9 /9
St art
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T 10
M6
T 11
M8
T 12
Finish
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 22
Staff allocation
4 /7
Fred
11 /7
1 8/ 7
2 5/
1 /8
8 /8
1 5/ 8
22 /8
29 /8
5 /9
1 2/ 9
19 /9
T4
T8
T1 1
T1 2
Jane
T1
T3
T9
Anne
T2
T6
Jim
M ary
©Ian Sommerville 2000
T1 0
T7
T5
Software Engineering, 6th edition. Chapter 4
Slide 23
Risk management


Risk management is concerned with identifying
risks and drawing up plans to minimise their
effect on a project.
A risk is a probability that some adverse
circumstance will occur.
•
•
•
Project risks affect schedule or resources
Product risks affect the quality or performance of the software
being developed
Business risks affect the organisation developing or procuring
the software
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 24
Software risks
R isk
S t aff tu rn ov er
R isk t yp e
P ro je c t
M a n ag em en t hcan g e
P ro je c t
H a dr w a er un av a lia bil tiy
P ro je c t
R e qu irem e nts ch a ng e
P ro je c ta nd
p ro du c t
S pe c fi i ca t oi n d ela ys
P ro je c ta nd
p ro du c t
P ro je c ta nd
p ro du c t
P ro du ct
S i ze un de r estim ate
C AS E ot ol u nd e -r
p e fro rm an c e
T e hcno lo gy ch a ng e
P ro du ct c mp
o e ittion
©Ian Sommerville 2000
B us in ess
B us in ess
D esc ription
E x p eri en c ed sta ff w ill le av e hte
p ro j e tcb e for e t iis finis h ed .
T h e er w ill be a hcan g eof
o rg a nis a iton a lm a n ag em en t w ith
d iff eren t pr i oriti es.
H a dr w a er w h ic h is essen tia lfor t h e
p ro j e tcw i l n ot b ed eliv ere do n
sch e du l e.
T h e er w ill be a larg er n umb e rof
ch a ng es to the re qu irem e nts th an
an t ci ip a t de.
S pe c fi i ca t oi ns of essen tia linte fr ac es
are n ot av a lia ble o n sc h ed ule
T h e siz e of t h es ystem has b ee n
u nd e er s t m
i ate d.
C AS E ot ols w hic hsu pp ort th e
p ro j e tcd o n ot pe rform as a nti cip ated
T h e nude rlying t ec hn olog y o n w h i ch
th e sys t em is b u lit is su p ers ed e dby
n e w t e hcno lo gy .
A co m p eti itv eprod uc t is m a kr ete d
b e of r e hte sys t em is com ple t de.
Software Engineering, 6th edition. Chapter 4
Slide 25
The risk management process

Risk identification
•

Risk analysis
•

Assess the likelihood and consequences of these risks
Risk planning
•

Identify project, product and business risks
Draw up plans to avoid or minimise the effects of the risk
Risk monitoring
•
Monitor the risks throughout the project
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 26
The risk management process
R i sk
i dent ifi cati on
R i sk anal ys is
Li s t o f po ten ti al
ris k s
P rio rit is ed ri sk
l is t
©Ian Sommerville 2000
R is k pl ann ing
R i sk avo id ance
and co nt in gen cy
p lans
Software Engineering, 6th edition. Chapter 4
R i sk
m o ni to ri ng
R i sk
ass ess m ent
Slide 27
Risk identification





Technology risks
People risks
Organisational risks
Requirements risks
Estimation risks
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 28
Risks and risk types
R is k ty p e
T e c h n o lo g y
P e o p le
O rg a n is a tio n a l
T o o ls
R e q u ire m e n ts
E s tim a tio n
©Ian Sommerville 2000
P o s s ib le ris k s
T h e d a ta b a s e u s e d in th e s y s te m c a n n o t p ro c e s s a s
m a n y tra n s a c tio n s p e r s e c o n d a s e xp e c te d .
S o ftw a re c o m p o n e n ts w h ic h s h o u ld b e re u s e d c o n ta in
d e fe c ts w h ic h lim it th e ir fu n c tio n a lity .
It is im p o s s ib le to re c ru it s ta ff w ith th e s k ills re q u ire d .
K e y s ta ff a re ill a n d u n a v a ila b le a t c ritic a l tim e s .
R e q u ire d tra in in g fo r s ta ff is n o t a v a ila b le .
T h e o rg a n is a tio n is re s tru c tu re d s o th a t d iffe re n t
m a n a g e m e n t a re re s p o n s ib le fo r th e p ro je c t.
O rg a n is a tio n a l fin a n c ia l p ro b le m s fo rc e re d u c tio n s in th e
p ro je c t b u d g e t.
T h e c o d e g e n e ra te d b y C A S E to o ls is in e ffic ie n t.
C A S E to o ls c a n n o t b e in te g ra te d .
C h a n g e s to re q u ire m e n ts w h ic h re q u ire m a jo r d e s ig n
re w o rk a re p ro p o s e d .
C u s to m e rs fa il to u n d e rs ta n d th e im p a c t o f re q u ire m e n ts
changes.
T h e tim e re q u ire d to d e v e lo p th e s o ftw a re is
u n d e re s tim a te d .
T h e ra te o f d e fe c t re p a ir is u n d e re s tim a te d .
T h e s iz e o f th e s o ftw a re is u n d e re s tim a te d .
Software Engineering, 6th edition. Chapter 4
Slide 29
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 30
Risk analysis
R is k
O rg a n is a tio n a l
f in a n c ia l
p ro b le m s
f o rc e
re d u c tio n s in th e p ro je c t b u d g e t.
It is im p o s s ib le to re c ru it s ta f f w ith th e s k ills
re q u ire d f o r th e p ro je c t.
K e y s ta f f a re ill a t c ritic a l tim e s in th e p ro je c t.
S o f tw a re c o m p o n e n ts w h ic h s h o u ld b e re u s e d
c o n ta in d e f e c ts w h ic h lim it th e ir f u n c tio n a lity .
C h a n g e s to re q u ire m e n ts w h ic h re q u ire m a jo r
d e s ig n re w o rk a re p ro p o s e d .
T h e o rg a n is a tio n is re s tru c tu re d s o th a t d if f e re n t
m a n a g e m e n t a re re s p o n s ib le f o r th e p ro je c t.
T h e d a ta b a s e u s e d in th e s y s te m c a n n o t p ro c e s s
a s m a n y tra n s a c tio n s p e r s e c o n d a s e x p e c te d .
T h e tim e re q u ire d to d e v e lo p th e s o f tw a re is
u n d e re s tim a te d .
C A S E to o ls c a n n o t b e in te g ra te d .
C u s to m e rs f a il to u n d e rs ta n d th e im p a c t o f
re q u ire m e n ts c h a n g e s .
R e q u ire d tra in in g f o r s ta f f is n o t a v a ila b le .
T h e ra te o f d e f e c t re p a ir is u n d e re s tim a te d .
T h e s iz e o f th e s o f tw a re is u n d e re s tim a te d .
T h e c o d e g e n e ra te d b y C A S E to o ls is in e f f ic ie n t.
©Ian Sommerville 2000
P r o b a b ility
Low
E ffe c ts
C a ta s tro p h ic
H ig h
C a ta s tro p h ic
M o d e ra te
M o d e ra te
S e rio u s
S e rio u s
M o d e ra te
S e rio u s
H ig h
S e rio u s
M o d e ra te
S e rio u s
H ig h
S e rio u s
H ig h
M o d e ra te
T o le ra b le
T o le ra b le
M o d e ra te
M o d e ra te
H ig h
M o d e ra te
T o le ra b le
T o le ra b le
T o le ra b le
In s ig n if ic a n t
Software Engineering, 6th edition. Chapter 4
Slide 31
Risk planning


Consider each risk and develop a strategy to
manage that risk
Avoidance strategies
•

Minimisation strategies
•

The probability that the risk will arise is reduced
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 32
Risk management strategies
R is k
O rg a n isa tio n a l
fin a n cia l p ro b le m s
R e cru itm e n t
p ro b le m s
S ta ff illn e ss
D e fe ctive
co m p o n e n ts
R e q u ire m e n ts
ch a n g e s
O rg a n isa tio n a l
re stru ctu rin g
D a ta b a se
p e rfo rm a n ce
U n d e re stim a te d
d e ve lo p m e n t tim e
©Ian Sommerville 2000
S tra te g y
P re p a re a b rie fin g d o cu m e n t fo r se n io r m a n a g e m e n t sh o w in g h o w th e p ro je ct is
m a k in g a ve ry im p o rta n t co n trib u tio n to th e g o a ls o f th e b u sin e ss.
A le rt cu sto m e r o f p o te n tia l d ifficu ltie s a n d th e p o ssib ility o f d e la ys, in ve stig a te
b u yin g -in co m p o n e n ts.
R e o rg a n ise te a m so th a t th e re is m o re o ve rla p o f w o rk a n d p e o p le th e re fo re
u n d e rsta n d e a ch o th e r’s jo b s.
R e p la ce p o te n tia lly d e fe ctive co m p o n e n ts w ith b o u g h t-in co m p o n e n ts o f k n o w n
re lia b ility.
D e rive tra ce a b ility in fo rm a tio n to a sse ss re q u ire m e n ts ch a n g e im p a ct, m a xim ise
in fo rm a tio n h id in g in th e d e sig n .
P re p a re a b rie fin g d o cu m e n t fo r se n io r m a n a g e m e n t sh o w in g h o w th e p ro je ct is
m a k in g a ve ry im p o rta n t co n trib u tio n to th e g o a ls o f th e b u sin e ss.
In ve stig a te th e p o ssib ility o f b u yin g a h ig h e r-p e rfo rm a n ce d a ta b a se .
In ve stig a te b u yin g in co m p o n e n ts , in ve stig a te u se o f a p ro g ra m g e n e ra to r.
Software Engineering, 6th edition. Chapter 4
Slide 33
Risk monitoring



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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 34
Risk factors
R isk typ e
T ec hnology
P eople
O rganisational
T ools
R equirem ents
E stim ation
©Ian Sommerville 2000
P o ten tial in d icato rs
Late deliv ery of hardw are or support softw are, m any reported
tec hnology problem s
P oor staff m orale, poor relationships am ongst team m em ber,
job av ailability
organisational gossip, lac k of ac tion by senior m anagem ent
reluc tanc e by team m em bers to use tools, c om plaints about
C A S E tools, dem ands for higher-pow ered w ork stations
m any requirem ents c hange requests, c ustom er c om plaints
failure to m eet agreed sc hedule, failure to c lear reported
defec ts
Software Engineering, 6th edition. Chapter 4
Slide 35
Key points




Good project management is essential for project
success
The intangible nature of software causes problems for
management
Managers have diverse roles but their most significant
activities are planning, estimating and scheduling
Planning and estimating are iterative processes
which continue throughout the course of a
project
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 36
Key points



A project milestone is a predictable state where
some formal report of progress is presented to
management.
Risks may be project risks, product risks or
business risks
Risk management is concerned with identifying
risks which may affect the project and planning
to ensure that these risks do not develop into
major threats
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 37