RISK, QUALITY MANAGEMENT AND

REENGINEERING

UNIT-5

Prof. Dr. M. Subramaniam

RISK, QUALITY MANAGEMENT
AND REENGINEERING
 Risk and Quality Management:
 Reactive and Proactive risk strategies,
 Software risks,
 Risk Mitigation Monitoring and Management (RMMM),
 RMMM plan,
 Software quality factors,
 Defect Amplification Model,
 Formal Technical Reviews (FTR),
 Software Quality Assurance (SQA)-Tasks, Goals and Metrics;
 Software reliability.
 Reengineering:
 Introduction,
 Business Process Reengineering (BPR),
 Software Reengineering,
 Restructuring,
 Reverse engineering, 2
 Forward engineering.
RISK MANAGEMENT
 Introduction
 Risk identification
 Risk projection (estimation)
 Risk mitigation, monitoring, and
management

3
DEFINITION OF RISK
 A risk is a potential problem – it might happen and it
might not
 Conceptual definition of risk
 Risk concerns future happenings
 Risk involves change in mind, opinion, actions, places, etc.
 Risk involves choice and the uncertainty that choice entails
 Two characteristics of risk
 Uncertainty – the risk may or may not happen, that is, there are
no 100% risks (those, instead, are called constraints)
 Loss – the risk becomes a reality and unwanted consequences
or losses occur

4
RISKCATEGORIZATION – APPROACH #1
 Project risks
 They threaten the project plan
 If they become real, it is likely that the project schedule will slip
and that costs will increase
 Technical risks
 They threaten the quality and timeliness of the software to be
produced
 If they become real, implementation may become difficult or
impossible
 Business risks
 They threaten the viability of the software to be built
 If they become real, they jeopardize the project or the product
5
RISKCATEGORIZATION – APPROACH #1 (CONTINUED)
 Sub-categories of Business risks
 Market risk – building an excellent product or system that
no one really wants
 Strategic risk – building a product that no longer fits into
the overall business strategy for the company
 Sales risk – building a product that the sales force doesn't
understand how to sell
 Management risk – losing the support of senior
management due to a change in focus or a change in people
 Budget risk – losing budgetary or personnel commitment

6
RISKCATEGORIZATION – APPROACH #2
 Known risks
 Those risks that can be uncovered after careful evaluation of the
project plan, the business and technical environment in which
the project is being developed, and other reliable information
sources (e.g., unrealistic delivery date)
 Predictable risks
 Those risks that are extrapolated from past project experience
(e.g., past turnover)
 Unpredictable risks
 Those risks that can and do occur, but are extremely difficult to
identify in advance

7
REACTIVE VS. PROACTIVE RISKSTRATEGIES
 Reactive risk strategies
 "Don't worry, I'll thinkof something"
 The majority of software teams and managers rely on this
approach
 Nothing is done about risks until something goes wrong
 The team then flies into action in an attempt to correct the problem
rapidly (fire fighting)
 Crisis management is the choice of management techniques
 Proactive risk strategies
 Steps for risk management are followed (see next slide)
 Primary objective is to avoid risk and to have a contingency plan
in place to handle unavoidable risks in a controlled and effective
manner
8
STEPSFOR RISK MANAGEMENT
1) Identify possible risks; recognize what can go wrong
2) Analyze each risk to estimate the probability that it
will occur and the impact (i.e., damage) that it will do
if it does occur
3) Rank the risks by probability and impact
- Impact may be negligible, marginal, critical, and catastrophic
4) Develop a contingency plan to manage those risks
having high probability and high impact

9
RISKIDENTIFICATION

10
BACKGROUND
 Risk identification is a systematic attempt to specify threats to the
project plan
 By identifying known and predictable risks, the project manager
takes a first step toward avoiding them when possible and
controlling them when necessary
 Generic risks
 Risks that are a potential threat to every software project
 Product-specific risks
 Risks that can be identified only by those a with a clear understanding
of the technology, the people, and the environment that is specific to
the software that is to be built
 This requires examination of the project plan and the statement of
scope
 "What special characteristics of this product may threaten our project
plan?"
11
RISKITEM CHECKLIST
 Used as one way to identify risks
 Focuses on known and predictable risks in specific
