2005 IAS, Universitt Stuttgart 1

SER
4 Project Management
Software Engineering for Real-Time Systems
4.1 Contents of Project Management
4.2 Preparing a Development Project
4.3 Project Planning
4.4 Risk Management
4.5 Project Execution
4.6 Summary
2005 IAS, Universitt Stuttgart 2
SER
Objectives
To introduce software project management and to describe its distinctive
characteristics
To discuss project planning and the planning process
To show how graphical schedule representations are used by project
management
To discuss the notion of risks and the risk management process
To introduce techniques for follow-up and effective execution
4.1 Contents of Project Management
2005 IAS, Universitt Stuttgart 3
SER
Software project management
Definition: Organising, planning, scheduling, and executing software
projects
Concerned with activities to ensure that software is delivered on time and
on schedule and in accordance with the requirements of the organisations
developing and procuring the software
Project management is needed because software development is always
subject to budget and schedule constraints that are set by the organization
developing the software
4.1 Contents of Project Management
2005 IAS, Universitt Stuttgart 4
SER
Reasons for the failure of projects
absence of project planning, project organization and
project standards
incompetent project leadership
absence of an up to date documentation
deficient project progress and quality control
absence of an efficient cost control
4.1 Contents of Project Management
management
failures
2005 IAS, Universitt Stuttgart 5
SER
Main Skills of effective project managers:
Planning
Project monitoring and reviews
Staff selection and evaluation
Resource management
Risk management
Cost effectiveness control
Contact to customers
Leadership
And a good solid understanding of underlying technical aspects, markets, and
organizational interdependencies
4.1 Contents of Project Management
2005 IAS, Universitt Stuttgart 6
SER
Magic triangle of project management
4.1 Contents of Project Management
functionality,
efficiency,
reliability,
usability,
extendibility, ...
functionality,
efficiency,
reliability,
usability,
extendibility, ...
quality
quality
development,
inception,
transition,
Industrialization,
maintenance
development,
inception,
transition,
Industrialization,
maintenance
costs
costs
Product life cycle,
Efficiency,
predictability
Product life cycle,
Efficiency,
predictability
time
time
2005 IAS, Universitt Stuttgart 7
SER
Tasks before the actual start of the project execution
determine project objectives
define product(s)
identify constraints
determine limitations on the costs
estimation of deadlines
project plan (software management plan) detailed execution plans
demarcation of the technical content
scheduling
cost management (resource management)
personnel planning
risk management
4.1 Contents of Project Management
2005 IAS, Universitt Stuttgart 8
SER
Tasks during the project
project sequence control
schedule control
control of resources
4.1 Contents of Project Management
Tasks after the project
preparation and launching of service, operations, and maintenance
projects schedule control
review and feed back cost / schedule vs. actuals
archiving project information
2005 IAS, Universitt Stuttgart 9
SER
Project management is no isolated discipline
4.1 Contents of Project Management
plan and control the
project
provide prerequisites
and software
development
environments
quality
requirements
test products
develop
product
plan the
product
configuration
administrate
products/
rights/
relations
configuration
structure
rights,
relations
product
quality
requirements
product
PM
Dvmt / QA
Dvmt
CM
actual
data
actual
data
actual
data
desired
data
desired
data
desired
data WBS
WBS
WBS
Q
A

