UNIT-5

SOFTWARE
MAINTENANCE
 INTRODUCTION
• Software maintenance is the last stage of s/w life
cycle .
• After the product has been released, the
maintenance phase keeps the s/w up to date with
environment changes & changing user
requirements.
• It consumes about 40-70% of the cost of the entire
life cycle.
• Maintenance can only happen efficiently if the
earlier phases are done properly.
SOFTWARE AS AN EVOLUTIONARY ENTITY

• Software Maintenance includes error correction,

enhancements of capabilities, deletion of obsolete
capabilities & optimization.
• As changes cannot be avoided, we should develop
mechanism for evaluating, controlling & making
modifications.
• Hence any work done to change the s/w after its
operation is considered to be a maintenance work.
• The term “evolution” has been used with reference to
s/w since 1960’s to signify the growth dynamics of s/w.
 WHAT IS SOFTWARE MAINTENANCE
• Software Maintenance is a very broad activity that includes
error corrections, enhancements of capabilities, deletion of
obsolete capabilities, and optimization.

• As per IEEE, it is a modification of s/w product after delivery

to correct faults, to improve performance or other attributes
or to adapt the product to a modified environment.

• As per ISO, it is a set of activities performed when s/w

undergoes modifications to code & associated
documentation due to a problem or the need for
improvement or adaptation.
 NEED FOR MAINTENANCE
• Software Maintenance is needed for:-
– Correct errors.
– Change in user requirement with time.
– Changing hardware/software environment.
– To improve system efficiency
– To optimize the code to run faster
– To modify the components.
– To eliminate any unwanted side effects.
Thus, the maintenance is needed to ensure that the
system continues to satisfy user requirements.
 AIM of Software Maintenance
• To correct errors.
• To enhance the s/w by changing its functions.
• To update the s/w.
• To adapt the s/w to cope with changes in the
environment.
CATEGORIES OF SOFTWARE MAINTENANCE
• There are four types of software maintenance:

1. Corrective maintenance :
This refer to modifications initiated by defects in the software.

2. Adaptive maintenance:
It includes modifying the software to match changes in the ever changing
environment.

3. Perfective maintenance:
It means improving processing efficiency or performance, or restructuring
the software to improve changeability. This may include enhancement of
existing system functionality, improvement in computational efficiency
etc.
4. Preventive maintenance:
It is the process by which we prevent our
system from being obsolete. It involves the
concept of reengineering & reverse
engineering in which an old system with an
old technology is re-engineered using new
technology. This maintenance prevents the
system from dying out.
SOFTWARE MAINTENANCE

Fig: Distribution of maintenance effort

 Problems during Maintenance
• Often the program is written by another
person or group of persons.
• Often the program is changed by person who
did not understand it clearly.
• Program listings are not structured.
• High staff turnover.
• Information gap.
• Systems are not designed for change.
 Potential Solutions to Maintenance
Problems

• Budget and effort reallocation

• Complete replacement of the system
• Maintenance of existing system
The Maintenance Process
• Program Understanding
The first phase consists of analyzing the program in order to
understand.

• Generating Particular Maintenance Proposal

The second phase consists of generating a particular maintenance
proposal to accomplish the implementation of the maintenance
objective.

• Ripple Effect
The third phase consists of accounting for all of the ripple effect
as a consequence of program modifications.
• Modified Program Testing
The fourth phase consists of testing the modified program to
ensure that the modified program has at least the same
reliability level as before.

• Maintainability
Each of these four phases and their associated software
quality attributes are critical to the maintenance process. All
of these factors must be combined to form maintainability.
How easy is to maintain a program depends on how easy is
to understand it.
 COST OF MAINTENANCE
• To estimate maintenance cost, two models
have been proposed. They are:
1. Belady and Lehman model
2. Boehm model
 Belady and Lehman Model

This model indicates that the effort and cost can increase
exponentially if poor Software development approach is used &
the person or group that used the approach is no longer available
to perform maintenance. The basic equation is given by:

Where,
M : Total effort expended
P : Productive effort that involves analysis, design, coding, testing and
evaluation.
K : An empirically determined constant.
c : Complexity measure due to lack of good design and documentation.
d : Degree to which maintenance team is familiar with the software.
Example
Solution
Boehm Model
Example
Solution
 Introduction to Re-engineering
• Re-engineering means to re-implement
systems to make more maintainable.
• In this, the functionality & architecture of the
system remains the same but it includes
redocumenting, organizing, modifying &
updating the system.
• When re-engineering principles are applied to
business process then it is called Business
Process Reengineering (BPR).
 Steps in Re-engineering
