CHAPTER 6

RISK MANAGEMENT

Risk

A problem or a threat that you would prefer not to have during your project development
because it can threaten the project, software or the organization.

Risk Management

Involves anticipating risks that might affect the project schedule or quality of
software being developed and taking actions to avoid those risks. Results of risks
analysis should be documented in project plan along with an analysis of the consequences
of risk occurring.

Importance of risk management

It is easier to cope with problems and ensure that they do not lead to unacceptable
budget or schedule slippage.
- Because of inherent uncertainties that most projects face.

Categories of Risks

i) Project risks - affect project schedule or resources e.g.

Loss of experienced designer.

ii) Product Risks – Affect quality or performance of

software e.g. purchased component not performing as
expected.

iii) Business risks - Affect organizational dev or procuring

software e.g. Competitor introducing new product.

Causes of risks

-Stem from loosely defined requirements.

-Difficulty in estimating the time and resources required for

software development.

-Dependence on individual skills.

-Requirements changes due to changes in customer needs.

Types of risks and possible risks

There are different types of risks:

i. Technology risks – are risks from software and hardware technologies. E.g.
database used in system can’t process as many transactions as possible.
ii. People risks – are associated with people in the development team .e.g.
impossible to recruit staff with skills required.
iii. Organizational risks – derived from the organizational environment where
software is being developed. E.g. organizational financial problems.
iv. Tools risks – derived from case tools and other software used to develop the
system. E.g. code generated by case tools is inefficient.
v. Requirements risks – derived from changes in customer requirements and
processes of managing the requirements change. E.g. changes in requirements that
require major design rework are proposed.
vi. Estimation risks – derived from management estimates of system characteristics
and resources required to build the system. E.g. time required to develop the
system is underestimated.

Stages of risk management

Process of risk management involves four stages:

1. Risk identification – is whereby the possible project, product and business

risks are identified. This may be carried out as a team process using a
brainstorming approach.

2. Risk analysis – is whereby the likelihood and consequences of this risk are
assessed. Consider each identified risk and make judgment about probability
and seriousness of it. Estimate probability i.e. very low (<10%), low (10-
25%), moderate (25-50%), high (50-75%) or very high (>75%).

3. Risk planning – whereby plans to address the risk either by avoiding or

minimizing its effect are discussed and strategies to manage it are identified.
i.e.
Avoidance strategy – following this means that probability that
the risk will arise will be reduced.
Minimization strategy – following this means that impact of the
risk will be reduced.
Contingency plans - following this means that you are
prepared for the worst and have a strategy in place to deal with it.

4. Risk monitoring – whereby the risk is constantly assessed and plans for risk
mitigation revised as more information about the risk become available.
 Stages of Risk Management Process (Diagram)

Risk Risk Risk Risk

Identification Analysis Planning Monitoring

List of Prioritized Risk voidance Risk

potential risk list and contingency assessment
risks plans

SYSTEM DOCUMENTATION

It is a very important aid to maintenance engineers.

Definition.
It includes all documents describing implementation of the system from requirements
specification to final test plan.
The documents include:
 Requirement documents and an associated rationale
 System architecture documents
 Design description
 Program source code
 Validation documents on how validation is done
 Maintenance guide for possible /known problems.

Documentation should be
 Clear and non-ambiguous
 Structured and directive
 Readable and presentable
 Tool-assisted (case tools) in production (automation).

PROGRAM EVALUATION DYNAMICS

Program evolution is the study of system change Lehman’s Laws (by Lehman Beladay
1985) about system change.
The Laws are:
a) Law of Continuing change
Program used in real world environment must change or become progressively less useful
in the environment.
b) Law of Increasing complexity
Program changes make its structure more complex therefore extra resources must be
devoted to preserving and simplifying the structure.
c) Law of Large program evolution
Program evaluation in self-regulating process.
d) Law of Organization stability
In a program lifetime its rate of development is approximately constant and independent
of resources devoted to system development.
e) Law of Conservation familiarity
Over the system lifetime the incremental change in each release is approximately
constant.

CONFIGURATION MANAGEMENT
Software configuration
A collection of the items that comprise all information produced as part of the software
process.
The output of software process in information and include PC programs, documentation
and the data (in its program and external to it).

