Module 4

Software Risk, Configuration Management

- Risk Identification, Risk Assessment, Risk Projection,
RMMM Software Configuration management, SCM
repositories, SCM process
-Software Quality Assurance Task and Plan, Metrics, Software
Reliability, Formal Technical Review (FTR), Walkthrough.

Dr. Smita Mane (Assistant Professor)

 Project Risks
What can go wrong?
What is the likelihood?
What will the damage be?
What can we do about it?

2
 What Is Software Risk?
• Risk is an expectation of loss, a potential problem
that may or may not occur in the future.
• It is generally caused due to lack of information,
control or time.
• A possibility of suffering from loss in software
development process is called a software risk.
• Loss can be anything, increase in production cost,
development of poor quality software, not being able to
complete the project on time.

3
 Types of software risks
• Software risk exists because the future is
uncertain and there are many known and
unknown things that cannot be incorporated in
the project plan.
• A software risk can be of two types
(1) internal risks that are within the control of the
project manager
(2) external risks that are beyond the control of project
manager.

4
 Definition of Risk
• A risk is a potential problem – it might happen and it might
not
• Conceptual definition of risk
– Risk concerns future happenings
– Risk involves change in mind, opinion, actions, places, etc.
– Risk involves choice and the uncertainty that choice entails
• Two characteristics of risk
– Uncertainty – the risk may or may not happen, that is,
there are no 100% risks (those, instead, are called
constraints)
– Loss – the risk becomes a reality and unwanted
consequences or losses occur 5
Risk Categorization – Approach #1
• Project risks
– They threaten the project plan
– If they become real, it is likely that the project schedule will
slip and that costs will increase
• Technical risks
– They threaten the quality and timeliness of the software to be
produced
– If they become real, implementation may become difficult or
impossible
• Business risks
– They threaten the viability of the software to be built
– If they become real, they jeopardize the project or the product
6
(More on next slide)
 Risk Categorization – Approach
#1 (continued)
• Sub-categories of Business risks
– Market risk – building an excellent product or system that
no one really wants
– Strategic risk – building a product that no longer fits into
the overall business strategy for the company
– Sales risk – building a product that the sales force doesn't
understand how to sell
– Management risk – losing the support of senior
management due to a change in focus or a change in people
– Budget risk – losing budgetary or personnel commitment

7
8
9
 Risk Categorization – Approach
#2
• Known risks
– Those risks that can be uncovered after careful evaluation of
the project plan, the business and technical environment in
which the project is being developed, and other reliable
information sources (e.g., unrealistic delivery date)
• Predictable risks
– Those risks that are extrapolated from past project experience
(e.g., past turnover, Poor Customer communication)
• Unpredictable risks
– Those risks that can and do occur, but are extremely difficult to
identify in advance

10
11
 Risk Management

• Risk management is carried out to:

– Identify the risk
– Reduce the impact of risk
– Reduce the probability or likelihood of risk
– Risk monitoring

12
 Risk identification
❖ It is the critical first step of the risk
management process.
❖ The objective of risk identification is the early
and continuous identification of events that,
if they occur, will have negative impacts on the
project's ability to achieve performance or
capability outcome goals.

13
 Steps for Risk Management
1) Identify possible risks; recognize what can go wrong
2) Analyze each risk to estimate the probability that it will
occur and the impact (i.e., damage) that it will do if it does
occur
3) Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and
catastrophic(suddenly)
4) Develop a contingency plan to manage those risks having
high probability and high impact

14
 Flow for Risk Management

Identify possible risks; recognize what can go

wrong
Analyze each risk to estimate the probability that it
will occur and the impact (i.e., damage) that it will
do if it does occur
Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, &
catastrophic
Develop a contingency plan to manage those risks
having high probability and high impact
15
 Risk Identification
• Risk identification is a systematic attempt to specify threats to the
project plan
• By identifying known and predictable risks, the project manager
takes a first step toward avoiding them when possible and
controlling them when necessary

16
 Methods for Identifying Risks
1) Checklist Analysis
2) Brainstorming
3) Casual Mapping
4) SWOT Analysis
5) Flowchart Method