• The steps involved in re-engineering are-
– Goal setting
– Critical analysis of existing scenario such as
process, task, design, methods etc.
– Identifying the problems & solving them by new
innovative thinking.

In other words, it uses new technology to gain a

significant breakthrough improvement.
 Software RE-Engineering
• The principles of re-engineering when applied
to s/w development processes , it is called s/w
reengineering.
• Acc to IBM user group guide, “the process of
modifying the internal mechanism of a system
or program or the data structures of a system
or program without changing its
functionality”.
• Software re-engineering is concerned with
taking existing legacy systems and re-
implementing them to make them more
maintainable.
• The critical distinction between re-engineering
and new software development is the starting
point for the development as shown in Fig
• The following suggestions may be useful for the modification
of the legacy code:

– Study code well before attempting changes

– Concentrate on overall control flow and not coding
– Heavily comment internal code.
– Create Cross References
– Build Symbol tables
– Use own variables, constants and declarations to localize the effect
– Keep detailed maintenance document
– Use modern design techniques
 Source Code Translation
1. Hardware platform update: The organization may wish to
change its standard hardware platform. Compilers for the
original language may not be available on the new platform.

2. Staff Skill Shortages: There may be lack of trained

maintenance staff for the original language. This is a particular
problem where programs were written in some non standard
language that has now gone out of general use.

3. Organizational policy changes: An organization may decide to

standardize on a particular language to minimize its support
software costs. Maintaining many versions of old compilers
can be very expensive.
 Program Restructuring
1. Control flow driven restructuring: This involves the
imposition of a clear control structure within the
source code and can be either inter modular or
intra modular in nature.

2. Efficiency driven restructuring: This involves

restructuring a function or algorithm to make it
more efficient. A simple example is the replacement
of an IF-THEN-ELSE-IF-ELSE construct with a CASE
construct.
3. Adaption driven restructuring: This involves
changing the coding style in order to adapt
the program to a new programming language
or new operating environment, for instance
changing an imperative program in PASCAL
into a functional program in LISP.
 Advantages of Re-engineering
• Lower costs
• Lower risks
• Better use of existing staff
• Incremental development
 Disadvantages of Re-engineering
• Major architectural changes or radical
reorganizing of the system data management
has to be done manually.
• Re-engineered system is not likely to be as
maintainable as a new system developed
using modern s/w engineering methods.
 Reverse Engineering
• Reverse engineering is the process followed in
order to find difficult,
unknown and hidden
information about a
software system.
• Software reverse engineering is the process of
recovering the design and the requirements
specification of a product from an analysis of
its code.
• The purpose of reverse engineering is to
facilitate maintenance work by improving the
understandability of a system and to produce
the necessary documents for a legacy system.
 Scope and Tasks
• The areas where reverse engineering is applicable
include (but not limited to):

1. Program comprehension
2. Redocumentation and/ or document generation
3. Recovery of design approach and design details at any
level of abstraction
4. Identifying reusable components
5. Identifying components that need restructuring
6. Understanding high level system description
The reverse engineering process is shown in fig. The
process starts with an analysis phase. During this
phase, the system is analyzed using automated tools
to discover its structure. They add information to this,
which they have collected by understanding the
system. This information is maintained as a directed
graph that is linked to the program source code.

Information store browsers are used to compare the

graph structure & the code & to annotate the graph
with extra information. Documents of various types
such as program & data structure diagrams &
traceability matrices. Traceability matrices show where
entities in the system are defined and referenced.
 Reverse Engineering tasks
Reverse Engineering encompasses a wide array of tasks related to
understanding and modifying software system. This array of tasks can be
broken into a number of classes. Few of these are discussed below:

1. Mapping between application and program domains

2.Mapping between concrete and abstract levels
3. Rediscovering high level structures
4. Finding missing links between program syntax
and semantics
5. To extract reusable component
 Levels of Reverse Engineering
• Reverse Engineers detect low level
implementation constructs and replace them
with their high level counterparts.
• The process eventually results in an
incremental formation of an overall
architecture of the program.
Fig: Levels of abstraction
• Redocumentation
Redocumentation is the recreation of a semantically equivalent
representation within the same relative abstraction level.

