Unit -V

Risks and Configuration

Management
Content….
 Risk Management
 Software Risk
 Risk identification
 Risk Protection
 Monitoring and Management
 RMMM Plan
Risk Management
 Risk:- "Tomorrow problems are today's risk." Hence,
a clear definition of a "risk" is a problem that could
cause some loss the progress of the project, but
which has not happened yet.
 These potential issues might harm cost, schedule or
technical success of the project and the quality of
our software device, or project team morale.
 Risk Management is the system of identifying
addressing and eliminating these problems before
they can damage the project.
 Risk management is a sequence of steps that help a
software team to understand , analyze and manage
uncertainty.
 Risk management consists of
➢Risk Identification
➢Risk analysis
➢Risk Planning
➢Risk Monitoring
 There are three main classifications of risks which
can affect a software project:
1. Project risks
2. Technical risks
3. Business risks
Principle of Risk Management
 Global Perspective: In this, we review the bigger
system description, design, and implementation. We
look at the chance and the impact the risk is going to
have.
 Take a forward-looking view: Consider the threat
which may appear in the future and create future
plans for directing the next events.
 Open Communication: This is to allow the free flow
of communications between the client and the team
members so that they have certainty about the risks.
 Integrated management: In this method risk
management is made an integral part of project
management.
 Continuous process: In this phase, the risks are
tracked continuously throughout the risk
management paradigm.

Question: Explain principles of risk management in details. 8 marks

Risk Management Paradigm:
Software Risk
 A possibility of suffering from loss in software
development process is called a software risk.
 Risk is an uncertain future event with a probability of
occurrence and potential for loss.
 Loss can be anything, increase in production cost,
development of poor quality software, not being able
to complete the project on time.
 Software risk exists because the future is uncertain
and there are many known and unknown things that
cannot be incorporated in the project plan.
Source of Risk:
 Misunderstanding of customer requirement.
 Uncontrolled and continuous changing of customer
requirements.
 Unrealistic promises given to the customers.
 Misunderstanding of real impact of new
methodologies.
 Miscalculation of team work and group effectiveness.
 Wrong budget estimation.
 Types of Risk:
Risks

Project Risks Business Risks

Product Risks
1) Project Risks:
 These are the risks that directly affect the schedule
of the project and the resources involved in the
development process.
 Example of project loss: loss of an experienced
developer and designer.
2) Product Risks:
 The product risks affect the quality and
performance of the application built.
 Example of product risks: failure of purchased
component to perform as per expectation.
3) Business Risks:
The business risks are affecting the organization those
develop and process the software.
Example of business risks: a competitor of the
organization introducing a new product.

Question : what are the types of risks? Explain in brief. 6 Marks

Risk Management Process
Risk Identification
 The project organizer needs to find out risk in the
project as early as possible.
 We identify the risks and list them.
 So, the impact of risk can be reduced by making
effective risk management planning.
 There are two Types of risks Identification.

generic risks product-specific risks

Identification Identification
 Generic risks are a potential threat to every software
project.(Overall)
 Product-specific risks can be identified only by those
with a clear understanding of the technology, the
people, and the environment that is specific to the
project at hand.
 Steps in risk Identification

1) preparation of risk item check list

2) creating risk components and drivers

list.
1) preparation of risk item check
list.
The check list can be created of risk and then focus is
subset of known and predictable risks in following
subcategories.
➢ Business impact
➢ Product size
➢ Customer characteristics
➢ Process definition
➢ Development environment
➢ Technology to be built
➢ Staff size and experience
 Product size—risks associated with the overall size of
the software to be built or modified.

 Business impact—risks associated with constraints

imposed by management or the marketplace.

 Customer characteristics—risks associated with the

sophistication of the customer and the developer's
ability to communicate with the customer in a timely
manner.

 Process definition—risks associated with the degree

to which the software process has been defined and
is followed by the development organization.
 Development environment—risks associated with
the availability and quality of the tools to be used to
build the product.

 Technology to be built—risks associated with the

complexity of the system to be built and the
"newness" of the technology that is packaged by the
system.

 Staff size and experience—risks associated with the

overall technical and project experience of the
software engineers who will do the work.
2) creating risk components and drivers
list.
In the project development process it is essential for a
project manager to identify the factors that affect the
following risk components.
➢ Performance
➢ Cost
➢ Support
➢ Schedule

1) Performance: it is defined as the degree of

