Project Management

Lecture 1
Introduction to Project
Management
Overview
 Software engineering
 Software project management
 Formal methods
Software Crisis
 Faulty software
 Delay in completion time
 Over budgeted
 Difficult to maintain software
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 Engineering
 No standard definitions
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
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
Phases of Software
Development
 Requirements analysis and
specifications
 Design
 Coding
 Testing
 Operation
 Maintenance
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
Characteristics of software
 Simple and elegant mathematical
representation
 Logic intensive
 Cannot have partial completion
 Design costs are more expensive
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
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
Major processes in developing a
software system
 Feasibility study
 Project planning
 Project execution
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
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
What is management?
 Management involves the following
activities:
 Planning
 Staffing
 Innovating
 Directing
 Monitoring
 Liaising
 …?
What is software project
management?
 Understand the characteristics of
software products
 Understand what is meant by a project
 Understand what is meant by
management
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
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
 ISO 9000
 Performance tracking and reporting
Major issues of software project
management to be covered (cont’d)
 Software project configuration
management
 Software project team management
Main problems encountered with
requirements and specifications
 Ambiguous
 Incomplete
 Inconsistent
Main problems encountered with
requirements and specifications (cont’d)
 To overcome these problems via
 Formality – achieving precision
 Abstraction – concentrating on essential
parts
Formal Methods
 Mathematically based techniques
 Providing a universal and concise language
 Supporting formality
 Supporting abstraction
 Supporting logical reasoning
 May support automation
Why formal methods?
 Unambiguous
 Concise
 May support automatic verification
 May support automatic processing
Why not formal methods?
 Lack of knowledge
 Lack of experienced staff
 Lack of supporting tools
 Cost-effectiveness
Formal Methods
 Most commonly used mathematical
techniques:
 Set theory
 Logic
Formal Methods (continued)
 Two important aspects:
 Expressiveness
 Solvable properties – automation
 Logic
Expressiveness

 Propositional calculus

Solvability
 First-order predicate calculus
 Second-order predicate calculus
Example (Expressiveness):
Consider the following:
Every citizen has an ID number.
Since John is a citizen, John has an ID
number.
This kind of information cannot be
described using the propositional
calculus; first-order predicate calculus is
required.
Solvable Properties
 A problem is solvable if there is an
algorithm which can determine “yes” or
“no” as the solution to the problem
 A problem is unsolvable if it is not
solvable.
 A problem is partially solvable if there is
an algorithm which can determine “yes”
as the solution to the problem
Solvable Properties
(continued)
 The validity problem of the
propositional calculus is solvable
 The validity problem of the first-order
predicate calculus is unsolvable, but
partially solvable.
 The validity problem of the second-
order predicate calculus is not partially
solvable.
A Dilemma
 More expressive
 Solvable in preference to partially
solvable
 Partially solvable in preference to
unsolvable
Z
 Developed at Oxford University (UK) in
the late 1970s and early 1980s
 Uses set theory and first-order logic to
model the requirements
 Can check inconsistency among
requirements
Z
 A specification language is not a
programming language
 A what-to not a how-to
 Specify pre-conditions and post-
conditions
 Based on state-based models
Essentials of State-Based
Model
Besides variables and their types, we
have:
 State

 Invariant

 Input and output

 Operation
 An Example: Container and
Indicator
Container Indicator
light : { on, off }
contents : 
currLevel : 
capacity :  lowLevel : 

contents  capacity light = on  currLevel  lowLevel

Schema Name StorageTank

Container
Schema Signature Indicator

currLevel = contents
Schema Predicate capacity = 1500
lowLevel = 50
An Example: A Storage Tank
StorageTank
contents : 
capacity : 
light : { on, off }
currLevel : 
lowLevel : 

contents  capacity
light = on  currLevel  lowLevel
currLevel = contents
capacity = 1500
lowLevel = 50
 An Example: Filling the Tank
Message ::= okMsg | overfillMsg
FillTank Overfill
 StorageTank  StorageTank
fillAmount? :  fillAmount? : 
msg! : Message msg! : Message

currLevel + fillAmount?  capacity currLevel + fillAmount? >

currLevel’ = currLevel + fillAmount? capacity
msg! = okMsg msg! = overfillMsg

DoFillTank  FillTank  Overfill

References
 Hughes, B., and Cotterell, M. (1999)
Software Project Management, 2nd ed.,
McGraw Hill
 Dean, C.N., and Hinchey, M.G. (1996)
Teaching and Learning Formal Methods,
Academic Press
 Sommerville, I. (2001) Software
Engineering, 6th ed., Pearson Education.