UNIT V

Software as an Evolutionary Entity

In software engineering, software evolution is referred to

as the process of developing, maintaining, and updating
software for various reasons. Software changes are
inevitable because there are many factors that change
during the life cycle of a piece of software.

It is a product and, at the same time, the vehicle for

delivering a product. As a product, it delivers the
computing potential embodied by computer hardware or,
more broadly, a network of computers that are accessible
by local hardware.

Some of the factors include:

• Requirement changes
• Environment changes
• Errors or security breaches
• New equipment added or removed, and finally
• Improvements to the system
Software Maintenance
Software Maintenance is the process of modifying a software product after it has been delivered to the customer. The main purpose of
software maintenance is to modify and update software applications after delivery to correct faults and to improve performance.  

Need for Maintenance – 

Software Maintenance must be performed in order to: 
• Correct faults.
• Improve the design.
• Implement enhancements.
• Interface with other systems.
• Accommodate programs so that different hardware, software, system features, and telecommunications facilities can be used.
• Migrate legacy software.
• Retire software.
• Requirement of user changes.
• Run the code fast

Purpose of Maintenance:
• Failure Avoidance
• Equipment Reliability
• Least Operating Costs
• Risk Reduction
• Maximum Production
• Defect Simulation
Challenges in Software Maintenance:

The various challenges in software maintenance are given below:

• The popular age of any software program is taken into consideration up to ten to fifteen years. As
software program renovation is open ended and might maintain for decades making it very expensive.
• Older software program’s, which had been intended to paintings on sluggish machines with much less
reminiscence and garage ability can not maintain themselves tough in opposition to newly coming more
advantageous software program on contemporary-day hardware.
• Changes are frequently left undocumented which can also additionally reason greater conflicts in future.
• As era advances, it turns into high priced to preserve vintage software program.
• Often adjustments made can without problems harm the authentic shape of the software program,
making it difficult for any next adjustments.
• There is lack of Code Comments.
Categories of Software Maintenance
Maintenance can be divided into the following: 
1. Corrective maintenance: 
Corrective maintenance of a software product may be essential
either to rectify some bugs observed while the system is in
use, or to enhance the performance of the system. 
 
2. Adaptive maintenance: 
This includes modifications and updations when the customers
need the product to run on new platforms, on new operating
systems, or when they need the product to interface with new
hardware and software. 

3. Preventive maintenance: 
This type of maintenance includes modifications and updations
to prevent future problems of the software. It goals to attend
problems, which are not significant at this moment but may
cause serious issues in future.
 
4. Perfective maintenance: 
A software product needs maintenance to support the new
features that the users want or to change different types of
functionalities of the system according to the customer
demands. 
Causes of Software Maintenance Problems

Lack of Traceability
• Codes are rarely traceable to the requirements and design
specifications.
• It makes it very difficult for a programmer to detect and correct a
critical defect affecting customer operations.
• Like a detective, the programmer pores over the program looking
for clues.
• Life Cycle documents are not always produced even as part of a
development project.
Lack of Code Comments
• Most of the software system codes lack adequate comments.
Lesser comments may not be helpful in certain situations.
Obsolete Legacy Systems
• In most of the countries worldwide, the legacy system that
provides the backbone of the nation's critical industries, e.g.,
telecommunications, medical, transportation utility services,
were not designed with maintenance in mind.
• They were not expected to last for a quarter of a century or
more!
• As a consequence, the code supporting these systems is devoid
of traceability to the requirements, compliance to design and
programming standards and often includes dead, extra and
uncommented code, which all make the maintenance task next
to the impossible.
Software Maintenance Cost Factors
There are two types of cost factors involved in software maintenance.
These are
• Non-Technical Factors
• Technical Factors

Non-Technical Factors
1. Application Domain
• If the application of the program is defined and well understood, the system
requirements may be definitive and maintenance due to changing needs
minimized.
• If the form is entirely new, it is likely that the initial conditions will be
modified frequently, as user gain experience with the system.

2. Staff Stability
• It is simple for the original writer of a program to understand and change an
application rather than some other person who must understand the
program by the study of the reports and code listing.
• If the implementation of a system also maintains that systems, maintenance
costs will reduce.
• In practice, the feature of the programming profession is such that persons
change jobs regularly. It is unusual for one user to develop and maintain an
application throughout its useful life.