uncertainty that an application satisfy the requirement
expected by the customer.
2) Cost risk:
It is defined as the degree of uncertainty that a project
does not exceed its budget.
3) Support risk:
It is defined as the degree of uncertainty that the final
product will be adaptable and easy to maintain.
4) Schedule risk:
It is defined as the degree of uncertainty that the final
product will be delivered on its deadline as mentioned
in the documents.

What is risk Identification ? What are the different categories of risks? 8M

Risk Projection
 Risk Projection is also called as Risk estimation.
 Two methods in Risk Projection.
➢The probability that risk is real.
➢The consequence with that risk.

 The project planner along with other technical and

managers staff, performs 4 risk projection activities
that are as follows
1. Building risk table
2. Enlist the consequence of risks.
3. Estimate the impact of those risks on our project.
4. Maintaining overall accuracy of risk projection.
Developing a Risk Table
 A risk table provides a project manager with a simple
technique for risk projection.
 sample risk table is illustrated in below Figure.
 In the table Impact values are as follows:
1= for the disastrous situations
2= for some critical situations
3= for the average situations
4= for the negligible situations.
 In above table the categories used are as follows:
 PS used for project size risk
 BU used for business risk
 CU used loss of funds
Simple Risk Table
 A project team begins by listing all risks in the first
column of the table.
 This can be accomplished with the help of the risk
item checklists.
 Each risk is categorized in the second column (e.g.,
PS implies a project size risk, BU implies a business
risk).
 The probability of occurrence of each risk is entered
in the next column of the table.

Question: Write a short note on Risk Table. 4 Marks

Risk Refinement
 Risk refinement is a process of specifying the risk in
more detail.
 Risk refinement can be represented using CTC
format.
 CTC = Condition- transition- consequence.
 The condition is first stated and based on this
condition sub condition can be derived.
 Then determine effects of this sub condition in order
to refine the risk.
 This refinement helps in exposing risk.
 This approach makes it easier for project manager to
analyze risk in detail.
Risk Mitigation, Monitoring and
management(RMMM)
An effective strategy for dealing with risk must consider three
issues.
➢Risk Mitigation(Avoidance)
➢Risk Monitoring
➢Risk management
1) Risk Mitigation

 It is an activity used to avoid problems (Risk

Avoidance).
Steps for mitigating the risks as follows.
➢Finding out the risk.
➢Removing causes that are the reason for risk
creation.
➢Controlling the corresponding documents from
time to time.
➢Conducting timely reviews to speed up the work.
Risk 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.
Risk 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.
Example of RMMM:
Example:
Let us understand RMMM with the help of an example of
high staff turnover.
 Risk Mitigation:
 To mitigate this risk, project management must develop
a strategy for reducing turnover.
 Following are steps taken for risk avoidance:
➢Communicate with staff to find risk/ causes of turnover
(eg: poor working condition, low pay, competitive job
market)
➢Find out and eliminate all those causes that can create risk
before project start.
➢Develop policy which helps to continue project even some
staff leaves.
➢Maintain corresponding documents in timely
manner.
➢Conduct timely reviews in order to speed up work.
➢Assign additional staff for every critical technology.

Risk Monitoring:
Things must be monitored by project manager:
▪ Behavior of team members as pressure of project varies.
▪ Degree in which team performs with spirit of “Team-
Work”.
▪ Type of co-operation among team members.
▪ Type of problems that are occurring.
▪ Availability of jobs within and outside organization.
Risk Management:
◦ Many people leaves the organization then if sufficient
additional staff is available, and current development
activity is known to all also all latest documentation is
available then any new comer will easily understand
current development activity.
◦ So it will help in continuing work without any interval.

Question: Write a short note on RMMM 5 Marks

RMMM Plan
 RMMM plan is a document in which all the risk
analysis activities are described.
 Sometimes project manager includes this document
as part of overall project plan.
 If RMMM plan is not created, risk can be described in
risk information sheet.
 These sheet can be maintained by database systems.
 If we are documented risk using either RMMM plan
or Risk information sheet , the risk avoidance, risk
monitoring and risk analysis activities are stopped.
Examples of RMMM Plan
Ex: Some of risks may occur during development process.
1) Risk: Computer Crash:
Avoidance:
 Cause the loss of important data.
 It is always recommended that software organization
should keep multiple copies of data at multiple
locations to avoid loss.
Monitoring:
 Project manager must keep watch on working
