UNIT - VI

Risks and Configuration

Management
 5.1 Introduction to risk management
• Risk: The risk denote the uncertainty that occur in the choice
due to past actions and risk is something which causes heavy
losses.
• Risk management: It is the process of identifying, assessing,
and prioritizing the risks to minimize, monitor, and control the
probability of unfortunate events.
• Various activities that are carried out for risk management are-
[Link] identification
[Link] projection
[Link] refinement
[Link] mitigation, monitoring and management
 5.2 software risks
• There are two characteristics of the risks
1. The risk may or may not happen. It shows the
uncertainty of the risk.
2. When risk occur, unwanted consequences or losses
will occur.
• There are three main classifications of risks which can
affect a software project:
[Link] risks
[Link] risks
[Link] risks
[Link] risks:
• Project risk arise in the s/w development process then
they basically affect budget, schedule, resources and
requirements.
• When the project risk get severe then the project cost
will get increased.
[Link] risks:
• These risk affect quality and timeliness of the project .
• If technical risk become reality then potential design
implementation , interface , verification and
maintenance problems gets created. Technical risks
occur when problem becomes harder to solve.
[Link] risks:
• When feasibility of s/w product is in suspect then
business risks occur.
• Business risks can be further categorized as:
i)Market risk: when the quality s/w product is built but
there is no customer for this product then it is called
market risk.(i.e no market for the product).
ii)Strategic risk: when the product is built and if it is not
following the company’s business policies then such a
product brings strategic risk.
iii) Sales risk: when the product is built but how to sell is not
clear then such a situation brings sales risks.
iv)Management risk: when senior management or
responsible staff leaves the organization then
management risk occur.
v)Budget risk: losing the overall budget of the project is called
budget risk.
• Known risks are those risks that are identified after evaluating
project [Link] are also identified from other sources such
as environment in which the product gets developed,
unrealistic deadline, poor requirement specification and s/w
scope. there are 2 types of known risks
o predictable risks are those risks that can be identified in
advance based on past project experience.
eg. Experienced and skilled staff leaving in between or improper
communication with customer resulting in poor requirement
specification.
o Unpredictable risks are those risks that can be guessed earlier.
Eg. certain changes in government policies may affect the
business project.
 5.3 Risk identification
• Risk identification can be defined as the efforts taken to specify
threats to the project plan. Risk identification can be done by
identifying the known and predictable risks.
• The risk identification is based on two approaches.
[Link] risk identification: it includes potential threat
identification to s/w project.
[Link] specific risk identification: it includes product specific
threats identification by understanding people, technology and
working environment in which the product gets built.
• Normally the risk identification is done by project manager who
follows following steps:
Step 1: preparation of risk item check list: risk items can be
identified using following known and predictable components.
i) Product size: the risk items based on overall size of the s/w
product is identified
ii)business impact : risk item related to the marketplace
or management can be predicted.
iii) Customer characteristics: risk associated with
customer-developer communication can be identified.
iv)Process definition: the risk that get raised with
definition of s/w process. this category exposes
important risk items because whichever is the process
definition made, is then followed by whole team.
v)Development environment: the risks associated with
the technology and tool being used for developing the
product.
vI) Staff size and experience
Step 2: creating risk component and drivers list
The set of risk components and drivers list is prepared along
with their probability of occurrence . Then there impact on
the project can be analyzed.
 5.4 Risk projection

• Risk projection, also called risk estimation.

• There are two ways by which risk can be rated-
[Link] that the risk is real.
2. consequences of the problems associated with the risk.
• The project planner, along with other managers and
technical staff, performs four risk projection activities:
1) Establish a scale that indicates the probability of risk
beuing real.
2) Enlist the consequences of the risk.
3) Estimate the impact of the risk on the project and the
product.
4) Note the overall accuracy of the risk projection so that
there will be no misunderstandings.
 5.4.1 building risk table

• Risk table provides a project manager with a simple technique for

risk projection.
• steps in Setting up Risk Table
1) Project team begins by listing all risks in the first column of the
table.
• Accomplished with the help of the risk item checklists.
2) Each risk is categorized in the second column.
(e.g. PS implies a project size risk, BU implies a business risk).
3) The probability of occurrence of each risk is entered in the next
column of the table.
• The probability value for each risk can be estimated by team
members individually.
4) Individual team members are polled in round-robin fashion until
their assessment of risk probability begins to converge.
 5.4.2 Assessing Risk Impact
• Nature of the risk - the problems that are likely if it occurs.
• e.g. a poorly defined external interface to customer hardware (a
technical risk) will preclude early design and testing and will likely
lead to system integration problems late in a project.
• Scope of a risk - combines the severity with its overall distribution
(how much of the project will be affected or how many customers
are harmed?).
• Timing of a risk - when and how long the impact will be felt.
• Overall risk exposure, RE(risk exposure) , determined using:
• RE = P x C
• P is the probability of occurrence for a risk.
• C is the cost to the project should the risk occur.
 5.5 Risk refinement
