Unit IV: Software Reliability

What is Risk Management

Risk Management is a systematic process of recognizing, evaluating,

and handling threats or risks that have an effect on the finances, capital, and overall operations of an
organization. These risks can come from different areas, such as financial instability, legal issues,
errors in strategic planning, accidents, and natural disasters.

A risk is a probable problem; it might happen, or it might not. There are two main characteristics of
risk.

Uncertainty: the risk may or may not happen, which means there are no 100% risks.
Loss: If the risk occurs in reality, undesirable results or losses will occur.
Why is Risk Management Important?

Risk management helps organizations prepare for unexpected events and protect their financial
health, operations, and long-term stability.

For Example - If a key developer in a software project falls ill, collaborative tools allow the team to
continue smoothly. With proper resources and a consistent, systematic approach, organizations can
reduce negative impacts and improve outcomes.

In short, Risk Management:

 Helps organizations prepare for unexpected situations, from minor issues to major crises.

 Protects financial health and ensures smooth and continuous operations.

 Effective risk management requires proper resources and a structured, systematic approach.

 Supports better identification, assessment, and mitigation of major risks.

The Risk Management Process

Risk management is a sequence of steps that help a software team to understand, analyze, and
manage uncertainty.

The risk management process consists of:

Risk Identification

Risk identification refers to the systematic process of recognizing and evaluating potential threats or
hazards that could negatively impact an organization, its operations, or its workforce. This involves
identifying various types of risks, ranging from IT security threats like viruses and phishing attacks to
unforeseen events such as equipment failures and extreme weather conditions.

Risk analysis

Risk analysis is the process of evaluating and understanding the potential impact and likelihood of
identified risks on an organization. It helps determine how serious a risk is and how to best manage
or mitigate it. Risk Analysis involves evaluating each risk's probability and potential consequences to
prioritize and manage them effectively.

Risk Planning

Risk planning involves developing strategies and actions to manage and mitigate identified risks
effectively. It outlines how to respond to potential risks, including prevention, mitigation, and
contingency measures, to protect the organization's objectives and assets.

Risk Monitoring

Risk monitoring involves continuously tracking and overseeing identified risks to assess their status,
changes, and effectiveness of mitigation strategies. It ensures that risks are regularly reviewed and
managed to maintain alignment with organizational objectives and adapt to new developments or
challenges.

Understanding Risks in Software Projects

A computer code project may be laid low with an outsized sort of risk. To be ready to consistently
establish the necessary risks that could affect a computer code project, it's necessary to group risks
into completely different categories. The project manager will then examine the risks from every
category square measure relevant to the project.

There are mainly 3 classes of risks that may affect a computer code project:

1. Project Risks:

Project risks concern various sorts of monetary funds, schedules, personnel, resources, and
customer-related issues. A vital project risk is schedule slippage. Since computer code is intangible,
it's tough to observe and manage a computer code project. It's tough to manage one thing that can
not be seen. For any producing project, like producing cars, the project manager will see the
merchandise taking form.

For example - See that the engine is fitted, at the moment the area of the door unit is fitted, the
automotive is being painted, etc. so he will simply assess the progress of the work and manage it.
The physical property of the merchandise being developed is a vital reason why several computer
codes come to suffer from the danger of schedule slippage.

2. Technical Risks:

Technical risks concern potential style, implementation, interfacing, testing, and maintenance issues.
Technical risks conjointly embody ambiguous specifications, incomplete specifications, dynamic
specifications, technical uncertainty, and technical degeneration. Most technical risks occur thanks to
the event team’s lean information concerning the project.

3. Business Risks:

This type of risk embodies the risks of building a superb product that nobody needs, losing monetary
funds or personal commitments, etc.

Classification of Risk in a project

Example: Let us consider a satellite-based mobile communication project. The project manager can
identify many risks in this project. Let us classify them appropriately.
  What if the project cost escalates and overshoots what was estimated? - Project Risk

 What if the mobile phones that are developed become too bulky to conveniently
carry? Business Risk

 What if call hand-off between satellites becomes too difficult to implement? Technical Risk

Risk management Standards and Frameworks

Risk management standards and frameworks give organizations guidelines on how to find, evaluate,
and handle risks effectively. They provide a structured way to manage risks, making sure that
everyone follows consistent and reliable practices. Here are some well-known risk management
standards and frameworks:

1. COSO ERM Framework:

COSO ERM Framework was introduce in 2004. Its main purpose is to addresses the growing
complexity of Enterprise Risk Management (ERM).

Key Features:

 20 principles grouped into five components: Governance and culture, Strategy and objective-