17
 Checklist Analysis
❖ The checklist is basically developed by listing
items, steps, or even tasks and is then further
analyzed against criteria to just identify and
determine if procedure is completed correctly
or not.
❖ It is list of risk that is just found to occur
regularly in development of software project.

18
 Brainstorming
❖ It gives free and open approach that usually encourages each and
everyone on project team to participate.
❖ It also results in greater sense of ownership of project risk, and
team generally committed to managing risk for given time period of
project.
❖ It is creative and unique technique to gather risks spontaneously by
team members.
❖ The team members identify and determine risks in ‘no wrong
answer’ environment.
❖ This technique also provides opportunity for team members to
always develop on each other’s ideas.
❖ This technique is also used to determine best possible solution to
problems and issue that arises and emerge.
19
 Casual Mapping
❖ It is method that builds or develops on reflection and review of
failure factors in cause and effect of the diagrams.
❖ It is very useful for facilitating learning with an organization or
system simply as method of project-post evaluation.
❖ It is also key tool for risk assessment.

20
 SWOT
❖ Strengths-Weaknesses-Opportunities-Threat (SWOT) is very
technique and helpful for identifying risks within greater
organization context.
❖ It is generally used as planning tool for analyzing business, its
resources, and also its environment simply by looking at internal
strengths and weaknesses and opportunities and threats in external
environment.
❖ It is technique often used in formulation of strategy.
❖ The appropriate time and effort should be spent on thinking
seriously about weaknesses and threats of organization for SWOT
analysis to more effective and successful in risk identification.

21
 Flowchart Method
❖ This method allows for dynamic process to be diagrammatically
represented in paper.
❖ This method is generally used to represent activities of process
graphically and sequentially to simply identify the risk.

22
 Risk Identification
• Generic risks
– Risks that are a potential threat to every software project
• Product-specific risks
– Risks that can be identified only by those a with a clear
understanding of the technology, the people, and the
environment that is specific to the software that is to be built
– This requires examination of the project plan and the statement
of scope
– "What special characteristics of this product may threaten our
project plan?"

23
 Risk Item Checklist
Used as one way to identify risks

Focuses on known and predictable risks in

specific subcategories (see next slide)

Can be organized in several ways

•A list of characteristics relevant to each risk subcategory
•Questionnaire that leads to an estimate on the impact of
each risk
•A list containing a set of risk component and drivers 24
and their probability of occurrence
Known and Predictable Risk Categories

25
Recording Risk Information

Project: Embedded software for XYZ system

Risk type: schedule risk
Priority (1 low ... 5 critical): 4
Risk factor: Project completion will depend on tests which
require hardware component under development. Hardware
component delivery may be delayed
Probability: 60 %
Impact: Project completion will be delayed for each day that
hardware is unavailable for use in software testing
● Monitoring approach:
Scheduled milestone reviews with hardware group
● Contingency plan:
Modification of testing strategy to accommodate delay using
software simulation
● Estimated resources: 6 additional person months beginning
7-1-25

These courseware materials are 26

to be used in conjunction with
 Questionnaire on Project Risk
(Questions are ordered by their relative importance to project success)

1) Have top software and customer managers formally

committed to support the project?
2) Are end-users enthusiastically committed to the project and
the system/product to be built?
3) Are requirements fully understood by the software engineering
team and its customers?
4) Have customers been involved fully in the definition of
requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?

27
(More on next slide)
 Questionnaire on Project Risk
(continued)
7) Does the software engineering team have the right mix of skills?
8) Are project requirements stable?
9) Does the project team have experience with the technology to be
implemented?
10) Is the number of people on the project team adequate to do the job?
11) Do all customer/user constituencies agree on the importance of the
project and on the requirements for the system/product to be built?

28
 Risk Components and Drivers
