Critical Path

 Task dependencies define a partial

ordering among tasks, i.e.
 Completion of some tasks must precede the
starting time of some other tasks.
 A critical path:
 along which every milestone is critical to
meeting the project deadline.
 A Critical Path is a chain of tasks that
determine the duration of the project.

1
Critical Paths
 A critical paths is sequence of tasks such
that
 a delay in any of the tasks will cause a delay to
the entire project.
 There can be more than one critical path in a
project.
 It is important for the project manager to be
aware of the critical paths in a project:
 can ensure that tasks on these paths are
completed on time.

2
Critical Paths
 Other tasks may have some room for delay
without affecting the entire project.
 If necessary, the manager may switch
resources from a noncritical task to a critical
task.
 Several software packages are available
for automating the scheduling process:
 MacProject on Apple Macintosh computer
 MS-Project on Microsoft Windows Operating
System.

3
CPM and PERT Charts
 While Gantt charts show the
different tasks and their
durations clearly:
 they do not show intertask
dependencies explicitly.
 this shortcoming of Gantt charts
is overcome by PERT charts.

4
Critical Path Management
 Critical Path Management(CPM) is
a technique for:
 Identifying critical paths
 Managing project.
 The CPM technique is not specific
to software engineering
 has a much wider use.

5
Critical Path Management
 CPM can assist in answering
questions like:
 What are the critical paths in the
project?
 What is the shortest time in which the
project can be completed?
 What is the earliest (or latest) time a
task can be started (or finished) without
delaying the project?

6
Example
 A project involves three tasks:
 task a takes 4 hours,
 task b takes 5 hours
 task c takes 8 hours.
 task c cannot commence until task a is completed.
 What is the shortest time in which the project
can be completed?
b
start 5 finish

4 a c
8

7
Example
 Clearly, the project continues until task
a and then task c complete:
 which is 12 hours.
 Task b takes only 5 hours.
 Task b can have 7 hours of leeway to start
and finish.
b
start 5 finish

4 a c
8

8
What data do we need to construct a
CPM graph?
 To construct a CPM graph,
 a list of tasks and their durations are
required.
 Also, for each task a list of tasks upon
which it depends is required.
 A task may depend on more than one
task.
 Project task details can be given in the
form of a table.

9
Task Table
 Task Duration Dependents
a 10
b 20
c 20 a,g
d 5 b
e 10 b
f 5 h

10
CPM Graph
c:20

a:10

start finish
g:5
b:20 f:5
d:10

e:10

11
How do we work out the various start and
finish times for tasks?
 Minimum time to complete project (MT) =
Maximum of all paths from start to finish
 Earliest start time (ES) of a task = Maximum of
all paths from start to this task
 Earliest finish time (EF) of a task = ES +
duration of the task
 Latest finish time (LF) of a task = MT -
Maximum of all paths from this task to finish
 Slack time = LS - ES = LF - EF

12
Start and finish times for
tasks.
 Latest start time (LS) of a task = LF - duration
of the task
Task MT EF ES LF LS
a 10 0 10 15 5
b 20 0 20 25 0
c 20 10 30 35 15
d 5 20 25 30 25
e 10 20 30 30 20
f 5 0 5 15 10

13
What are the float time (or slack time)
of tasks?
 Float time (or slack time) is the total
time that a task may be delayed
 before it will affect the end time of the
project.
 The float times indicate the "flexibility"
in starting and completion of tasks:
 A critical activity is an activity with zero
(0) slack or float time.

14
What is PERT and how
does it work?
 PERT (Program Evaluation and Review
Technique) is a variation of CPM:
 incorporates uncertainty about duration of tasks.
 Gantt charts can be derived automatically from
PERT charts.
 Gantt chart representation of schedule is
helpful in planning the utilization of resources,
 while PERT chart is more useful for monitoring the
timely progress of activities.

15
Risk Management
 A risk is any unfavourable event or
circumstance:
 which might hamper successful or timely
completion of a project.
 Risk management:
 concerned with the reduction of the impact of
risks.
 Risk management consists of three activities:
 risk identification,
 risk assessment, and
 risk containment.

16
Risk identification
 To be able to identify various risks:
 we must categorize risks into different
classes.
 Three main categories of risks can
affect a software project:
 project risks
 technical risks
 business risks