r
e
s
u
l
t
2005 IAS, Universitt Stuttgart 10
SER
4 Project Management
Software Engineering for Real-Time Systems
4.1 Contents of Project Management
4.2 Preparing a Development Project
4.3 Project Planning
4.4 Risk Management
4.5 Project Execution
4.6 Summary
2005 IAS, Universitt Stuttgart 11
SER
Preparing a Development Project
4.2 Preparing a Development Project
Concepts
determining or adapting a project organization
identification of the individual steps of the project on the basis of a software
life cycle model
identification of work products
determining a Work Breakdown Structure (WBS)
Identifying applicable processes, infrastructure
Contract evaluation, cost information, business case
Content of a project plan
All tasks that have to be executed, scheduling, dependencies
Procedures, methods, tools to be used
Expected results and deliverables in the individual phases, milestones
Skills profiles and responsibilities
Risk list and mitigation actions
2005 IAS, Universitt Stuttgart 12
SER
Cost estimation
Example: COCOMO-method
software without interface to existing systems (standalone IS)
PM = 2,4 x (KLOC)
1,05
software with a couple of interfaces to existing systems
PM = 3,0 x (KLOC)
1,12
software that has to fit in existing systems (real-time, embedded)
PM = 3,6 x (KLOC)
1,20
4.2 Preparing a Development Project
2005 IAS, Universitt Stuttgart 13
SER
Cost distribution matrix (example)
4.2 Preparing a Development Project
phase incep- design imple- tran-
tion menta- sition
tion
analyze requirements 42% 10% 3% 2%
design the product 16% 42% 10% 4%
coding + verification 10% 14% 36% 26%
test planning + execution 16% 18% 35% 40%
project management 8% 7% 5% 6%
configuration management 3% 2% 6% 15%
quality assurance 5% 7% 5% 7%
100% 100% 100% 100%
Globally per phase 8% 18% 48% 26%
2005 IAS, Universitt Stuttgart 14
SER
Example: cost estimation
4.2 Preparing a Development Project
You want to build an embedded real-time system and you estimate
roughly 40 000 source lines.
According to the COCOMO basic equation you estimate the efforts in
person-months as:
PM = 2.4 * (thousand-source lines)
1.2
= 2.4 * 40
1.2
= about 200 person months
According to the cost matrix indicated above the distribution can be estimated
as follows:
phase: requirement analysis and conception : 16 PM
design : 36 PM
implementation : 96 PM
integration and test : 52 PM
2005 IAS, Universitt Stuttgart 15
SER
Example: In the implementation phase the distribution can
be considered as follows:
4.2 Preparing a Development Project
analysis activities : 3% or 3 PM
design activities : 10% or 10 PM
coding activities: 36% or 35 PM
test activities : 35% or 34 PM
project management: 5% or 5 PM
configuration management: 6% or 6 PM
quality assurance: 5% or 5 PM
2005 IAS, Universitt Stuttgart 16
SER
Duration Total Effort Defects
Key Drivers of Project Performance
The Key Development Drivers determine Time, Effort and Quality
4.2 Preparing a Development Project
Driver:
Product Size
(Features)
Process
Productivity
Staffing/ Time
Pressure
For instance, an increase in staffing leads to decreased schedule
duration, increased development costs, and more defects.
2005 IAS, Universitt Stuttgart 17
SER
4 Project Management
Software Engineering for Real-Time Systems
4.1 Contents of Project Management
4.2 Preparing a Development Project
4.3 Project Planning
4.4 Risk Management
4.5 Project Execution
4.6 Summary
2005 IAS, Universitt Stuttgart 18
SER
Types of project plans
4.3 Project Planning
Plan Description
Quality plan Describes the quality procedures and
standards that will be used in a project.
Validation plan Describes the approach, resources and
schedule used for system validation.
Configuration
management plan
Describes the configuration management
procedures and structures to be used.
Maintenance plan Predicts the maintenance requirements of
the system, maintenance costs and effort
required.
Staff development plan Describes how the skills and experience of
the project team members will be
developed.
Delivery plan Describes the different work products
with responsibilities, versioning, dates.
2005 IAS, Universitt Stuttgart 19
SER
Project plan structure
Introduction
Project organization
Risk analysis
Hardware and software resource requirements
Work breakdown
Project schedule
Monitoring and reporting mechanisms
4.3 Project Planning
2005 IAS, Universitt Stuttgart 20
SER
Example: Project Portal
4.3 Project Planning
Hyperlinks to
X.500 services
Hyperlinks to
Decision Review Portals
Hyperlinks to
Product Database
Progress
Bar
Xyz
2005 IAS, Universitt Stuttgart 21
SER
Project scheduling
Activities / tasks in a project should be organised to produce tangible
outputs to judge progress
Split project into tasks and estimate time and resources required to
complete each task.
Organize tasks concurrently to make optimal use of workforce (mapping to
available skills over time, considering dependencies)
Critical path analysis. Minimize task dependencies to avoid delays caused
by one task waiting for another to complete
Backwards and forward planning
Avoid too much detail. Details only for next month to come.
4.3 Project Planning
2005 IAS, Universitt Stuttgart 22
SER
The project scheduling process
4.3 Project Planning
Identify
activities
Identify
activities
dependencies
Estimate
resources
for activities
Allocate
people to
activities
Create project
charts
Software
requirements
Activity charts
and bar charts
2005 IAS, Universitt Stuttgart 23
SER
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
Too small tasks start micro-management. Allow 1..2 weeks per task.
4.3 Project Planning
2005 IAS, Universitt Stuttgart 24
SER
Non-linear Relationships
4.3 Project Planning
1
2
3
100 K
S
tm
ts (P
I=12)
90 K
S
tm
ts (P
I=12)
time
target
budget
limit
time
effort
0
4
100 KStm
ts (PI=13)
Legend
1 - optimized solution
(shortest distance between
0 and graph)
2 - optimized to time target
3 - optimized to budget limit
4 - fixed time and budget limit
(result : new size)
effort =
B * size
PI * time
3
4 3
Graph :
2005 IAS, Universitt Stuttgart 25
SER
Auxiliary means for planning
project structure plan
graphic display of the hierarchical structure of the tasks that have to
be executed in the project
the lowest level is the level of work packages
product tree
graphic display of the hierarchical structure of the products that have
to be realized in the project
network plan
graphic display of the logical processing sequences of project
activities
bar chart
graphic display of the execution and the temporal arrangement of
project activities
project organization plan
graphic display of the hierarchical structure of participating persons
in the project
4.3 Project Planning
2005 IAS, Universitt Stuttgart 26
SER
Connection of project structure plan and network plan
4.3 Project Planning
project
AV 1.1
task cluster-1-1
WP 3.1
task cluster-2-1
WP 3.3
task cluster-1-2
WP 3.2
task cluster-2-2
WP 3.4
task cluster-1-1
WP 3.1
task cluster-1-2
WP 3.2
task cluster-2-1
WP 3.3
partial activity-2-2-1
WP 4.1
partial activity-2-2-2
WP 4.2
partial project-1
AV 2.1
code 1
partial project-2
AV 2.2
code 2
2005 IAS, Universitt Stuttgart 27
SER
There are two strictly different deadline calculation methods
used in the network planning:
Forward planning
The start of the project is fix. The following deadlines can be calculated
with the help of the estimated duration of the network plan activities.
Backwards planning
The end of the project is fix. The precedent project deadlines can be
calculated with the help of the estimated duration of the precedent network
plan activities.
4.3 Project Planning
2005 IAS, Universitt Stuttgart 28
SER
Example: network planning
4.3 Project Planning
day # 1 day # 3
2
4
day # 3
day # 7
5
day # 7 day # 12
3
day # 3 day # 6
day # 1 is the first day of the project
day # 12 is the day following the project end
2005 IAS, Universitt Stuttgart 29
SER
Introduction of buffer times
Buffer times clearly indicate the highest possible delay of an activity in the
network plan that will not affect the final date of the project.
total buffer
This time is at disposal for an activity. Other activities are affected.
free buffer
This time is at disposal for an activity and will not affect another
activity.
4.3 Project Planning
2005 IAS, Universitt Stuttgart 30
SER
Critical Path Method
The activities without a buffer are considered as being critical. Those activities
are located on the critical path. Therefore the network planning can also be
referred to as the Critical Path Method.
4.3 Project Planning
day # 1
day # 1
day # 3
day # 3
2
4
day # 3
day # 3
day # 7
day # 7
5
day # 7
day # 7
day # 12
day # 12
3
day # 3
day # 4
day # 6
day # 7
0
0
1
1
0
0
0
0
critical path
2005 IAS, Universitt Stuttgart 31
SER
Project organization
Determining the project team:
What kind of teams are needed ?
What kind of relationships to superiors and functional departments exist ?
Project and matrix organization
Which work packages are processed by which team?
Which work packages are processed by which team?
Note that you get not always the best resources on your project.
This impacts estimation and planning (task duration, initial quality level).
4.3 Project Planning
2005 IAS, Universitt Stuttgart 32
SER
4.3 Project Planning
Relationship project structure, project organization, scheduling
plan of project structure
project
sub
project B
sub
project A
sub
project C
A1
A2
A3
B1
B2
C1
C2
C3
Task entities
requirements
Proj.Mgr
Maier
assistant
Mller
sub project
manager
Bauer
sub project
manager
Schneider
Lehmann
Schulze
Schmidt
Comp. S
dpmt U
plan of project organization
scheduling
through network plan
B1
A1
A2
C1
B2
C2
A3
C3
plan of
costs
resource
plan
2005 IAS, Universitt Stuttgart 33
SER
4 Project Management
Software Engineering for Real-Time Systems
4.1 Contents of Project Management
4.2 Preparing a Development Project
4.3 Project Planning
4.4 Risk Management
4.5 Project Execution
4.6 Summary
2005 IAS, Universitt Stuttgart 34
SER
Risk Management
Risk management is concerned with identifying risks and drawing up
plans to minimise their effect on a project.
Risk = probability of undesired outcome x effect
Project risks affect schedule or resources
Product risks affect the quality or performance of the software
being developed
Business risks affect the organization developing or procuring the
software
4.4 Risk Management
2005 IAS, Universitt Stuttgart 35
SER
The risk management process
4.4 Risk Management
Risk strategy
Risk
identification
Risk Evaluation
Risk Mitigation
Operational Risk
Management
Strategic Risk
Management
Changed environmental conditions and re-estimation
Project reviews
Prioritized mitigation list
and follow-up metrics
Project scenarios,
proposed actions
Environment, processes,
project objectives, tools,
requirements, staffing
Business objectives,
strategy
Risk Monitoring
2005 IAS, Universitt Stuttgart 36
SER
Risk Identification and Risk Evaluation
Assess probability and (undesired) effects of each risk
Probability may be very low, low, moderate, high or very high
Risk effects might be catastrophic, serious, tolerable or insignificant
Relate identified risks to project planning to evaluate impacts (e.g., delays).
4.4 Risk Management
2005 IAS, Universitt Stuttgart 37
SER
Risk Mitigation
Consider each risk and develop a strategy to manage that risk
Avoidance strategies
The probability that the risk will arise is reduced
Mitigation strategies
The impact of the risk on the project or product will be reduced
Contingency plans
If the risk arises, contingency plans are plans to deal with
that risk
4.4 Risk Management
2005 IAS, Universitt Stuttgart 38
SER
Risks and Mitigation Proposals
4.4 Risk Management
Risik Potential Mitigation
1 Insufficient resources Consider capabilities; use best capabilities; team building;
synchronisation with internal competitors; training
2 Unrealistic planning and
budget
Detailed cost estimation; design to cost; incremental development;
reuse; evaluate and prioritize requirements
3 Wrong functionality is
developed
Analysis of project objectives; user interviews; use cases;
prototyping; early documentation; quality function deployment
4 Inadequate user
interface
Prototyping; use cases; scenarios; user interviews; user
involvement; usability laboratory
5 Gold plating Requirements evaluation; prorotyping; cost-benefit analysis;
design to cost; value analysis
6 Continuous changes of
requirements
Thresholds and milestones for requirement changes; incremental
development; information hiding
7 Insufficient reused
external components
Benchmarking of suppliers; inspetcions; compatibility analysis;
early integration tests with supplier
8 Poor Outsourcing
Management
Interface management; audits in front of each milestone; usability
and result-driven contracts; competition; common teams
9 Insufficient real-time
performance
Simulation; modelling; prototyping; performance models and
measurements; early test environments for critical resources
10 Inadequate technical
know-how of staff
In-depth technical analysis of requirements vs. available skills;
cost-benefit analysis; prototyping; coaching; consulting
2005 IAS, Universitt Stuttgart 39
SER
Risk Monitoring
Assess each identified risks regularly to decide whether or not it is
becoming less or more probable
Also assess whether the effects of the risk have changed
Each key risk should be discussed at management progress
meetings
4.4 Risk Management
2005 IAS, Universitt Stuttgart 40
SER
4 Project Management
Software Engineering for Real-Time Systems
4.1 Contents of Project Management
4.2 Preparing a Development Project
4.3 Project Planning
4.4 Risk Management
4.5 Project Execution
4.6 Summary
2005 IAS, Universitt Stuttgart 41
SER
Project Execution
Tasks of the project management during the project execution
monitoring deadlines
planning of resources
release of work packages
release of work packages
detection of problems and problem solutions
Basis:
data of project planning
report system
analysis through project management tools
4.5 Project Execution
2005 IAS, Universitt Stuttgart 42
SER
Project Management and SW Processes
4.5 Project Execution
SW
process
Work
products
Product and
process
metrics
Risk
analysis
corrective
actions
evaluation
Process and
project goals
2005 IAS, Universitt Stuttgart 43
SER
Example: Decision Review Portal
4.5 Project Execution
Hyperlinks to specific
Documents vaults
Mail to
Invitation List
Quick Status
Overview
Decision Review Checklist
with Responsibility + Status
2005 IAS, Universitt Stuttgart 44
SER
Monitoring deadlines
4.5 Project Execution
Monitoring of project progress is
based on a state changes of
activities or work products. E.g.,
documents
requirements
test cases
defects
released
planned
accepted
in process
being tested
states of the
work package
2005 IAS, Universitt Stuttgart 45
SER
What does a progress report contain ?
information on the progress of the development
information on occurring difficulties
message on achieved states (e.g., work products, requirements)
information on the stage of desired development results (e.g., quality)
information on consumed resources
estimation on further resource needs (e.g., budget, skills, people, time)
4.5 Project Execution
2005 IAS, Universitt Stuttgart 46
SER
Progress Reports Compare Actuals with Plans.
4.5 Project Execution
Total Cum Normalized Defects
0
600
S 2 3 4 5 6 7 8 9
S 2 4 6 7 8 9
D
e
f
e
c
t
s
1 4 7 10 13 16 *
Apr
'99
Jul Oct Jan
00
Apr Jul
Total Cum Effort
0
150
S 2 3 4 5 6 7 8 9
S 2 4 6 7 8 9
P
M
1 4 7 10 13 16 *
Apr
'99
Jul Oct Jan
00
Apr Jul
Total Defect Rate
0
80
S 2 3 4 5 6 7 8 9
S 2 4 6 7 8 9
D
e
f
e
c
t
s
1 4 7 10 13 16 *
Apr
'99
Jul Oct Jan
00
Apr Jul
Aggregate Staffing Rate
0
15
30
S 2 3 4 5 6 7 8 9
S 2 4 6 7 8 9
P
e
o
p
l
e
1 4 7 10 13 16 *
Apr
'99
Jul Oct Jan
00
Apr Jul
Total Cum Normal Defects
Total Defect Rate
Total Cum Effort (PM)
Agg. Staff
Size (ESLOC(K))
PI 12.6 14.6
MBI 3.0 3.5
Date 05.09.2000 (17.16 mos)
Plan
Actual/
Forecast
Est. to
Complete
613 769 1
1 1
123.89 201.93 0.00
0.21
37.30 67.30 0.00
Current Plan Actual
Size
0
40
80
S 2 3 4 5 6 7 8 9
S 2 4 6 7 8 9
E
S
L
O
C