setting, Performance, Review and revision, Information, communication, and reporting.

 It promote integrating risk into business strategies and operations.

2. ISO 31000:

ISO 31000 was introduce in 2009, revised in 2018. It provides principles and a framework for ERM.

Key Features:

 It offers guidance on applying risk management to operations.

 It focuses on identifying, evaluating, and mitigating risks.

 It promote senior management's role and integrating risk management across the
organization.

3. BS 31100:

This framework is British Standard for Risk Management and latest version issued in 2001. It offers a
structured approach to applying the principles outlined in ISO 31000:2018, covering tasks like
identifying, evaluating, and addressing risks, followed by reporting and reviewing risk management
efforts.

Benefits of risk management

Here are some benefits of risk management:

 Helps protect against potential losses.

 Improves decision-making by considering risks.

 Reduces unexpected expenses.

 Ensures adherence to laws and regulations.

  Builds resilience against unexpected challenges.

 Safeguards company reputation.

In software engineering, reliability measures how often a system fails (e.g., MTBF, MTTF, ROCOF),
while availability measures the percentage of time it's operational and ready for use, considering
both failures and repairs (Uptime, MTTR). Key metrics link these concepts: MTBF (Mean Time
Between Failures) shows uptime between issues, MTTF (Mean Time To Failure) is for non-repairable
systems, and MTTR (Mean Time To Repair) reflects recovery speed, all feeding into the crucial
availability formula: MTBF / (MTBF + MTTR).

Reliability Measures (Frequency of Failure)

 Rate of Occurrence of Failure (ROCOF): The number of failures per unit of time, indicating
failure frequency.

 Mean Time To Failure (MTTF): Average time a system operates before its first failure, used
for non-repairable items.

 Mean Time Between Failures (MTBF): Average time between successive failures for
repairable systems; higher is better.

 Probability of Failure on Demand (POFOD): Probability a system fails when a service is

requested, without time measurement.

Availability Measures (Operational Readiness)

 Availability (Uptime Percentage): The proportion of time the system is operational (Up
Time / (Up Time + Down Time)), often expressed in "nines" (e.g., 99.999%).

 Mean Time To Repair (MTTR): Average time to diagnose and fix a failure, crucial for
minimizing downtime.

 Mean Time Between Failures (MTBF): Also used for availability, as it contributes to total
uptime.

Key Formulas & Relationships

 Availability Formula: MTBF / (MTBF + MTTR).

 MTBF Formula: Total Operational Time / Number of Failures.

 Reliability vs. Availability: Reliability focuses on "if" it fails, while availability focuses on
"when" it's working. A highly reliable system that takes ages to repair might have low
availability

Software safety in engineering ensures software in critical systems doesn't cause harm, focusing on
hazard identification, risk mitigation (probability x consequence), and rigorous processes (analysis,
testing, standards compliance) to achieve acceptable risk levels, distinct from security (protecting
against malicious attacks) but vital for preventing failures in areas like aviation, automotive, and
medical devices where malfunctions lead to injury or death. It's a systematic discipline ensuring
software performs safely, even with hardware/environmental faults, by building resilience and
verifying intended functions, often guided by standards like DO-178C or ISO 26262
Core Concepts

 Hazard Mitigation: Identifying potential dangers (e.g., radiation-induced errors, sensor

failures) and implementing controls to reduce risk.

 System Context: Recognizing that software itself isn't harmful, but its failure within a larger
system (like a car or plane) can be, requiring analysis of its role in potential loss events.

 Reliability vs. Safety: Reliability is meeting specs; safety ensures the system remains
harmless even if it doesn't meet specs or encounters unexpected conditions (like incomplete
requirements or hardware faults).

 Functional Safety: Deals with internal defects and ensuring components fail safely or shut
down, using backup systems to reach a safe state.

 Safety of Intended Function: Addresses gaps in real-world requirements, ensuring resilience

to unforeseen scenarios.

What is Software Maintenance?

Software maintenance is a continuous process that occurs throughout the entire life cycle of the
software system.

 The goal of software maintenance is to keep the software system working correctly,
efficiently, and securely, and to ensure that it continues to meet the needs of the users.

 This can include fixing bugs, adding new features, improving performance, or updating the
software to work with new hardware or software systems.

 It is also important to consider the cost and effort required for software maintenance when
planning and developing a software system.

 It is important to have a well-defined maintenance process in place, which includes testing

and validation, version control, and communication with stakeholders.

 It's important to note that software maintenance can be costly and complex, especially for
