(22A0508T)-Software Quality, Reliability, And Other Issues (Unit-5)

Q1. What is Risk and Risk Management?

"Tomorrow problems are today's risk." Hence, a clear definition of a "risk" is a problem that could cause some loss or
threaten 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.
We need to differentiate risks, as potential issues, from the current problems of the project.
Different methods are required to address these two kinds of issues.
For example, staff storage, because we have not been able to select people with the right technical skills is a current
problem, but the threat of our technical persons being hired away by the competition is a risk.
Risk Management
A software project can be concerned with a large variety of risks. In order to be adept to systematically identify the
significant risks which might affect a software project, it is essential to classify risks into different classes. The project
manager can then check which risks from each class are relevant to the project.
There are three main classifications of risks which can affect a software project:
1. Project risks
2. Technical risks
3. Business risks
1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource, and customer-related
problems. A vital project risk is schedule slippage. Since the software is intangible, it is very tough to monitor and
control a software project. It is very tough to control something which cannot be identified. For any manufacturing
program, such as the manufacturing of cars, the plan executive can recognize the product taking shape.
2. Technical risks: Technical risks concern potential method, implementation, interfacing, testing, and maintenance issue. It also
consists of an ambiguous specification, incomplete specification, changing specification, technical uncertainty, and technical
obsolescence. Most technical risks appear due to the development team's insufficient knowledge about the project.
3. Business risks: This type of risks contain risks of building an excellent product that no one need, losing budgetary or personnel
commitments, etc.
Other risk categories
1. 1. Known risks: Those risks that can be uncovered after careful assessment of the project program, the business and
technical environment in which the plan is being developed, and more reliable data sources (e.g., unrealistic delivery date)
2. 2. Predictable risks: Those risks that are hypothesized from previous project experience (e.g., past turnover)
3. 3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to identify in advance.
Principle of Risk Management
1. 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.
2. Take a forward-looking view: Consider the threat which may appear in the future and create future plans for directing the
next events.
3. 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.
4. Integrated management: In this method risk management is made an integral part of project management.
5. Continuous process: In this phase, the risks are tracked continuously throughout the risk management paradigm.

Q2. Risk Identification:

Risk identification is a systematic attempt to specify threats to the project plan (estimates, schedule, resource loading, etc.). By
identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and controlling
them when necessary.

There are two distinct types of risks : generic risks and product-specific risks. Generic risks are a potential threat to every
software project. 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. To identify product-specific risks, the project plan and the software statement
of scope are examined and an answer to the following question is developed: "What special characteristics of this product may
threaten our project plan?"

One method for identifying risks is to create a risk item checklist. The checklist can be used for risk identification and focuses on
some subset of known and predictable risks in the following generic subcategories:

• 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.

Designed by B. Rama Murthi, GIST, Nellore,

RG22
 (22A0508T)-Software Quality, Reliability, And Other Issues (Unit-5)

• 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.

The risk item checklist can be organized in different ways. Questions relevant to each of the topics can be answered for each
software project. The answers to these questions allow the planner to estimate the impact of risk. A different risk item checklist format
simply lists characteristics that are relevant to each generic subcategory. Finally, a set of “risk components and drivers" are listed
along with their probability of occurrence. Drivers for performance, support, cost, and schedule are discussed in answer to later
questions.
A number of comprehensive checklists for software project risk have been proposed in the literature . These provide useful insight
into generic risks for software projects and should be used whenever risk analysis and management is instituted. However, a relatively
short list of questions can be used to provide a preliminary indication of whether a project is “at risk.”

Q3. Risk projection

Risk projection, also called risk estimation, attempts to rate each risk in two ways—the likelihood or probability that the risk is real
and the consequences of the problems associated with the risk, should it occur. The project planner, along with other managers and
technical staff, performs four risk projection activities: (1) establish a scale that reflects the perceived likelihood of a risk, (2) delineate
the consequences of the risk, (3) estimate the impact of the risk on the project and the product, and (4)note the overall accuracy of
the risk projection so that there will be no misunderstandings.

Developing a Risk Table

A risk table provides a project manager with a simple technique for risk projection .A project team begins by listing all risks (no
matter how remote) 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. The probability value for each risk can be estimated by team members
individually. Individual team members are polled in round-robin fashion until their assessment of risk probability begins to converge.

Next, the impact of each risk is assessed. Each risk component is assessed and an impact category is determined. The categories
for each of the four risk components—performance, support, cost, and schedule—are averaged to determine an overall impact value.