• Design recovery
Design recovery entails identifying and extracting meaningful
higher level abstractions beyond those obtained directly from
examination of the source code. This may be achieved from a
combination of code, existing design documentation, personal
experience, and knowledge of the problem and application
domains.
Advantages of Reverse Engineering
• It concentrates on recovering the lost
information from the programs
• It provides the abstract information from the
detailed source code implementation.
• It improves system documentation that is
either incomplete or out of date.
• It detects the adverse effects of modification
in the s/w system.
 Difference between Reverse, Forward &
Reengineering
• Reverse Engineering
It performs transformation from a large abstraction
level to a higher one.
• Forward Engineering
It performs transformation from a higher abstraction
level to a lower one.
• Reengineering
It transforms an existing s/w system into a new but
more maintainable system.
The Constructive Cost Model (COCOMO)

It is a hierarchy of software costs estimation models, which include basic, intermediate &
detailed sub models.
 BASIC MODEL

It aims at estimating small

to medium sized software
projects.

Three modes of
development are
considered in this model:
organic, semidetached and
embedded.
Comparison of three COCOMO models
 Basic model
• Basic COCOMO model takes the form –

where E is effort applied in Person-Months

and D is the development time in months and
the coefficients ab, bb, cb, db are given in table.
Basic COCOMO Coefficients
Example
Solution
Example
Solution
 Intermediate Model
• The basic model allowed for a quick and rough
estimate, but it resulted in a lack of accuracy.

• Boehm introduced an additional set of 15 predictors

called cost drivers in the intermediate model to take
account of the software development environment.

• Cost drivers are used to adjust the nominal cost of a

project to the actual project environment, hence
increasing the accuracy of the estimate.
The cost drivers are grouped into four
categories: -
Multiplier Values for Effort Calculation
The multiplying factors for all 15 cost drivers are multiplied to get
the effort adjustment factor(EAF).
 Detailed COCOMO Model
• It offers a means for processing all the project characteristics to
construct a s/w estimate. The detailed model introduces two more
capabilities:

– Phase sensitive effort multiplier: Some phases are more

affected than others by factors defined by the cost drivers. The
detailed model provides a set of phase sensitive effort multipliers
for each cost driver. This helps in determining the manpower
allocation for each phase of the project.

– Three-level product hierarchy: Three product levels are

defined. These are module, subsystem and system levels.
The ratings of the cost drivers are done at appropriate level, i.e
the level at which it is most susceptible to variation.
 CONFIGURATION MANAGEMENT
ACTIVITIES

• The software may be considered as configurations of software

components. These software components are released in the
form of executable code whereas supplier company keeps the
source code. This source code is the representation of an
executable equivalent.

• Source code can be modified without any effect upon

executable versions in use. If strict controls are not kept, the
source code which is the exact representation of a particular
executable version may no longer exist.

• The means by which the process of software development and

maintenance is controlled is called configuration management.
 Goals of SCM
• Goals of SCM are-
– SCM activities are planned.
– Changes to identified software work products are
controlled.
– Affected groups & individuals are informed of the
status and content of s/w baselines.
– Selected s/w work products are identified,
controlled and available.
 Functions of SCM

• Identification

• Change Control

• Status Accounting

• Auditing
• Identification -identifies those items whose configuration needs to be
controlled, usually consisting of hardware, software, and documentation.

• Change Control - establishes procedures for proposing or requesting

changes, evaluating those changes for desirability, obtaining authorization
for changes, publishing and tracking changes, and implementing changes.
This function also identifies the people and organizations who have
authority to make changes at various levels.

• Status Accounting -is the documentation function of CM. Its primary

purpose is to maintain formal records of established configurations and
make regular reports of configuration status. These records should
accurately describe the product, and are used to verify the configuration
of the system for testing, delivery, and other activities.

• Auditing -Effective CM requires regular evaluation of the configuration. This

is done through the auditing function, where the physical and functional
configurations are compared to the documented configuration. The
purpose of auditing is to maintain the integrity of the baseline and release
configurations for all controlled products
 Following documents are required -
• Project plan
• SRS document
• Software design description document
• Source code listing
• Test plans/ procedures/ test cases.
• User manuals
• All the components of the system’s configuration are
recorded along with all relationships & dependencies
b/w them.
• Any change/addition, deletion or modification must be
recorded and its effect upon the rest of the system’s
components should be checked.
• After a change has been made, a new configuration is
recorded. There is need to know who is responsible for
every procedure & process along the way.
• It is a management task both to assign these
responsibilities and to conduct audit to see that they
are carried out.
 Principal Activities of SCM
