MODULE-V Risk, Quality Management and Reengineering

5.1 Risk and quality Management

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.

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:

Project risks
Technical risks
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.
2. 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

Learn more
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. Predictable risks: Those risks that are hypothesized from previous project
experience (e.g., past turnover)
3. Unpredictable risks: Those risks that can and do occur, but are extremely tough
to identify in advance.
Principle of Risk Management
Global Perspective: In this, we review the bigger system description, design, and
implementation. We look at the chance and the impact the risk is going to have.
Take a forward-looking view: Consider the threat which may appear in the future
and create future plans for directing the next events.
Open Communication: This is to allow the free flow of communications between the
client and the team members so that they have certainty about the risks.
Integrated management: In this method risk management is made an integral part
of project management.
Continuous process: In this phase, the risks are tracked continuously throughout the
risk management paradigm.
5.2 Reactive and proactive risk strategies
Root Cause Analysis (RCA) is one of the best methods to identify main cause or root
cause of problems or events in very systematic way or process. RCA is based on the
idea that for effective management, we need to find out way to prevent arising or
occurring problems.

Each one needs to understand that if they want to solve or eliminate any problem, it
is essential to go to the root cause of the problem and then eliminate problems so
that they can reduce or control the reoccurrence of the problem. For organizations
that want to improve and grow continuously, it is very essential to identify the root
cause although it is tough to do so, it is essential. RCA can also be used to modify or
change core processes and issues in such way that prevents future problems.

Reactive and Proactive RCA :

The main question that arises is whether RCA is reactive or proactive? Some people
think that RCA is only required to solve problems or failures that have already
occurred. But, it’s not true. One should know that RCA can be both i.e. reactive and
proactive as given below –
1. Reactive RCA :
The main question that arises in reactive RCA is “What went wrong?”. Before
investigating or identifying the root cause of failure or defect, failure needs to be in
place or should be occurred already. One can only identify the root cause and
perform the analysis only when problem or failure had occurred that causes
malfunctioning in the system. Reactive RCA is a root cause analysis that is
performed after the occurrence of failure or defect.

It is simply done to control, implemented to reduce the impact and severity of

defect that has occurred. It is also known as reactive risk management. It reacts
quickly as soon as problem occurs by simply treating symptoms. RCA is generally
reactive but it has the potential to be proactive. RCA is reactive at initial and it can
only be proactive if one addresses and identifies small things too that can cause
problem as well as exposes hidden causes of the problem.

Advantages :

Helps one to prioritize tasks according to its severity and then resolve it.
Increases teamwork and their knowledge.
Disadvantages :

Sometimes, resolving equipment after failure can be more costly than preventing
failure from an occurrence.
Failed equipment can cause greater damage to system and interrupts production
activities.

2. Proactive RCA :
The main question that arises in proactive RCA is “What could go wrong?”. RCA can
also be used proactively to mitigate failure or risk. The main importance of RCA can
be seen when it is applied to events that have not occurred yet. Proactive RCA is a
root cause analysis that is performed before any occurrence of failure or defect. It is
simply done to control, implemented to prevent defect from its occurrence. As both
reactive and proactive RCAs are is important, one should move from reactive to
proactive RCA.
It is better to prevent issues from its occurrence rather than correcting it after its
occurrence. In simple words, Prevention is better than correction. Here, prevention
action is considered as proactive and corrective action is considered as reactive. It
is also known as proactive risk management. It identifies the root cause of problem
to eliminate it from reoccurring. With help of proactive RCA, we can identify the
main root cause that leads to the occurrence of problem or failure, or defect. After
knowing this, we can take various measures and implement actions to prevent
these causes from the occurrence.

Advantages :

Future chances of failure occurrence can be minimized.

Reduce overall cost required to resolve failure by simply preventing failure from an
occurrence.
Increases overall productivity by minimizing chances of interruption due to failure.
Disadvantages :

Sometimes, preventing equipment from failure can be more costly than resolving
failure after occurrence.
Many resources and tools required to prevent failure from an occurrence that can
affect the overall cost.
Requires highly skilled technicians to perform maintenance tasks.
5.3 Software risks
Software development is a multi stage approach of design, documentation,
programming, prototyping, testing etc which follows a Software Development Life
Cycle (SDLC) process. Different tasks are performed based on SDLC framework
during software development. Developing and Maintaining software project involves
risk in each step.