Once the first four columns of the risk table have been completed, the table is sorted by probability and by impact. High-probability,
high-impact risks percolate to the top of the table, and low-probability risks drop to the bottom. This accomplishes first-order risk
prioritization.

The project manager studies the resultant sorted table and defines a cutoff line. The cutoff line (drawn horizontally at some point in
the table) implies that only risks that lie above the line will be given further attention. Risks that fall below the line are re-evaluated to
accomplish second-order prioritization. Risk impact and probability have a distinct influence on management concern. A risk factor
that has a high impact but a very low probability of occurrence should not absorb a significant amount of management time. However,
high-impact risks with moderate to high probability and low-impact risks with high probability should be carried forward into the risk
analysis steps that follow.

All risks that lie above the cutoff line must be managed. The column labeled RMMM contains a pointer into a Risk Mitigation,
Monitoring and Management Plan or alternatively, a collection of risk information sheets developed for all risks that lie above the
cutoff.
Risk probability can be determined by making individual estimates and then developing a single consensus value. Although that
approach is workable, more sophisticated techniques for determining risk probability have been developed. Risk drivers can be
assessed on a qualitative probability scale that has the following values: impossible, improbable, probable, and frequent.
Mathematical probability can then be associated with each qualitative value (e.g., a probability of 0.7 to 1.0 implies a highly probable
risk).

Assessing Risk Impact

Three factors affect the consequences that are likely if a risk does occur: its nature, its scope, and its timing. The nature of the
risk indicates the problems that are likely if it occurs. For example, a poorly defined external interface to customer hardware (a
technical risk) will preclude early design and testing and will likely lead to system integration problems late in a project. The scope of
a risk combines the severity (just how serious is it?) with its overall distribution (how much of the project will be affected or how many
customers are harmed?). Finally, the timing of a risk considers when and for how long the impact will be felt. In most cases, a project
manager might want the “bad news” to occur as soon as possible, but in some cases, the longer the delay, the better.

Returning once more to the risk analysis approach proposed by the U.S. Air Force , the following steps are recommended to
determine the overall consequences of a risk:
1. Determine the average probability of occurrence value for each risk component.
2. Determine the impact for each component based on the criteria .
3. Complete the risk table and analyze the results as described in the preceding sections.
The overall risk exposure, RE, is determined using the following relationship:

Designed by B. Rama Murthi, GIST, Nellore,

RG22
 (22A0508T)-Software Quality, Reliability, And Other Issues (Unit-5)

RE = P x C

where P is the probability of occurrence for a risk, and C is the the cost to the project should the risk occur.

For example, assume that the software team defines a project risk in the following manner:

Risk identification. Only 70 percent of the software components scheduled for reuse will, in fact, be integrated into the application.
The remaining functionality will have to be custom developed.
Risk probability. 80% (likely).
Risk impact. 60 reusable software components were planned.
Risk exposure. RE = 0.80 x 25,200 ~ $20,200.

Q3. Risk Refinement

Risk Refinement: The Process of restating the risks as a set of more detailed risks that will be easier to mitigate,
monitor, and manage.
During early stages of project planning, a risk may be stated quite generally. As time passes and more is learned about the project
and the risk, it may be possible to refine the risk into a set of more detailed risks, each somewhat easier to mitigate, monitor, and
manage.

One way to do this is to represent the risk in condition-transition-consequence (CTC) format . That is, the risk is stated in the
following form: Given that <condition> then there is concern that (possibly) <consequence>.

Using the CTC format for the reuse risk noted in Section 6.4.2, we can write:
Given that all reusable software components must conform to specific design standards and that some do not conform, then there
is concern that (possibly) only 70 percent of the planned reusable modules may actually be integrated into the as-built system,
resulting in the need to custom engineer the remaining 30 percent of components.

This general condition can be refined in the following manner:

Subcondition 1. Certain reusable components were developed by a third party with no knowledge of internal design standards.

Subcondition 2. The design standard for component interfaces has not been solidified and may not conform to certain existing
reusable components.

Subcondition 3. Certain reusable components have been implemented in a language that is not supported on the target
environment.

The consequences associated with these refined subconditions remains the same (i.e., 30 percent of software components must
be customer engineered), but the refinement helps to isolate the underlying risks and might lead to easier analysis and response.

Q4. Risk Mitigation, Monitoring, and Management (RMMM) plan

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.
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