large and complex systems. Therefore, the cost and effort of maintenance should be taken
into account during the planning and development phases of a software project.

 It's also important to have a clear and well-defined maintenance plan that includes regular
maintenance activities, such as testing, backup, and bug fixing.

Several Key Aspects of Software Maintenance

1. Bug Fixing: The process of finding and fixing errors and problems in the software.

2. Enhancements: The process of adding new features or improving existing features to meet
the evolving needs of the users.

3. Performance Optimization: The process of improving the speed, efficiency, and reliability of
the software.

4. Porting and Migration: The process of adapting the software to run on new hardware or
software platforms.
 5. Re-Engineering: The process of improving the design and architecture of the software to
make it more maintainable and scalable.

6. Documentation: The process of creating, updating, and maintaining the documentation for
the software, including user manuals, technical specifications, and design documents.

Several Types of Software Maintenance

1. Corrective Maintenance: This involves fixing errors and bugs in the software system.

2. Patching: It is an emergency fix implemented mainly due to pressure from management.

Patching is done for corrective maintenance but it gives rise to unforeseen future errors due
to lack of proper impact analysis.

3. Adaptive Maintenance: This involves modifying the software system to adapt it to changes
in the environment, such as changes in hardware or software, government policies, and
business rules.

4. Perfective Maintenance: This involves improving functionality, performance, and reliability,

and restructuring the software system to improve changeability.

5. Preventive Maintenance: This involves taking measures to prevent future problems, such as
optimization, updating documentation, reviewing and testing the system, and implementing
preventive measures such as backups.

Maintenance can be categorized into proactive and reactive types. Proactive maintenance involves
taking preventive measures to avoid problems from occurring, while reactive maintenance involves
addressing problems that have already occurred.

Maintenance can be performed by different stakeholders, including the original development team,
an in-house maintenance team, or a third-party maintenance provider. Maintenance activities can be
planned or unplanned. Planned activities include regular maintenance tasks that are scheduled in
advance, such as updates and backups. Unplanned activities are reactive and are triggered by
unexpected events, such as system crashes or security breaches. Software maintenance can involve
modifying the software code, as well as its documentation, user manuals, and training materials. This
ensures that the software is up-to-date and continues to meet the needs of its users.

Software maintenance can also involve upgrading the software to a new version or platform. This can
be necessary to keep up with changes in technology and to ensure that the software remains
compatible with other systems. The success of software maintenance depends on effective
communication with stakeholders, including users, developers, and management. Regular updates
and reports can help to keep stakeholders informed and involved in the maintenance process.

Software maintenance is also an important part of the Software Development Life Cycle (SDLC). To
update the software application and do all modifications in software application so as to improve
performance is the main focus of software maintenance. Software is a model that runs on the basis
of the real world. so, whenever any change requires in the software that means the need for real-
world changes wherever possible.

Need for Maintenance

Software Maintenance must be performed in order to:

 Correct faults.
  Improve the design.

 Implement enhancements.

 Interface with other systems.

 Accommodate programs so that different hardware, software, system features, and

telecommunications facilities can be used.

 Migrate legacy software.

 Retire software.

 Requirement of user changes.

 Run the code fast

Challenges in Software Maintenance

The various challenges in software maintenance are given below:

 The popular age of any software program is taken into consideration up to ten to fifteen
years. As software program renovation is open-ended and might maintain for decades
making it very expensive.

 Older software programs, which had been intended to paint on sluggish machines with much
less reminiscence and garage ability can not maintain themselves tough in opposition to
newly coming more advantageous software programs on contemporary-day hardware.

 Changes are frequently left undocumented which can also additionally reason greater
conflicts in the future.

 As the era advances, it turns into high prices to preserve vintage software programs.

 Often adjustments made can without problems harm the authentic shape of the software
program, making it difficult for any next adjustments.

 There is a lack of Code Comments.

 Lack of documentation: Poorly documented systems can make it difficult to understand how
the system works, making it difficult to identify and fix problems.

 Legacy code: Maintaining older systems with outdated technologies can be difficult, as it
may require specialized knowledge and skills.

 Complexity: Large and complex systems can be difficult to understand and modify, making it
difficult to identify and fix problems.

 Changing requirements: As user requirements change over time, the software system may
need to be modified to meet these new requirements, which can be difficult and time-
consuming.

 Interoperability issues: Systems that need to work with other systems or software can be
difficult to maintain, as changes to one system can affect the other systems.
  Lack of test coverage: Systems that have not been thoroughly tested can be difficult to