Most enterprises rely on software and ignoring the risks associated with any phase
needs to be identified and managed/solved otherwise it creates unforeseen
challenges for business. Before analyzing different risks involved in software
development, Let’s first understand what is actually risk and why risk management
is important for a business.

Risk and importance of risk management :

Risk is uncertain events associated with future events which have a probability of
occurrence but it may or may not occur and if occurs it brings loss to the project.
Risk identification and management are very important task during software project
development because success and failure of any software project depends on it.

Various Kinds of Risks in Software Development :

Schedule Risk :
Schedule related risks refers to time related risks or project delivery related
planning risks. The wrong schedule affects the project development and delivery.
These risks are mainly indicates to running behind time as a result project
development doesn’t progress timely and it directly impacts to delivery of project.
Finally if schedule risks are not managed properly it gives rise to project failure and
at last it affect to organization/company economy very badly.
Some reasons for Schedule risks –

 Time is not estimated perfectly

 Improper resource allocation
 Tracking of resources like system, skill, staff etc
 Frequent project scope expansion
 Failure in function identification and its’ completion
Budget Risk :
Budget related risks refers to the monetary risks mainly it occurs due to budget
overruns. Always the financial aspect for the project should be managed as per
decided but if financial aspect of project mismanaged then there budget concerns
will arise by giving rise to budget risks. So proper finance distribution and
management are required for the success of project otherwise it may lead to project
failure.
Some reasons for Budget risks –

 Wrong/Improper budget estimation

 Unexpected Project Scope expansion
 Mismanagement in budget handling
 Cost overruns
 Improper tracking of Budget
Operational Risks :
Operational risk refers to the procedural risks means these are the risks which
happen in day-to-day operational activities during project development due to
improper process implementation or some external operational risks.
Some reasons for Operational risks –
Insufficient resources
 Conflict between tasks and employees
 Improper management of tasks
 No proper planning about project
 Less number of skilled people
 Lack of communication and cooperation
 Lack of clarity in roles and responsibilities
 Insufficient training
Technical Risks :
Technical risks refers to the functional risk or performance risk which means this
technical risk mainly associated with functionality of product or performance part of
the software product.
Some reasons for Technical risks –

 Frequent changes in requirement

 Less use of future technologies
 Less number of skilled employee
 High complexity in implementation
 Improper integration of modules
Programmatic Risks :
Programmatic risks refers to the external risk or other unavoidable risks. These are
the external risks which are unavoidable in nature. These risks come from outside
and it is out of control of programs.
Some reasons for Programmatic risks –

 Rapid development of market

 Running out of fund / Limited fund for project development
 Changes in Government rules/policy
 Loss of contracts due to any reason

5.4 Risk mitigation monitoring and management

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.

Finding out the risk.

Removing causes that are the reason for risk creation.
Controlling the corresponding documents from time to time.
Conducting timely reviews to speed up the work.
Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.

To check if predicted risks occur or not.

To ensure proper application of risk aversion steps defined for risk.
To collect data for future risk analysis.
To allocate what problems are caused by which risks throughout the project.
Risk Management 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.
5.5 software quality factors
The various factors, which influence the software, are termed as software factors.
They can be broadly divided into two categories. The first category of the factors is
of those that can be measured directly such as the number of logical errors, and the
second category clubs those factors which can be measured only indirectly. For
example, maintainability but each of the factors is to be measured to check for the
content and the quality control.
Several models of software quality factors and their categorization have been
suggested over the years. The classic model of software quality factors, suggested
by McCall, consists of 11 factors (McCall et al., 1977). Similarly, models consisting of
12 to 15 factors, were suggested by Deutsch and Willis (1988) and by Evans and
Marciniak (1987).
All these models do not differ substantially from McCall’s model. The McCall factor
model provides a practical, up-to-date method for classifying software requirements
(Pressman, 2000).
McCall’s Factor Model
This model classifies all software requirements into 11 software quality factors. The
11 factors are grouped into three categories – product operation, product revision,
and product transition factors.
 Product operation factors − Correctness, Reliability, Efficiency,