• Configuration mgmt is carried out through two
principal activities:

– Configuration identification involves deciding

which parts of the system should be kept track of.

– Configuration control ensures that changes to a

system happen smoothly.
 Change Control Process

• Change control involves procedures and tools to bring order in

the change process. Larger projects have a formal change
control board (CCB), whose responsibility is to review and
approve or disapprove change.

• It is the CCB responsibility to provide the mechanism to

maintain orderly change processes. For a large software
engineering project, uncontrolled change rapidly leads to
chaos. For such projects, change control combines human
procedures & automated tools to provide a mechanism for the
control of change.
Goals of Change Control Process
– Offer a mechanism for accepting changes that enhance the
product while rejecting those that degrade it.
– Offer revision control & backup safety for work products
during their formative development.
– Facilitate changes to work products during their initial
formative development while avoiding unnecessary overhead
or formality.
– Permit for formal acceptance of work products after their initial
formative development has been finished.
– Permit all parties materially affected by proposed changes to
accepted work products to assess the resource, schedule or
product impact of the changes.
– Notify interested parties on the periphery of development
regarding change proposals, their assessed impact and
whether the changes were approved or rejected.
 Software Version Control
• During software maintenance at least two
versions of the software system are produced ,
one being the old version and the other one
or more new versions.
• As a s/w system comprises of s/w components,
there will also be two or more versions of each
component that has been changed. Thus, the
software maintenance team has to cope with
multiple versions of the software
• A version control tool is the first stage towards being able to manage
multiple versions. Once, it is in place, a detailed record of every version
of the software must be kept. This comprises the-
– Name of each source code component, including the variations and revisions
– The versions of the various compilers and linkers used
– The name of the software staff who constructed the component
– The date and the time at which it was constructed

• A version control system is a repository of files . Every change made to

the source is tracked, along with who made the change, why they
made it and references to problems fixed or enhancements
introduced, by the change.

• User’s may wish to compare today’s version of some s/w with

yesterday’s version or last year’s version. Since version control system
keep track of every version of the s/w, this becomes a straightforward
task.
• Version control activity is divided in four sub-
activities:
1. Identifying new versions
2. Numbering scheme : It will have the
following format
Version X.Y.Z…
3. Visibility
4. Tracking
1. Identifying new versions: A s/w configuration item (SCI) will
get a new version no. when there has been a change to its
established baseline. Each previous version will be stored in a
corresponding directory like version 0, version1, version2 etc.

2. Numbering scheme: It will have the following format

Version X.Y.Z…

• (X) denotes the entire SCI. Therefore, changes made to the

entire configuration item, or changes large enough to
warrant a completely new release of the item, will cause the
first digit to increase.
• (Y) denotes the component of SCI. this digit will sequentially
increase if a change is made to a component or multiple
components.
• (Z) denotes the section of the component of a SCI. This
no. will only be visible if a component of an SCI can be
divided into individual sections. Changes made at this
level of detail will need a sequential change of third digit.

3. Visibility: the version no. can be seen either in frame or

below the title.

4. Tracking : the best way to keep track of the different

versions is with a version evolution graph.
 CASE
• CASE stands
for Computer Aided Software Engineering. It
means, development and maintenance of
software projects with help of various
automated software tools.
 CASE Tools
• Computer aided software engineering tool assist software
engineering managers & practitioners in every activity
associated with the software process.

• Thus, a CASE tool means any tool used to automate some

activity associated with software development. Many
CASE tools are available. Some of these CASE tools assist
in phase related tasks such as specification, structure
analysis, design, coding, testing etc; and others to non-
phase activities such as project management and
configuration management.
 CASE TOOLS
• CASE tools are software programs that are
designed to assist human programmers with
the complexity of the processes & the artifacts
of software engineering.
• As we know, software engineering is a
systematic approach to the development,
operations, maintenance & retirement of
software.
• Software engineering mainly includes the
following processes, which may be aided by
CASE:-
– Translation of user needs into software
requirements.
– Transformation of software requirements into design
specifications.
– Implementation of design into code.
– Testing of the code for the operational use.
– Documentation.
 Reasons for using CASE Tools
• The primary reason for using a CASE Tool are:
– To increase productivity: Automation of various activities of system
development and management processes increases productivity of
the development team.
– To help produce better quality software at low maintenance cost:
Use of CASE tools makes the software easy to maintain and hence
reduce the maintenance costs.

Other major benefits include the following-