• The project manager identifies the risk drivers that affect the following risk
components
– Performance risk - the degree of uncertainty that the product will meet its
requirements and be fit for its intended use
– Cost risk - the degree of uncertainty that the project budget will be maintained
– Support risk - the degree of uncertainty that the resultant software will be easy
to correct, adapt, and enhance
– Schedule risk - the degree of uncertainty that the project schedule will be
maintained and that the product will be delivered on time
• The impact of each risk driver on the risk component is divided into one of
four impact levels
– Negligible, marginal, critical, and catastrophic
• Risk drivers can be assessed as impossible, improbable, probable, and
frequent

29
 Module 4
Software Risk, Configuration Management
- Risk Identification, Risk Assessment, Risk Projection,
RMMM Software Configuration management, SCM
repositories, SCM process
-Software Quality Assurance Task and Plan, Metrics,
Software Reliability, Formal Technical Review (FTR),
Walkthrough.

30
Dr. Smita Mane (Assistant Professor)
 Risk Assessment
❖ Risk assessment simply means to describe the
overall process or method to identify risk and
problem factors that might cause harm.
❖ It is a systematic examination of a task or
project that you perform to simply identify
significant risks, problems, and hazards, and
then to find out control measures that you will
take to reduce risk.
❖ The best approach is to prepare a set of
questions that can be answered by project
managers to assess overall project risks.
31
 These questions are shown below:
1. Will the project get proper support from the customer manager?
2. Are end-users committed to software that has been produced?
3. Is there a clear understanding of the requirements?
4. Is there an active involvement of customers in the requirement
definition?
5. Are the expectations set for the product are realistic?
6. Is the project scope stable?
7. Are there team members with the required skills?
8. Are project requirements stable?
9. Is the technology used for software known to developers?
10. Is the size of the team sufficient to develop the required
product?
11. Do all customers know the importance of the
32
product/requirements of the system to be built?
Risk Projection (Estimation)

33
 Reactive vs. Proactive Risk
Strategies
• Reactive risk strategies
– "Don't worry, I'll think of something"
– The majority of software teams and managers rely on this
approach
– Nothing is done about risks until something goes wrong
• The team then flies into action in an attempt to correct the problem
rapidly (fire fighting)
– Crisis management is the choice of management techniques
• Proactive risk strategies
– Steps for risk management are followed (see next slide)
– Primary objective is to avoid risk and to have a contingency
plan in place to handle unavoidable risks in a controlled and
effective manner
34
 Risk Projection (Estimation)
• Risk projection (or estimation) attempts to rate each risk in two
ways
– The probability that the risk is real
– The consequence of the problems associated with the risk,
should it occur
• The project planner, managers, and technical staff perform four
risk projection steps
• The intent of these steps is to consider risks in a manner that
leads to prioritization
• By prioritizing risks, the software team can allocate limited
resources where they will have the most impact

35
 • Risk Projection/Estimation Steps
1) Establish a scale that reflects the perceived likelihood
of a risk (e.g., 1-low, 10-high)
2) Delineate the consequences of the risk
3) Estimate the impact of the risk on the project and
product
4) Note the overall accuracy of the risk projection so that
there will be no misunderstandings

36
 Contents of a Risk Table
• A risk table provides a project manager with a simple technique for risk
projection
• It consists of five columns
– Risk Summary – short description of the risk
– Risk Category – one of seven risk categories (slide 12)
– Probability – estimation of risk occurrence based on group input
– Impact – (1) catastrophic (2) critical (3) marginal (4) negligible
– RMMM – Pointer to a paragraph in the Risk Mitigation, Monitoring,
and Management Plan

Risk Summary Risk Probability Impact (1-4) RMMM

Category

37
 Developing a Risk Table
• List all risks in the first column (by way of the help of the risk
item checklists)
• Mark the category of each risk
• Estimate the probability of each risk occurring
• Assess the impact of each risk based on an averaging of the four
risk components to determine an overall impact value (See next
slide)
• Sort the rows by probability and impact in descending order
• Draw a horizontal cutoff line in the table that indicates the risks
that will be given further attention

38
 Assessing Risk Impact
