The Project Management Discipline
Yazd University, Electrical and Computer Engineering Department
Course Title: Advanced Software Engineering
By: Mohammad Ali Zare Chahooki
Purpose
It does
not cover :
 Managing people: hiring, training, coaching
 Managing budgets: defining, allocating
 Managing contracts with suppliers and customers
2
Purpose
This discipline focuses on:
 Planning an iterative project
through the lifecycle and planning a particular iteration
 Risk management
 Monitoring the progress of an iterative project and
measurements
3
Purpose
plans to be
realistic
must have a very good understanding of what will be built
Therefore:
 Must have stable requirements and
 A stable architecture, and
 Must have built a similar system from which
 you can derive a detailed work breakdown structure (WBS).
4
Planning and Iterative Project
In an iterative process, the development is based on two kinds
of plans:
 A coarse-grained plan
 the phase plan
 A series of fine-grained plans
 the iteration plans
5
Purpose
6
The Concept of Risk
 Direct risk
 a risk over which the project has a large degree of control
 Indirect risk
 a risk over which the project has little or no control
7
The Concept of Risk
Risk important attributes:
 The probability of occurrence (its likelihood)
 The impact on the project (its severity)
8
The Concept of Risk
Strategies: How to Cope with Risks
The key idea in risk management:
You dont wait passively until a risk becomes a problem
9
The Concept of Risk
Main routes:
 Risk avoidance
 Reorganize the project so that …
 it cannot be affected by the risk.
 Risk transfer
 Reorganize the project so that someone or something else bears the
risk.
 For example: the customer, vendor, bank, or another element
 Risk acceptance
 Decide to live with the risk as a contingency.
 Monitor the risk symptoms and
 determine what to do if the risk materializes.
10
The Concept of Risk
When accepting a risk, you should do two things:
 Mitigate the risk
 steps to reduce the probability or the impact of the risk.
 Define a contingency plan
 Determine the action to take if the risk becomes an actual
problem
11
The Concept of Measurement
 Measuring key aspects of a project adds a non-negligible cost
 We must set precise goals for a measurement effort and
 Collect only measurements that allow us to satisfy these
goals.
12
The Concept of Measurement
Two kinds of goals:
 Knowledge goals
 Assess product quality,
 Monitor test coverage or
 Monitor requirements changes.
 Change goals
 They express an interest in seeing how things change or
improve over time,
 from one iteration to another, and
 from one project to another.
13
The Concept of Measurement
Goals examples:
 Monitor progress relative to the plan.
 Improve customer satisfaction.
 Improve productivity.
 Increase reuse.
14
The Concept of Measurement
Goals Action goals
For example: "Improve customer satisfaction"
 Define customer satisfaction.
 Measure customer satisfaction over several releases.
 Verify that satisfaction improves.
15
The Concept of Measurement
Goal Sub-goals
Example: "Improve productivity"
 Measure effort.
 Measure progress.
 Calculate productivity over several iterations or
projects.
 Compare the results.
16
Roles and Artifacts
17
18
Workflow
Staff/Schedule Trade-off
Cannot trade staff for schedule.
COCOMO (Constructive Cost Model)
19
Workflow
20
Workflow
Some heuristics:
1) Stretch the inception phase
 If need a long time to
 scope the project,
 find the funding,
 conduct market research, or
 build an initial proof-of-concept prototype,
21
Workflow
2) Stretch the elaboration phase
 If
 No architecture in place,
 Using new and unknown technology,
 Have severe performance constraints,
 Have a number of technical risks, and
 Have a lot of new staff,.
22
Workflow
 If this is the second generation of a product or
 if you will make no major changes to the architecture,
shrink the inception and elaboration phases.
23
Workflow
 If you must hit the market quickly
 because you are late or
 because you are creating the market
 If you must plan to finish the product gradually,
 you can shorten the construction phase and
 lengthen the transition phase
24
Duration of an Iteration
Workflow-
 An iteration starts with planning and requirements and ends
with a release, either internal or external.
 Ideally, an iteration should span from two to six weeks, but
this varies from project to project.
25
Duration of an Iteration
Workflow-
How quickly you can iterate depends on:
 Size of the development organization.
 Degree of the organization's familiarity with the iterative
approach;
 Level of automation used by the team to manage code
 Testing and automation of it.
an iteration has some fixed overhead for planning,
synchronizing, and analyzing the results.
26
Number of Iteration
In inception phase:
Workflow-
 there will be no real iteration;
 no software is produced, and
 there are only planning and marketing activities.
In some cases, an iteration for:
 Building a prototype
27
Number of Iteration
Workflow-
In elaboration phase:
 Should plan at least one iteration.
 If have no architecture must accommodate a lot of new factors
 New people,
 New tools,
 New Technology,
 New Platform, or
 New programming language
 Then should plan two or three iterations.
 Cannot tackle all the risks at once.
 May need to show a prototype to the customer or end users
 Need an iteration to correct early mistakes on the architecture.
28
Number of Iteration
Workflow-
In construction phase
 Should plan at least one iteration.
 Two is more reasonable for a better integration and testing.
 For more ambitious projects, three or more iterations are even
better
29
Number of Iteration
Workflow-
In transition phase
 At least one iteration,
 Too often,
 The realities of the market or
 The (poor) quality of the initial release will force you to do
more iterations.
30
Number of Iteration
Workflow-
Over the entire development cycle [I, E, C, T]:
 Low: three iterations [0, 1, 1, 1]
 Typical: six iterations [1, 2, 2, 1]
 High: nine iterations [1, 3, 3, 2]
31
Building an Iteration Plan
Follow these four steps:
1) Define objective criteria for the success of the iteration.
 These criteria will used in an iteration assessment review
2) Identify the artifacts that will need to be developed or
updated and the activities that will be required to achieve this.
3) Beginning with a typical iteration work breakdown structure
(WBS) , and aarange it to take into account the actual
activities that must take place.
4) Use estimates to assign duration and effort to each activity,
keeping all numbers within your budget.
32
Building an Iteration Plan
Objective drivers of an iteration in elaboration phase:
1) Risk
2) Criticality
3) Coverage
33
Objective Drivers
Building an Iteration Plan-
1) Risk
 For damaging risks, identify a scenario in one use case that
would force the development team to "confront" the risk.
 Examples:
 If there is an integration risk, such as "database D working properly with
OS Y," be sure to include one scenario that involves some database
interaction even.
 If there is a performance risk, such as "excessive time to compute the
trajectory of the aircraft," be sure to include one scenario that includes
this computation, at least for the most obvious and frequent case.
34
Objective Drivers
Building an Iteration Plan-
2) Criticality
 Select scenarios from the use cases that represent the most
common or the most frequent form of the service or feature
offered by the system.
3) Coverage
 Include scenarios that touch areas you know will require
development even if these scenarios are neither critical nor
risky
35