– Improved productivity
– Better documentation
– Reduced lifetime maintenance
– Improved accuracy
– Opportunity to non-programmers.
• Improved productivity: CASE tools provide automation &
reduce the time to complete many tasks, hence
improvements in productivity.

• Better documentation: By using CASE Tools, vast amount

of documentation are produced along the way.

• Reduced Lifetime Maintenance: As a result of better

design, better analysis and automatic code generation,
automatic testing & debugging overall system’s quality
improves. There is better documentation also. Thus, the
net effort & cost involved with maintenance is reduced.
• Improved Accuracy: CASE tools can provide ongoing
debugging & error checking which is very vital for early
defect removal, which actually played a major role in
shaping modern software.

• Opportunity to non-programmers: With the increased

movement towards object oriented technology & client
server bases, programming can also be done by people
who don’t have a complete programming background. By
using the lower case tools, it could be possible to develop
software from the initial design & analysis phase.
 Characteristics of a CASE Tool

A CASE tool must have the following characteristics in order to be used

efficiently:

• A standard methodology

• Flexibility

• Strong Integration

• Integration with testing software

• Support for reverse engineering

• On-line help
• A standard methodology: A CASE tool must support a standard software
development methodology and standard modeling techniques. In the present
scenario most of the CASE tools are moving towards UML.

• Flexibility: Flexibility in use of editors and other tools. The CASE tool must offer
flexibility and the choice for the user of editors' development environments.

• Strong Integration: The CASE tools should be integrated to support all the
stages. This implies that if a change is made at any stage, for example, in the
model, it should get reflected in the code documentation and all related design
and other documents, thus providing a cohesive environment for software
development.

• Integration with testing software: The CASE tools must provide interfaces for
automatic testing tools that take care of regression and other kinds of testing
software under the changing requirements.

• Support for reverse engineering: A CASE tools must be able to generate

complex models from already generated code.
 Categories of CASE Tools:

• Sometimes CASE tools are classified in to following categories due

to their activities:
– UPPER CASE Tools
– LOWER CASE Tools
– INTEGRATED CASE Tools

Upper CASE tools: They support the analysis and the design
phase. They include tools for analysis modeling, reports and forms
generation.

Lower CASE tools: They support the coding phase, configuration

management, etc.

Integrated CASE tools: It is known as I-CASE and also supports

analysis, design and coding phases.
Positioning of CASE tools in a Software Application development:
 Limitations of CASE tools
• The major limitations of using CASE tools are:

– Cost

– Learning Curve

– Tool mix
– Cost: Using CASE tools is a very costly affair. In fact, most firms
engaged in software development on a small scale do not invest in
CASE tools because they think that the benefits of CASE are
justifiable only in the development of large systems.

– Learning Curve: In most cases, programmer productivity may fall in

the initial phase of implementation, because user need time to learn
the technology. In fact, a CASE consulting industry has evolved to
support uses of CASE tools. The consultants offer training & on-site
services that can be crucial to accelerate the learning curve and to
the development & use of the tools.

– Tool mix: It is important to make an appropriate selection of tool mix

to get cost advantage CASE integration & data integration across all
platforms is also very important. The ability to share the results of
work done on one CASE tool with another CASE tool is perhaps the
most important type of CASE integration.
CASE Support in Software Life Cycle
• There are various types of support that CASE
provides during the different phases of a
software life cycle.

– Prototyping Support
– Structured analysis & design
– Code Generation
– Test CASE generator
Prototyping Support: The prototyping is
useful to understand the requirements of
complex software products, to market new
ideas and so on. The prototyping CASE tools
requirements are as follows:
 Define user interaction
 Define the system control flow
 Store & retrieve data required by the system
 Incorporate some processing logic
 Structured Analysis & Design: Several diagramming techniques are
used for structured analysis and structured design. The following
supports might be available from CASE tools.

• A CASE tool should support one or more of the structured analysis and
design techniques.
• It should support effortlessly drawing analysis and design diagrams.
• It should support drawing for fairly complex diagrams, preferably
through a hierarchy of levels.
• The CASE tool should provide easy navigation through the different
levels and through the design and analysis.
• The tool must support completeness and consistency checking across
the design and analysis and through all levels of analysis hierarchy.
Whenever it is possible, the system should disallow any inconsistent
operation, but it may be very difficult to implement such a feature.
Whenever there arises heavy computational load while consistency
checking, it should be possible to temporarily disable consistency
checking.
Code Generation: As far as code generation is concerned, the
general expectation of a CASE tool is quite low. A reasonable
requirement is traceability from source file to design data.
More pragmatic supports expected from a CASE tool during
code generation phase are the following:

