Risk Analysis & Risk Management in Software Engineering

What Is the Definition of Risk in Software Engineering?

Simply put, a risk is a potential problem. It is an activity or event that has the
potential to jeopardize the success of a software development project. Risk is the
possibility of experiencing loss, and total risk exposure to a specific project will
account for both the likelihood and magnitude of the potential loss. Therefore, risk
management should be made an integral part of any project management.

A project manager has to deal with risks arising from three possible cases:

1. Known knowns: are software risks that are actually facts known to the team
as well as to the entire project. For example not having enough number of
developers can delay the project delivery. Such risks are described and
included in the Project Management Plan.
2. Known unknowns: are risks that the project team is aware of but it is
unknown that such risk exists in the project or not. For example if the
communication with the client is not of good level then it is not possible to
capture the requirement properly. This is a fact known to the project team
however whether the client has communicated all the information properly
or not is unknown to the project.
3. Unknown Unknowns: are those kind of risks about which the organization
has no idea. Such risks are generally related to technology such as working
with technologies or tools that you have no idea about because your client
wants you to work that way suddenly exposes you to absolutely unknown
unknown risks.

What is Risk Analysis?

Risk Analysis in project management is a sequence of processes to identify the
factors that may affect a project’s success. These processes include risk
identification, analysis of risks, risk management and control, etc. Proper risk
analysis helps to control possible future events that may harm the overall project. It
is more of a pro-active than a reactive process.
 Principles of Risk Management in Software Engineering
1. Global Perspective: In this step of project management, we will go over the
overall system description, design, and implementation. We consider the risk and
its potential consequences.
2. Keep an eye on the future: Consider the threat that might appear in the future and
make plans to direct the next events.
3. Open Communication: This allows for the free flow of information between the
client and the team members, allowing them to be confident about the risks.
4. Integrated management: Risk management is integrated into project management
in this method.
5. Continuous process: The risks are tracked constantly throughout the risk
management paradigm during this phase.

Steps of Risk Management

1. Risk Identification

Risk identification entails brainstorming. It also entails the creation of a risk list.
Brainstorming is a group discussion technique in which the whole project
management is present. This technique generates new ideas and encourages
creative thinking. The preparation of a risk list entails identifying risks that have
occurred repeatedly in previous software projects.

2. Risk Assessment and Prioritization

It is a procedure within project management that includes the following steps:

 Identifying the issues that are causing risk in projects

 Determining the likelihood of a problem occurring
 Determining the problem's impact
 Assigning probability and impact values ranging from 1 to 10
 Determining the risk exposure factor

The project manager should make a table with all of the values and rank the risks
according to the risk exposure factor.

3. Risk Avoidance and Mitigation

The goal of this technique is to eliminate the occurrence of risks entirely. To avoid
risks, reduce the scope of projects by eliminating non-essential requirements. Risk
avoidance involves identifying potential risks and then eliminating them as much
as possible, or reducing their impact if they cannot be eliminated.

Examples of risk avoidance include:

 Not using certain features in the software due to the potential for bugs or
other problems to occur;
 Increase software testing activities using test cases to ensure no bugs exist in
a product before it goes live;
 Making sure that any changes made to software are thoroughly tested before
they are deployed.

4. Risk transfer

This technique is used in software engineering to reduce the risk of a project. Risk
transfer is usually used when the scope of a project is too large for any one team to
handle, and there is no way to split up the work so that each team can be
responsible for its own piece of it. In this case, you have to find an outside
company that can take on some portion of your project.

For example, if you're working on a video editor app and your team doesn't have
enough designers or programmers to make it happen, project management could
decide to hire someone else who does have the necessary resources. That way, you
don't have to worry about handling all parts of the app yourself and can focus on
what's most important--making sure that everything comes together in an enjoyable
way!

5. Risk acceptance

In software engineering risk acceptance is a technique that involves taking on risks

in order to complete the system. It can be a good idea if there is a lot of uncertainty
about which features will be required and when they'll be needed. In this case, it
makes sense to accept some level of risk in order to have time to figure out what
needs to be done and how long it will take. The only way to know whether this will
work is by trying it out—you may find that you were right all along, or you may
discover that you need more time than expected.
6. Risk Monitoring