3. Program Lifetime
• Programs become obsolete when the program becomes obsolete, or their
original hardware is replaced, and conversion costs exceed rewriting costs.
4. Dependence on External Environment
• If an application is dependent on its external environment, it must be modified as the climate changes.
• For example:
• Changes in a taxation system might need payroll, accounting, and stock control programs to be modified.
• Taxation changes are nearly frequent, and maintenance costs for these programs are associated with the
frequency of these changes.
• A program used in mathematical applications does not typically depend on humans changing the
assumptions on which the program is based.

5. Hardware Stability
• If an application is designed to operate on a specific hardware configuration and that configuration does
not changes during the program's lifetime, no maintenance costs due to hardware changes will be
incurred.
• Hardware developments are so increased that this situation is rare.
• The application must be changed to use new hardware that replaces obsolete equipment.
Technical Factors

Technical Factors include the following:

1. Module Independence
It should be possible to change one program unit of a
system without affecting any other unit.

2. Programming Language
Programs written in a high-level programming
language are generally easier to understand than
programs written in a low-level language.

3. Programming Style
The method in which a program is written contributes
to its understandability and hence, the ease with
which it can be modified.
4. Program Validation and Testing
• Generally, more the time and effort are spent on design validation and program testing, the fewer bugs in
the program and, consequently, maintenance costs resulting from bugs correction are lower.
• Maintenance costs due to bug's correction are governed by the type of fault to be repaired.
• Coding errors are generally relatively cheap to correct, design errors are more expensive as they may
include the rewriting of one or more program units.
• Bugs in the software requirements are usually the most expensive to correct because of the drastic design
which is generally involved.

5. Documentation
• If a program is supported by clear, complete yet concise documentation, the functions of understanding
the application can be associatively straight-forward.
• Program maintenance costs tends to be less for well-reported systems than for the system supplied with
inadequate or incomplete documentation.

6. Configuration Management Techniques

• One of the essential costs of maintenance is keeping track of all system documents and ensuring that
these are kept consistent.
• Effective configuration management can help control these costs.
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.

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

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.
• 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
CASE tool.
Difference between Forward Engineering and Reverse Engineering:  
 

S.NO Forward Engineering Reverse Engineering

In forward engineering, the application are developed with the In reverse engineering or backward engineering, the
1. given requirements. information are collected from the given application.

2. Forward Engineering is a high proficiency skill. Reverse Engineering or backward engineering is a low
proficiency skill.
Forward Engineering takes more time to develop an While Reverse Engineering or backward engineering takes less
3.
application. time to develop an application.

4. The nature of forward engineering is Prescriptive. The nature of reverse engineering or backward engineering is
Adaptive.
In forward engineering, production is started with given In reverse engineering, production is started by taking the
5. requirements.  existing products.

6. The example of forward engineering is the construction of An example of backward engineering is research on
electronic kit, construction of DC MOTOR , etc. Instruments etc.
Software Configuration Management

In Software Engineering, Software Configuration Management(SCM) is a process to systematically manage,

organize, and control the changes in the documents, codes, and other entities during the Software
Development Life Cycle. The primary goal is to increase productivity with minimal mistakes. SCM is part of
cross-disciplinary field of configuration management and it can accurately determine who made which
revision.

Why do we need Configuration management?

The primary reasons for Implementing Technical Software Configuration Management System are:
• There are multiple people working on software which is continually updating
• It may be a case where multiple version, branches, authors are involved in a software config project, and
the team is geographically distributed and works concurrently
• Changes in user requirement, policy, budget, schedule need to be accommodated.
• Software should able to run on various machines and Operating Systems
• Helps to develop coordination among stakeholders
• SCM process is also beneficial to control the costs involved in making changes to a system
Tasks in SCM process
• Configuration Identification
• Baselines
• Change Control
• Configuration Status Accounting
• Configuration Audits and Reviews

1. Configuration Identification:
Configuration identification is a method of determining the scope of the software system. With the help of
this step, you can manage or control something even if you don’t know what it is. It is a description that
contains the CSCI type (Computer Software Configuration Item), a project identifier and version information.

Activities during this process:

• Identification of configuration Items like source code modules, test case, and requirements specification.
• Identification of each CSCI in the SCM repository, by using an object-oriented approach
• The process starts with basic objects which are grouped into aggregate objects. Details of what, why,
when and by whom changes in the test are made
• Every object has its own features that identify its name that is explicit to all other objects
• List of resources required such as the document, the file, tools, etc.
2. Baseline:
A baseline is a formally accepted version of a software configuration item. It is designated and fixed at a
specific time while conducting the SCM process. It can only be changed through formal change control
procedures.
Activities during this process:
• Facilitate construction of various versions of an application
• Defining and determining mechanisms for managing various versions of these work products
• The functional baseline corresponds to the reviewed system requirements
• Widely used baselines include functional, developmental, and product baselines