– The CASE tool should support generation of module skeletons or

templates in one or more popular languages. It should be possible to
include copyright message, brief description of the module, author
name and the date of creation in some selectable format.
– The tool should generate records, structures, class definition
automatically from the contents of the data dictionary in one or more
popular languages.
– It should generate database tables for relational database
management systems.
– The tool should generate code for user interface from prototype
definition for X window and MS window based applications.
Test CASE Generator: The CASE tool for test
case generation should have the following
features:
– It should support both design and requirement
testing.
– It should generate test set reports in ASCII format
which can be directly imported into the test plan
document.
CASE Environment
• Although individual CASE tools are useful, the true power of a
tool set can be realized only when these set of tools are
integrated into a common framework or environment. CASE
tools are characterized by the stage or stages of software
development life cycle on which they focus. Since different tools
covering different stages share common information, it is
required that they integrate through some central repository to
have a consistent view of information associated with the
software development artifacts. This central repository is
usually a data dictionary containing the definition of all
composite and elementary data items. Through the central
repository all the CASE tools in a CASE environment share
common information among themselves. Thus a CASE
environment facilities the automation of the step-by-step
methodologies for software development. A schematic
representation of a CASE environment is shown in fig.
 Benefits of CASE
• A key benefit arising out of the use of a CASE environment is cost saving through all
development phases. Different studies carry out to measure the impact of CASE put
the effort reduction between 30% to 40%.

• Use of CASE tools leads to considerable improvements to quality. This is mainly due
to the facts that one can effortlessly iterate through the different phases of software
development and the chances of human error are considerably reduced.

• CASE tools help produce high quality and consistent documents. Since the important
data relating to a software product are maintained in a central repository,
redundancy in the stored data is reduced and therefore chances of inconsistent
documentation is reduced to a great extent.

• CASE tools have led to revolutionary cost saving in software maintenance efforts.
This arises not only due to the tremendous value of a CASE environment in
traceability and consistency checks, but also due to the systematic information
capture during the various phases of software development as a result of adhering to
a CASE environment.
Advantages and Disadvantages of CASE
Tools:
Software Risk Management
 What is risk ?

• Tomorrow’s problems are today’s risks.

“Risk is a problem that may cause some loss or

threaten the success of the project, but which
has not happened yet”.
 Types of Risks

• Development Process Risks

– are development errors, natural disasters,
disgruntled (dissatisfied) employees and poor
management objectives.

• Product Risks
– Includes Project risks, Technical risks, Business
risks
Another general categorization of risks is -

• Known Risks are those 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

• Predictable Risks are basis from past project

experience.

• Unpredictable risks can and do occur, but they are

extremely difficult to identify in advance.
 RISK ANALYSIS AND MANAGEMENT

• Risk analysis and management are a series of steps that help a software
team to understand and manage uncertainty. Many problems can plague a
software project. A risk is a potential problem – it might happen, it might
not.

• So, the key idea in risk management is not to wait for a risk to materialize
and become a problem. The objective of risk management is to ensure
that for each perceived risk , we know very well how to tackle it in
advance.

• According to the risk management guru Barry Boehm, “Risk management

focuses the project manager’s attention on those portions of the project
most likely to cause trouble”
 REACTIVE VS PROACTIVE RISK STRATEGIES

• A reactive strategy monitors the project for likely risks. Resources are
set aside to deal with them, should they become actual problems. More
commonly, the software team does nothing about risks, until something
goes wrong. Then, the team flies into action in an attempt to correct
the problem rapidly. This is often called a fire fighting mode.

• A proactive strategy begins long before technical work is initiated.

Potential risks are identified, their probability and impact are assessed,
and they are ranked by importance. Then, the software team
establishes a plan for managing risk. The primary objective is to avoid
risk, but because not all risks can be avoided, the team works to
develop a contingency plan that will enable it to respond in a controlled
and effective manner.
• Risk Identification
With the identification phase, several activities occur. The
main activities are:
– Identify risks
– Define risk attributes
– Documentation
– Communicate

• Risk Analysis
The main activities in this phase are –
– Group similar risks
– Determine risk drivers
– Determine source of risks
– Estimate risk exposure
– Evaluate against criteria
• Risk Planning
– Risk avoidance
– Risk minimization
– Risk Contingency Plans
END OF UNIT-5

****All the Best****