The risk should be continuously monitored by reevaluating the risks, the impact of
the risk, and the probability of the risk occurring.

This guarantees that:

 The dangers have been discovered and reduced.

 The magnitude and impact of risk are assessed.

RMMM Plan :
A risk management technique is usually seen in the software Project plan. This
can be divided into Risk Mitigation, Monitoring, and Management Plan
(RMMM). In this plan, all works are done as part of risk analysis. As part of the
overall project plan project manager generally uses this RMMM plan.
In some software teams, risk is documented with the help of a Risk Information
Sheet (RIS). This RIS is controlled by using a database system for easier
management of information i.e creation, priority ordering, searching, and other
analysis. After documentation of RMMM and start of a project, risk mitigation
and monitoring steps will start.
Risk Mitigation:
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. 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.
1. To check if predicted risks occur or not.
2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the project.
Risk Management and planning:
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.

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. The possible steps to be taken are:
 Meet the 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.
 Assign a backup staff member for every critical technologist.
Risk Monitoring:
As the project proceeds, risk monitoring activities commence. The project
manager monitors factors that may provide an indication of whether the risk is
becoming more or less likely. In the case of high staff turnover, the following
factors can be monitored:
 General attitude of team members based on project pressures.
 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.
Risk Management:
Risk management and contingency planning assumes that mitigation efforts have
failed and that the risk has become a reality. Continuing the example, the project
is well underway, and a number of people announce that they will be leaving. If
the mitigation strategy has been followed, backup is available, information is
documented, and knowledge has been dispersed across the team. In addition, the
project manager may temporarily refocus resources (and readjust the project
schedule) to those functions that are fully staffed, enabling newcomers who must
be added to the team to “get up to the speed“.
Drawbacks of RMMM:
 It incurs additional project costs.
 It takes additional time.
 For larger projects, implementing an RMMM may itself turn out to be another
tedious project.
 RMMM does not guarantee a risk-free project, infact, risks may also come up
after the project is delivered.

Types of software quality metrics

1. Dependability

Users rely on software to be dependable and consistent so that they can use
the features to produce the same results. This involves having a program that
behaves predictably depending on user inputs. It also requires reliable
maintenance practices to resolve issues quickly. Here are a few specific
metrics that uphold dependable software quality:

 Failure rate: This is the frequency at which a system fails, which

people express as failures per unit time. Software systems may fail at a
higher rate because of a lack of user participation, failure to specify
user requirements or lack of resources.
 System availability: For a system to be available, it requires functional
equipment that it uses to operate efficiently under normal conditions.
System availability is a metric that measures the probability that a
system isn't failing or undergoing repairs when you schedule it to
operate in production companies.
 Crash rate: This metric measures the rate at which a system crashes
once users operate it. A high crash rate indicates that a system has
several flaws or a few significant flaws that can inconvenience users,
and it's crucial for developers to determine and resolve the causes.

2. Functionality

For a software program to meet user expectations, it's essential that all
features function with minimal bugs and errors. A primary aspect of the
testing process in software development and maintenance is identifying and
removing errors to improve functionality. This involves using functionality-
related metrics to track common errors and the features or aspects of the code
that cause the most issues for users. Examples of software function metrics
for quality include:

 Probability of failures: This metric calculates the likelihood of a

system failing at a specific time. Developers use this probability to
perform a risk analysis by determining the potential mechanisms that
can damage a system.
 Number of bugs: Finding the number of bugs in a system's code is
integral in software testing. Developers and testers use various tactics
to identify these bugs in the shortest time possible, such as by setting
goals for software quality, so they know which bugs to look for, or
testing the software on real devices rather than simulators to get
accurate data.
 Severity of bugs: Bug severity measures how a bug can impact a
system while users operate it. The severity can be low or unnoticeable,
minor but not enough to disrupt the system, major or collapse large
parts of the system or critical and trigger a complete system shutdown.