Integrity, Usability.
 Product revision factors − Maintainability, Flexibility, Testability.
 Product transition factors − Portability, Reusability, Interoperability.
Product Operation Software Quality Factors
According to McCall’s model, product operation category includes five software
quality factors, which deal with the requirements that directly affect the daily
operation of the software. They are as follows −
Correctness
These requirements deal with the correctness of the output of the software system.
They include −
 Output mission
 The required accuracy of output that can be negatively affected by
inaccurate data or inaccurate calculations.
 The completeness of the output information, which can be affected by
incomplete data.
 The up-to-dateness of the information defined as the time between the
event and the response by the software system.
  The availability of the information.
 The standards for coding and documenting the software system.
Reliability
Reliability requirements deal with service failure. They determine the maximum
allowed failure rate of the software system, and can refer to the entire system or to
one or more of its separate functions.
Efficiency
It deals with the hardware resources needed to perform the different functions of
the software system. It includes processing capabilities (given in MHz), its storage
capacity (given in MB or GB) and the data communication capability (given in MBPS
or GBPS).
It also deals with the time between recharging of the system’s portable units, such
as, information system units located in portable computers, or meteorological units
placed outdoors.
Integrity
This factor deals with the software system security, that is, to prevent access to
unauthorized persons, also to distinguish between the group of people to be given
read as well as write permit.
Usability
Usability requirements deal with the staff resources needed to train a new
employee and to operate the software system.
Product Revision Quality Factors
According to McCall’s model, three software quality factors are included in the
product revision category. These factors are as follows −
Maintainability
This factor considers the efforts that will be needed by users and maintenance
personnel to identify the reasons for software failures, to correct the failures, and to
verify the success of the corrections.
Flexibility
This factor deals with the capabilities and efforts required to support adaptive
maintenance activities of the software. These include adapting the current software
to additional circumstances and customers without changing the software. This
factor’s requirements also support perfective maintenance activities, such as
changes and additions to the software in order to improve its service and to adapt it
to changes in the firm’s technical or commercial environment.
Testability
Testability requirements deal with the testing of the software system as well as with
its operation. It includes predefined intermediate results, log files, and also the
automatic diagnostics performed by the software system prior to starting the
system, to find out whether all components of the system are in working order and
to obtain a report about the detected faults. Another type of these requirements
deals with automatic diagnostic checks applied by the maintenance technicians to
detect the causes of software failures.
Product Transition Software Quality Factor
According to McCall’s model, three software quality factors are included in the
product transition category that deals with the adaptation of software to other
environments and its interaction with other software systems. These factors are as
follows −
Portability
Portability requirements tend to the adaptation of a software system to other
environments consisting of different hardware, different operating systems, and so
forth. The software should be possible to continue using the same basic software in
diverse situations.
Reusability
This factor deals with the use of software modules originally designed for one
project in a new software project currently being developed. They may also enable
future projects to make use of a given module or a group of modules of the
currently developed software. The reuse of software is expected to save
development resources, shorten the development period, and provide higher quality
modules.
Interoperability
Interoperability requirements focus on creating interfaces with other software
systems or with other equipment firmware. For example, the firmware of the
production machinery and testing equipment interfaces with the production control
software.

5.6 Defect Amplication model

Defect Amplification and Removal
Defect amplification model:
used to illustrate the generation and detection of errors during the preliminary
design, detail design, and coding steps of the software engineering process.
 Fig:5.6.1 Development step
A box represents a software development step.
During the step, errors may be inadvertently generated.
Review may fail to uncover newly generated errors and errors from previous steps,
resulting in some number of errors that are passed through.
In some cases, errors passed through from previous steps are amplified
(amplification factor, x) by current work.
box subdivisions represent each of these characteristics and the percent of
efficiency for detecting errors, a function of the thoroughness of the review.

Fig: 5.6.2 validation Test

Hypothetical example of defect amplification for a software development process in
which no reviews are conducted.
Each test step uncovers and corrects 50 percent of all incoming errors without
introducing any new errors.
Ten preliminary design defects are amplified to 94 errors before testing
commences.
Twelve latent errors are released to the field.
 Fig:5.6.3 Testing model
