Software Project Management
Lecture 1
Introduction to Software Project
Management
Overview
Software engineering
Software project management
Formal methods
Software Project Management 2
Software Crisis
Faulty software
Delay in completion time
Over budgeted
Difficult to maintain software
Software Project Management 3
Some UK projects
Home Office asylum seeker Casework system: £80m;
abandoned 2001 (Siemens).
Pathway UK benefits identity card system:
abandoned 1999 with £1bn losses (ICLFujitsu).
Datacentre for UK cabinet office: £85m, cancelled in
2004 (ITNET).
MRC Laboratory of Molecular Biology, FAMIS
purchasing system: £55m; ‘operating failure’
(LogicaGMC).
UK e-University: £62m; abandoned 2004 (Sun,
though only £20m of the full figure).
Software Project Management 4
American experience
25% of development projects are abandoned
probability of cancellation rises to 50% for
largest developments
average project overshoots schedule by 50%
75% of systems are regarded as ‘operating
failures’
U.S. Bureau of Labor Statistics, 1997
Software Project Management 5
Some important facts
Relative cost of the software in a
system is growing
Increase in demand for software
Increase in size and complexity of
software
Increase in performance of hardware
Software Project Management 6
Software Engineering
An initial, loose definition:
“the establishment and use of sound
engineering principles in order to obtain,
economically, software that is reliable and
works efficiently on real machines”
[Bauer, 1969]
Software Project Management 7
A more useful definition
“The application of scientific and engineering efforts to
1. transform an operational need into a system through
the use of an iterative process of definition, analysis,
design, test, and validation;
2. ensure the compatibility of all interfaces […];
3. integrate reliability, maintainability, disposability, […]
to meet cost, schedule, and technical performance
objectives.”
[Blanchard, 1998]
Software Project Management 8
Software Engineering
Aimed at large software
Systematic and well-defined techniques,
methodologies and tools
To design, code, test and maintain
quality software
Within a resource constrained
environment
Software Project Management 9
Large Software
Developed by more than one person
Effective communications are important
– standards, documentation, etc
Management issues
Techniques and methodologies are
useful only if automated systems can be
built upon them
Software Project Management 10
Phases of Software
Development
Requirements analysis and specification
Design
Coding
Testing
Installation
Maintenance
Software Project Management 11
Some important observations
Maintenance is the most expensive
phase and coding is the least expensive
phase
The earlier the detection of faults, the
less expensive the correction of faults
Software Project Management 12
Characteristics of software
Simple and elegant mathematical
representation
Logic intensive
Cannot have partial completion
Design costs are relatively expensive
Software Project Management 13
What is a project?
Key characteristics of a project:
A planned activity
Specific objectives or products
Work to be carried out in several phases
Limited resources
Deadline
Large and complex
Software Project Management 14
Major differences between software
products and hardware products
Progress of software development is not
obviously visible
Modifications of software products are
more easy and flexible
Software products are usually more
complex than the hardware products in
terms of development or construction
cost
Software Project Management 15
Major processes in developing a
software system
Feasibility study
Project planning
Project execution
Software Project Management 16
Feasibility Study
Analyze the general requirements, costs
and the functionalities and services
provided by the system to be developed
Aimed to determine whether a system
should be developed or not
Can be viewed as a project itself
Software Project Management 17
Important factors in planning
a software project
To know the nature of the system to be
developed
A management information system or a
control system
To know clearly the objectives and
products of the project
How to evaluate the objectives and
products after the completion of the
project
Software Project Management 18
What is management?
Management involves the following activities:
Planning
Staffing
Innovating
Directing
Monitoring
Liaising
…?
Software Project Management 19
What is software project
management?
Understand the characteristics of
software products
Understand what is meant by a project
Understand what is meant by
management
Software Project Management 20
Common problems with
software projects
Lack of quality standards and measures
Lack of measurable milestones
Difficult to make the progress visible
Poor communications
Poor documentation
Frequent changes of requirements
Over budget and late delivery of software
Software Project Management 21
Major issues of software project
management to be covered
Software development models
Software size and cost estimation
Software project planning
Software risk management
Resource allocation
Standards: ISO 9000 and CMM
Performance tracking and reporting
Software Project Management 22
Major issues of software project
management to be covered (cont’d)
Software project configuration
management
Software project team management
Software Project Management 23
Main problems encountered with
requirements and specifications
Ambiguous
Incomplete
Inconsistent
Software Project Management 24
Main problems encountered with
requirements and specifications (cont’d)
To overcome these problems via
Formality – achieving precision
Abstraction – concentrating on essential
parts
Software Project Management 25
Formal Methods
Mathematically based techniques
Providing a precise and concise language
Supporting formality
Supporting abstraction
Supporting logical reasoning
May support automation
Software Project Management 26
Example: traffic light control
• Simple 4-way crossroads
• Traffic lights control each entry
• Roads run North-South and East-West
Software Project Management 27
type
Light == red | redamber | green | amber,
Junction :: ns : Light ew : Light timer : Nat
value
nextLight : Light → Light
nextLight(l) is
case l of
red → redamber,
redamber → green,
green → amber,
amber → red
end,
Software Project 28
Management
limit : Junction → Nat
limit(j) is
if ns(j) isin {amber, redamber} \/
ew(j) isin {amber, redamber}
then 1 else 4 end,
next : Junction → Junction
next(j) is
if limit(j) ≤ timer(j)
then mk_Junction(nextLight(ns(j)), nextLight(ew(j)), 0)
else mk_Junction(ns(j), ew(j), timer(j) + 1)
end,
safe : Junction → Bool
safe(j) is ~ (ns(j) = green /\ ew(j) = green)
Software Project 29
Management
Critical properties
Safety:
Not both green at the same time:
G(safe(junction))
i.e. Globally (in all states), the junction is safe
Liveness:
In each direction, lights will eventually go green:
G(F(ns(junction) = green))
i.e. Globally, in the Future, North-South is green
/\ G(F(ew(junction) = green))
Software Project Management 30
Is the junction safe and live?
Safe? – depends on what state it starts
in
Live? – yes
We can model check the specification
to prove these.
Software Project Management 31
transition_system
[T]
local junction : Junction := mk_Junction(red, red, 0)
in
[change]
true ==> junction' = next(junction)
end
ltl_assertion
[safe] T |- G(safe(junction)),
[live_ns] T |- G(F(ns(junction) = green)),
[live_ew] T |- G(F(ew(junction) = green))
Software Project 32
Management
Counterexample for 'safe':
========================
Step 0:
junction = mk_Junction(red, red, 0)
------------------------
Step 1:
junction = mk_Junction(red, red, 1)
...
Step 4:
junction = mk_Junction(red, red, 4)
------------------------
Step 5:
junction = mk_Junction(redamber, redamber, 0)
...
Step 7:
junction = mk_Junction(green, green, 0)
Summary:
The assertion 'safe' is invalid.
The assertion 'live_ns' is valid.
The assertion 'live_ew' located at is valid.
Software Project 33
Management
What are formal methods for?
Clarify and fix requirements
Support early analysis:
Static analysis
Testing
Model checking
Proof
Provide a basis for implementation
Software Project Management 34
Specification languages
The traffic light example was written in
RAISE
There are many formal methods, some
general purpose, some specialised
Software Project Management 35
A good slogan
You may not be able to avoid making
mistakes …
But you must find them before they
cost too much!
Software Project Management 36
Modelling
Modern software engineering is based
on making models
A formal model (eg in RAISE) supports
more analysis than in informal one (eg
in UML)
Increasingly, implementations will be
derived from models: programmers will
be obsolete
Software Project Management 37
References
Hughes, B., and Cotterell, M. (1999)
Software Project Management, McGraw
Hill
Dean, C.N., and Hinchey, M.G. (1996)
Teaching and Learning Formal Methods,
Academic Press
Sommerville, I. (2001) Software
Engineering, Pearson Education.
Software Project Management 38
References
RAISE: http://www.iist.unu.edu/raise
Dines Bjørner (2006) Software
Engineering, Springer
Software Project Management 39