• Three factors affect the consequences that are likely if a risk
does occur
– Its nature – This indicates the problems that are likely if the risk occurs
– Its scope – This combines the severity of the risk (how serious was it)
with its overall distribution (how much was affected)
– Its timing – This considers when and for how long the impact will be felt
• The overall risk exposure formula is RE = P x C
– P = the probability of occurrence for a risk
– C = the cost to the project should the risk actually occur
• Example
– P = 80% probability that 18 of 60 software components will have to be
developed
– C = Total cost of developing 18 components is 25,000Rs
– RE = .80 x 25,000Rs = 20,000Rs

39
 Contents of a Risk Table

Probability of
Impact of Risk
Risk No Problem occurrence of Priority
problem exposure
problem

Issue of
R1 incorrect 2 2 4 10
password

Testing
R2 reveals a lot 1 9 9 7
of defects

The design is
R3 2 7 14 5
not robust

40
 Module 4
Software Risk, Configuration Management
- Risk Identification, Risk Assessment, Risk Projection,
RMMM, Software Configuration management, SCM
repositories, SCM process
-Software Quality Assurance Task and Plan, Metrics,
Software Reliability, Formal Technical Review (FTR),
Walkthrough.

41
Dr. Smita Mane (Assistant Professor)
Risk Mitigation, Monitoring, and
Management
(RMMM)
 Background
• An effective strategy for dealing with risk must consider three
issues
(Note: these are not mutually exclusive)
– Risk mitigation (i.e., avoidance)
– Risk monitoring
– Risk management and contingency planning
• Risk mitigation (avoidance) is the primary strategy and is achieved
through a plan
– Example: Risk of high staff turnover (see next slide)

(More on next slide) 43

 Strategy for Reducing Staff Turnover
❑ Meet with current staff to determine causes for turnover (e.g.,
poor working conditions, low pay, competitive job market)
❑ Mitigate those causes that are under our control before the
project starts
❑ Once the project commences, assume turnover will occur and
develop techniques to ensure continuity when people leave
❑ Organize project teams so that information about each
development activity is widely dispersed
❑ Define documentation standards and establish mechanisms to
ensure that documents are developed in a timely manner
❑ Conduct peer reviews of all work (so that more than one person
is "up to speed")
❑ Assign a backup staff member for every critical technologist

44
 Background (continued)
• During risk monitoring, the project manager monitors factors
that may provide an indication of whether a risk is becoming
more or less likely
• Risk management and contingency planning assume that
mitigation efforts have failed and that the risk has become a
reality
• RMMM steps incur additional project cost
– Large projects may have identified 30 – 40 risks
• Risk is not limited to the software project itself
– Risks can occur after the software has been delivered to the
user

(More on next slide)

45
 Background (continued)
• Software safety and hazard analysis
– These are software quality assurance activities that
focus on the identification and assessment of potential
hazards that may affect software negatively and cause
an entire system to fail
– If hazards can be identified early in the software
process, software design features can be specified that
will either eliminate or control potential hazards

46
 The RMMM Plan
• The RMMM plan may be a part of the software development plan or
may be a separate document
• Once RMMM has been documented and the project has begun, the
risk mitigation, and monitoring steps begin
– Risk mitigation is a problem avoidance activity
– Risk monitoring is a project tracking activity
• Risk monitoring has three objectives
– To assess whether predicted risks do, in fact, occur
– To ensure that risk aversion steps defined for the risk are being
properly applied
– To collect information that can be used for future risk analysis
• The findings from risk monitoring may allow the project manager to
ascertain what risks caused which problems throughout the project
47
Seven Principles of Risk Management
Maintain a global View software risks within the context of a system and
perspective the business problem that is intended to solve
Take a forward-looking Think about risks that may arise in the future; establish
view
contingency plans
Encourage open Encourage all stakeholders and users to point out risks at
communication any time
Integrate risk Integrate the consideration of risk into the software
management process
Emphasize a
continuous process of Modify identified risks as more becomes known and add
risk management new risks as better insight is achieved
Develop a shared A shared vision by all stakeholders facilitates better
product vision risk identification and assessment
Encourage teamwork Pool the skills and experience of all stakeholders when
when managing risk conducting risk management activities 48
 Summary