• It is the process of specifying the risk in more detail.
• The risk refinement can be represented using CTC
(condition transition consequence) format.
• The condition is first stated and then based on this
condition sub conditions can be derived.
• Then determine the effects of these sub conditions in
order to refine the risk.
• This refinement helps in exposing the underlying risks.
 5.6 Risk Mitigation, monitoring and
management (RMMM)
• RMMM stands for Risk Mitigation, monitoring and
management .there are three issues in strategy for
handling the risk is-
[Link] avoidance
[Link] monitoring
[Link] management
[Link] mitigation:
• It is an activity used to avoid problems (Risk Avoidance).
• Steps for mitigating the risks as follows.
[Link] out the risk.
[Link] causes that are the reason for risk creation.
[Link] the corresponding documents from time to time.
[Link] timely reviews to speed up the work.

[Link] monitoring
• It is an activity used for project tracking.
• It has the following primary objectives as follows.

• To check if predicted risks occur or not.

• To ensure proper application of risk aversion steps defined for risk.
• To collect data for future risk analysis.
• To allocate what problems are caused by which risks throughout the
project.
[Link] management:
• It assumes that the mitigation activity failed and the risk
is a reality. This task is done by Project manager when
risk becomes reality and causes severe problems.
• If the project manager effectively uses project
mitigation to remove risks successfully then it is easier
to manage the risks.
• This shows that the response that will be taken for each
risk by a manager.
• The main objective of the risk management plan is the
risk register. This risk register describes and focuses on
the predicted threats to a software project.
 5.7 RMMM plan

• The RMMM plan is a document in which all the risk

analysis activities are described.
• Sometimes project manager includes this document as a
part of overall project plan.
• Sometimes specific RMMM plan is not created,
however each risk can be described individually using
risk information sheet.
• The risk information sheet can be maintained by
database systems.
• After documenting the risks using either RMMM plan or
Risk information sheet the risk mitigation, monitoring
and analysis activities are stopped.
 5.8 Software configuration management(SCM)
• In Software Engineering, Software Configuration
Management(SCM) is a process to systematically manage,
organize, and control the changes in the documents, codes, and
other entities during the Software Development Life Cycle.
• During the development of s/w,change must be managed and
controlled in order to improve quality and reduce error.
• Hence s/w configuration management is a quality assurance
activity that is applied throughout the s/w process.
• The origins of changes that are requested for s/w are-
1. New business or market position cause the changes in the
requirements. Due to which the changes need to occur.
[Link] stakeholders may require some changes in the existing
requirements.
[Link] to business growth or project extension it is essential to
makes changes in the project.
[Link] due to schedule or budget
constraints, changes are must in project.
• SCM is concerned with managing evolving
software systems.
• s/w configuration management is a set of
tracking and control activities that begin when
a s/w development project begins and
terminates when the s/w is taken out of
operation.
 5.8.1 Goals in change management
• During s/w development process, various roles and tasks
are involved.
• The goal of the project manager is to ensure that the
project is getting completed within the given schedule and
budget. Hence project managers continuously track the
progress of the project.
• The configuration managers ensure that the changes in the
projects are appropriately taking place and the testing is
conducted thoroughly after the modification in the project.
• The goal of the s/w engineer is to work on the assigned
module to produce efficient code and error-free code.
• Finally the customer uses the product, analyze it and may
request for a change or find out the bugs
 5.8.2 elements of configuration management
system
• Susan Dart had identified four important elements
for software configuration management system.
These elements are-
1. Component elements
2. Process elements
3. Construction elements
4. Human element
1. Component elements: it consists of a collection of
tools that are used for file management system
Eg. database
2. Process elements: It consists of actions and
tasks used during change management and the
use of s/w.
3. Construction elements: it is a collection of tools
that automate the construction of s/w.
[Link] elements: it consist of set of tools that
are used by s/w team to implement s/w
configuration management.
 5.8.3 baselines
• A baseline is a milestone in the development of
s/w that is marked by delivery of one or more
s/w configuration items and the approval of
them is obtained through formal technical
review.
• The baseline is the shared project database. it is
an SCM task to maintain the integrity of the set
of artifacts.
• In simple words, baseline means ready for
release.
 s/w engineer’s
modification private workspace

SCI

Technical
s/w tasks Approved
SCI review SCI

Project DB

SCI

Extracted
SCM
SCI Extract
control

Fig. Software Baseline

