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