subcategories (see next slide)
 Can be organized in several ways
 Alist of characteristics relevant to each risk subcategory
 Questionnaire that leads to an estimate on the impact of each
risk
 A list containing a set of risk component and drivers and their
probability of occurrence

12
KNOWN AND PREDICTABLERISKCATEGORIES
 Product size – risks associated with overall size of the software
to be built
 Business impact – risks associated with constraints imposed by
management or the marketplace
 Customer characteristics – risks associated with
sophistication of the customer and the developer's ability to
communicate with the customer in a timely manner
 Process definition – risks associated with the degree to which
the software process has been defined and is followed

13
KNOWN AND PREDICTABLERISKCATEGORIES
 Development environment – risks associated with
availability and quality of the tools to be used to build the project
 Technology to be built – risks associated with complexity of
the system to be built and the "newness" of the technology in the
system
 Staff size and experience – risks associated with overall
technical and project experience of the software engineers who will
do the work

14
QUESTIONNAIREON PROJECTRISK
1) Have top software and customer managers formally
committed to support the project?
2) Are end-users enthusiastically committed to the
project and the system/product to be built?
3) Are requirements fully understood by the software
engineering team and its customers?
4) Have customers been involved fully in the definition
of requirements?
5) Do end-users have realistic expectations?
6) Is the project scope stable?
15
QUESTIONNAIREON PROJECTRISK (CONTINUED)
7) Does the software engineering team have the right
mix of skills?
8) Are project requirements stable?
9) Does the project team have experience with the
technology to be implemented?
10) Is the number of people on the project team
adequate to do the job?
11) Do all customer/user constituencies agree on the
importance of the project and on the requirements
for the system/product to be built?
16
RISKCOMPONENTSAND DRIVERS
 The project manager identifies the risk drivers that affect the
following risk components
 Performance risk - the degree of uncertainty that the product will
meet its requirements and be fit for its intended use
 Cost risk - the degree of uncertainty that the project budget will be
maintained
 Support risk - the degree of uncertainty that the resultant software
will be easy to correct, adapt, and enhance
 Schedule risk - the degree of uncertainty that the project schedule
will be maintained and that the product will be delivered on time
 The impact of each risk driver on the risk component is divided into
one of four impact levels
 Negligible, marginal, critical, and catastrophic
 Risk drivers can be assessed as impossible, improbable, probable,
and frequent

17
RISKPROJECTION (ESTIMATION)

18
BACKGROUND
 Risk projection (or estimation) attempts to rate each risk
in two ways
 The probability that the risk is real
 The consequence of the problems associated with the risk,
should it occur
 The project planner, managers, and technical staff
perform four risk projection steps (see next slide)
 The intent of these steps is to consider risks in a manner
that leads to prioritization
 Be prioritizing risks, the software team can allocate
limited resources where they will have the most impact

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

20
CONTENTSOFA RISKTABLE
 A risk table provides a project manager with a simple technique for
riskprojection
 It consists of five columns
 RiskSummary – short description of the risk
 RiskCategory – one of seven risk categories
 Probability – estimation of risk occurrence based on group input
 Impact – (1) catastrophic (2) critical (3) marginal (4) negligible
 RMMM – Pointer to a paragraph in the Risk Mitigation, Monitoring,
and Management Plan

Risk Summary Risk Category Probability Impact (1-4) RMMM

21
DEVELOPINGA RISKTABLE
 List all risks in the first column (by way of the help of the
riskitem checklists)
 Markthe category of each risk
 Estimate the probability of each risk occurring
 Assess the impact of each risk based on an averaging of
the four risk components to determine an overall impact
value (See next slide)
 Sort the rows by probability and impact in descending
order
 Draw a horizontal cutoff line in the table that indicates
the risks that will be given further attention
22
ASSESSING RISKIMPACT
 Three factors affect the consequences that are likely if a risk does
occur
 Its nature – This indicates the problems that are likely if the risk
occurs
 Its scope – This combines the severity of the risk (how serious was it)
with its overall distribution (how much was affected)
 Its timing – This considers when and for how long the impact will be