17
Project Risks
 Project risks associated with:
 budget,
 schedule,
 personnel,
 resource, and
 customer problems.

18
Technical Risks
 Technical risks concern:
 requirements specification
 (e.g ambiguous, incomplete, changing
specifications)
 design problems,
 implementation problems,
 interfacing problems,
 testing, and maintenance problems.
 technical uncertainty, and technical
obsolescence are technical risk factors too.

19
Business Risks
 Business Risks include:
 building an excellent product that no one
wants,
 losing budgetary or personnel commitments, etc.
 It is a good idea to have a “company
disaster list”,
 a list of all bad things that have happened in the
past
 project managers can jog their mind to see
which items their project is vulnerable to.

20
Risk assessment
 Objective of risk assessment is to
prioritize the risks:
 Likelihood of a risk being real.
 Consequence of the problems
associated with that risk.
 Prioritization helps in handling the most
damaging risks first.
 Priority of a risk is the product of the
likelihood of the risk and the consequences of
the problems associated with that risk.

21
Risk Handling
 Three main strategies for risk handling:
 Avoid the risk: e.g. change the requirements
for performance or functionality.
 Transfer the risk: allocate risks to third
party
 or buy insurance to cover any financial loss
should the risk become a reality.
 Contingency planning: Prepare contingency
pans to minimize the impact of the risk.

22
Risk Handling
 To decide about risk
handling options, we
must take into account:
 cost of reducing risk
 resulting cost saving from
risk reduction.

23
Risk Containment
 Let us see how we can contain an
important type of risk:
 schedule slippage
 can be dealt with by increasing the visibility
of the project.
 Milestones are placed at regular
intervals
 provide a manager with regular
indication of progress.

24
Containing Schedule
Slippage
 A milestone is reached,
 when documentation
produced has
successfully been
reviewed.

25
Software Configuration
Management
 The results (aka deliverables) of any
large software development effort
consists of a large number of objects:
 source code,
 design document,
 SRS document,
 test document,
 project plan (SPMP) document, etc.

26
Software Configuration
Management (CONT.)
 A configuration is a collection of
deliverables:
 being developed for some customer.
 As development proceeds,
 the components comprising a
configuration undergo changes:
 Even during maintenance, the
components comprising a configuration
keep changing.

27
What is configuration
management?
 The set of activities through
which the configuration
items are managed and
maintained
 as the product undergoes its
life cycle phases.

28
Versions
 A configuration for a particular
system is called a version:
 The initial delivery might consist of
several versions,
 more versions might be added later on.
 For example, one version of a
mathematical package might run on a
Unix machine,
 another on Windows NT, and
 another on Solaris.

29
Versions
 As a software is released and used by the
customers:
 errors are discovered,
 enhancements to the functionalities might be
needed.
 A new release of the software is an
improved system intended to replace an old
one.
 Usually a product is described as version m
and release n (or as version m.n)

30
Software Configuration
Management
 Existence of variants of a
software product causes several
problems.
 Suppose you have several
versions of the same module, and
 find a bug in one of them.
 it has to be fixed in all versions.

31
Software Configuration
Management
 Different objects are accessed and
modified by a number of
engineers.
 Unless strict discipline is enforced:
 regarding updation and storage of
the objects through some automated
tool,
 several problems appear.

32
Software Configuration
Management
 For example, an engineer might update
the module that he has designed ---
 without informing the engineers who need
to interface with this module.
 Or, two engineers may simultaneously
carry out changes to different portions
of a module:
 while saving overwrite each other.

33
Why Configuration
Management?
 To be able to identify the exact state of different
deliverables at any time.
 To avoid the problems associated with having replicated
objects accessible by multiple engineers.
 Controlling concurrent work on a module by different
engineers. (Overwriting one engineer’s work by another)
 Letting different engineers work on related modules at
the same time.
 Keeping track of variants (versions) and helping fix bugs
in them.
 Storing versions and revisions efficiently.
 Maintaining revision history (accounting).

34
Software Configuration
Management
 Configuration management helps to:
 quickly determine the current state of the
product
 change the various components
(modifications, revisions, variations etc.)
in a controlled manner.
 maintaining the current up-to-date status
of various versions of the software,
 control and account changes to the
product.

35
In short
 Inconsistency problem when the objects are
replicated-changes to local copy bt not
informing
 Problems associated with concurrent access
 Providing a stable development environment-