3. Code characteristics

The way programmers write code also contributes to the quality of the final
program. You can use a variety of performance measures to determine how
the style and content of software scripts influence quality factors, such as
defect rates and user satisfaction. Here are some elements of code
characteristics to measure:

 Number of lines of code: This metric measures a system's size by

calculating the number of lines of code. A simple code may have 500
lines, while a complex one can have over 100,000 source code lines.
 Code clarity: A code with clarity includes organization, possesses a
clear separation of ideas and is easy to read. Coders can achieve this by
using each block of code for a specific function, separating commands
and queries and ensuring that the code has a high level of cohesion.
  Adherence to coding rules: Programmers can adhere to specific
coding standards to ensure the quality of their code. They can use a
static analysis tool to enforce these standards.

4. Interface accessibility

It's essential that software interfaces are accessible and usable to impress
customers. This involves having an attractive design and an intuitive
navigation panel that's easy for people to understand. Many software
programs also have a tutorial mode that teaches users how to operate the
basic functions of the program, so it's essential that the application is as
accessible as possible.

5. System performance

Another aspect of software quality to measure is the overall performance of

the system and the volume of input or user activity it can handle. This is
important for software applications that host complex code and have complex
system requirements, such as computer games or database software services.
When users input complex commands, it's important that the software can
keep up with these requirements.

6. Defect management

Although the goal of software developer is to eliminate errors, bugs and

defects are a normal part of any application. This means ongoing
maintenance and managing defects are important for upholding software
quality. To appropriately address defects, you can track the frequency of
errors, determine how long it takes to address them and evaluate the success
of your solutions with these quality metrics:

 Mean time to detect crashes and bugs: This is how long it takes a
programmer or team to detect crashes or bugs from the time they exist.

 Mean time between system failures: This is a measure of the time

between two system failures.
  Mean time to resolve bugs: This comprises the average time it takes
to solve a bug or issue, including detection, diagnosis, repair and
prevention.

7. Documentation

Software design involves regular updates and collaboration from multiple

software development professionals, so you can also monitor the quality of
your documentation. In software development, documentation involves
explaining changes to code, describing updates and making internal notes to
communicate with other developers. Each software development team has its
own practices for documentation, so tracking documentation typically
involves adhering to those rules.

8. Adaptability across platforms

Many software developers design applications that work on multiple

platforms or integrate with other programs. To ensure this function works,
you can compare software performance on each channel to determine how
well the integration works. For example, you can compare defect rates, the
number of bugs and other key metrics on multiple operating systems to
measure the adaptability of the software.

9. Safety and security

Building a relationship with software users so that they trust you with their
data is essential for software developers. You can develop confidence in the
security of your application by recording details about how you protect user
data and tracking metrics regarding the integrity of your existing security
measures. These security indicators for software can show your quality
management for user data safety:

 Time to repair vulnerabilities: The time it takes to resolve a critical

cybersecurity vulnerability fully
 Nonhuman traffic levels: The generation of online clicks and views
from bots instead of humans
 Virus scan frequency: The number of times a system undergoes
scanning by antiviral software
Formal Technical Reviews
 Formal Technical review is a software quality assurance activity performed by
software engineer.

Objectives of FTR

1. FTR is useful to uncover error in logic, function and implementation for any
representation of the software.
2. The purpose of FTR is to ensure that software meets specified requirements.
3. It is also ensure that software is represented according to predefined standards.
4. It helps to review the uniformity in software development process.
5. It makes the project more manageable.

 Besides the above mentioned objectives, the purpose of FTR is to enable junior
engineer to observer the analysis, design, coding and testing approach more
closely.

 Each FTR is conducted as meeting and is considered successfully only if it is

properly planned, controlled and attended.

Steps in FTR

1. The review meeting

 Every review meeting should be conducted by considering the following

constraints-

1. Involvement of people

Between 3 and 5 people should be involve in the review.

2. Advance preparation Advance preparation should occur but it should be very

short that is at the most 2 hours of work for each person can be spent in this
preparation

