Project management

Organising, planning and
scheduling software projects
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 1
Software project management


ensuring that software is delivered on time
and on schedule and meets requirements
needed because software development is
subject to budget and schedule constraints
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 4
Managers



Plan and schedule development
Supervise work
Monitor progress
Good Management doesn’t cause success;
poor management leads to failure
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 5
Software management distinctions





The product is intangible
The product is uniquely flexible
The software development process is not
standardised
Many software projects are 'one-off'
projects
Rapid change in technology
©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 not peculiar to software
mgmt
Many techniques of engineering project
management applicable to software
Innovative, 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 planning




time-consuming
Continuous activity
Plans must be regularly revised
Various different types of plan
©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
Des cription
Des cribes the quality
procedures and
s tandards that will be us ed in a project.
Des cribes the approach, resources and
s chedule used for sys tem validation.
Des cribes the configuration management
procedures and structures to be us ed.
Predicts the maintenance requirements of
the s ystem, maintenance cos ts and
effort
required.
Des cribes how the skills and experience of
the project team
members will be
developed.
Software Engineering, 6th edition. Chapter 4
Slide 11
Project planning process
Establish the project cons traints
Make initial as sess ments of the project parameters
Define project m iles tones and deliverables
while project has not been com pleted or cancelledloop
Draw up project schedule
Initiate activities according to s chedule
Wait ( for a while )
Review project progres s
Revise estimates of project parameters
Update the project s chedule
Re-negotiate project constraints and deliverables
if ( problems arise )then
Initiate technical review and pos sible revis ion
end if
end loop
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 12
Project plan







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




Need tangible outputs for management to
judge progress
Milestones are the end-point of a process
activity
Deliverables are project results delivered
to customers
Waterfall process leads to easy definition
of milestones
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 14
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 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
Identify
activities
Identify activity
dependencies
Estimate resources
for activities
Allocate people
to activities
Software
requirements
©Ian Sommerville 2000
Create project
charts
Activity charts
and bar charts
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.
Activity charts show task dependencies
and the critical path
Bar charts show schedule against
calendar time
Project management software automates
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 19
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 20
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 21
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 22
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 23
Risk management


identifying risks and drawing up plans to
minimise their effect on a project.
A risk is a probability that some adverse
circumstance will occur.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 24
Risk Management is Important



Loosely defined requirements
Difficulties in estimating
dependence on individual knowledge and skills
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 25
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 26
The risk management process
Risk
identification
Risk analysis
Risk planning
Risk
monitoring
List of potential
risks
Prioritised risk
list
Risk avoidance
and contingency
plans
Risk
assessment
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 28
Risk identification






Technology risks
People risks
Organisational risks
Tools risks
Requirements risks
Estimation risks
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 29
Risks and risk types
Risk type
Techno logy
People
Organ isationa l
Tools
Requi rements
Estim ation
©Ian Sommerville 2000
Possibl e risks
The da tabase used in the system canno t process as many
transa ctions per second as exp ected.
Software componen ts which shou ld be reused cont ain de fects
which limit their fun ction alit y.
It is im possible to recruit staff wit h the skill s required.
Key staff are ill and unava il able at criti cal tim es.
Requi red training for staff is not availa ble.
The o rgan isation is restructured so that diff erent manag ement
are respons ible for the project.
Organ isationa l f inancial problems force reduc tions in the project
budge t.
The cod e gen erated by CASE tools is i neffi cient.
CASE tools canno t be integrated.
Changes to requirements which requir e major design rework are
proposed .
Customers fail to unde rstand the im pact of requirements
chang es.
The tim e requir ed to deve lop the software is unde restim ated.
The rate of defect repair is und erestim ated.
The size o f t he software is unde restim ated.
Software Engineering, 6th edition. Chapter 4
Slide 30
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 31
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 rework 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 32
Risk planning




Consider each risk and develop a
strategy to manage that risk
Avoidance strategies
Minimisation strategies
Contingency plans
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 33
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 34
Risk monitoring



monitor risks regularly - becoming less or
more probable
Also - whether the effects of the risk have
changed
Each key risk discussed at management
progress meetings
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 4
Slide 35
Risk factors
Risk type
Techno logy
People
Organ isationa l
Tools
Requi rements
Estim ation
©Ian Sommerville 2000
Potential indi cators
Late delivery of hardware or support software, many
reported techno logy problems
Poor staff morale, poor relationsh ips amongst team
member, job availa bilit y
organ isationa l gos sip, lack of action by senior
manage me nt
reluctance by team members to use tools , complaints
about CASE tools, demand s for highe r-powered
workstations
many requir ements chang e reque sts, customer
complaints
fail ure to meet agreed schedule, failure to clear
reported defects
Software Engineering, 6th edition. Chapter 4
Slide 36
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 37
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 38