(
t
h
o
u
s
a
n
d
s
)
1 4 7 10 13 16 *
Apr
'99
Jul Oct Jan
00
Apr Jul
Interpolated Current Forecast Green Control Bound Yellow Contr. Bound
S = DR1, 2 = CDR, 3 = FCC, 4 = SIT, 5 = DR2, 6 = IOC, 7 = DR4, 8 = 99R, 9 = DR5
Actuals, History, Outlook
compared to approved plan
2005 IAS, Universitt Stuttgart 47
SER
Progress Reports check progress with Respect to
Committed Plans
4.5 Project Execution
2005 IAS, Universitt Stuttgart 48
SER
to Avoid Fog and Table Dancing
4.5 Project Execution
statement meaning
1 The program is practically finished. It is still in the designing phase.
2 A subprogram is still missing. The main program is 10% done.
3 The program still contains slight errors. The program crashes right after the
printout of the header.
4 The program is being tested. The program survived the first trial
without terminating early.
5 The program passed the overall test. The program runs with the values 1,3,5
but not with 0,2,4.
6 The program has been sold over 50 times. A pilot client will recommend the
program after successful testing to his
subsidiaries.
7 The program is being adopted in a system. In a fever of exitement it is tried to run
the program on the initial system still
without much success.
8 Fully compatible and portable on all common ...as long as the systems are exactly the
systems... same (incl. space planning)
9 The program is being introduced to the market The first command is being encoded.
soon.
10 He doesn't have time, he's at a customer's place.Man hat keine Zeit, ist beim Kunden, There's nothing like it should be at all.
Computer failure.
11 The documentation is being worked upon. ...discovered by change on scrap paper.
2005 IAS, Universitt Stuttgart 49
SER
4 Project Management
Software Engineering for Real-Time Systems
4.1 Contents of Project Management
4.2 Preparing a Development Project
4.3 Project Planning
4.4 Risk Management
4.5 Project Execution
4.6 Summary
2005 IAS, Universitt Stuttgart 50
SER
Summary
Good project management is essential for project success
The intangible nature of software causes problems for management
Managers have different 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
A project milestone is a predictable state where some formal report of
progress s 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
4.6 Summary
2005 IAS, Universitt Stuttgart 51
SER 4.6 Summary
Useful Hints
A good management is more important than a good technique, or tool
Understanding of priorities of clients
Motivation of the staff is the key to success
A couple of good developers are better than a lot of fair developers
Trust your staff
The ability to communicate is essential
Follow progress based on results, not documents
Do not set up unrealistic plans - culture would suffer as well
Provide visibility and ask for accountability. Dont hide things that are out of
your control.
Correct planning of resources, if necessary
2005 IAS, Universitt Stuttgart 52
SER
Further Information
4.6 Summary
Software Project Survival Guide
by Steve C. McConnell,
$19.99
Paperback - 250 pages
Microsoft Press;
ISBN: 1572316217
Very pragmatic with many useful
hints on how to best manage a
project.