infrastructure before development work starts.
Management:
 Any inconvenience in working environment must be
noticed immediately and proper action should be taken.
2) Risk: Poor Comments in code:
Avoidance:
 Writing standard must be followed while coding.
 All functions and sub functions must be commented
properly for better understanding of code
Monitoring:
 Code must be reviewed on regular basis to
determine any poor comment.
Management:
 If any poor comments are observed , actions must
be taken to minimize poor commenting .

Question: Explain RMMM plan with suitable example. 6 Marks

Software Configuration
Management (SCM)
 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.
 The primary goal is to increase productivity with
minimal mistakes.
 So, SCM is Quality Assurance Activity that is applied
throughout software process.
 Sources of changes that are requested for software
are:
1. New business or market positions cause changes in
requirements. Due to which changes need to occur.
2. New stakeholders may require some changes in
existing requirements.
3. Due to business growth or project extension, it is
essential to make changes in project.
4. Due to schedule or budget constraints, changes
must in project.
Diagram of SCM
Elements of Configuration
Management System(SCM):

Component Construction
Element Element

Elements of SCM

Process Element Human Element

1) Component Elements:
It consist of collection of tools that are used for file
management. EX: Database.
2) Process Elements:
It consist of actions and tasks used during change
management and use of software.
3) Construction Elements:
It is collection of tools that automate construction of
software.
4) Human Elements:
It consist of set of tools that are used by software team to
implement software configuration management.
Question: Write a short note on : Elements of a configuration Management
System. 5 Marks.
Baselines of SCM
 A baseline is milestone and reference point in
software development that is marked by completion
or delivery of one or more software configuration items
and formal approval of set of predefined products is
obtained through formal technical review.
 Baseline is shared project database.
 It is task of Software Configuration Management (SCM)
that is used to maintain integrity of set of products.
 Main aim of baseline is to reduce and control
vulnerability i.e. Weakness of projects that can easily
affect project and leads to changes that are
uncontrollable.
 Example - Baselines of SCM :

Steps in S/W Process Baseline defined at this Level

System Engineering System Specification
Requirements Analysis S/W Requirements specification
Software Design Design Specification
Coding Source Code
Testing Test Plans/Procedures/data
Release Operational System
Baselined SCIs and the project
Database Diagram
Software Configuration Items
Definition: Information that is created as part of the
software engineering process.
Software Configuration Items refers to the fundamental
structural unit of SCM.
It is an aggregation of software that is designed for
configuration management and treated as a single
entity in the SRM process.
A configuration item(CI) is any service component,
infrastructure element, or other item that needs to
be managed in order to ensure the successful
delivery of services.
Software Configuration Objects
SCM Repository
 Since the SCM is an old concept necessary for any
software development work, it started with a paper-
based repository with manual operations.
 A paper based repository is like a fine cabinet
containing folders.
 In the early days of software engineering software
configuration items(SCI) are were maintained as
paper documents (or punched computer cards)
placed in file folders and stored in metal cabinets.
This approach was problematic for many reasons.
➢ To find a SCI is a difficult task when it is needed.
➢ To determine which items were changed and by
whom. It is always challenging.
➢ To develop a new version from an existing program is
prone to errors and time consuming too.
➢ To describe detailed relationship is actually
impossible.

Question: What is Software SCM repository? 5 Marks

Role of the Repository
 The repository will perform all the fundamental
operations of database management system and in
addition it will perform the following operations:

Information
Data Integrity
Sharing

Role of the
Tool integration Repository Data Integration

Methodology Document
enforcement Standardization
1) Data Integrity:
data integrity validates all the entries to the repository
and make sure that the consistency among various
objects intact and takes care of all modification takes
place.
It will also ensure cascading modification i.e. change in
one object causes change in a dependent object also.
2) Information Sharing:
It is mechanism for sharing information among various
developers and between various tools.
These tools mange and control multi-user access to
data, and locks or unlock objects to retain its
Consistency.
3) Tool integration:
Tool integration is a model that can be used by many
software engineering tools to control access to the
data and performs appropriate configuration
management functions.

4) Data Integration:
Data integration provides database functions that
allow various SCM tasks to be performed on one or
more SCIs.
5) Document Standardization:
Document Standardization is an important task for
defining the objects.
This standardization is a good approach for making
software engineering documents.

