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.

1
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

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

3
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.

4
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.

5
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.

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

7
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.

8
Containing Schedule
Slippage
A milestone is
reached,
 when documentation
produced has
successfully been
reviewed.
9
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.
10
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.

11
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.

12
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.

13
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)

14
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.

15
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).

16
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.

17
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

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

19
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.

20
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.

21
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.

22
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

23
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).

24
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.

25
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.

26
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

27
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.

28
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.

29
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.

30
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.

31
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.

32
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.

33
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

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

35