Transcript Project Management

Based on Chapter 5 of the textbook [SE-8]
Ian Sommerville, Software Engineering, 8th Ed., Addison-Wesley, 2006
and on Ch5 PPT presentation from http://www.software-engin.com/
September 17, 2007
1
Outline

Introduction
 Project Planning
 Project Scheduling
 Risk Management
2
Introduction.


Software project management is aimed to ensure that the
software is delivered on time, within budget and schedule
constraints, and satisfies the requirements of the client
Management of software projects is different from other
types of management because:
● Software is not tangible
● Software processes are relatively new and still “under trial”
● Larger software projects are usually “one-off” projects
● Computer technology evolves very rapidly
3
.Introduction

4
Management activities:
● Writing proposals
● Planning the project
● Scheduling the project
● Estimating the cost of the project
● Monitoring and reviewing the project’s progress
● Selecting, hiring, and evaluating personnel
● Writing reports and giving presentations
Project Planning…



5
A project plan should be drawn at the start of the project. This plan
drives the project and needs to be continuously adjusted
The role of the project manager is to anticipate possible problems
and be prepared with solutions for these problems
Other plans that need be developed:
● Quality plan
● Validation and verification plan
● Configuration management plan
● Maintenance plan
● Staff development plan
.Project Planning..

The planning process [Fig 5.2, SE-8]
Establish the pr oj ect constraints
Make ini tial assessments of the proj ect par ameter s
Define project mi lestones and del iverabl es
while project has not been completed or cancell ed loop
Draw up pr oj ect schedul e
Initi ate acti vities accor di ng to schedul e
Wai t ( for a whi le )
Review project pr og ress
Revise estimates of pr oj ect par ameter s
Update the proj ect schedule
Re- negotiate project constraints and del iverabl es
if ( pr oblems arise ) then
Initi ate technical r eview and possi ble r evisi on
end if
end loop
6
..Project Planning.

The structure of the project plan:
● Introduction (objectives, constraints)
● Project organization (team structure, personnel involved, roles)
● Risk analysis (types of risk, probabilities, solutions to prevent or
●
●
●
●
7
reduce the risk)
Hardware and software resources needed (prices, delivery schedule)
Work breakdown (activities, milestones, deliverables)
Project schedule (dependencies between activities/tasks, work
assignments, time allocated per task)
Monitoring and reporting mechanisms (reports, dates)
…Project Planning



Milestone = end-point of a specific, distinct software process
activity or task (for each milestone a report should be presented
to the management)
Deliverable = project result delivered to the client
In order to establish milestones the phases of the software
process need be divided in basic activities/tasks. Example for
requirements engineering [Fig. 5.3, SE-8]
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
8
Project Scheduling……

9
Software managers:
● Divide the project in activities/tasks
● Estimate time and resources needed to finish the project
● Allocate resources to tasks
● Try to employ efficiently all the project personnel
● Minimize dependencies between tasks and teams
● Prepare contingency plans
● Rely on experience and intuition
.Project Scheduling…..

Identify
activities
Software
requirements
10
The scheduling process [Fig. 5.4, SE-8]
Identify activity
dependencies
Estimate resources
for activities
Allocate people
to activities
Create project
charts
Activity charts
and bar charts
..Project Scheduling….

Graphical notations used in software
project scheduling:
● Tables: summary description of tasks
● Bar charts: show schedule against the time
● Activity charts: graphs that depict dependencies
between tasks and indicate the critical path (the
longest path in the activity graph)
11
…Project Scheduling…

Task
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
12
Example of tabular description [Fig. 5.5, SE-8]:
Duration (days)
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)
….Project Scheduling..

Example of activity chart [Fig. 5.6, SE-8]
8 day s
1 4 /7 /0 3
15 da y s
M1
T3
15 da y s
T9
T1
5 day s
4 /8/ 03
T6
M4
2 5 /7 /0 3
4 /7 /0 3
st ar t
M3
2 5 /8/ 03
M6
7 day s
2 0 day s
15 day s
T7
T2
25 /7 /0 3
10 da y s
M2
T4
T11
10 day s
M7
T5
5 /9/ 03
11 /8/ 03
T10
1 8 /7 /0 3
M8
15 da y s
10 da ys
T12
M5
2 5 day s
13
Fini sh
T8
19 /9/ 03
…..Project Scheduling.

