Software project management
Concerned with activities involved in ensuring that
software is delivered:
• on time
• on schedule
• within budget
• meets standards
• in accordance with requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 1
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 2
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
In addition to overall plan, can have: Quality
Assurance Plan, Risk Management Plan, CM
Plan, Staff Development Plan, etc.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 3
Project planning process
Establi sh the p roject cons train ts
Make in itia l as sess ments of the proj ect para mete rs
Defi ne p roject m iles tone s an d de liverab les
w hile p roject h as n ot b een com pleted o r ca nce lledloop
Draw up proj ect schedu le
In itia te a cti vi ties accord ing to s che dule
Wa it ( for a while )
Review p roject p rogres s
Revise estimates o f pro ject pa rameters
Upda te the p roject s che dule
Re-ne goti ate proje ct con strai nts and deli ve rable s
if ( probl ems arise )the n
In itia te tech nical re vi ew and pos sibl e revis ion
end if
end loop
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 4
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 5
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
and should be accompanied be a formal output:
•
•
a short internal report
a Deliverable: a project result delivered to customers
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 6
Milestones in the RE process
ACT IVITIES
Feasibility
study
Requir ements
analysis
Prototype
development
Design
study
Requir ements
specification
Feasibility
report
Requir ements
definition
Evaluation
report
Architectural
design
Requir ements
specification
MILESTONES
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 7
Why are many projects late?






unrealistic deadlines (pricing to win)
changing requirements
poor estimates
poor risk management
poor process
unpredictable problems
How did you get a year behind schedule?
Brooks: “One Day at a Time”
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 8
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 9
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 10
Task durations and dependencies
Task
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
©Ian Sommerville 2000
Duration (da ys)
8
15
15
10
10
5
20
25
15
15
7
10
Dependencies
T1 (M1)
T2, T4 (M2)
T1, T2 (M3)
T1 (M1)
T4 (M5)
T3, T6 (M4)
T5, T7 (M7)
T9 (M6)
T11 (M8)
Software Engineering, 6th edition. Chapter 4
Slide 11
Activity network
8 days
15 days
M1
T3
15 days
T9
T1
25/7/99
4/7/99
start
14/7/99
5 days
4/8/99
25/8/99
T6
M4
M6
M3
7 days
20 days
15 days
T7
T2
25/7/99
10 days
M2
T4
T11
10 days
M7
T5
5/9/99
11/8/99
T10
18/7/99
M8
15 days
10 days
T12
M5
25 days
T8
Finish
19/9/99
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 12
Activity timeline
4/ 7
11/ 7
18 /7
25 /7
1/ 8
8/ 8
15 /8
22 /8
29 /8
5/ 9
12 /9
19 /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
Fi nish
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 13
Staff allocation
4/7
Fred
11/7
18/7
25/
1/8
8/8
15/8 22/8
29/8
5/9
12/9
19/9
T4
T8
T11
T12
Jane
T1
T3
T9
Anne
T2
T6
Jim
M ary
©Ian Sommerville 2000
T10
T7
T5
Software Engineering, 6th edition. Chapter 4
Slide 14
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 15
Software risks
Risk
Staff turnover
Risk type
Project
Management change
Project
Hardware unavailability
Project
Requirements change
Project and
product
Specification delays
Project and
product
Project and
product
Product
Size underestimate
CASE t ool underperformance
Technology change
Product comp etition
©Ian Sommerville 2000
Business
Business
Description
Experienced staff will leave the
project before it is finished.
There will be a change of
organisational management with
different priorities.
Hardware which is essential for the
project will not be delivered on
schedule.
There will be a larger numb er of
changes to the requirements than
anticipated.
Specifications of essential interfaces
are not available on schedule
The size of the system has been
underestimated.
CASE t ools which support the
project do not perform as anticipated
The underlying technology on which
the system is b uilt is superseded by
new technology.
A competitive product is marketed
before the system is completed.
Software Engineering, 6th edition. Chapter 4
Slide 16
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 17
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 18
Risk analysis
Risk
Organ isationa l f inancial problems force reduc tions
in the project budge t.
It is im possible to recruit staff wit h the skill s
required for the p roject.
Key staff are ill at crit ical tim es in the project.
Software componen ts which shou ld be reused
contain defects which limit their func tiona lit y.
Changes to requirements which requir e major
design rewo rk are proposed.
The o rgan isation is restructured so that diff erent
manage me nt are respons ible for the project.
The da tabase used in the system canno t process as
many transactions per second as expec ted.
The tim e requir ed to deve lop the software is
unde restim ated.
CASE tools canno t be integrated.
Customers fail to unde rstand the im pact of
requirements change s.
Requi red training for staff is not availa ble.
The rate of defect repair is und erestim ated.
The size o f t he software is unde restim ated.
The cod e gen erated by CASE tools is i neffi cient.
©Ian Sommerville 2000
Probability Effects
Low
Catastrophic
High
Catastrophic
Moderate
Moderate
Serious
Serious
Moderate
Serious
High
Serious
Moderate
Serious
High
Serious
High
Moderate
Tolerable
Tolerable
Moderate
Moderate
High
Moderate
Tolerable
Tolerable
Tolerable
Insignif icant
Software Engineering, 6th edition. Chapter 4
Slide 19
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 20
Risk management strategies
Risk
Organ isationa l
financ ial problems
Recruitm ent
problems
Staff illness
Defective
componen ts
Requi rements
chang es
Organ isationa l
restructuring
Database
performanc e
Unde restim ated
deve lopment time
©Ian Sommerville 2000
Strategy
Prepare a briefing document for senior manage ment show ing
how the p roject is making a very im portant contribu tion to the
goa ls of the bus iness.
Alert customer of potential difficulti es and the possibil ity of
delays, inves tigate buying- in componen ts.
Reorgan is e team so that there is more ove rlap of work and
people therefo re unde rstand each other ’s jobs.
Replace pot entia lly defective componen ts wit h bough t-in
componen ts of known reli abilit y.
Derive traceabili ty info rmation to assess requ ir ements chang e
im pact, maximi se information hid ing in the design.
Prepare a briefing document for senior manage ment show ing
how the p roject is making a very im portant contribu tion to the
goa ls of the bus iness.
Inves tigate the po ssibilit y o f buy ing a high er-performanc e
database.
Inves tigate buying in componen ts, inve stigate use of a program
gene rator.
Software Engineering, 6th edition. Chapter 4
Slide 21
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 22