A integrates , B and C changes –cont,etc
 System accounting and maintaining status
information
 Handling variants

36
Baseline

 A baseline is the status of all the objects

under configuration control. When any of
the objects under c control is changed, a
new baseline gets formed.
 It may be archived periodically(copying to
a safe place) so that the last baseline can
be recovered in case of disaster.

37
Software Configuration Management
Activities
 Configuration management is
carried out through three
principal activities:
 configuration identification,
 configuration control,
 configuration accounting and
reporting.

38
Software Configuration
Management Activities
 Configuration identification
 which parts of the system must be
kept track of?
 Configuration control
 ensures that changes to a component
happen smoothly.
 Configuration accounting
 keeps track of what has been
changed, when, and why.

39
Configuration
Identification
 Deliverable objects can be classified
into three main categories:
 controlled,
 precontrolled,
 uncontrolled.
 Controlled objects are under
configuration control:
 you must follow some formal procedures to
change them.

40
Configuration
Identification
 Precontrolled objects are not
yet under configuration control,
 but may eventually be under
configuration control.
 Uncontrolled objects are not
and will not be subject to
configuration control.

41
Configuration
Identification
 Typical controllable objects include:
 Design documents
 Tools used to build the system, such as
compilers, linkers, lexical analyzers,
parsers, etc.
 Source code for each module
 Test cases
 Problem reports

42
Configuration Control
 Configuration control is the process of
managing changes.
 It is the part of configuration
management that most directly affects
day-to-day operations of the developers.
 Once an object goes under
configuration control,
 any further changes requires approval
from a change control board (CCB).

43
Configuration Control
 The CCB is constituted from among
the development team members.
 For every change carried out,
 CCB certifies several things about the
change:
 Change is well-motivated.
 Developer has considered and documented
the effects of change.
 Appropriate people have validated the
change.

44
Configuration Control
 An important reason for configuration control:
 people need a stable environment to develop a
software product.
 Suppose you are trying to integrate module A,
with the modules B and C,
 you cannot make progress if developer of module C
keeps changing it;
 this is especially frustrating if a change to module C
forces you to recompile A.
 As soon as a document under configuration
control is updated,
 the updated version is frozen and is called a baseline.

45
Configuration Control
Baseline New Baseline

A B A B

C D C’ D

Reserve
Replace

Cancel Reservation

C
Private Copy

46
Configuration Control
 This establishes a baseline for others to use.

 Freezing a configuration may involve

archiving everything needed to rebuild it.
 Archiving means copying to a safe place such as
a magnetic tape.
 At any given time, a programmer may pay
attention to:
 Current baseline configuration
 Programmer's private version

47
SCCS (Source Code Control
System)
 SCCS is a configuration
management tool:
 available on Unix systems:
 helps control and manage text files.
 also implements an efficient way of
storing versions:
 minimizes the amount of occupied disk
space.

48
SCCS
 Suppose a module is present in 3
versions:
 MOD1.1, MOD1.2, and MOD1.3.
 SCCS stores the original module
MOD1.1
 together with changes needed to
transform it into MOD1.2 and MOD1.3.
 the modifications are called deltas.

49
SCCS Features
 Access control facilities provided by SCCS
include:
 facilities for checking components in and
out.
 Individual developers check out
components and modify them.
 after they have changed a module as required
and the module has been successfully tested,
 they check in the changed module into SCCS.

50
SCCS Features
 Revisions are denoted by numbers
in ascending order,
 e.g, 1.1, 1.2, 1.3 etc.
 It is also possible to create
variants of a component
 by creating a fork in the development
history.

51
Summary
 Project staffing requires careful
understanding of the attributes of good
software engineers.
 Project scheduling:
 break down large tasks into smaller logical
units,
 determine dependencies among tasks,
 determine expected duration of tasks,
 assign resources, and
 assign times.

52
Summary
 Several techniques are available to
help in scheduling:
 Work breakdown structure
 Activity networks
 Gantt charts
 PERT and CPM
 Commercial software tools are
available to assist in developing these.

53
Summary
 It is necessary to determine the
critical paths in a project:
 to meet the timing for critical activities.
 An important project planning
activity is risk management:
 Risk identification
 Risk assessment
 Risk containment

54
Summary
 Configuration
management.
 the set of activities by
which a large number of
objects are managed and
maintained.

55