felt
 The overall risk exposure formula isRE= P xC
 P= the probability of occurrence for a risk
 C= the cost to the project should the risk actually occur
 Example
 P = 80% probability that 18 of 60 software components will have to be
developed
 C= Total cost of developing 18 components is $25,000
 RE= .80 x $25,000 = $20,000
23
RISK MITIGATION, MONITORING, AND MANAGEMENT

24
BACKGROUND
 An effective strategy for dealing with risk must consider
three issues
(Note: these are not mutually exclusive)
 Risk mitigation (i.e., avoidance)
 Risk monitoring
 Risk management and contingency planning
 Risk mitigation (avoidance) is the primary strategy and is
achieved through a plan
 Example: Risk of high staff turnover (see next slide)

25
BACKGROUND (CONTINUED)
 Strategy for Reducing Staff Turnover
❑ Meet with current staff to determine causes for turnover (e.g., poor
working conditions, low pay, competitive job market)
❑ Mitigate those causes that are under our control before the project
starts
❑ Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave
❑ Organize project teams so that information about each development
activity is widely dispersed
❑ Define documentation standards and establish mechanisms to ensure
that documents are developed in a timely manner
❑ Conduct peer reviews of all work (so that more than one person is "up
to speed")
❑ Assign a backup staff member for every critical technologist
26
BACKGROUND (CONTINUED)
 During risk monitoring, the project manager monitors
factors that may provide an indication of whether a risk
is becoming more or less likely
 Risk management and contingency planning assume
that mitigation efforts have failed and that the risk has
become a reality
 RMMM steps incur additional project cost
 Large projects may have identified 30 – 40 risks
 Riskis not limited to the software project itself
 Risks can occur after the software has been delivered to the
user
27
BACKGROUND (CONTINUED)
 Software safety and hazard analysis
 These are software quality assurance activities that focus on the
identification and assessment of potential hazards that may
affect software negatively and cause an entire system to fail
 If hazards can be identified early in the software process,
software design features can be specified that will either
eliminate or control potential hazards

28
THERMMM PLAN
 The RMMM plan may be a part of the software development plan
or may be a separate document
 Once RMMM has been documented and the project has begun, the
riskmitigation, and monitoring steps begin
 Riskmitigation is a problem avoidance activity
 Risk monitoring is a project tracking activity
 Risk monitoring has three objectives
 To assess whether predicted risks do, in fact, occur
 To ensure that risk aversion steps defined for the risk are being
properly applied
 To collect information that can be used for future risk analysis
 The findings from risk monitoring may allow the project manager to
ascertain what risks caused which problems throughout the project

29
SEVEN PRINCIPLESOF RISK MANAGEMENT
 Maintain a global perspective
 View software risks within the context of a system and the business
problem that is is intended to solve
 Take a forward-looking view
 Thinkabout risks that may arise in the future; establish contingency plans
 Encourage open communication
 Encourage all stakeholders and users to point out risks at any time
 Integrate risk management
 Integrate the consideration of riskinto the software process
 Emphasize a continuous process of risk management
 Modify identified risks as more becomes known and add new risks as better
insight is achieved
 Develop a shared product vision
 A shared vision by all stakeholders facilitates better risk identification and
assessment
 Encourage teamwork when managing risk
 Pool the skills and experience of all stakeholders when conducting risk
management activities
30
SUMMARY
 Whenever much is riding on a software project, common sense
dictates risk analysis
 Yet, most project managers do it informally and superficially, if at all
 However, the time spent in risk management results in
 Less upheaval during the project
 Agreater ability to track and control a project
 The confidence that comes with planning for problems before they
occur
 Risk management can absorb a significant amount of the project
planning effort…but the effort is worth it

31
INTRODUCTION
 SQA – Definition
 Software quality assurance is, A systematic, planned set of
actions necessary to provide adequate confidence that the
software development process or the maintenance process
of a software system product conforms to established
functional technical requirements as well as with the
managerial requirements of keeping the schedule and
operating within the budgetary confines.

32
IEEE- DEFINITION OF SQA
 A planned and systematic pattern of all actions
necessary to provide adequate confidence that an item
or product conforms to established technical
requirements.
 A set of activities designed to evaluate the process by
which the products are developed or manufactured.
Contrast with quality control.

33
IEEE- DEFINITION OF SQA
 A planned and systematic pattern of all actions
necessary to provide adequate confidence that an item
or product conforms to established technical
requirements.
 A set of activities designed to evaluate the process by
which the products are developed or manufactured.
Contrast with quality control.

34
SOFTWARE QUALITY

 Conformance to explicitly stated functional and

performance requirements, explicitly documented
development standards, and implicit characteristics that
are expected of all professionally developed software

35
THE GOALS OF SQA
 To improve software quality by appropriately monitoring
both the s/w and the development process that
produces it.
 To ensure full compliance with the established standards
and procedures for the software process
 To ensure that any inadequacies in the product, the
process or the standards are brought to management
attention so that inadequacies can be fixed.

36
SOFTWARE QUALITY ASSURANCEPLAN
 “Software Quality Assurance Plan” that specifies its goal,
the SQA tasks to be performed, the standards against
which development work is to be measured and the
procedure are organizational structure.

37
DEVELOPMENT PLAN AND QUALITY PLAN
OBJECTIVES

I. Scheduling development activities that will lead to the successful

and timely completion of the project, and estimating the
required manpower resources and budget.
II. Recruiting team members and allocating development resources
(according to activity schedules and manpower resource
requirement estimates).
III. Resolving development risks.
IV. Implementing required SQAactivities.
V. Providing management with data needed for project control.

38
ELEMENTS COMPRISING A DEVELOPMENT PLAN

 Project products, specifying “deliverables”

 Project interfaces
 Project methodology and development tools
 Software development standards and procedures
 Map of the development process
 Project milestones
 Project staff organization
 Required development facilities
 Development risks and risk management actions
 Control methods
 Project cost estimates
39
ELEMENTS OF A SOFTWARE QUALITY PLAN
 List of quality goals
 Review activities

 Software tests

 Acceptance tests for software externally developed

 Configuration management tools and procedures

40
PARTICIPATES IN THE DEVELOPMENT OF
THE PROJECT’S SOFTWARE PROCESS
DESCRIPTION

 The software team selects a process for the work to be

performed.
 The SQA group reviews the process description for
compliance with organizational policy, internal software
standards, externally imposed standards (e.g., ISO-
9001), and other parts of the software project plan.

41
REVIEWS SOFTWARE ENGINEERING
ACTIVITIES TO VERIFY COMPLIANCE WITH
THE DEFINED

 Software process. The SQA group identifies,

documents, and tracks deviations from the process and
verifies that corrections have been made.
 Audits designated software work products
to verify compliance with those defined as
part of the software process. The SQA group
reviews selected work products; identifies, documents,
and tracks deviations; verifies that corrections have
been made; and periodically reports the results of its
work to the project manager.

42
 CONTD…
 Ensures that deviations in software work
and work products are documented and
handled according to a documented
procedure. Deviations may be encountered in the
project plan, process description, applicable standards,
or technical work products.
 Records any noncompliance and reports to
senior management. Noncompliance items are
tracked until they are resolved.

43
DEFECT AMPLIFICATION AND REMOVAL
 A defect amplification model can be used to illustrate the
generation and detection of errors during the preliminary design,
detail design, and coding steps of the software engineering process.
 The model is illustrated schematically in Figure. 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.
 The box subdivisions represent each of these characteristics and
the percent of efficiency for detecting errors, a function of the
thoroughness of the review.
44
Following Figure illustrates a hypothetical example of defect amplification for a software
development process in which no reviews are conducted. Referring to the figure, each
test step is assumed to uncover and correct 50 percent of all incoming errors without
introducing any new errors (an optimistic assumption). Ten preliminary design defects
are amplified to 94 errors before testing commences. Twelve latent errors are released
to the field. Figure 8.4 considers the same conditions except that design and code
reviews are conducted as part of each development step. In this case, ten initial
preliminary design errors are amplified to 24 errors before testing commences. Only
three latent errors exist. Recalling the relative costs associated with the discovery and
correction of errors, overall cost (with and without review for our hypothetical example)
can be established. 45
46
PROJECT METRICS
 Project metrics and the indicators derived from them
are used by a project manager and a software team to
adapt project work flow and technical activities.
 The first application of project metrics on most software
projects occurs during estimation.
 Metrics collected from past projects are used as a basis
from which effort and time estimates are made for
current software work.
 As a project proceeds, measures of effort and calendar
time expended are compared to original estimates (and
the project schedule).
47
PROJECT METRICS
 The project manager uses these data to monitor and
control progress.
 As technical work commences, other project metrics
begin to have significance.
 Production rates represented in terms of pages of
documentation, review hours, function points, and
delivered source lines are measured.
 In addition, errors uncovered during each software
engineering task are tracked.

48
PROJECT METRICS
 The intent of project metrics is twofold. First, these metrics are
used to minimize the development schedule by making the
adjustments necessary to avoid delays and mitigate potential
problems and risks. Second, project metrics are used to assess
product quality on an ongoing basis and, when necessary, modify
the technical approach to improve quality.
 Another model of software project metrics suggests that every
project should measure:
 • Inputs—measures of the resources (e.g., people, environment)
required to do the work.
 • Outputs—measures of the deliverables or work products
created during the software engineering process.
 • Results—measures that indicate the effectiveness of the
deliverables.
49
FUNCTION-ORIENTED METRICS
 Function-oriented software metrics use a measure of
the functionality delivered by the application as a
normalization value,
 Function points are computed by completing the table
shown in Figure .Five information domain characteristics
are determined and counts are provided in the
appropriate table location. Information domain values
are defined in the following manner:

50
FUNCTION-ORIENTED METRICS
 Number of user inputs. Each user input that
provides distinct application oriented data to the
software is counted. Inputs should be distinguished
from inquiries, which are counted separately.
 Number of user outputs. Each user output that
provides application oriented information to the user is
counted. In this context output refers to reports,
screens, error messages, etc. Individual data items
within a report are not counted separately.

51
FUNCTION-ORIENTED METRICS
 Number of user inquiries. An inquiry is defined
as an on-line input that results in the generation of
some immediate software response in the form of an
on-line output. Each distinct inquiry is counted.
 Number of files. Each logical master file (i.e., a
logical grouping of data that may be one part of a large
database or a separate file) is counted.
 Number of external interfaces. All machine
readable interfaces (e.g., data files on storage media)
that are used to transmit information to another system
are counted.
52
FUNCTION-ORIENTED METRICS
 Once these data have been collected, a complexity value is
associated with each count. Organizations that use function
point methods develop criteria for determining whether a
particular entry is simple, average, or complex. Nonetheless,
the determination of complexity is somewhat subjective.
 To compute function points (FP), the following relationship is
used:
 FP = count total _ [0.65 + 0.01 _ Σ(Fi)] (4-1)
 where count total is the sum of all FP entries obtained from
Figure
 The Fi (i = 1 to 14) are "complexity adjustment values"
based on responses to the questions
53
SOFTWARE QUALITY FACTORS- MCCALL'S
QUALITY MODEL

 McCall’s factor 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 – as follows:
 Product operation factors: Correctness, Reliability, Efficiency,
Integrity, Usability.
 Product revision factors: Maintainability, Flexibility, Testability.
 Product transition factors: Portability, Reusability,
Interoperability.

54
MCCALL’S FACTOR MODELTREE

55
PRODUCT OPERATION FACTORS

 Correctness
 Correctness requirements are defined in a list of the
software system’s required outputs, such as a query display
of a customer’s balance in the sales accounting information
system, or the air supply as a function of temperature
specified by the firmware of an industrial control unit.
 Output specifications are usually multidimensional.

 Reliability
 Reliability requirements deal with failures to provide service.
 They determine the maximum allowed software system
failure rate, and can refer to the entire system or to one or
more of its separate functions.

56
PRODUCT OPERATION FACTORS

 Efficiency
 Deal with the hardware resources needed to perform all the
functions of the software system in conformance to all other
requirements.
 The main hardware resources to be considered are the
computer’s processing capabilities and the data communication
capability of the communication lines.
 Deals with the time between recharging of the system’s portable
units, such as, information systems units located in portable
computers, or meteorological units placed outdoors.

57
PRODUCT OPERATION FACTORS

 Integrity
 Deal with the software system security, that is, requirements to
prevent access to unauthorized persons, to distinguish between
the majority of personnel allowed to see the information (“read
permit”) and a limited group who will be allowed to add and
change data (“write permit”), and so forth.
 Usability
 Deal with the scope of staff resources needed to train a new
employee and to operate the software system.

58
PRODUCT REVISION FACTORS

 Maintainability
 Maintainability requirements determine 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. This factor’s
requirements refer to the modular structure of software, the
internal program documentation, and the programmer’s
manual, among other items.
 Flexibility
 The capabilities and efforts required to support adaptive
maintenance activities are covered by the flexibility
requirements. These include the resources (i.e. in man-days)
required to adapt a software package to a variety of
customers of the same trade, of various extents of activities,
of different ranges of products and so on.
59
PRODUCT REVISION FACTORS

 Testability.
 Testability requirements deal with the testing of an
information system as well as with its operation.
 Testability requirements for the ease of testing are related to
special features in the programs that help the tester, for
instance by providing predefined intermediate results and
log files.
 Testability requirements related to software operation
include automatic diagnostics performed by the software
system prior to starting the system, to find out whether all
components of the software system are in working order and
to obtain a report about the detected faults.

60
PRODUCT TRANSITION FACTORS
 Portability
 Portability requirements tend to the adaptation of a software
system to other environments consisting of different
hardware, different operating systems, and so forth. These
requirements make it possible to continue using the same
basic software in diverse situations or to use it
simultaneously in diverse hardware and operating systems
situations.

61
PRODUCT TRANSITION FACTORS
 Reusability
 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.

62
PRODUCT TRANSITION FACTORS
 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).
 Interoperability requirements can specify the name(s) of the