Same conditions except that design and code reviews are conducted as part of each
development step.
Ten initial preliminary design errors are amplified to 24 errors before testing
commences.

Only three latent errors exist.

5.7 Formal technical reviews(FTR)

Objectives of the FTR –
 to uncover errors in function, logic, or implementation for any representation
of the software
 to verify that the software under review meets its requirements
 to ensure that the software has been represented according to predefined
standards
 to achieve software that is developed in a uniform manner;
 to make projects more manageable.

FTR
  serves as a training ground

 promotes backup and continuity because a number of people become

familiar with parts of the software that they may not have otherwise seen.
class of reviews that includes:
 walkthroughs
 inspections
 round-robin reviews
 other small group technical assessments of software.
Each FTR is conducted as a meeting that is planned, controlled, and attended.
The Review Meeting
Review meeting constraints:

Between three and five people should be involved in the review.

Advance preparation should require no more than two hours of work for each
person.
The duration of the review meeting should be less than two hours.

NOTE: FTR focuses on a specific (and small) part of the overall software.

o Walkthroughs are conducted for each component or small group of

components.

o FTR focuses on a work product (e.g., a portion of a requirements

specification, a detailed component design, a source code listing for a
component).

o Individual who has developed the work product informs the project
leader that the work product is complete and that a review is required.

o The project leader contacts a review leader, who evaluates the product
for readiness, generates copies of product materials, and distributes
them to two or three reviewers for advance preparation.
 o Each reviewer is expected to spend between one and two hours
reviewing the product, making notes, and otherwise becoming familiar
with the work. Concurrently, the review leader also reviews the product
and establishes an agenda for the review meeting, which is typically
scheduled for the next day.

o Review meeting attended by

o review leader

o all reviewers

o the producer.

o One reviewer takes on the role of the recorder; that is, the individual
who records (in writing) all important issues raised during the review.

1. The FTR begins with an introduction of the agenda and a brief introduction by
the producer.

2. The producer then proceeds to "walk through" the work product, explaining the
material, while reviewers raise issues based on their advance preparation.

3. When valid problems or errors are discovered, the recorder notes each.

4. At the end of the review, all attendees of the FTR must decide whether to

1. accept the product without further modification

2. reject the product due to severe errors (once corrected, another review must
be performed)
3. accept the product provisionally (minor errors have been encountered and
must be corrected, but no additional review will be required).

5.8 Software quality assurance

Software Quality Assurance (SQA) is simply a way to assure quality in the software.
It is the set of activities which ensure processes, procedures as well as standards
are suitable for the project and implemented correctly.
Software Quality Assurance is a process which works parallel to development of
software. It focuses on improving the process of development of software so that
problems can be prevented before they become a major issue. Software Quality
Assurance is a kind of Umbrella activity that is applied throughout the software
process.

Software Quality Assurance has:

A quality management approach

Formal technical reviews
Multi testing strategy
Effective software engineering technology
Measurement and reporting mechanism
Major Software Quality Assurance Activities:

SQA Management Plan:

Make a plan for how you will carry out the sqathrough out the project. Think about
which set of software engineering activities are the best for project. check level of
sqa team skills.

Set The Check Points:

SQA team should set checkpoints. Evaluate the performance of the project on the
basis of collected data on different check points.

Multi testing Strategy:

Do not depend on a single testing approach. When you have a lot of testing
approaches available use them.
Measure Change Impact:
The changes for making the correction of an error sometimes re introduces more
errors keep the measure of impact of change on project. Reset the new change to
change check the compatibility of this fix with whole project.

Manage Good Relations:

In the working environment managing good relations with other teams involved in
the project development is mandatory. Bad relation of sqa team with programmers
team will impact directly and badly on project. Don’t play politics.

Benefits of Software Quality Assurance (SQA):

SQA produces high quality software.
High quality application saves time and cost.
SQA is beneficial for better reliability.
SQA is beneficial in the condition of no maintenance for a long time.
High quality commercial software increase market share of company.
Improving the process of creating software.
Improves the quality of the software.

Disadvantage of SQA:
There are a number of disadvantages of quality assurance. Some of them include
adding more resources, employing more workers to help maintain quality and so
much more.
5.9 software reliability