• Whenever much is riding on a software project, common sense
dictates risk analysis
– Yet, most project managers do it informally and superficially, if at
all
• However, the time spent in risk management results in
– Less upheaval during the project
– A greater ability to track and control a project
– The confidence that comes with planning for problems before they
occur
• Risk management can absorb a significant amount of the project
planning effort…but the effort is worth it
49
☺
 Module 4
Software Risk, Configuration Management
- Risk Identification, Risk Assessment, Risk Projection,
RMMM ,Software Configuration management, SCM
repositories, SCM process
-Software Quality Assurance Task and Plan, Metrics, Software
Reliability, Formal Technical Review (FTR), Walkthrough.

Dr. Smita Mane (Assistant Professor)

 System Configuration Management (SCM)
• System Configuration Management (SCM) is an arrangement of
exercises that controls change by recognizing the items for
change, setting up connections between those things,
making/characterizing instruments for overseeing diverse
variants, controlling the changes being executed in the current
framework, inspecting and revealing/reporting on the changes
made.
• It is essential to control the changes because if the changes are not
checked legitimately then they may wind up undermining a
well-run programming.
• SCM is a fundamental piece of all project management
activities.

51
 Processes involved in SCM
Configuration management provides a disciplined environment for
smooth control of work products. It involves the following activities:

1) Identification and Establishment – Identifying the configuration

items from products that compose baselines at given points in time
(a baseline is a set of mutually consistent Configuration Items,
which has been formally reviewed and agreed upon, and serves as
the basis of further development). Establishing relationships among
items, creating a mechanism to manage multiple levels of control
and procedure for the change management system.
2) Version control – Creating versions/specifications of the existing
product to build new products with the help of the SCM system. A
description of the version is given below:

52
Suppose after some changes, the version of the configuration object changes
from 1.0 to 1.1. Minor corrections and changes result in versions 1.1.1 and
1.1.2, which is followed by a major update that is object 1.2. The
development of object 1.0 continues through 1.3 and 1.4, but finally, a
noteworthy change to the object results in a new evolutionary path, version
2.0. Both versions are currently supported. 53
3) Change control – Controlling changes to
Configuration items (CI). The change control
process is explained in Figure below:

54
55
• A change request (CR) is submitted and evaluated to assess
technical merit, potential side effects, the overall impact on other
configuration objects and system functions, and the projected cost
of the change.
• The results of the evaluation are presented as a change report,
which is used by a change control board (CCB) —a person or
group who makes a final decision on the status and priority of the
change.
• An engineering change Request (ECR) is generated for each
approved change. Also, CCB notifies the developer in case the
change is rejected with proper reason.
• The ECR describes the change to be made, the constraints that
must be respected, and the criteria for review and audit.
• The object to be changed is “checked out” of the project database,
the change is made, and then the object is tested again. The object
is then “checked in” to the database and appropriate version
control mechanisms are used to create the next version of 56 the
software.
4) Configuration auditing – A software configuration audit
complements the formal technical review of the process and
product. It focuses on the technical correctness of the
configuration object that has been modified. The audit
confirms the completeness, correctness, and consistency of
items in the SCM system and tracks action items from the audit
to closure.
5) Reporting – Providing accurate status and current
configuration data to developers, testers, end users, customers,
and stakeholders through admin guides, user guides, FAQs,
Release notes, Memos, Installation Guide, Configuration
guides, etc.

57
 Importance of Software Configuration Management
● Effective Bug Tracking: Linking code modifications to issues
that have been reported, makes bug tracking more effective.
● Continuous Deployment and Integration: SCM combines with
continuous processes to automate deployment and testing,
resulting in more dependable and timely software delivery.
● Risk management: SCM lowers the chance of introducing
critical flaws by assisting in the early detection and correction of
problems.
● Support for Big Projects: Source Code Control (SCM) offers an
orderly method to handle code modifications for big projects,
fostering a well-organized development process.
● Reproducibility: By recording precise versions of code, libraries,
and dependencies, source code versioning (SCM) makes builds
repeatable.
● Parallel Development: SCM facilitates parallel development by
enabling several developers to collaborate on various branches 58 at
once.