Designed by B. Rama Murthi, GIST, Nellore,

RG22
 (22A0508T)-Software Quality, Reliability, And Other Issues (Unit-5)
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.

Q5. Software Maintenance

Software maintenance is a part of the Software Development Life Cycle. Its primary goal is to modify and update software
application after delivery to correct errors and to improve performance. Software is a model of the real world. When the
real world changes, the software require alteration wherever possible.
Software Maintenance is an inclusive activity that includes error corrections, enhancement of capabilities, deletion of
obsolete capabilities, and optimization.
Need for Maintenance
Software Maintenance is needed for:-
o Correct errors
o Change in user requirement with time
o Changing hardware/software requirements
o To improve system efficiency
o To optimize the code to run faster
o To modify the components
o To reduce any unwanted side effects.
Thus the maintenance is required to ensure that the system continues to satisfy user requirements.
1. Corrective Maintenance
Corrective maintenance aims to correct any remaining errors regardless of where they may cause specifications, design,
coding, testing, and documentation, etc.

Designed by B. Rama Murthi, GIST, Nellore,

RG22
 (22A0508T)-Software Quality, Reliability, And Other Issues (Unit-5)

2. Adaptive Maintenance
It contains modifying the software to match changes in the ever-changing environment.
3. Preventive Maintenance
It is the process by which we prevent our system from being obsolete. It involves the concept of reengineering & reverse
engineering in which an old system with old technology is re-engineered using new technology. This maintenance
prevents the system from dying out.
4. Perfective Maintenance
It defines improving processing efficiency or performance or restricting the software to enhance changeability. This may
contain enhancement of existing system functionality, improvement in computational efficiency, etc.

Q6. Reengineering:
Software Re-engineering is a process of software development which is done to improve the maintainability
of a software system. Re-engineering is the examination and alteration of a system to reconstitute it in a new
form. This process encompasses a combination of sub-processes like reverse engineering, forward engineering,
reconstructing etc.
Re-engineering, also known as reverse engineering or software re-engineering, is the process of analyzing,
designing, and modifying existing software systems to improve their quality, performance, and maintainability.
This can include updating the software to work with new hardware or software platforms, adding new features,
or improving the software’s overall design and architecture.
Software re-engineering, also known as software restructuring or software renovation, refers to the process of
improving or upgrading existing software systems to improve their quality, maintainability, or functionality. It
involves reusing the existing software artifacts, such as code, design, and documentation, and transforming
them to meet new or updated requirements.
The primary goal of software re-engineering is to improve the quality and maintainability of the software system,
while minimizing the risks and costs associated with the redevelopment of the system from scratch. Software
re-engineering can be initiated for various reasons, such as:
1. Improving software quality: Re-engineering can help improve the quality of software by eliminating defects,
improving performance, and enhancing reliability and maintainability.
2. Updating technology: Re-engineering can help modernize the software system by updating the technology
used to develop, test, and deploy the system.
3. Enhancing functionality: Re-engineering can help enhance the functionality of the software system by
adding new features or improving existing ones.
4. Resolving issues: Re-engineering can help resolve issues related to scalability, security, or compatibility
with other systems.
The process of software re-engineering involves the following steps:
1. Planning: The first step is to plan the re-engineering process, which involves identifying the reasons for re-
engineering, defining the scope, and establishing the goals and objectives of the process.
2. Analysis: The next step is to analyze the existing system, including the code, documentation, and other
artifacts. This involves identifying the system’s strengths and weaknesses, as well as any issues that need
to be addressed.
3. Design: Based on the analysis, the next step is to design the new or updated software system. This involves
identifying the changes that need to be made and developing a plan to implement them.
4. Implementation: The next step is to implement the changes by modifying the existing code, adding new
features, and updating the documentation and other artifacts.
5. Testing: Once the changes have been implemented, the software system needs to be tested to ensure that
it meets the new requirements and specifications.
6. Deployment: The final step is to deploy the re-engineered software system and make it available to end-
users.
Overall, software re-engineering can be a cost-effective way to improve the quality and functionality of existing
software systems, while minimizing the risks and costs associated with starting from scratch.
Re-engineering can be done for a variety of reasons, such as:
To improve the software’s performance and scalability: By analyzing the existing code and identifying
bottlenecks, re-engineering can be used to improve the software’s performance and scalability.
1. To add new features: Re-engineering can be used to add new features or functionality to existing
software.
2. To support new platforms: Re-engineering can be used to update existing software to work with new
hardware or software platforms.
3. To improve maintainability: Re-engineering can be used to improve the software’s overall design and
architecture, making it easier to maintain and update over time.