Software Reliability means Operational reliability. It is described as the ability of

a system or component to perform its required functions under static conditions for
a specific period.

Software reliability is also defined as the probability that a software system fulfills
its assigned task in a given environment for a predefined number of input cases,
assuming that the hardware and the input are free of error.

Software Reliability is an essential connect of software quality, composed with

functionality, usability, performance, serviceability, capability, installability,
maintainability, and documentation. Software Reliability is hard to achieve because
the complexity of software turn to be high. While any system with a high degree of
complexity, containing software, will be hard to reach a certain level of reliability,
system developers tend to push complexity into the software layer, with the speedy
growth of system size and ease of doing so by upgrading the software.

For example, large next-generation aircraft will have over 1 million source lines of
software on-board; next-generation air traffic control systems will contain between
one and two million lines; the upcoming International Space Station will have over
two million lines on-board and over 10 million lines of ground support software;
several significant life-critical defense systems will have over 5 million source lines
of software. While the complexity of software is inversely associated with software
reliability, it is directly related to other vital factors in software quality, especially
functionality, capability, etc.

5.10 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 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.
Steps involved in Re-engineering:
 Inventory Analysis
 Document Reconstruction
 Reverse Engineering
 Code Reconstruction
 Data Reconstruction
 Forward Engineering
 Fig:5.10 Reengineering
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
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 which 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.
Disadvantages of Re-engineering:
 Practical limits to the extent of re-engineering.
 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.

5.11 Business process reengineering

Business process re-engineering is not just a change, but actually it is a dramatic
change and dramatic improvements. This is only achieved through overhaul the
organization structures, job descriptions, performance management, training and
the most importantly, the use of IT i.e. Information Technology.

Fig:5.11 Business Process Re-engineering

BPR projects have failed sometimes to meet high expectations. Many unsuccessful
BPR attempts are due to the confusion surrounding BPR and how it should be
performed. It becomes the process of trial and error.

Phases of BPR :
According to Peter F. Drucker, ” Re-engineering is new, and it has to be done.”
There are 7 different phases for BPR. All the projects for BPR begin with the most
critical requirement i.e. communication throughout the organization.

 Begin organizational change.

 Build the re-engineering organization.
 Identify BPR opportunities.
 Understand the existing process.
 Reengineer the process
 Blueprint the new business system.
 Perform the transformation.
Objectives of BPR :
Following are the objectives of the BPR :
  To dramatically reduce cost.
 To reduce time requirements.
 To improve customer services dramatically.
 To reinvent the basic rules of the business e.g. The airline industry.
 Customer satisfaction.
 Organizational learning.
Challenges faced by BPR process :
All the BPR processes are not as successful as described. The companies that have
start the use of BPR projects face many of the following challenges :

Resistance
 Tradition
 Time requirements
 Cost
 Job losses
Advantages of BPR :
Following are the advantages of BPR :

 BPR offers tight integration among different modules.

 It offers same views for the business i.e. same database, consistent reporting
and analysis.
 It offers process orientation facility i.e. streamline processes.
 It offers rich functionality like templates and reference models.
 It is flexible.
 It is scalable.
 It is expandable.
Disadvantages of BPR :
Following are the Disadvantages of BPR :

It depends on various factors like size and availability of resources. So, it will not fit
for every business.

5.12 software reengineering

Software Re-Engineering is the examination and alteration of a system to
reconstitute it in a new form. The principles of Re-Engineering when applied to the
software development process is called software re-engineering. It affects positively
at software cost, quality, service to the customer and speed of delivery. In Software
Re-engineering, we are improving the software to make it more efficient and
effective.
The need of 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 product 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,
new ideas hit in your mind. This makes the developers 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 here developers develop the product from its existing
stage to enhance some specific features that are brought in concern by
stakeholders or its users. Such kind of practice reduces the chances of fault
fallibility.

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

f) Optimization: This process refines the system features, functionalities and

reduces the complexity of the product by consistent optimization as maximum as
possible.

Re-Engineering cost factors:

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

 The tool support availability for engineering.
 The extent of the data conversion which is required.
 The availability of expert staff for Re-engineering.