software or firmware for which interface is required. They
can also specify the output structure accepted as standard in
a specific industry or applications area.

63
FORMAL TECHNICAL REVIEW (FTR)
 Formal Technical Review (FTR) is a software quality
control activity performed by software engineers.
 Objectives of formal technical review (FTR):
Some of these are:
 Useful to uncover error in logic, function and implementation for
any representation of the software.
 The purpose of FTR is to verify that the software meets specified
requirements.
 To ensure that software is represented according to predefined
standards.
 It helps to review the uniformity in software that is development in
a uniform manner.
 To makes the project more manageable.
64
FORMAL TECHNICAL REVIEW (FTR)
 In addition, the purpose of FTR is to enable junior
engineer to observer the analysis, design, coding and
testing approach more closely.
 FTR also works to promote back up and continuity
become familiar with parts of software they might not
have seen otherwise.
 Actually, FTR is a class of reviews that include
walkthroughs, inspections, round robin reviews and
other small group technical assessments of software.
 Each FTR is conducted as meeting and is considered
successfully only if it is properly planned, controlled and
attended.
65
THE REVIEW MEETING:
 Each review meeting should be held considering the
following constraints-
 Involvement of people:
 Between 3, 4 and 5 people should be involve in the review.
 Advance preparation should occur but it should be very short