3. Change Control:
Change control is a procedural method which ensures quality and consistency when changes are made in the
configuration object. In this step, the change request is submitted to software configuration manager.
Activities during this process:
• Control ad-hoc change to build stable software development environment. Changes are committed to the
repository
• The request will be checked based on the technical merit, possible side effects and overall impact on
other configuration objects.
• It manages changes and making configuration items available during the software lifecycle
4. Configuration Status Accounting:
Configuration status accounting tracks each release during the SCM process. This stage involves tracking
what each version has and the changes that lead to this version.
Activities during this process:
• Keeps a record of all the changes made to the previous baseline to reach a new baseline
• Identify all items to define the software configuration
• Monitor status of change requests
• Complete listing of all changes since the last baseline
• Allows tracking of progress to next baseline
• Allows to check previous releases/versions to be extracted for testing

5. Configuration Audits and Reviews:

Software Configuration audits verify that all the software product satisfies the baseline needs. It ensures that
what is built is what is delivered.
Activities during this process:
• Configuration auditing is conducted by auditors by checking that defined processes are being followed
and ensuring that the SCM goals are satisfied.
• To verify compliance with configuration control standards. auditing and reporting the changes made
• SCM audits also ensure that traceability is maintained during the process.
• Ensures that changes made to a baseline comply with the configuration status reports
• Validation of completeness and consistency
Software Configuration Management Tools

Any Change management software should have the following 3 Key features:
1. Concurrency Management:
When two or more tasks are happening at the same time, it is known as concurrent operation. Concurrency
in context to SCM means that the same file being edited by multiple persons at the same time.
If concurrency is not managed correctly with SCM tools, then it may create many pressing issues.

2. Version Control:
SCM uses archiving method or saves every change made to file. With the help of archiving or save feature, it
is possible to roll back to the previous version in case of issues.

3. Synchronization:
Users can checkout more than one files or an entire copy of the repository. The user then works on the
needed file and checks in the changes back to the repository. They can synchronize their local copy to stay
updated with the changes made by other team members.
COCOMO Model