Software Re-Engineering Activities:

1. Inventory Analysis:
Every software organisation should have an inventory of all the applications.
Inventory can be nothing more than a spreadsheet model containing information
that provides a detailed description of every active application.
By sorting this information according to business criticality, longevity, current
maintainability and other local important criteria, candidates for re-engineering
appear.
The resource can then be allocated to a candidate application for re-engineering
work.
2. Document reconstructing:
Documentation of a system either explains how it operates or how to use it.
Documentation must be updated.
It may not be necessary to fully document an application.
The system is business-critical and must be fully re-documented.
3. Reverse Engineering:
Reverse engineering is a process of design recovery. Reverse engineering tools
extract data, architectural and procedural design information from an existing
program.

4. Code Reconstructing:
To accomplish code reconstructing, the source code is analysed using a
reconstructing tool. Violations of structured programming construct are noted and
code is then reconstructed.
The resultant restructured code is reviewed and tested to ensure that no anomalies
have been introduced.
5. Data Restructuring:

Data restructuring begins with a reverse engineering activity.

Current data architecture is dissected, and the necessary data models are defined.
Data objects and attributes are identified, and existing data structure are reviewed
for quality.
6. Forward Engineering:
Forward Engineering also called as renovation or reclamation not only for recovers
design information from existing software but uses this information to alter or
reconstitute the existing system in an effort to improve its overall quality.

5.13 restructuring
Software restructuring modifies source code and/or data in an effort to make it
amenable to future changes. In general, restructuring does not modify the overall
program architecture. It tends to focus on the design details of individual modules
and on local data structures defined within modules. If the restructuring effort
extends beyond module boundaries and encompasses the software architecture,
restructuring becomes forward engineering .

Arnold defines a number of benefits that can be achieved when software is

restructured:

• Programs have higher quality—better documentation, less complexity, and

conformance to modern software engineering practices and standards.
• Frustration among software engineers who must work on the program is reduced,
thereby improving productivity and making learning easier.
• Effort required to perform maintenance activities is reduced.
• Software is easier to test and debug.

Restructuring occurs when the basic architecture of an application is solid, even

though technical internals need work. It is initiated when major parts of the software
are serviceable and only a subset of all modules and data need extensive
modification.

Code Restructuring

Code restructuring is performed to yield a design that produces the same function
but with higher quality than the original program. In general, code restructuring
techniques model program logic using Boolean algebra and then apply a series of
transformation rules that yield restructured logic. The objective is to take
"spaghetti-bowl" code and derive a procedural design that conforms to the
structured programming philosophy.

Other restructuring techniques have also been proposed for use with reengineering
tools. A resource exchange diagram maps each program module and the resources
(data types, procedures and variables) that are exchanged between it and other
modules. By creating representations of resource flow, the program architecture
can be restructured to achieve minimum coupling among modules.

Data Restructuring

Before data restructuring can begin, a reverse engineering activity called analysis of
source code must be conducted. All programming language statements that contain
data definitions, file descriptions, I/O, and interface descriptions are evaluated. The
intent is to extract data items and objects, to get information on data flow, and to
understand the existing data structures that have been implemented. This activity
is sometimes called data analysis .

Once data analysis has been completed, data redesign commences. In its simplest
form, a data record standardization step clarifies data definitions to achieve
consistency among data item names or physical record formats within an existing
data structure or file format. Another form of redesign, called data name
rationalization, ensures that all data naming conventions conform to local standards
and that aliases are eliminated as data flow through the system.

When restructuring moves beyond standardization and rationalization, physical

modifications to existing data structures are made to make the data design more
effective. This may mean a translation from one file format to another, or in some
cases, translation from one type of database to another.

5.14 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 to produce the necessary
documents for a legacy system.

Reverse Engineering Goals:

 Cope with Complexity.
 Recover lost information.
 Detect side effects.
 Synthesise higher abstraction.
 Facilitate Reuse.
Steps of Software Reverse Engineering:
Collection Information:
This step focuses on collecting all possible information (i.e., source design
documents etc.) about the software.
Examining the information:
The information collected in step-1 as studied so as to get familiar with the system.
Extracting the structure:
This step concerns with identification of program structure in the form of structure
chart where each node corresponds to some routine.
Recording the functionality:
During this step processing details of each module of the structure, charts are
recorded using structured language like decision table, etc.
Recording data flow:
From the information extracted in step-3 and step-4, set of data flow diagrams are
derived to show the flow of data among the processes.