Software configuration management

Definition 1
These are a set of activities that are developed to manage change through out the life
cycle of PC software.
Changes are caused by:
 new business / market conditions and rules
 new customer needs
 reorganization or business growth
 Budgetary or scheduling constraints e.t.c.

Definition 2
The process, which controls the changes, made to a system and managers the different
versions of the evolving software product.
Involves development and application of procedures and standards for managing an
evolving system product. Procedures should be developed for building system releasing
them to customers
Standards should be developed for recording for recording and processing proposed
system changes and identifying and storing different versions of the system.
Configuration managers (team) are responsible for controlling software changes.
Controlled systems are called baselines. They are the starting point for controlled
evolution.

Software may exist in different configurations (versions).

 produced for different computers (hardware)
 produced for different operating system
 produced for different client-specific functions e.t.c

Configuration managers are responsible for keeping track of difference between software
versions and ensuring new versions are derived in a controlled way.
Are also responsible for ensuring that new versions are released to the correct customers
at the appropriate time.

Configuration management and associated documentation should be based on a set of

standards, which should be published in configuration management hand book (or quality
handbook) E.g. IEEE standards 8238-1983 which is standard for configuration
management plans.

Main configuration management’s activities:

1. configuration management planning (planning for product evolution)
2. managing changes to the systems
3. controlling versions and releases (of systems)
4. building systems from other components

Configuration Management and Planning

Configuration management and planing takes control of the systems after they have been
developed therefore planning the process must start during development.
The plan should be developed as part of overall project planning process.
The plan should include:
(a) Definitions of what entities are to be managed and formal scheme for identifying
these entities.
(b) Statement configuration management team.
(c) Configuration management policies for change and version control / management.
(d) Description of the tools to be used in configuration management and the process to be
used.
(e) Definition of the configuration database which will be used to record configuration
information. (Recording and retrieval of project information.)
(f) Description of management of external information
(g) Auditing procedures.

Configuration database is used to record all relevant information relating to configuration

to:
a) assert with assessing the impact of system changes
b) Provide management information about configuration management.
Configuration database defines/describes
 Customers who have taken delivery of a particular version
 Hardware and software operating system requirements to run a given version.
 The number of versions of system so far made and when they were made e.t.c.
CHANGE MANAGEMENT.

Change management process involves technical change analysis, cost-benefit analysis

and change tracking

Stages of change management:

(1) 1st Stage
1st stage in change management is to complete a change request from (CRF).
A change request form is a formal document that sets out the changes required to the
system, records recommendations regarding the change, estimated costs of the change,
dates when change was requested, approved, implemented and validated. Also section
where engineers outline how change is to be implemented.
(2) 2nd stage
It involves analysis of the change requested, for validity. (If it is invalid, duplicated or
already considered it is rejected). Any rejection should be returned to the person who
rejected it.
(3) 3rd stage
For valid changes. Assessment and costing of the change is made, the impact of the
change on the rest of system assessed, also check on how (technically) it will be
implemented.
(4) 4th Stage
Submission to Change Control Board (CCB) who decide whether on not the change
should be accepted (after considering cost, impact e.t.c)
(5) 5th Stage
After approval by the CCB the software is taken to software maintenance team for
implementation, after which it is validated (tested) then released (by configuration
management team and not maintenance team).

VERSION AND RELEASE MANAGEMENT.

Version and release management are the processes of identifying and keeping track of
versions and new releases of system.
 Ensures release (time), right version is released.
 Some versions may be designed to operate in different hardware or software
(operating system) platforms though their functions are the same.
System release - version that is distributed to customer.
A release (isn’t only a set of programs but) includes: -
 Configuration files - defining how the release should be configured for installations.
 Data files – needed for successful system operation.
 Installation programs - to help install the system on target hardware
 Electronic and paper documentation - describing the system.
All information must be availed to customers.
SYSTEM BUILDING

System building is the process of combining the components of a system into a program,
which executes on a particular target configuration.
It involves
 Compilation of some components.
 Linking processes putting object code together to make executable systems.
System building tools have been developed to reduce the build time and effort of
compiling and linkage (e.g. “make” for Unix system)