that is at the most 2 hours of work for every person.
 The short duration of the review meeting should be less than
two hour. Gives these constraints, it should be clear that an
FTR focuses on specific (and small) part of the overall
software.

66
THE REVIEW MEETING:
 At the end of the review, all attendees of FTR must
decide what to do.
 Accept the product without any modification.

 Reject the project due to serious error (Once corrected,

another app need to be reviewed), or
 Accept the product provisional (minor errors are
encountered and are should be corrected, but no
additional review will be required).
 The decision was made, with all FTR attendees
completing a sign-of indicating their participation in the
review and their agreement with the findings of the
67
review team.
REVIEW REPORTING AND RECORD
KEEPING :-

 During the FTR, the reviewer actively records all issues

that have been raised.
 At the end of the meeting all these issues raised are
consolidated and a review list is prepared.
 Finally, a formal technical review summary report is
prepared.
 It answers three questions :-
 What was reviewed ?
 Who reviewed it ?
 What were the findings and conclusions ?

68
REVIEW GUIDELINES :-
 Guidelines for the conducting of formal technical reviews should be
established in advance. These guidelines must be distributed to all
reviewers, agreed upon, and then followed. A review that is
unregistered can often be worse than a review that does not minimum
set of guidelines for FTR.
 Review the product, not the manufacture (producer).
 Take written notes (record purpose)
 Limit the number of participants and insists upon advance preparation.
 Develop a checklist for each product that is likely to be reviewed.
 Allocate resources and time schedule for FTRs in order to maintain time