COCOMO (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines of
Code. It is a procedural cost estimate model for software projects and often used as a process of
reliably predicting the various parameters associated with making a project such as size, effort,
cost, time and quality. It was proposed by Barry Boehm in 1970 and is based on the study of 63
projects, which make it one of the best-documented models.

The key parameters which define the quality of any software products, which are also an outcome
of the COCOMO are primarily Effort & Schedule:
• Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.
• Schedule: Simply means the amount of time required for the completion of the job, which is, of
course, proportional to the effort put. It is measured in the units of time such as weeks, months.

Different models of C0C0MO have been proposed to predict the cost estimation at different levels,
based on the amount of accuracy and correctness required. All of these models can be applied to a
variety of projects, whose characteristics determine the value of constant to be used in subsequent
calculations. These characteristics pertaining to different system types are mentioned below.
Boehm’s definition of organic, semidetached, and embedded systems:
• Organic – A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and
also the team members have a nominal experience regarding the problem.
• Semi-detached – A software project is said to be a Semi-detached type if the vital
characteristics such as team-size, experience, knowledge of the various programming
environment lie in between that of organic and Embedded. The projects classified as
Semi-Detached are comparatively less familiar and difficult to develop compared to the
organic ones and require more experience and better guidance and creativity. Eg:
Compilers or different Embedded Systems can be considered of Semi-Detached type.
• Embedded – A software project with requiring the highest level of complexity, creativity,
and experience requirement fall under this category. Such software requires a larger
team size than the other two models and also the developers need to be sufficiently
experienced and creative to develop such complex models.

All the above system types utilize different values of the constants used in Effort
Calculations.
Types of Models: 
COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. Any of
the three forms can be adopted according to our requirements. These are types of
COCOMO model:
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model

The first level, Basic COCOMO can be used for quick and slightly rough calculations of
Software Costs. Its accuracy is somewhat restricted due to the absence of sufficient factor
considerations.

Intermediate COCOMO takes these Cost Drivers into account and Detailed

COCOMO additionally accounts for the influence of individual project phases, i.e in case of
Detailed it accounts for both these cost drivers and also calculations are performed phase
wise henceforth producing a more accurate result.
 Estimation of Effort: Calculations –
1. Basic Model –

The above formula is used for the cost estimation of for the basic COCOMO model, and
also is used in the subsequent models. The constant values a and b for the Basic Model for
the different categories of system:
Software Projects a b
Organic 2.4 1.05
Semi Detached 3.0 1.12
Embedded 3.6 1.20

The effort is measured in Person-Months and as evident from the formula is

dependent on Kilo-Lines of code. These formulas are used as such in the Basic Model
calculations, as not much consideration of different factors such as reliability,
expertise is taken into account, henceforth the estimate is rough.
2. Intermediate Model –
The basic COCOMO model assumes that the effort is only a function of the number of lines of code and some constants evaluated
according to the different software system. However, in reality, no system’s effort and schedule can be solely calculated on the basis of
Lines of Code. For that, various other factors such as reliability, experience, Capability. These factors are known as Cost Drivers and the
Intermediate Model utilizes 15 such drivers for cost estimation.
Classification of Cost Drivers and their attributes:
(i) Product attributes –
• Required software reliability extent
• Size of the application database
• The complexity of the product
(ii) Hardware attributes –
• Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment
• Required turnabout time
(iii) Personnel attributes –
• Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
(iv) Project attributes –
• Use of software tools
• Application of software engineering methods
• Required development schedule
 Cost Drivers Very Low Low Nominal High Very High
Product Attributes
Required Software
0.75 0.88 1.00 1.15 1.40
Reliability
Size of Application
0.94 1.00 1.08 1.16
Database
Complexity of The
Product 0.70 0.85 1.00 1.15 1.30
Hardware Attributes
Runtime Performance
Constraints 1.00 1.11 1.30

Memory Constraints 1.00 1.06 1.21

Volatility of the virtual
machine environment 0.87 1.00 1.15 1.30

Required turnabout time 0.94 1.00 1.07 1.15

Personnel attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82
Software engineer
1.42 1.17 1.00 0.86 0.70
capability
Virtual machine
1.21 1.10 1.00 0.90
experience
Programming language
experience 1.14 1.07 1.00 0.95

Project Attributes

Application of software
1.24 1.10 1.00 0.91 0.82
engineering methods

Use of software tools 1.24 1.10 1.00 0.91 0.83

Required development 1.23 1.08 1.00 1.04 1.10
schedule
The project manager is to rate these 15 different parameters for a particular project on a
scale of one to three. Then, depending on these ratings, appropriate cost driver values are
taken from the above table. These 15 values are then multiplied to calculate the EAF (Effort
Adjustment Factor). The Intermediate COCOMO formula now takes the form:

The values of a and b in case of the intermediate model are as follows:

Software a b
Projects
Organic 3.2 1.05
Semi
3.0 1.12
Detached
Embeddedc 2.8 1.20
3. Detailed Model –
Detailed COCOMO incorporates all characteristics of the intermediate version with an
assessment of the cost driver’s impact on each step of the software engineering process.
The detailed model uses different effort multipliers for each cost driver attribute. In
detailed COCOCMO, the whole software is divided into different modules and then we
apply COCOMO in different modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:
• Planning and requirements
• System design
• Detailed design
• Module code and test
• Integration and test
• Cost Constructive model
The effort is calculated as a function of program size and a set of cost drivers are given
according to each phase of the software lifecycle.
Computer Aided Software Engineering (CASE)
Computer aided software engineering (CASE) is the implementation of computer facilitated tools and
methods in software development. CASE is used to ensure a high-quality and defect-free software. CASE
ensures a check-pointed and disciplined approach and helps designers, developers, testers, managers and
others to see the project milestones during development. 
CASE can also help as a warehouse for documents related to projects, like business plans, requirements and
design specifications. One of the major advantages of using CASE is the delivery of the final product, which is
more likely to meet real-world requirements as it ensures that customers remain part of the process. 
CASE illustrates a wide set of labor-saving tools that are used in software development. It generates a
framework for organizing projects and to be helpful in enhancing productivity. There was more interest in the
concept of CASE tools years ago, but less so today, as the tools have morphed into different functions, often
in reaction to software developer needs. The concept of CASE also received a heavy dose of criticism after its
release. 

CASE Tools: 
The essential idea of CASE tools is that in-built programs can help to analyze developing systems in order to
enhance quality and provide better outcomes. Throughout the 1990, CASE tool became part of the software
lexicon, and big companies like IBM were using these kinds of tools to help create software. 
Various tools are incorporated in CASE and are called CASE tools, which are used to support different stages
and milestones in a software development life cycle. 
Types of CASE Tools: 
 
• Diagramming Tools: 
It helps in diagrammatic and graphical representations of the data and system processes. It represents system elements, control flow
and data flow among different software components and system structure in a pictorial form. 
For example, Flow Chart Maker tool for making state-of-the-art flowcharts.  

• Computer Display and Report Generators: 

It helps in understanding the data requirements and the relationships involved.  

• Analysis Tools: 
It focuses on inconsistent, incorrect specifications involved in the diagram and data flow. It helps in collecting requirements,
automatically check for any irregularity, imprecision in the diagrams, data redundancies or erroneous omissions. 
For example, 
(i) Accept 360, Accompa, CaseComplete for requirement analysis. 
(ii) Visible Analyst for total analysis. 

• Central Repository: 
It provides the single point of storage for data diagrams, reports and documents related to project management.  

• Documentation Generators: 
It helps in generating user and technical documentation as per standards. It creates documents for technical users and end users. 
For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.  

• Code Generators: 
It aids in the auto generation of code, including definitions, with the help of the designs, documents and diagrams
Advantages of the CASE approach: 
 
• As special emphasis is placed on redesign as well as testing, the servicing
cost of a product over its expected lifetime is considerably reduced. 
 
• The overall quality of the product is improved as an organized approach is
undertaken during the process of development. 
 
• Chances to meet real-world requirements are more likely and easier with a
computer-aided software engineering approach. 
 
• CASE indirectly provides an organization with a competitive advantage by
helping ensure the development of high-quality products. 
Disadvantages of the CASE approach: 

• Cost: Using case tool is a very costly. Mostly firms engaged in software development on
a small scale do not invest in CASE tools because they think that the benefit of CASE are
justifiable only in the development of large systems.

• Learning Curve: In most cases, programmers productivity may fall in the initial phase of
implementation , because user need time to learn the technology. Many consultants
offer training and on-site services that can be important to accelerate the learning curve
and to the development and use of the CASE tools.

• Tool Mix: It is important to build an appropriate selection tool mix to urge cost
advantage CASE integration and data integration across all platforms is extremely
important. 
Risk Management

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

1. Uncertainty- the risk may or may not happen that means there are no 100%
risks.
2. Loss – If the risk occurs in reality , undesirable result or losses will occur.

Risk management is a sequence of steps that help a software team to

understand , analyze and manage uncertainty. Risk management consists of
• Risk Identification
• Risk analysis
• Risk Planning
• Risk Monitoring
A computer code project may be laid low with an outsized sort of risk. so as to be ready to consistently establish the
necessary risks which could have an effect on a computer code project, it’s necessary to reason risks into completely
different categories. The project manager will then examine the risks from every category square measure relevant to the
project. There square measure 3 main classes of risks that may have an effect on a computer code project: 

• Project Risks: 
Project risks concern various sorts of monetary funds, schedules, personnel, resource, and customer-related issues. a
vital project risk is schedule slippage. Since computer code is intangible, it’s terribly tough to observe and manage a
computer code project. it’s terribly tough to manage one thing that can not be seen. For any producing project, like
producing cars, the project manager will see the merchandise taking form. For example, see that the engine is fitted,
at the moment the area of the door unit fitted, the automotive is obtaining painted, etc. so he will simply assess the
progress of the work and manage it. The physical property of the merchandise being developed is a vital reason why
several computer codes come to suffer from the danger of schedule slippage. 

• Technical Risks: 
Technical risks concern potential style, implementation, interfacing, testing, and maintenance issues. Technical risks
conjointly embody ambiguous specifications, incomplete specification, dynamic specification, technical uncertainty,
and technical degeneration. Most technical risks occur thanks to the event team’s lean information concerning the
project.
  
• Business Risks: 
This type of risk embodies the risks of building a superb product that nobody needs, losing monetary funds or
personal commitments, etc.  
Classification of Risk in a project:

Example: Let us consider a satellite based mobile communication project. The project

manager can identify several risks in this project. Let us classify them appropriately.
• What if the project cost escalates and overshoots what was estimated? – Project Risk
• What if the mobile phones that are developed become too bulky in size to conveniently
carry? Business Risk
• What if call hand-off between satellites becomes too difficult to implement? Technical
Risk