Designed by B. Rama Murthi, GIST, Nellore,

RG22
 (22A0508T)-Software Quality, Reliability, And Other Issues (Unit-5)
4. To meet new regulations and compliance: Re-engineering can be done to ensure that the software is
compliant with new regulations and standards.
5. Re-engineering can be a complex and time-consuming process, and it requires a thorough
understanding of the existing software system. It also requires a structured and disciplined approach to
software development, similar to software engineering.
6. Re-engineering can be beneficial in many cases, it can help to improve the quality, performance, and
maintainability of existing software systems, but it also has its own drawbacks, such as:
7. High costs: Re-engineering can be a resource-intensive process and can require a significant investment
in tools and training.
8. Risk of introducing new bugs: Changing existing code can introduce new bugs and compatibility issues.
9. High learning curve: Re-engineering can be complex, and it requires a lot of learning and training, which
can be challenging for new developers.
The process of software re-engineering typically involves the following steps:
1. Assessment: The existing software system is analyzed to identify its strengths and weaknesses, and to
determine the extent of the required re-engineering effort.
2. Planning: A plan is developed to guide the re-engineering effort, including the identification of goals,
objectives, and performance metrics.
3. Requirements analysis: The requirements of the new system are defined based on user needs and
business requirements.
4. Architecture and design: The architecture and design of the new system are developed, taking into
account the requirements of the new system and the limitations of the existing system.
5. Implementation: The new system is developed and implemented, either by modifying the existing system
or by developing a new system from scratch.
6. Testing: The new system is tested to ensure that it meets the requirements of the new system and is free
from errors and defects.
7. Maintenance: The new system is maintained over time to ensure that it remains reliable, performant, and
secure.
Re-engineering is the reorganizing and modifying existing software systems to make them more maintainable.
Objectives of Re-engineering:
• To describe a cost-effective option for system evolution.
• To describe the activities involved in the software maintenance process.
• To distinguish between software and data re-engineering and to explain the problems of data re-engineering.
Diagrammatic Representation:
Steps involved in Re-engineering:
1. Inventory Analysis
2. Document Reconstruction
3. Reverse Engineering
4. Code Reconstruction
5. Data Reconstruction
6. Forward Engineering
Re-engineering Cost Factors:
• The quality of the software to be re-engineered
• The tool support available for re-engineering
• The extent of the required data conversion
• The availability of expert staff for re-engineering
Re-engineering can be a costly process, and there are several
factors that can affect the cost of re-engineering a software
system:
1. Size and complexity of the software: The larger and more complex the software system, the more time and
resources will be required to analyze, design, and modify it.
2. Number of features to be added or modified: The more features that need to be added or modified, the more
time and resources will be required.
Advantages of Re-engineering:
• Reduced Risk: As the software is already existing, the risk is less as compared to new software
development. Development problems, staffing problems and specification problems are the lots of problems
that may arise in new software development.
• Reduced Cost: The cost of re-engineering is less than the costs of developing new software.
• Revelation of Business Rules: As a system is re-engineered , business rules that are embedded in the
system are rediscovered.
• Better use of Existing Staff: Existing staff expertise can be maintained and extended accommodate new
skills during re-engineering.
• Practical limits to the extent of re-engineering.

Designed by B. Rama Murthi, GIST, Nellore,

RG22
 (22A0508T)-Software Quality, Reliability, And Other Issues (Unit-5)
• Major architectural changes or radical reorganizing of the systems data management has to be done
manually.
• Re-engineered system is not likely to be as maintainable as a new system developed using modern software
Re-engineering methods.
• High costs: Re-engineering can be a costly process, requiring significant investments in time, resources, and
technology.

Q7. Reverse Engineering