• Step1: The s/w engineering task produce one or more
SCIs.
• Step2:The SCIs are then reviewed and approved.
• Step3: These are then placed in project database or
project library.
• Step4:when s/w engineer wants to make changes to
baselined SCI, it is copied to software engineers private
workspace.
• Step 5:The extracted SCI is modified only if SCM controls
are followed.
 5.8.4 Software configuration items
• S/w configuration items are basically the information
that is created as part of s/w engineering process.
• [Link] s/w configuration items-
Computer programs:
 source program
 Executable program
Documents describing the program
 Technical manual
 Users manual
Data
 Program components or functions
 External data
 File structure
• For each type of item , there may be a large number
of different individual items produced.
• For instance there may be many documents for a
software specification such as project plan, quality
paln,test plan ,design documents,program ,test
reports,review reports.
• These SCI or items will be produced during the
project, stored ,retrieved ,changed ,stored again and
so on.
• Each configuration items must have unique name and
a description or specification which distinguishes it
from other items of the same type.
 5.9 SCM Repository
• Software configuration items (SCI)are maintained in
project repository or project library.
• The software repository is basically a database that acts
as a center for both accumulation and storage for
software engineering information.
• The software engineer interacts with repository using
tools that are integrated within it.
5.9.1 Role of project repository:
• It is collection of information accessed by s/w engineer
to make appropriate changes in it.
• This repository is handled using all the modern databse
management functions.
• This must maintain important properties such as data
integrity,sharing and integration.
• The repository must maintain uniform structure and
format for s/w engineer work products.
• To achieve this capability , the repository is defined in
terms of meta-model. The meta model determines=
i) How information is stored in repository?
ii) How data can be accessed by using the tool?
iii) How the security and integrity of the data is
maintained?
iv) How the existing model can be extended to
accommodate new requirements?
 5.9.2 Features
• The SCM can be performed by interacting with repository. The
repository must have toolset that provides support for
following features-
[Link]:
 as project progresses various versions of individual work
products may get created.
 Repository must be able to maintain all these versions and
permit the developer to go back to previous versions during
testing and debugging.
[Link] tracking and change management:
 The data elements stored in the repository are related to each
other.
 The repository must have an ability to keep track of these
relationship and to maintain data integrity.
[Link] tracing:
 If the constructed components , its designed is tracked,
then particular requirement can be traced out.
 The repository must have this ability to trace the
requirement from constructed components.
[Link] management:
 The repository must be able to keep track of series of
configurations representing project milestones and
production releases.
 5.10 SCM process
• The primary objectives of software configuration
management process (SCM) are-
1. Configuration identification: identify the items that
define the s/w configuration.
2. Change control: manage changes to one or more items.
3. Version control: facilitate to create different versions of
the application.
4. Configuration authentication: to ensure that the
quality of the s/w is maintained as the configuration
evolves over the time.
 5.11.1 identification of objects in software
configuration
The software configuration items must be separately named
and identified as object.
• These objects must be arranged using object oriented
approach.
• There are two categories of objects- basic objects and
aggregate objects.
• The basic object is unit of information created during
requirements analysis, design,coding or testing.
Eg. basic object can be part of source code.
• Aggregate object is a collection of basic objects and other
aggregate objects.
Eg. SRS or data model can be aggregate object
• Each object can be uniquely identified because it has
got-
[Link]: the name of object is nothing but the collection
of characters(string)or some text. It is unique.
[Link]: for describing the objects, the object
description can be given. This description
Contains document, program or some other description
such as project identifier or version information.
[Link] of resources: the resources are the entities that are
used for accessing referencing and processing of
objects. The data type and functionality can serve as a
resource.
[Link] or identification: It is pointer to object.
 5.12 Configuration management for any
suitable s/w system
• Configuration management for web based application.
5.12.1 Dominant issues:
• Web apps get developed in a short span of time using
customer driven approach. Hence there are four major
issues that need to be handled during configuration
management for web application. These issues are-
[Link]:
 The typical web app contains text, graphics, scripts ,
audio/video files, forms, active web pages and so on.
 There is a challenge to organize these contents into
configuration objects and establish control mechanism
for these objects
[Link]:
 Many times the contents for web apps are developed by
the people having no s/w engineering background. Such
people are completely unaware of need for
configuration management.
[Link]:
 The web app grows significantly with interconnections
with information subsystems.
 As size and complexity grows the small changes are
difficult to incorporate of these changes may lead to
problematic situation.
 Hence as scalability of web app grows , the
configuration control mechanism need to be rigorously
applied.
[Link]:
There can be issues related to -
 responsibility for quality control of the web site before
publishing the web site.
 Responsibility about making changes.
 Responsibility for accuracy of information on web page.
 Responsibility for cost changes.
Thank you