Recording control flow:

High level control structure of the software is recorded.
Review extracted design:
Design document extracted is reviewed several times to ensure consistency and
correctness. It also ensures that the design represents the program.

Generate documentation:
Finally, in this step, the complete documentation including SRS, design document,
history, overview, etc. are recorded for future use.
Reverse Engineering Tools:
Reverse engineering if done manually would consume lot of time and human labour
and hence must be supported by automated tools. Some of tools are given below:

CIAO and CIA: A graphical navigator for software and web repositories along with a
collection of Reverse Engineering tools.
Rigi: A visual software understanding tool.
Bunch: A software clustering/modularization tool.
GEN++: An application generator to support development of analysis tools for the
C++ language.
PBS: Software Bookshelf tools for extracting and visualizing the architecture of
programs.

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

o Reverse engineering can extract design information from source code, but
the degree of abstraction, the thoroughness of the documentation, and the
degree to which tools and a human analyst work together.
o The process's directionality varies greatly.
o The sophistication of the design information that can be derived from the
source code is referred to as the abstraction level of a reverse engineering
process and the tools used to achieve it.
o Ideally, the abstraction level ought to be as high as is practical.
o The level of detail offered at an abstraction level is what is referred to as the
completeness of a reverse engineering process. The completeness typically
declines as the number of abstractions rises.
o An interaction refers to the degree to which a human is integrated with
automated technologies to produce successful reverse engineering.
o In many circumstances, interaction must rise as the abstraction level does or
completeness would suffer.
o The reverse engineering method has a one-way directionality: all knowledge
gleaned from the source code is sent to the software engineer for use in
future maintenance tasks.
 o An example of backward engineering is research on Instruments etc.

What is Reverse Engineering?

Exploring Existing Designs and Maneuvers
We are able to observe what already exists thanks to reverse engineering. This
includes any components, system, or procedures that might serve communities in
other way. Through analysis of existing products, innovation and discovery are
made possible.
Discovering Any Product Vulnerabilities
Reverse engineering helps in identifying product flaws, just as in the prior step. This
is done to protect the users of the product's safety and wellbeing. An issue should
ideally come up in the research stage rather than the distribution stage.
Inspiring Creative Minds with Old Ideas
Last but not least, reverse engineering provides a way for innovative design. An
engineer may come upon a system during the process that could be valuable for a
totally unrelated project. This demonstrates how engineering links tasks to prior
knowledge.
Creative a Reliable CAD Model for Future Reference
The majority of reverse engineering procedures include creating a fully functional
CAD file for future use. In order to inspect the part digitally in the event that
problems develop later, a CAD file is made. This type of technology has improved
product expressiveness and engineering productivity.
Bringing Less Expensive and More Efficient Products to the Market
The basic objective of reverse engineering is to guide engineers toward success and
innovation. Reduced manufacturing costs and maximum product efficacy are
necessary for succeeding.
Reconstructing a Product that is Outdated
Understanding the product itself is a crucial component of redesigning an existing
product. Working out the quirks in an antiquated system with the help of reverse
engineering gives us the visual. The most crucial factor in this procedure is quality.
S.N
O Forward Engineering Reverse Engineering
In forward engineering, the application In reverse engineering or backward
are developed with the given engineering, the information are
1. requirements. collected from the given application.
Forward Engineering is a high Reverse Engineering or backward
2. proficiency skill. engineering is a low proficiency skill.
While Reverse Engineering or
Forward Engineering takes more time backward engineering takes less time
3. to develop an application. to develop an application.
4. The nature of forward engineering is The nature of reverse engineering or
 Prescriptive. backward engineering is Adaptive.
In reverse engineering, production is
In forward engineering, production isstarted by taking the existing
5. started with given requirements. products.
The example of forward engineering is
the construction of electronic kit, An example of backward engineering
6. construction of DC MOTOR , etc. is research on Instruments etc.

Table:5.15 Differences between forward and reverse engineering