Example of bar chart [Fig. 5.7, SE-8]
4 /7
11 /7
1 8/7
2 5/7
1 /8
8 /8
1 5/8
2 2/8
2 9/8
5 /9
1 2/9
1 9/9
Start
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8
14
T12
Fini sh
……Project Scheduling

Staff allocation chart [Fig. 5.8, SE-8]
4/7
Fre d
11/7
18/7
25/
1/8
8/8
15/8 22/8
29/8
5/9
T4
T8
T11
T12
Ja ne
T1
T3
T9
Anne
T2
T6
Jim
Mar y
15
T7
T5
T10
12/9
19/9
Risk Management…….

Risk = some adverse circumstance that may
happen and affect negatively the project, the
product, and/or the business
 Categories of risk:
● Project risks
● Product risks
● Business risks
 Risk management means anticipating risks and
preparing plans to reduce their effect
16
.Risk Management……

17
Examples of risks in the software process [Fig. 5.9, SE-8]
Risk
Affects
Description
Staff turnover
Project
Experienced staff w ill leave the project before it is finished.
Management change
Project
There will be a change of o rganisational management with
different priorities.
Hardware unavailability
Project
Hardware that is essential for the project will not be
delivered on schedule.
Requirements change
Project and
product
There will be a larger numb er of changes to the
requirements than anticipated.
Specification delays
Project and
product
Specifications of essential interfaces are not available on
schedule
Size underestimate
Project and
product
The size of t he system has been underestimated.
CASE tool underperfo rmance
Product
CASE tools which support the project do not perfo rm as
anticipated
Technology change
Business
The underlying technology on which the system is built is
superseded by new technology.
Product comp etition
Business
A competitive product is marketed before the system is
completed.
..Risk Management…..

The risk management activities [Fig. 5.10, SE-8]
Risk
identification
List of potential
risks
18
Risk analysis
Risk planning
Risk
monitoring
Prioritised risk
list
Risk avoidance
and contingency
plans
Risk
assessment
…Risk Management….

19
Types of risk in risk identification [Fig. 5.11, SE-8]
Risk type
Poten tial i n dic ators
Technology
Late delivery of hardware or support software, many reported
technology problems
People
Poor st aff morale, poor relat ionships amongst team member,
job availability
Organisat ional
Organisat ional gossip, lack of act ion by senior management
Tools
Reluctance by team members t o use tools, complaint s about
CASE tools, demands for higher-powered workstat ions
Requirement s
Many requirements change reques t s, customer complaint s
Est imat ion
Failure to meet agreed schedule, failure to clear reported
defect s
….Risk Management…

Risk analysis:
● Estimate risk probability:
 Very
low (< 10%)
 Low (10-25%)
 Moderate (25-50%)
 High (50-75%)
 Very high (> 75%)
● Establish risk seriousness:
 Insignificant
 Tolerable
 Serious
 Catastrophic
20
…..Risk Management..

Risk planning means preparing a strategy
to deal with each of the risks identified
 Classes of strategies:
● Avoidance strategies: the probability of the risk
will be diminished
● Minimization strategies: the effect of the risk will
be reduced
● Contingency strategies: plans for the worst case
scenarios
21
……Risk Management.

22
Examples of risk management strategies [Fig. 5.13, SE-8]
Risk
Strategy
Organisational
financial problems
Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business.
Recruitment
problems
Alert customer of potential difficulties and the
possibility of delays, investigate buying-in
components.
Staff illness
Reorganise team so that there is more overlap of work
and people therefore understand each other’s jobs.
Defective
components
Replace potentially defective components with boughtin components of known reliability.
Risk
Strategy
Requirements
changes
Derive traceability information to assess requirements
change impact, maximise information hiding in the
design.
Organisational
restructuring
Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business.
Database
performance
Investigate the possibility of buying a higherperformance database.
Underestimated
development time
Investigate buying in components, investigate use of a
program generator
…….Risk Management

Risk monitoring:
● Frequently re-assess the risks
Changes in risk probability?
 Changes in risk gravity?

● Take into consideration risk factors
● Discuss key risks at each management project
progress meeting
23