maintain as it can be hard to identify and fix problems without knowing how the system
behaves in different scenarios.

 Lack of personnel: A lack of personnel with the necessary skills and knowledge to maintain
the system can make it difficult to keep the system up-to-date and running smoothly.

 High-Cost: The cost of maintenance can be high, especially for large and complex systems,
which can be difficult to budget for and manage.

Software Supportability:

Software supportability in software engineering is designing systems to be easily maintained,

updated, and operated throughout their entire lifecycle, ensuring efficient fixes, enhancements, and
adaptations to changing needs, reducing long-term costs and improving user satisfaction by
integrating support features from the start, not as an afterthought. It's a holistic approach,
encompassing not just bug fixing (Corrective), but also Adaptive (new environments)
and Perfective (new features) maintenance, supported by tools, documentation, and infrastructure
for smooth operation and cost-effectiveness.

Key Aspects of Software Supportability:

 Lifecycle Integration: Considered from initial design through deployment and retirement,
involving development, testing, and post-release support.

 Holistic View: Goes beyond just maintenance to include installation, configuration, error
recovery, logistics, and user assistance (help desks, documentation).

 Design for Support: Incorporates features like modular design, clear documentation,
configuration management, and robust testing (e.g., replicated staging environments) to
ease support.

 Cost & Efficiency: Aims to reduce operational costs, improve availability, and speed up
problem resolution by making support easier and more efficient.

Benefits:

 Reduced Costs: Lower expenses for bug fixes, updates, and ongoing operations.

 Improved Availability: Faster recovery from failures and smoother updates.

 Better User Experience: Quicker resolution of issues and more responsive feature additions.

 Adaptability: Easier integration with new technologies and changing user demands.

Software Re-Engineering

Software Re-Engineering is the examination and alteration of a system to reconstitute it in a new

form. The principle of Re-Engineering when applied to the software development process is called
software re-engineering. It positively affects software cost, quality, customer service, and delivery
speed. In Software Re-engineering, we are improving the software to make it more efficient and
effective.
It is a process where the software's design is changed and the source code is created from scratch.
Sometimes software engineers notice that certain software product components need more upkeep
than other components, necessitating their re-engineering.

The re-Engineering procedure requires the following steps

1. Decide which components of the software we want to re-engineer. Is it the complete

software or just some components of the software?

2. Do Reverse Engineering to learn about existing software functionalities.

3. Perform restructuring of source code if needed for example modifying functional-Oriented

programs in Object-Oriented programs

4. Perform restructuring of data if required

5. Use Forward Engineering ideas to generate re-engineered software

The need for software Re-engineering: Software re-engineering is an economical process for
software development and quality enhancement of the product. This process enables us to identify
the useless consumption of deployed resources and the constraints that are restricting the
development process so that the development process could be made easier and cost-effective
(time, financial, direct advantage, optimize the code, indirect benefits, etc.) and maintainable. The
software reengineering is necessary for having-

a) Boost up productivity: Software reengineering increase productivity by optimizing the code and
database so that processing gets faster.

b) Processes in continuity: The functionality of older software products can be still used while the
testing or development of software.

c) Improvement opportunity: Meanwhile the process of software reengineering, not only software
qualities, features, and functionality but also your skills are refined, and new ideas hit your mind.
This makes the developer's mind accustomed to capturing new opportunities so that more and more
new features can be developed.

d) Reduction in risks: Instead of developing the software product from scratch or from the beginning
stage, developers develop the product from its existing stage to enhance some specific features
brought in concern by stakeholders or its users. Such kind of practice reduces the chances of fault
fallibility.

e) Saves time: As stated above, the product is developed from the existing stage rather than the
beginning stage, so the time consumed in software engineering is lesser.

f) Optimization: This process refines the system features, and functionalities and reduces the
complexity of the product by consistent optimization as maximum as possible.

Re-Engineering cost factors:

 The quality of the software is to be re-engineered.

  The tool support availability for engineering.

 The extent of the data conversion is required.

 The availability of expert staff for Re-engineering.

Reverse Engineering

Reverse engineering can extract design information from source code, but
the abstraction level, the completeness of the documentation, the degree to which tools and a
human analyst work together, and the directionality of the process are highly variable.

Objective of Reverse Engineering:

1. Reducing Costs: Reverse engineering can help cut costs in product development by finding
replacements or cost-effective alternatives for systems or components.

2. Analysis of Security: Reverse engineering is used in cybersecurity to examine exploits,

vulnerabilities, and malware. This helps in understanding of threat mechanisms and the
development of practical defenses by security experts.

