Download ECSE 321: Introduction to Software Engineering

ECSE 321:
INTRODUCTION TO SOFTWARE ENGINEERING
Software Project Management
Daniel Sinnig, PhD
[email protected]
08-Jan-14
Department of Electrical and
Computer Engineering
ECSE 321: Introduction to Software Engineering
What is a project?
Some dictionary definitions:
“A specific plan or design”
“A planned undertaking”
“A large undertaking e.g. a public works scheme”
The Guide to the Project Management Body of Knowledge
(PMBOK), defines project as:
“a temporary endeavor undertaken to achieve a specific and unique product
or service.”
08-Jan-15
Daniel Sinnig, PhD
2
ECSE 321: Introduction to Software Engineering
What is a project?
• ‘Jobs’ – repetition of very well-defined and well understood tasks with
very little uncertainty
• ‘Exploration / Research’ – e.g. finding a cure for cancer: the outcome is
very uncertain
• Projects – in the middle!
©Hughes and Cotterell. “Software Project Management” (5th edition)
08-Jan-15
Daniel Sinnig, PhD
3
ECSE 321: Introduction to Software Engineering
Characteristics of projects
A task is more ‘project-like’ if it is:
• Non-routine
• Planned
• Aiming at a specific target
• Carried out for a customer
• Carried out by a temporary work group
• Involving several specialisms
• Made up of several different phases
• Constrained by time and resources
• Large and/or complex
©Hughes and Cotterell. “Software Project Management” (5th edition)
08-Jan-15
Daniel Sinnig, PhD
4
ECSE 321: Introduction to Software Engineering
In-class Exercise
Which of the following may be classified as projects?
•
•
•
•
•
•
•
•
Producing an edition of a newspaper
Writing a paper
Preparing a COMP 354 lecture
Getting married
Amending a financial computer system to deal with the EURO currency
A COMP 354 midterm
Writing an automated trading system
Installing a new version of MS Office
08-Jan-15
Daniel Sinnig, PhD
5
ECSE 321: Introduction to Software Engineering
What are software projects?
Are software projects really different from other projects?
Not really …but the following characteristics of software make
software more problematic to build than other engineered artefacts.
• Invisibility
• Complexity
• Conformity
• Flexibility
© C. Constantinidies
08-Jan-15
Daniel Sinnig, PhD
6
ECSE 321: Introduction to Software Engineering
Types of Software Projects
Software Projects can be:
• In-house: clients and developers are employed by the same
organization
• Out-sourced: clients and developers employed by different
organizations
• ‘Project manager’ could be:
– a ‘contract manager’ in the client organization
– a technical project manager in the supplier/services organization
©Hughes and Cotterell. “Software Project Management” (5th edition)
08-Jan-15
Daniel Sinnig, PhD
7
ECSE 321: Introduction to Software Engineering
Activities covered by project management
• Feasibility study: Is project technically feasible and worthwhile from a
business point of view?
• Planning: Only done if project is feasible
• Execution: Implement plan, but plan may be changed as we go along
©Hughes and Cotterell. “Software Project Management” (5th edition)
08-Jan-15
Daniel Sinnig, PhD
8
ECSE 321: Introduction to Software Engineering
What is management?
This involves the following activities:
•
•
•
•
•
•
•
•
Planning – deciding what is to be done
Organizing – making arrangements
Staffing – selecting the right people for the job
Directing – giving instructions
Monitoring – checking on progress
Controlling – taking action to remedy hold-ups
Innovating – coming up with solutions when problems emerge
Representing – liaising with clients, users, developers and other stakeholders
©Hughes and Cotterell. “Software Project Management” (5th edition)
08-Jan-15
Daniel Sinnig, PhD
9
ECSE 321: Introduction to Software Engineering
Why projects fail
• Ignorance of management over engineering (IT) issues.
• Deadline pressure.
• Poor role definition: Who does what. Who has access to what (technical)
resources.
• Requirements can be incomplete, ambiguous, inconsistent, or not measurable.
Success criteria can be incorrect or undefined.
• Lack of (developer) knowledge of application area.
• Poor estimation and planning. Casual estimates of milestones.
• Ineffective environment. Unavailability of the right tools.
• Lack of reliable documentation (especially for maintenance tasks).
©Hughes and Cotterell. “Software Project Management” (5th edition)
08-Jan-15
Daniel Sinnig, PhD
10
ECSE 321: Introduction to Software Engineering
Project scheduling
• Before starting a project, it is important to know:
– How long will it take to develop the system?
– How much will it cost to develop the system?
• Answering these questions require a well thought out project schedule. A
project schedule describes the development cycle of a particular project by
enumerating the different phases of a project. Each phase is broken down
into discrete tasks or activities. The completion of important activities is
called a milestone.
08-Jan-15
Daniel Sinnig, PhD
11
ECSE 321: Introduction to Software Engineering
Activity Planning (Scheduling)
• The schedule also captures the interdependence between these
activities. In particular,
– Which activities can only be completed after another activity?
– Which activities can be done in parallel?
– Which activities do not depend on others (e.g., project review meetings)
• An easy way to visualize this interdependence is using activity graphs or
precedence diagrams. Activity charts can be down in two ways:
– Activity on Node (AON)
– Activity on Arrow (AOA)
08-Jan-15
Daniel Sinnig, PhD
12
ECSE 321: Introduction to Software Engineering
Activity Planning (Scheduling)
• Break down (or compartmentalize) the overall project into manageable
components, called activities (or tasks).
•
Deciding in advance, what to do, why do it, how to do it, when to do it and who
is to do it.
Result: A detailed project plan including:
• Projected start and completion days of the project
• Break-down of project into list of activities (tasks) including
• For each activity:
–
–
–
–
–
08-Jan-15
Duration (incl. start and completion dates)
Effort required
Required resources
Inter-dependencies to other activities
Etc.
Daniel Sinnig, PhD
13
ECSE 321: Introduction to Software Engineering
Fundamentals of activity planning
• A project is:
– Composed of a number of activities
– May start when at least one of its activities is ready to start
– Completed when all its activities are completed
• An activity has/is:
– Clearly defined start and end point
– Clearly defined outcome (normally a work-product (or artifact).
• Work products are combined into deliverables.
• For example, the artifacts produced by the activities of a an iteration are
combined into the deliverable for that particular iteration.
– Assigned to a specific team member
– Precedence requirements
08-Jan-15
Daniel Sinnig, PhD
14
ECSE 321: Introduction to Software Engineering
The relationship between people and effort
• There is a common myth that if we fall behind schedule, we can always
add more developers and catch up later in the project.
• Unfortunately this is not so simple and this policy most likely would
create more problems than the ones it aims at solving.
• Adding people late in a project often has a disruptive effect on the
project (causing schedules to slip even further) as new people must learn
the system, and people who teach them are the same people who do the
work.
• During teaching, no work is done. Furthermore, more people increase
the complexity of communication throughout the project.
• Brook’s law: “Adding manpower to a late project makes it later”
08-Jan-15
Daniel Sinnig, PhD
15
ECSE 321: Introduction to Software Engineering
Activity networks
• Mathematical graphs that help managers to:
– Visualize the plan of a project
– Assess the feasibility of the completion date
– Identify how resources would need to map to activities and how they will
need to be deployed to them, and to calculate when costs will be incurred.
• Activity networks provide a tool for the coordination (and
the motivation – why?) of the project team
08-Jan-15
Daniel Sinnig, PhD
16
ECSE 321: Introduction to Software Engineering
Activity-on-node networks
• An activity-on-node network is a directed mathematical
graph where
– Nodes represent activities
– Edges represent transitions from one activity to another, explicitly
illustrating their sequence.
• Each node includes the following information:
Legend:
• ES = Earliest start
• LS = Latest start
• EF = Earliest finish
• LF = Latest finish
08-Jan-15
Daniel Sinnig, PhD
17
ECSE 321: Introduction to Software Engineering
Activity-on-node networks: Constraints
• Exactly one starting and end node
• A node (representing activity) has a duration, an edge does not
• A network may not contain loops (why)
• A network should not contain dangles
08-Jan-15
Daniel Sinnig, PhD
18
ECSE 321: Introduction to Software Engineering
Example: Activity-on-node network
•
•
•
•
•
•
•
The requirements specification of an IT application is estimated to take two weeks to
complete (a week is seven days).
When this activity has been completed, work can start on three software modules, A, B
and C.
The design/implementation of A, B and C will need five, ten and ten days respectively.
Modules A and B can only be unit-tested together as their functionality is closely
associated. This joint testing should take two weeks.
Module C will require eight days of unit testing.
Once all unit-testing has been completed, the planning of integrated system testing must
take place and it would require a ten days. The activity itself would take three weeks.
The project manager has decided not to allow any holiday for the duration of this
project. 
08-Jan-15
Daniel Sinnig, PhD
19
ECSE 321: Introduction to Software Engineering
Translating the problem statement into tabular form
08-Jan-15
Daniel Sinnig, PhD
20
ECSE 321: Introduction to Software Engineering
Translating the table into a graph
08-Jan-15
Daniel Sinnig, PhD
21
ECSE 321: Introduction to Software Engineering
Time parameters
• For each activity we must determine the following
parameters:
– Earliest start time (ES): the earliest time at which the activity can
start given that its precedent activities must be completed first.
– Earliest finish time (EF): equals to the earliest start time for the
activity plus the time required to complete the activity.
– Latest finish time (LF): the latest time at which the activity can be
completed without delaying the project.
– Latest start time (LS): equals to the latest finish time minus the
time required to complete the activity.
08-Jan-15
Daniel Sinnig, PhD
22
ECSE 321: Introduction to Software Engineering
Determining earliest times: Forward pass
• The earliest start and finish times of each activity are
determined by working forward through the network and
determining the earliest time at which an activity can start
and finish considering its predecessor activities.
• For each activity, we calculate the earliest times by applying
the forward pass rule.
• The forward pass rule: The earliest start date for the
current activity is the earliest finish date for the previous.
When there is more than one previous activity, we take the
latest between all previous activities.
– The earliest start date for the start node is 0 (“end of day 0)
08-Jan-15
Daniel Sinnig, PhD
23
ECSE 321: Introduction to Software Engineering
Performing a forward pass
• Activity S can start immediately (we follow the convention to
write “the end of day 0”).
• It will take 14 days, which is the earliest it can finish. Thus,
– ES(S) = 0
– EF(S) = 14
08-Jan-15
Daniel Sinnig, PhD
24
ECSE 321: Introduction to Software Engineering
Performing a forward pass (cont.)
• Activities DCA, DCB and DCC can start as soon as S
completes. Activity DCA will take 5 days, so the earliest it
can finish is (at the end of) day 19.
• Similarly, the earliest finish for activities DCB and DCC
(both of which will take 10 weeks) is (at the end of) day 24.
– ES(DCA) = ES(DCB) = ES(DCC) = 14
– EF(DCA) = 19
– EF(DCB) = EF(DCC) = 24
08-Jan-15
Daniel Sinnig, PhD
25
ECSE 321: Introduction to Software Engineering
Performing a forward pass (cont.)
• Activity UTAB cannot start until both its preceding activities
can finish.
• The earliest start for UTAB is the latest between the earliest
finish of its preceding activities, i.e. the latest between
EF(DCA), and EF(DCB) which is (at the end of) day 24.
• Activity UTAB will take 14 days to complete, and so the
earliest it can finish is (at the end of) day 38.
– ES(UTAB) = 24
– EF(UTAB) = 38
08-Jan-15
Daniel Sinnig, PhD
26
ECSE 321: Introduction to Software Engineering
Performing a forward pass (cont.)
• Activity UTC cannot start until activity DCC finishes, i.e.
ES(UTC) = EF(DCC) = 24.
• Activity UTC will take 8 days to complete, so the earliest it
can finish is (at the end of) day 32.
– ES(UTC) = 24
– EF(UTC) = 32
08-Jan-15
Daniel Sinnig, PhD
27
ECSE 321: Introduction to Software Engineering
Performing a forward pass (cont.)
• Activity P cannot start until both its preceding activities
finish.
• The earliest that activity P can start is the latest between the
earliest finish of its preceding activities UTAB and UTC, i.e.
the latest of EF(UTAB), and EF(UTC), which is 38.
• Activity P will take 10 days to complete, so the earliest it can
finish is (at the end of) day 48.
– ES(P) = 38
– EF(P) = 48
08-Jan-15
Daniel Sinnig, PhD
28
ECSE 321: Introduction to Software Engineering
Performing a forward pass (cont.)
• Activity IST cannot start until activity P finishes.
• The earliest start of IST is the earliest finish of P.
• Activity IST will take 21 days to complete, so the earliest is
can finish is (at the end of) day 69.
– ES(IST) = 48
– EF(IST) = 69
• The project will be complete when activity IST is complete.
• The earliest the project can complete is (at the end of) day
69.
08-Jan-15
Daniel Sinnig, PhD
29
ECSE 321: Introduction to Software Engineering
Forward pass: Conclusion
08-Jan-15
Daniel Sinnig, PhD
30
ECSE 321: Introduction to Software Engineering
Determining latest times: The backward pass
• The latest start and finish times are the latest times that an
activity can start and finish without delaying the project and
they are found by working backward through the network.
• We assume that the latest finish date for the project is the
same as the earliest finish date, i.e. we wish to complete the
project as early as possible.
08-Jan-15
Daniel Sinnig, PhD
31
ECSE 321: Introduction to Software Engineering
Determining latest times: The backward pass rule
• Start from the last activity: The latest finish (LF) for the last activity is the
earliest the project can complete.
– E.g., Earliest finish (EF) of last activity
• We now work backwards for each subsequent activities: The latest finish (LF)
for a given activity is the latest start (see below) of its following activity, i.e. LF
(activity) = LS (following activity).
• If more than one following activity exists, we take the earliest of the latest start
dates of its following activities, i.e. LF (activity) = min (LSs of following
activities).
• The latest start (LS) of a given activity is given by the difference between its
latest finish (LF) and its duration, i.e. LS(activity) = LF(activity) duration(activity).
08-Jan-15
Daniel Sinnig, PhD
32
ECSE 321: Introduction to Software Engineering
Performing a backward pass
• The latest completion date for activities IST is assumed to be (the
end of) day 69.
• This assumption is based on the fact that we do not want to delay
the project more than its earliest possible completion date.
• Since the duration of IST is 21 days, its latest start is the difference
between its latest finish and its duration.
– LF(IST) = 69
– LS(IST) = LF(IST) - duration(IST) = 48
08-Jan-15
Daniel Sinnig, PhD
33
ECSE 321: Introduction to Software Engineering
Performing a backward pass (cont.)
• The latest completion date for activity P is the latest date at which
the following activity, IST, can start.
• Also, the latest start for activity P is the difference between its
latest finish and its duration i.e.
– LF(P) = LS(IST) = 48
– LS(P) = LF(P) - duration(P) = 48 - 10 = 38
08-Jan-15
Daniel Sinnig, PhD
34
ECSE 321: Introduction to Software Engineering
Performing a backward pass (cont.)
• The latest completion date for activities UTAB and UTC are the
latest day at which the following activity, P, can start.
– LF(UTAB) = LF(UTC) = LS(P) = 38
08-Jan-15
Daniel Sinnig, PhD
35
ECSE 321: Introduction to Software Engineering
Performing a backward pass (cont.)
• The latest start for activity UTAB is the difference between its
latest finish and its duration, i.e.
– LS(UTAB) = LF(UTAB) - duration(UTAB) = 38 - 14 = 24
• Similarly the latest start for activity UTC is the difference between
its latest finish and its duration, i.e.
– LS(UTC) = LF(UTC) - duration(UTC) = 38 - 8 = 30
08-Jan-15
Daniel Sinnig, PhD
36
ECSE 321: Introduction to Software Engineering
Performing a backward pass (cont.)
• The latest finish dates for activities DCA and DCB are the latest
day at which the following activity, UTAB, can start, i.e.
– LF(DCA) = LF(DCB) = LS(UTAB) = 24
• The latest start date for DCA and DCB are the differences
between their corresponding latest finish dates and their duration,
i.e.
– LS(DCA) = LF(DCA) - duration(DCA) = 24 - 5 = 19
– LS(DCB) = LF(DCB) - duration(DCB) = 24 - 10 = 14
08-Jan-15
Daniel Sinnig, PhD
37
ECSE 321: Introduction to Software Engineering
Performing a backward pass (cont.)
• The latest finish date for activity DCC is the latest day at which
the following activity, UTC, can start, i.e.
– LF(DCC) = LS(UTC) = 30
• The latest start date for activity DCC is the difference between its
latest finish date and its duration, i.e.
– LS(DCC) = LF(DCC) - duration(DCC) = 30 - 10 = 20
08-Jan-15
Daniel Sinnig, PhD
38
ECSE 321: Introduction to Software Engineering
Performing a backward pass (cont.)
• The latest finish date for activity S is the earliest of the latest start
dates of its following activities, DCA, DCB and DCC, i.e. the
minimum of LS(DCA), LS(DCB), and DC(DCC).
– LF(S) = 14
• The latest start date for activity S is the difference between its
latest finish date and its duration, i.e.
– LS(S) = LF(S) - duration(S) = 0
08-Jan-15
Daniel Sinnig, PhD
39
ECSE 321: Introduction to Software Engineering
Backward pass: Conclusion
08-Jan-15
Daniel Sinnig, PhD
40
ECSE 321: Introduction to Software Engineering
Activity float
• The difference between an activity’s earliest start date (ES) and its
latest start date (LS) (or the difference between earliest and latest
finish dates) is known as the activity’s float, i.e.
– Float = LS − ES
• But LS = (LF − Duration), so
– Float = LF − Duration − ES
• In essence, float is a measure of how much the start or completion
of an activity may be delayed without affecting the end date of the
project. Any activity with zero float is critical as any delay will
affect the completion of the entire project.
08-Jan-15
Daniel Sinnig, PhD
41
ECSE 321: Introduction to Software Engineering
Critical path
• Critical path defines the duration of the project
– Any delay to any activity on the critical path will delay the project
– If activities outside the critical path speed up the total project time does not
change.
• The “float” of all activities on the critical path is ‘0’
• The critical path is determined by adding the times for the
activities in each sequence and determining the longest path in the
project.
• In the activity network, there will be one at least critical path.
08-Jan-15
Daniel Sinnig, PhD
42
ECSE 321: Introduction to Software Engineering
Determining the float and critical path in the example
08-Jan-15
Daniel Sinnig, PhD
43
ECSE 321: Introduction to Software Engineering
Maximum duration
• There is one parameter we still have not mentioned: As a project
manager you need to plan the resources required for each
activity.
• To do that, you need to calculate, for each activity, the maximum
possible duration. This is given by LF − ES.
08-Jan-15
Daniel Sinnig, PhD
44
ECSE 321: Introduction to Software Engineering
PERT to evaluate the effects of uncertainty
• So far, we considered models with “single time estimates” for
activity durations
– Called CPM = Critical Path Models
• PERT = Program Evaluation and Review Technique
• PERT requires three estimates for each activity
– Most likely time (m): Activity duration under normal circumstances
– Optimistic time (a): Shortest time to complete the activity
– Pessimistic time (b): Worst possible time to complete the activity
• Derived attribute: Expected duration(t) t= (a+4m+b) / 6
• Derived attribute: Standard deviation*(s) s = (b-a) / 6
*
Definition of standard derivation differs from (math) textbook definition
08-Jan-15
Daniel Sinnig, PhD
45
ECSE 321: Introduction to Software Engineering
Example: PERT Activities
Activity Precedents Optimistic
label
(a)
Most
likely (m)
Pessimistic Expected Standard
(b)
(t)
derivation
A
5
6
8
B
3
4
5
C
A
2
3
3
D
B
3.5
4
5
E
B
1
3
4
8
10
15
F
G
E, F
2
3
4
H
C, D
2
2
2.5
08-Jan-15
Daniel Sinnig, PhD
46
ECSE 321: Introduction to Software Engineering
Example: PERT Activities
Activity Precedents Optimistic
label
(a)
Most
likely (m)
Pessimistic Expected Standard
(b)
(t)
deviation
A
5
6
8
6.17
0.50
B
3
4
5
4.00
0.33
C
A
2
3
3
2.83
0.17
D
B
3.5
4
5
4.08
0.25
E
B
1
3
4
2.83
0.5
8
10
15
10.5
1.17
F
G
E, F
2
3
4
3.00
0.33
H
C, D
2
2
2.5
2.08
0.08
08-Jan-15
Daniel Sinnig, PhD
47
ECSE 321: Introduction to Software Engineering
PERT networks
• PERT can be modelled as activity-on-node and activity-on-arrow
networks
– In this course we will focus activity-on-arrow networks
• Each event is represented by a node structures as follows:
Event
Target
number
date
Expected Standard
date
deviation
• Each activity is represented by an arrow labelled as follows:
– Activity label
– Expected duration (t)
– Standard deviation (s)
08-Jan-15
Daniel Sinnig, PhD
48
ECSE 321: Introduction to Software Engineering
Activity-on-arrow networks
• An activity-on-arrow network is a mathematical graph where
nodes represent events of activities (or groups of activities:
starting or finishing), and edges represent activities (may also
include durations).
08-Jan-15
Daniel Sinnig, PhD
49
ECSE 321: Introduction to Software Engineering
Activity-on-arrow networks: Constraints
• We may have only one start and end node.
• Since an edge represents an activity, it has a duration.
• On the other hand, a node (representing some milestone) has no
duration.
• Nodes are numbered sequentially.
• If we choose not to show direction of edges, we must follow a
convention to read the graph properly. In our convention, time
moves from left to right.
• A graph may not contain loops.
• A graph may not contain dangles
08-Jan-15
Daniel Sinnig, PhD
50
ECSE 321: Introduction to Software Engineering
Example PERT network
08-Jan-15
Daniel Sinnig, PhD
51
ECSE 321: Introduction to Software Engineering
Calculating expected dates of events
Event
Target
number
date
Expected Standard
date
derivation
• Expected date = date the event is expected to occur
• Calculated using a forward pass
• Forward pass rule:
– Expected date (Event) : Latest expected finish (EF) date of all preceding
activities
– Expected Start (ES) (activity) = Earliest expected date (Event) in which
the activity originates from.
– EF(activity) = ES(activity) + Expected Duration(activity)
08-Jan-15
Daniel Sinnig, PhD
52
ECSE 321: Introduction to Software Engineering
Example PERT network (after the forward pass
for calculating expected dates of events)
08-Jan-15
Daniel Sinnig, PhD
53
ECSE 321: Introduction to Software Engineering
Calculating standard deviation of events
Event
Target
number
date
Expected Standard
date
derivation
• Calculated using a forward pass
• Forward pass rule:
– Standard deviation (Event) : Max of sqrt (s(activity’) 2+s (event’)2)
– s(activity’) = standard deviation of all preceding activities
– s(event’) = standard deviation of preceding event
08-Jan-15
Daniel Sinnig, PhD
54
ECSE 321: Introduction to Software Engineering
Example PERT network (after the forward pass
for calculating standard derivations of events)
08-Jan-15
Daniel Sinnig, PhD
55
ECSE 321: Introduction to Software Engineering
Calculating likelihood of target dates
Event
Target
number
date
Expected Standard
date
derivation
• For each event a target date (T) may be specified
• The following procedure calculates the probability of achieving
the target date:
(1) Calculate z-value for each event that has a target date as follows
z = (T-t) / s, where
T = target date for the event
t = expected date of event
s = standard deviation of the event
z-value = number of standard deviations between event’s expected date and
event’s target date
(2) Convert z-value to a probability (defined in subsequent slides)
08-Jan-15
Daniel Sinnig, PhD
56
ECSE 321: Introduction to Software Engineering
Example PERT network (setting target dates for
events 4, 5, 6)
08-Jan-15
Daniel Sinnig, PhD
57
ECSE 321: Introduction to Software Engineering
Example PERT network (calculating z-values for
events 4, 5, 6)
z4 = (10-9) / 0.53 = 1.89
z5 = (10-10.5) / 1.17 = -0.43
z6 = (15-13.5) / 1.22 = 1.23
Can you provide an intuitive interpretation of the z-value?
08-Jan-15
Daniel Sinnig, PhD
58
ECSE 321: Introduction to Software Engineering
Interpretation of z-value
• The higher the z-value the more likely it is to achieve the target
date. Why?
• The lower the z-value the less likely it is to achieve the target date.
Why?
08-Jan-15
Daniel Sinnig, PhD
59
ECSE 321: Introduction to Software Engineering
Convert z-value to a probability
08-Jan-15
Daniel Sinnig, PhD
60
ECSE 321: Introduction to Software Engineering
Example PERT network (interpreting z-values for
events 4, 5, 6)
z4 = (10-9) / 0.53 = 1.89
• The target date will be missed with a ~3% probability
• The target date will be achieved with a ~97% probability
z5 = (10-10.5) / 1.17 = -0.43
• The target date will be missed with a ~67% probability
• The target date will be achieved with a ~33% probability
z6 = (15-13.5) / 1.22 = 1.23
• The target date will be missed with a ~11% probability
• The target date will be achieved with a ~89 probability
08-Jan-15
Daniel Sinnig, PhD
61
ECSE 321: Introduction to Software Engineering
Project monitoring and control
• Project performance reporting
• Collection and dissemination of information on
– Project status
– Project progress
– Project forecast
• Addresses the following questions:
– “Where are we on schedule?”
– “Where are we on budget?”
– “Are tasks get accomplished according to plan?”
08-Jan-15
Daniel Sinnig, PhD
62
ECSE 321: Introduction to Software Engineering
Why monitoring?
• Monitoring implies taking a “snapshot” of the project at a single
point in time.
• In iterative development, monitoring is performed during every
iteration.
• Not only we need the above information to make some judgment
about the state of the project, but we may also need to apply
proper controls to bring the project back on track.
08-Jan-15
Daniel Sinnig, PhD
63
ECSE 321: Introduction to Software Engineering
Earned value analysis
• Quantitative analysis technique for measuring project
performance and progress
• Developed by US Department of Defense (DoD) to control
projects carried out by contractors
• The main idea behind earned value analysis is that the value of
the product increases as tasks are completed.
• Defines a set of key indicators to define project baseline, measure
progress and forecasting
08-Jan-15
Daniel Sinnig, PhD
64
ECSE 321: Introduction to Software Engineering
Planned value (budgeted costs)
Note: Earned value analysis uses the term “task” to depict an
activity of a project
• For a given task k, the planned value (PVk ) is defined as the budget planned
for that task (based on the resources involved).
• As a project is essentially a collection of tasks, in order to determine the
progress at any given point along the project schedule, the PV of the project
is the sum of the PVk values of all tasks that should have been completed
by that point in time on the project schedule.
08-Jan-15
Daniel Sinnig, PhD
65
ECSE 321: Introduction to Software Engineering
Planned value: An example
• Consider a project with the following (linear) tasks (in
parentheses are the associated planned values): A(20), B(5), C
(10), D (20), E (20), F (10), and G (15).
• If the tasks are placed on a time line, then on the time indicated
we plan to have spent the amount of 35.
08-Jan-15
Daniel Sinnig, PhD
66
ECSE 321: Introduction to Software Engineering
Earned value
• We define earned value (EV) as the planned value of the work
actually completed
– A task that has not yet started: Earned value of 0
– A task completed: Earned value = original planed value for that task
– Partially completed task, an evaluation method must be chosen and
consistently applied. Such as:
• 0/100 technique: EV of a task is 0 until completed
• 50/50 technique: EV = 50% of PV as soon as task is started. Matches some
contractual agreements where contractor is given 50% of PV when work is started
• 75/25 technique: EV = 75% of PV as soon as task is started. Often used when
expensive equipment is purchased at the beginning of the task
• Milestone technique: EV is given a certain value when a certain milestone has been
achieved
• Percentage technique: EV equals the percentage of actual task completion of the
planned value. We will use this technique for this class.
08-Jan-15
Daniel Sinnig, PhD
67
ECSE 321: Introduction to Software Engineering
Budget at completion
• The budget at completion (BAC) is the summation of the PV
values for all tasks:
BAC = (PVk) for all tasks k.
• In the following example, the BAC is 100.
08-Jan-15
Daniel Sinnig, PhD
68
ECSE 321: Introduction to Software Engineering
Percent scheduled for completion
• The Percent scheduled for completion is an indication of the percentage
of work that should have been completed by a given point in
time and it is given by
• Percent scheduled for completion =
𝑃𝑉(𝑝𝑟𝑜𝑗𝑒𝑐𝑡)
BAC
• In the previous example, PV(project) = 35, and BAC = 100, so
the percent scheduled for completion is 35%.
08-Jan-15
Daniel Sinnig, PhD
69
ECSE 321: Introduction to Software Engineering
Actual cost
• The actual cost (AC) is defined as the total of costs on tasks that
have actually been completed by a given point in time on the project
schedule.
08-Jan-15
Daniel Sinnig, PhD
70
ECSE 321: Introduction to Software Engineering
Percent complete
• Percent complete provides a quantitative indication of the
percent of completion of the project at a given point in time:
𝐸𝑉
𝑃𝑒𝑟𝑐𝑒𝑛𝑡 𝑐𝑜𝑚𝑝𝑙𝑒𝑡𝑒 =
𝐵𝐴𝐶
08-Jan-15
Daniel Sinnig, PhD
71
ECSE 321: Introduction to Software Engineering
Performance indicators
• The values for PV, AC and EV are used in combination to
provide measures of whether or not work is being accomplished
as planned:
–
–
–
–
08-Jan-15
Cost Variance (CV)
Schedule Variance (SV)
Cost Performance Index (CPI)
Schedule Performance Index (SPI)
Daniel Sinnig, PhD
72
ECSE 321: Introduction to Software Engineering
Cost variance
• The cost variance (CV) is defined as: 𝐶𝑜𝑠𝑡 𝑉𝑎𝑟𝑖𝑎𝑛𝑐𝑒 (𝐶𝑉) = 𝐸𝑉 − 𝐴𝐶
• Difference between what we should have paid for work actually
performed, and what was actually paid for work actually performed.
– It is an absolute indication of cost savings (against planned cost) or shortfall at
a particular stage of a project.
– A positive variance implies less money was spent for the work accomplished
than what was planned to be spent.
– A negative variance means more money was spent for the work accomplished
than what was planned.
08-Jan-15
Daniel Sinnig, PhD
73
ECSE 321: Introduction to Software Engineering
Schedule variance
• The schedule variance (SV) is defined as: SV = EV − PV
• Indicates the degree to which the value of completed work differs
from the value of the planned work.
• A positive value for SV implies that we are ahead of schedule.
• A negative value implies that we are behind schedule.
08-Jan-15
Daniel Sinnig, PhD
74
ECSE 321: Introduction to Software Engineering
Cost performance index
• The cost performance index (CPI) is defined as: 𝐶𝑃𝐼 =
𝐸𝑉
𝐴𝐶
• Ratio of the earned value over the actual cost of completed work, or
a quotient of what we should have paid for work performed, and
what was actually paid for work actually performed.
• CPI values close to 1.0 provide a strong indication that the project is
within its defined budget.
• CPI values greater than 1 indicate that the cost of completing the
work is less than planned.
• Similarly, CPI values less that 1 indicate that the cost of completing
the work is higher than planned.
08-Jan-15
Daniel Sinnig, PhD
75
ECSE 321: Introduction to Software Engineering
Schedule performance index
• The schedule performance index (SPI) is defined as: 𝑆𝑃𝐼 = EV
PV
• Quotient of the earned value over the planned value and it indicates
the rate of progress: the efficiency with which the project is utilizing
scheduled resources.
• SPI values close to 1.0 indicate efficient execution of the project
schedule.
• SPI values greater than 1 are favorable.
• SPI values less than 1 are not favorable.
08-Jan-15
Daniel Sinnig, PhD
76
ECSE 321: Introduction to Software Engineering
Estimate at completion
• The estimate at completion (EAC) is defined as:
𝐵𝐴𝐶
𝐸𝐴𝐶 =
𝐶𝑃𝐼
• Initially (before the project starts) our estimate is given by BAC. As
we embark on the project, EAC is the quotient of what we planned
to spend over what we are actually spending and it indicates what we
expect the job to cost.
08-Jan-15
Daniel Sinnig, PhD
77
ECSE 321: Introduction to Software Engineering
Estimate to complete
• Estimate to complete is defined as:
𝐸𝑇𝐶 = 𝐸𝐴𝐶 − 𝐴𝐶
• At any given point in time, ETC is a comparison of the estimate of
the final cost (EAC) to what we have spent to date (AC). ETC
indicates how much more will have to be spent in order to complete
the project.
08-Jan-15
Daniel Sinnig, PhD
78
ECSE 321: Introduction to Software Engineering
Getting the project back on track
• Usually, projects run into delays or other unexpected events.
• A project manager has the responsibility to recognize when this is
happening (or when this is about to happen).
• With minimum delay and minimum disruption to the project, the
project manager has the responsibility to mitigate the effects of these
events over the project.
• The overall duration of a project is determined by the current critical
path. Speeding up non-critical path activities will not have any effect
on the project completion date.
• What options might be available?
08-Jan-15
Daniel Sinnig, PhD
79
ECSE 321: Introduction to Software Engineering
Getting the project back on track (cont.)
• Allocate more efficient resources on activities on the critical path (or
swapping resources between critical and non-critical activities), e.g.
swap experienced programmers with junior programmers.
• Note that adding a programmer to a team might be counterproductive due to the time (and resources) required to bring the new
people on board with the project (Brooks’ Law)
• Resources can be available for longer (e.g. on weekends).
• People can work overtime
08-Jan-15
Daniel Sinnig, PhD
80
ECSE 321: Introduction to Software Engineering
Getting the project back on track (cont.)
• Other options include overlapping certain activities so that the start
of one activity does not have to wait for completion of another.
• This can also apply to iterations, i.e. iteration N + 1 can start before
iteration N is completed.
• Yet another option (last resort?) can be to renegotiate the contract.
08-Jan-15
Daniel Sinnig, PhD
81
ECSE 321: Introduction to Software Engineering
Example 1
• Consider the following activity diagram below:
08-Jan-15
Daniel Sinnig, PhD
82
ECSE 321: Introduction to Software Engineering
Example 1: Progress review
• Assume that the project is being prepared for a progress review at
the end of the second quarter (today).
• According to the budget plan, at the end of second quarter, tasks 1,
3, 5, 6 must have been completed.
• Task 2 should have been completed by 2/3, task 4 should have been
completed by 40%, and task 7 should have been completed by 50%.
• The project manager reports that tasks 1-6 have been completed as
planned, except task 7, which is 10% complete.
• The project manager also reports that the amount of money already
spent to date is $10,000.
08-Jan-15
Daniel Sinnig, PhD
83
ECSE 321: Introduction to Software Engineering
Example 1: Progress review
• Apply any and all appropriate performance indicators to provide an
analysis of the project status as of today in terms of 1) schedule and
2) budget.
• If your analysis presents a problematic situation, briefly describe your
recommendations to bring the project back to track.
08-Jan-15
Daniel Sinnig, PhD
84
ECSE 321: Introduction to Software Engineering
Example 1: Progress review
• PV = (100% × 2, 000) + (2/3 × 6, 000) + (100% × 1, 000) +
(40% × 5, 000) + (100% × 1, 000) + (100% × 1, 500) + (50% ×
6, 000) = 14, 500.
• EV = (100% × 2, 000) + (2/3 × 6, 000) + (100% × 1, 000) +
(40% × 5, 000) + (100% × 1, 000) + (100% × 1, 500) + (10% ×
6, 000) = 12, 100.
• The project is behind schedule (since EV < PV).
• The project is under budget (since AC < EV).
08-Jan-15
Daniel Sinnig, PhD
85
ECSE 321: Introduction to Software Engineering
Example 1: Performance indicators
• The performance indicators are calculated as follows:
• The Schedule Variance
(SV) = EV − PV = 12, 100 − 14, 500 = −2, 400.
• The Schedule Performance Index (SPI ) =
𝐸𝑉
𝑃𝑉
= 0.82 < 1
• The Cost Variance
(CV) = EV − AC = 12, 100 − 10, 000 = +2, 100.
• The Cost Performance Index (CPI ) =
08-Jan-15
Daniel Sinnig, PhD
𝐸𝑉
𝐴𝐶
= 1.21 > 1
86
ECSE 321: Introduction to Software Engineering
Example 1: Bringing the project back on track
• As we are under budget, we can afford to pay people overtime
(to complete more tasks), or recruit more people (even though
this may not be desirable), or even to replace junior developers
with senior developers (to have more tasks accomplished).
08-Jan-15
Daniel Sinnig, PhD
87
ECSE 321: Introduction to Software Engineering
Example 2
• Consider the following activity diagram below:
08-Jan-15
Daniel Sinnig, PhD
88
ECSE 321: Introduction to Software Engineering
Example 2: Progress review
• Assume that the project is being prepared for a progress review at
the end of the second quarter (today).
• According to the budget plan, at the end of second quarter, tasks 1,
3, 5, 6 must have been completed.
• Task 2 should have been completed by 60%, task 4 should have been
completed by 1/2, and task 7 should have been completed by 40%.
• The project manager reports that tasks 1-6 have been completed as
planned, except task 7, which is 15% complete.
• The project manager also reports that the amount of money already
spent as of today is $10,000.
08-Jan-15
Daniel Sinnig, PhD
89
ECSE 321: Introduction to Software Engineering
Example 2: Progress review
• Apply a full monitoring analysis.
• If your analysis presents a problematic situation, briefly describe your
recommendations to bring the project back to track.
08-Jan-15
Daniel Sinnig, PhD
90
ECSE 321: Introduction to Software Engineering
Example 2: Progress review
• The project budget, BAC, is given by
Σ(PVk ) = 1,500 + 6,000 + 1,000 + 3,000 + 3,000 + 2,000+
7,000 + 8, 000 = 31, 500.
• The planned value, PV, of the project at this moment in time is
given by
PV = (100% × 1,500) + (60% × 6,000) + (100% × 1,000)+
(1/2 × 3,000) + (100% × 3,000) + (100% × 2,000)+ (40% ×
7,000) = 15,400.
08-Jan-15
Daniel Sinnig, PhD
91
ECSE 321: Introduction to Software Engineering
Example 2: Basic parameters: Interpretation
• As of today (the end of second quarter), team members are expected to have
completed $15, 400 worth of work.
• Percent complete. The percent complete is given by
𝑃𝑉
𝐵𝐴𝐶
=
15,400
31,500
= 0.48
• As of today, the project is planned to be 48% completed.
• The earned value, EV, is given by
EV = (100% × 1, 500) + (60% × 6, 000) + (100% × 1, 000)+ (1/2 × 3,
000) + (100% × 3, 000) + (100% × 2, 000)+ (15% × 7, 000) = 13, 650.
• As of today, the work that the team members performed, cost (is worth)
$13,650.
08-Jan-15
Daniel Sinnig, PhD
92
ECSE 321: Introduction to Software Engineering
Example 2: Basic parameters: Interpretation
• The percent complete is given by
𝐸𝑉
𝐵𝐴𝐶
=
13,650
31,500
= 0.43
• As of today, 43% of the project is completed.
• The actual cost, AC = 10, 000.
• As of today, the work that the team members performed cost
$10, 000.
08-Jan-15
Daniel Sinnig, PhD
93
ECSE 321: Introduction to Software Engineering
Example 2: Performance indicators
• The performance indicators are calculated as follows:
• The Schedule Variance
(SV) = EV − PV = 13, 650 − 15, 400 = −1, 750.
• The Schedule Performance Index (SPI ) =
𝐸𝑉
𝑃𝑉
=
13,650
15,400
= 0.88 < 1
• As of today, the project is behind schedule. The team has completed 88% of what
it should have completed.
• The Cost Variance
(CV) = EV − AC = 13, 650 − 10, 000 = +3, 650.
• The Cost Performance Index (CPI ) =
𝐸𝑉
𝐴𝐶
=
13,650
10,000
= 1.36 > 1
• As of today, the project is under budget. We are getting $1.36 for every dollar that
we spend.
08-Jan-15
Daniel Sinnig, PhD
94
ECSE 321: Introduction to Software Engineering
Example 2: Forecasting
• The estimate at completion, EAC, is given by
𝐵𝐴𝐶
𝐶𝑃𝐼
=
31,500
1.36
= 23,161.76
• This value is the estimation of cost at the end of project (Quarter4), based
on Cost Performance Index.
• The estimate to complete, ETC, is given by EAC − AC = 23161.76 − 10,
000 = 13161.76.
• This value represents the amount of money still to be spent.
• The variance at completion, VAC, is given by BAC − EAC = 31, 500 −
23161.76 = 8338.235.
• This value represents the difference between the planed cost at the
beginning of the project and the estimation of cost based on today’s CPI.
08-Jan-15
Daniel Sinnig, PhD
95
ECSE 321: Introduction to Software Engineering
Example 3
• Consider the following activity diagram below:
08-Jan-15
Daniel Sinnig, PhD
96
ECSE 321: Introduction to Software Engineering
Example 3: Progress review
• Assume that the project is being prepared for a progress review at
the end of the second quarter (today).
• According to the budget plan, at the end of second quarter, tasks 1,
3, 5, 6 must have been completed.
• Task 2 should have been completed by 2/3, task 4 should have been
completed by 40%, and task 7 should have been completed by 60%.
• The project manager reports that tasks 1-6 have been completed as
planned, except task 7, which is 15% complete.
• The project manager also reports that the amount of money already
spent to date is $15,000.
08-Jan-15
Daniel Sinnig, PhD
97
ECSE 321: Introduction to Software Engineering
Example 3: Progress review
08-Jan-15
Daniel Sinnig, PhD
98
ECSE 321: Introduction to Software Engineering
Example 3: Progress review
08-Jan-15
Daniel Sinnig, PhD
99
ECSE 321: Introduction to Software Engineering
Example 3: Bringing the project back on track
• To correct the budget deficiencies, perform a forecasting assessment
of the project’s financial status
• EAC =
𝐵𝐴𝐶
𝐶𝑃𝐼
= $34, 239.
• ETC = EAC − AC = $19, 239.
• VAC = BAC − EAC = −$2739.
– Since VAC < 0, this indicates that the whole project will be over budget based on the
estimates of the remaining work.
– It is therefore incorrect to recommend any actions that would result in more funding
being needed unless the stakeholders/development organization are willing to invest
more.
– For example, asking the current developers to work overtime or hire new developers
would actually worsen the budget situation.
08-Jan-15
Daniel Sinnig, PhD
100
ECSE 321: Introduction to Software Engineering
Example 3: Bringing the project back on track
• To correct the schedule deficiencies
– Renegotiate contract with stakeholders to reduce the scope of the project or
extend the delivery date;
– Reassign more skilled developers to critical tasks;
– Use reusable components to minimize the time of development (COTS/Open
Source).
08-Jan-15
Daniel Sinnig, PhD
101