6) Methodology Enforcement:
Methodology Enforcement defines and (E-R Model) i.e.
Entity-Relationship model available in the database i.e.
repository.
This model may be used as a process model for
software engineering.
Question: Discuss role of SCM Repository. 5 Marks
SCM Features
Following are the Features of SCM:
1) Versioning:
 In the development process as the project
progresses, various versions of the product will be
developed and the database will save all these
versions.
 The repository will keep track of these versions
in order to make effective management of the
product delivery or the product releases.
2) Dependency tracking and change management:
 The databases or the repository stores various
relationships among the configuration objects.
 The relationships may be between entitles and
processes or between application design and
component design and between all the design elements
etc.
 Some relationships are optional and some of the
relationships are mandatory relationships that have
various dependencies.
 So to keep the tack of previous history and
relationships is very important for the consistency of
the information present in the databases.
3) Requirement tracing
 Requirement tracing will provide the ability to
trace all the design components and releases.
 This tracing results from a specific requirement
called ad forward tracing.
 It will also useful in finding that which
requirements are fulfilled properly from the
ready product. This is called as backward
tracing.
4) Configuration management:
The Configuration management is a facility to keep the
track of various configurations under development.
The series of configurations is used as the project
milestones and future releases.

5) Audit Trials:
The audit trials keeps additional information like the
changes made by whom and when.
Also it stores the reasons why changes have been made.
The source of each change in the development must be
stored in the repository.

Question: Explain the features of tool set supporting SCM repository. 6m

SCM Process
 It uses the tools which keep that the necessary change
has been implemented adequately to the appropriate
component.
 The SCM process involves various stakeholders,
including project managers, developers, configuration
managers, product owners, and testers.
 The SCM process defines a number of tasks or Layers:
1) Identification of objects in the software configuration
2) Version Control
3) Change Control
4) Configuration Audit
5) Status Reporting
Layers of SCM Process
1. Identification of objects in the
software configuration
 Identification separately names each SCI and then
organizes it in the SCM repository using an object-
oriented approach.
 Two types of objects can be identified.
 Basic object: a basic object is a unit of information
that has been created by a software engineer during
analysis , design, code or test.
 Aggregate object: an Aggregate object is a collection
of basic objects and other aggregate objects.
 Identifying items like test cases, specification
requirements , modules and schedule time.
 Identifying each computer SCI in the process.
 Group basic details of why, when changes will be
made and who will be in change of making them.

Examples:
1) Instead of naming a File login.php its should be
named login _v1.2.php where v1.2 stands for the
version number of the file.
2) Instead of naming folder ‘code’ it should be named
‘code_D’ where D represents code should be backed up
daily.
2. Version Control
 The version control actually controls the new
releases or new versions.
 It combines the procedures and tools in order to
control various of configuration objects.
 Also focuses on developing way to track the
hierarchy of different versions of the software.
 Developing standardized label scheme for all
products, versions and files so that everyone is in the
same page.
Example of Version Control
3.Change Control
 Change control is a systematic approach to managing
all changes made to a product or system.
 The purpose is to ensure that no unnecessary
changes are made, all changes are documented,
services are not unnecessarily disrupted and
resources are used efficiently.
 Examples: To add or edit various configuration items,
change user permissions or changing requirements of
clients.
Process
 Software team send changes to the software
Configuration Manager(SCM).
 SCM checking examining the overall impact they will
have on the project.
 Making approved changes or explaining why change
requests were denied to the team.
 If it is approved them implement all necessary
changes.
 After the Review or Reporting it.
Benefits of change control
 better cost and risk avoidance;
 lower risk associated with each individual change;
 reduced amount of time needed for changes;
 changes can be factored in with less disruption to
project schedule, as requests will be considered and
managed around the project timeline; and
 project managers will be informed about change
needs in the planning phase and have time to
consider possible courses of action.
4. Configuration Audit
 This process is used to ensure that application will
develop as per the project plan and test/verify the
application as per scope.
 The audit confirms the completeness, correctness
and consistency of modified items in the SCM system
and track action items form the audit to closure.
5. Status Reporting
 Focuses on communication of changes to all people
in organization that involve with change.
 During status reporting some questions are asked:
1. What happened?: (What are changes are required
specified it)
2. Who did it? : (Who will be handling these changes)
3. When did it happen?: (Time at which these changes
are arised)
4. What else will be affected? (Objects or parts of
software that might be reflected due to these
changes)
 It is useful in new releases or constructing new
versions.