3. Integration and Customization: Through the process of reverse engineering, developers can
incorporate or modify hardware or software components into pre-existing systems to
improve their operation or tailor them to meet particular needs.

4. Recovering Lost Source Code: Reverse engineering can be used to recover the source code
of a software application that has been lost or is inaccessible or at the very least, to
produce a higher-level representation of it.

5. Fixing bugs and maintenance: Reverse engineering can help find and repair flaws or
provide updates for systems for which the original source code is either unavailable or
inadequately documented.

Reverse Engineering Goals:

1. Cope with Complexity: Reverse engineering is a common tool used to understand and
control system complexity. It gives engineers the ability to analyze complex systems and
reveal details about their architecture, relationships and design patterns.

2. Recover lost information: Reverse engineering seeks to retrieve as much information as

possible in situations where source code or documentation are lost or unavailable.
Rebuilding source code, analyzing data structures and retrieving design details are a few
examples of this.

3. Detect side effects: Understanding a system or component's behavior requires analyzing its
side effects. Unintended implications, dependencies, and interactions that might not be
obvious from the system's documentation or original source code can be found with the
use of reverse engineering.

4. Synthesis higher abstraction: Abstracting low-level features in order to build higher-level

representations is a common practice in reverse engineering. This abstraction makes
communication and analysis easier by facilitating a greater understanding of the system's
functionality.
 5. Facilitate Reuse: Reverse engineering can be used to find reusable parts or modules in
systems that already exist. By understanding the functionality and architecture of a
system, developers can extract and repurpose components for use in other projects,
improving efficiency and decreasing development time.

Reverse Engineering

Reverse Engineering to Understand Data:

Reverse engineering of data occurs at different levels of abstraction .It is often the first
reengineering task.

1. At the program level, internal program data structures must often be reverse engineered
as part of an overall reengineering effort.

2. At the system level, global data structures (e.g., files, databases) are often reengineered to
accommodate new database management paradigms (e.g., the move from flat file to
relational or object-oriented database systems).

Internal Data Structures

Reverse engineering techniques for internal program data focus on the definition of classes of
objects.

1. This is accomplished by examining the program code with the intent of grouping related
program variables.

2. In many cases, the data organization within the code identifies abstract data types.

3. For example, record structures, files, lists, and other data structures often provide an initial
indicator of classes.

Database Structures

A database allows the definition of data objects and supports some method for establishing
relationships among the objects. Therefore, reengineering one database schema into another
requires an understanding of existing objects and their relationships.
The following steps define the existing data model as a precursor to reengineering a new database
model:

1. Build an initial object model.

2. Determine candidate keys (the attributes are examined to determine whether they are
used to point to another record or table; those that serve as pointers become candidate
keys).

3. Refine the tentative classes.

4. Define generalizations.

Restructuring, and Forward Engineering

In software engineering, Restructuring improves existing

code's internal structure without changing external behavior (like refactoring), while Forward
Engineering builds new systems from requirements (abstract to concrete), moving from design to
implementation, often used in re-engineering legacy systems to add new features or platforms.
The core difference: Forward Engineering creates; Restructuring improves what already exists by
analyzing, understanding (sometimes with Reverse Engineering), and then transforming the code
for better quality, maintainability, and adaptability.

Forward Engineering

 Definition: Developing new software or enhancing existing systems from well-defined

requirements, moving from high-level design to detailed implementation (abstract to
concrete).

 Process: Requirements analysis -> Design -> Implementation -> Testing.

 Goal: Create new functionality or systems, improve quality, migrate to new architectures
(e.g., mainframe to client-server).

 Example: Building a new mobile app or re-platforming a legacy system with new GUIs and
database structures.

Restructuring (Code Restructuring)

 Definition: Reorganizing the logical structure of existing code to improve attributes like
clarity, efficiency, or maintainability, without altering its external functions.

 Process: Analyzing existing code (often using reverse engineering) to understand design,
then transforming it.

 Goal: Enhance code quality, reduce complexity, make future changes easier.

 Example: Removing spaghetti code, improving class organization, or simplifying complex

algorithms within an existing application.

Relationship & Key Differences

 Re-engineering: Both processes contribute to software re-engineering, which aims to

improve legacy systems.

 Direction: Forward Engineering goes from abstract requirements to concrete code;

Restructuring modifies existing concrete code to better reflect an abstract ideal.

 Focus: Forward Engineering builds new or major features; Restructuring cleans up existing
code.

 Uncertainty: Forward Engineering starts with less uncertainty (clear specs); Restructuring
deals with the uncertainty of understanding legacy systems first.