schedule.
 Conduct meaningful training for all reviewers in order to make reviews effective.
 Reviews earlier reviews which serve as the base for the current review being
conducted.
 Set an agenda and maintain it.
 Separate the problem areas, but do not attempt to solve every problem notes.
 Limit debate and rebuttal.

69
SOFTWARERELIABILITY
 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 fulfils 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.

70
SOFTWARERELIABILITY
 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.
71
SOFTWARE RE-ENGINEERING
 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.
72
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.

73
SOFTWARE RE-ENGINEERING
 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.

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

75
 CONTD…
 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. 76
 CONTD…
 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.

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

78
SOFTWARE RE-ENGINEERING
ACTIVITIES

79
INVENTORY ANALYSIS
 Every software organisation should have an inventory of
all the applications.
 Inventory can be nothing more than a spread-sheet 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.

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

81
REVERSE ENGINEERING
 Reverse engineering is a process of design recovery.
 Reverse engineering tools extract data, architectural and
procedural design information from an existing program.

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

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

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

85
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

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

88
SOFTWARE REVERSE ENGINEERING

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

89
REVERSE ENGINEERING GOALS
 Cope with Complexity.
 Recover lost information.

 Detect side effects.

 Synthesise higher abstraction.

 Facilitate Reuse.

90
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.
91
STEPS OF SOFTWARE REVERSE
ENGINEERING
 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 exA tracted in step-3 and step-4, set of