Software Reverse Engineering is a process of recovering the design, requirement specifications, and
functions of a product from an analysis of its code. It builds a program database and generates information
from this.
The purpose of reverse engineering is to facilitate the maintenance work by improving the understandability of
a system and producing the necessary documents for a legacy system.
Reverse Engineering Goals:
• Cope with Complexity.
• Recover lost information.
• Detect side effects.
• Synthesis higher abstraction.
• Facilitate Reuse.
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.
This is accomplished by examining the program code with the
intent of grouping related program variables. In many cases, the data organization within the code identifies
abstract data types.
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,
Reverse Engineering to Understand Processing: To understand processing begins with an attempt to
understand and then extract procedural abstractions represented by the source code.
To understand procedural abstractions, the code is analyzed at varying levels of abstraction :system, program,
component, pattern, and statement.
• Each of the programs that make up the application system represents a functional abstraction at a high
level of detail. A block diagram, representing the interaction between these functional abstractions, is
created.
• Each component performs some subfunction and represents a defined procedural abstraction. A
processing narrative for each component is developed.
For large systems, reverse engineering is generally accomplished using a semiautomated(partial automation)
approach. Automated tools can be used to help you understand the semantics of existing code.
The output of this process is then passed to restructuring and forward engineering tools to complete the
reengineering process.
Steps of Software Reverse Engineering:
1. Collection Information:
This step focuses on collecting all possible information (i.e., source design documents, etc.) about the
software.
2. Examining the information:
The information collected in step-1 is studied so as to get familiar with the system.

Designed by B. Rama Murthi, GIST, Nellore,

RG22
 (22A0508T)-Software Quality, Reliability, And Other Issues (Unit-5)
3. Extracting the structure:
This step concerns identifying program structure in the form of a structure chart where each node
corresponds to some routine.
4. Recording the functionality:
During this step processing details of each module of the structure, charts are recorded using structured
language like decision table, etc.
5. Recording data flow:
From the information extracted in step-3 and step-4, a set of data flow diagrams is derived to show the flow
of data among the processes.
6. Recording control flow:
The high-level control structure of the software is recorded.
7. Review extracted design:
The design document extracted is reviewed several times to ensure consistency and correctness. It also
ensures that the design represents the program.
8. Generate documentation:
Finally, in this step, the complete documentation including SRS, design document, history, overview, etc. is
recorded for future use.
Reverse Engineering Tools:
Reverse engineering if done manually would consume a lot of time and human labor and hence must be
supported by automated tools. Some of the tools are given below:
• CIAO and CIA: A graphical navigator for software and web repositories and a collection of Reverse
Engineering tools.
• Rigi: A visual software understanding tool.
• Bunch: A software clustering/modularization tool.
• GEN++: An application generator to support the development of analysis tools for the C++ language.
• PBS: Software Bookshelf tools for extracting and visualizing the architecture of programs.

Q8. Forward Engineering.

Forward engineering is the process of building from a high-level model or concept to build in complexities and lower-
level details. This type of engineering has different principles in various software and database processes.
Generally, forward engineering is important in IT because it represents the ‘normal’ development process. For
example, building from a model into an implementation language. This will often result in loss of semantics, if models
are more semantically detailed, or levels of abstraction.
Forward engineering is thus related to the term ‘reverse engineering,’ where there is an effort to build backward,
from a coded set to a model, or to unravel the process of how something was put together.

Techopedia Explains Forward Engineering

It’s crucial to note, though, that reverse engineering is also a term widely used in IT to describe attempts to take a
software product or other technology apart and inspect how it works. In this type of contrast, forward engineering
would be a logical ‘forward-moving’ design, where reverse engineering would be a form of creative deconstruction.

Some experts provide specific examples of forward engineering, including the use of abstract database models or
templates into physical database tables. Other examples include a situation where developers or others make models or
diagrams into concrete code classes, or specific code modules.

Q8. Difference between Forward Engineering and Reverse Engineering

What is Forward Engineering?
It is a method through which we make or create an application according to the given set of requirements.
Reclamation or Renovation are some other names used for forward engineering. It requires pretty high proficiency
skills and takes up more time for application development.

What is Forward Engineering?

It is a method through which we make or create an application according to the given set of requirements.
Reclamation or Renovation are some other names used for forward engineering. It requires pretty high proficiency
skills and takes up more time for application development.

Forward engineering is basically a technique through which we create high-level designs or models using low-level
information under high complexities. Thus, this type of engineering consists of a completely different set of principles

Designed by B. Rama Murthi, GIST, Nellore,

RG22
 (22A0508T)-Software Quality, Reliability, And Other Issues (Unit-5)

for information process and packaging. It applies to all the processes of software engineering that contain SDLC for
recreating the existing application. The main aim of forward engineering here is to fulfill the needs of new users with
the process of re-engineering.
What is Reverse Engineering?
A common name of this type of engineering is backward engineering. Reverse engineering is basically a process
similar to that of forward engineering, but it happens in reverse. This process collects information out of the pre-
existing given application. This process takes comparatively less time than forward engineering when developing an
application. Reverse engineering breaks down an application into minute systems to extract its architecture or the
knowledge within.
Difference between Forward Engineering and Reverse Engineering
Here is a list of the differences between forward engineering and reverse engineering.