3. Short duration The short duration of the review meeting should be less than two
hour.
  Rather than attempting to review the entire design walkthrough are conducted for
modules or for small group of modules.
 The focus of the FTR is on work product (a software component to be reviewed).
The review meeting is attended by the review leader, all reviewers and the
producer.
 The review leader is responsible for evaluating for product for its deadlines. The
copies of product material is then distributed to reviewers. -The producer
organises “walkthrough” the product, explaining the material, while the reviewers
raise the issues based on theirs advance preparation.
 One of the reviewers become recorder who records all the important issues
raised during the review. When error are discovered, the recorder notes each.
 At the end of the review, the attendees decide whether to accept the product or
not, with or without modification.

2. Review reporting and record keeping

 During the FTR, the reviewer actively record all the issues that have been raised.
 At the end of meeting these all raised issues are consolidated and review issue
list is prepared.
 Finally, formal technical review summary report is produced.

3. Review guidelines

 Guidelines for the conducting of formal technical review must be established in

advance. These guidelines must be distributed to all reviewers, agreed upon, and
then followed.
 For example,

Guideline for review may include following things

1. Concentrate on work product only. That means review the product not the
producers.
2. Set an agenda of a review and maintain it.
3. When certain issues are raised then debate or arguments should be limited.
Reviews should not ultimately results in some hard feelings.
4. Find out problem areas, but don’t attempt to solve every problem noted.
5. Take written notes (it is for record purpose)
 6. Limit the number of participants and insists upon advance preparation.
7. Develop a checklist for each product that is likely to be reviewed.
8. Allocate resources and time schedule for FTRs in order to maintain time
schedule.
9. Conduct meaningful trainings for all reviewers in order to make reviews effective.
10. Reviews earlier reviews which serve as the base for the current review being
conducted.

What is Software Configuration Management?

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. The primary goal is to increase productivity with minimal mistakes.
SCM is part of cross-disciplinary field of configuration management and it
can accurately determine who made which revision.

Why do we need Configuration management?

The primary reasons for Implementing Technical Software Configuration
Management System are:

 There are multiple people working on software which is continually

updating
 It may be a case where multiple version, branches, authors are involved
in a software config project, and the team is geographically distributed
and works concurrently
 Changes in user requirement, policy, budget, schedule need to be
accommodated.
 Software should able to run on various machines and Operating
Systems
 Helps to develop coordination among stakeholders
 SCM process is also beneficial to control the costs involved in making
changes to a system
any change in the software configuration Items will affect the final product.
Therefore, changes to configuration items need to be controlled and
managed.
Participant of SCM process
Following are the key participants in SCM

1. Configuration Manager

 Configuration Manager is the head who is Responsible for identifying

configuration items.
 CM ensures team follows the SCM process
 He/She needs to approve or reject change requests

2. Developer

 The developer needs to change the code as per standard development

activities or change requests. He is responsible for maintaining
configuration of code.
 The developer should check the changes and resolves conflicts

3. Auditor
  The auditor is responsible for SCM audits and reviews.
 Need to ensure the consistency and completeness of release.

4. Project Manager:

 Ensure that the product is developed within a certain time frame

 Monitors the progress of development and recognizes issues in the
SCM process
 Generate reports about the status of the software system
 Make sure that processes and policies are followed for creating,
changing, and testing

5. User

The end user should understand the key SCM terms to ensure he has the
latest version of the software

Software Configuration Management Tools

Any Change management software should have the following 3 Key features:

Concurrency Management:

When two or more tasks are happening at the same time, it is known as
concurrent operation. Concurrency in context to SCM means that the same
file being edited by multiple persons at the same time.

If concurrency is not managed correctly with SCM tools, then it may create
many pressing issues.

Version Control:

SCM uses archiving method or saves every change made to file. With the
help of archiving or save feature, it is possible to roll back to the previous
version in case of issues.

Synchronization:
Users can checkout more than one files or an entire copy of the repository.
The user then works on the needed file and checks in the changes back to the
repository. They can synchronize their local copy to stay updated with the
changes made by other team members.