data flow diagrams are derived to show the flow of data
among the processes.
92
STEPS OF SOFTWARE REVERSE
ENGINEERING
 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.

93
FORWARD ENGINEERING
 Forward Engineering is a method of creating or making
an application with the help of the given requirements.
 Forward engineering is also known as Renovation and
Reclamation.
 Forward engineering is required high proficiency skills.
 It takes more time to construct or develop an
application.
 Forward engineering is a technique of creating high-
level models or designs to make in complexities and low-
level information.

94
FORWARD ENGINEERING
 Therefore this kind of engineering has completely
different principles in numerous package and
information processes.
 Forward Engineering applies of all the software
engineering process which contains SDLC to recreate
associate existing application.
 It is near to full fill new needs of the users into re-
engineering.

95
CHARACTERISTICS
OF FORWARD ENGINEERING

 Forward engineering is a variety of engineering that has

different principles in numerous package and
information processes.
 Forward engineering is vital in IT as a result of it
represents the ‘normal’ development process.
 Forward engineering deals with the conversion of
business processes, services, and functions into
applications.
 In this method business model is developed first.
Then, a top-to-down approach is followed to
urge the package from the model developed.
96
CHARACTERISTICS
OF FORWARD ENGINEERING

 Forward engineering tools are accustomed move from

implementation styles and logic to the event of supply
code.
 It essentially permits the user to develop a business
model which may then be translated into data system
components.
 These tools basically follow the top-to down approach.
System creator and visual Analyst is a forward
engineering CASEtool.

97
DIFFERENCE BETWEEN FORWARD AND
REVERSE ENGINEERING
S.N
Forward Engineering Reverse Engineering
O
In forward engineering, the application In reverse engineering or backward
1. are developed with the given engineering, the information are collected
requirements. from the given application.
Forward Engineering is a high proficiency Reverse Engineering or backward
2.
skill. engineering is a low proficiency skill.
While Reverse Engineering or backward
Forward Engineering takes more time to
3. engineering takes less time to develop an
develop an application.
application.
The nature of forward engineering is The nature of reverse engineering or
4.
Prescriptive. backward engineering is Adaptive.
In reverse engineering, production is
In forward engineering, production is
5. started by taking the products existing
started with given requirements.
products.
98
The example of forward engineering is
An example of backward engineering is
6. the construction of electronic kit,
research on Instruments etc.
construction of DC MOTOR , etc.