Parameters Forward Engineering Reverse Engineering

Basics Forward engineering aims at re-developing Reverse engineering aims at deducing the resources
an application with the provided resources and requirements that went into developing an
according to the current requirements. application in the first place.

Nature It is perceptive in nature. It is adaptive in nature.

Certainty It always leads to the production of Using this type of engineering, a user can easily yield a
applications that implement the specified lot of ideas associated with the requirements of the
requirements. implementation and development of the application.

Skills Needed It requires high-proficiency skills. It works even with a low level of expertise.

Total Time Required It takes more time. It takes comparatively less time.

Accuracy The model in engineering must be complete An inexact model can also yield partial information
and precise. about the initial requirements and resources that went
into its development.

Examples A few examples of forward engineering are Performing research on various instruments is a
the construction of a DC motor, constructing commendable example of backward engineering.
kits (electronic), etc.

Q9. Implementation of safe home system using software

engineering principles
Goals of this tutorial:
For researchers:
1. Differentiate case studies from other empirical methods
2. A solid grounding in the fundamentals of case studies as a research method
3. Understand and avoid common mistakes with case studies
For reviewers:
1.Guidance to judge quality and validity of reported case studies.
2. Criteria to assess whether research papers based on case studies are suitable for publication
For practitioners: Awareness of how to interpret the claims made by researchers about new software engineering
methods and tools. Insights into the roles practitioners can play in case studies research
Many methods available:
1.Controlled Experiments
2.Case Studies
3. Surveys Ethnographies
4. Artifact/Archive Analysis (“mining”!)
5. Action Research
6. Simulations
7. Benchmarks

Designed by B. Rama Murthi, GIST, Nellore,

RG22
 (22A0508T)-Software Quality, Reliability, And Other Issues (Unit-5)
NFC tag use, providing Password and PIR motion sensor. To open the door a person should provide NFC tag and
password. If one of them absence the door will not open. The door will opened by servomotor with a lock coupled in its
shaft.

What are the principles of software engineering?

Principles like modularization, top-down design, and stepwise
refinement break complex systems into manageable parts that are easier to
verify for correctness. Furthermore, strategies like unit testing, code reviews,
and walkthroughs detect errors early in the development process.
Through this blog post, we will try to decipher some basic principles related to
software engineering.
• What is Software Engineering?
• Why are Software Engineering Principles Important?
• Principles of Software Engineering
• Best Practices for Software Engineering
• Conclusion
Why are Software Engineering Principles Important?
Developing robust, maintainable software solutions necessitates the incorporation of essential software engineering
principles. Adhering to these principles guarantees accurate, efficient, and cost-effective development of the software.
Enumerated below are several key justifications for the significance of software engineering principles:
• Reliability and Correctness – Software engineering principles emphasize techniques that reduce the
number of defects and bugs in the software. Principles like modularization, top-down design, and stepwise
refinement break complex systems into manageable parts that are easier to verify for correctness.
Furthermore, strategies like unit testing, code reviews, and walkthroughs detect errors early in the
development process. This results in a more reliable software that behaves as intended.
• Manageability of Complexity– Large software systems can be extremely complex, with thousands of
interacting components. Software engineering principles promote ways to organize this complexity, for
example, through abstraction, encapsulation, and modularity. This makes the system easier to comprehend,
navigate, and change over time. Without such principles in place, managing complex software would be
literally impossible.
• Maintainability and Extensibility – Software engineering principles facilitate the maintenance and evolution
of software systems. Principles like information hiding, separation of concerns, and layering partition the
software into smaller logical pieces that can be modified independently. Conventions like naming standards
and documentation procedures also aid in maintainability. This makes the software adaptable to the ongoing
changes in requirements and technology.
• Productivity and Cost – Well-engineered software that follows basic principles tends to be less expensive to
develop, test, and maintain in the long run. Good design techniques minimize the rework and duplication of
effort. Issues are caught and fixed earlier in the development lifecycle to avoid costly defects in later stages. In
total, productivity is increased and development costs are reduced through the proper application of software
engineering principles.

Designed by B. Rama Murthi, GIST, Nellore,

RG22