Software Maintenance

Software maintenance is a part of the Software Development Life Cycle. Its primary goal is to modify and update
software application after delivery to correct errors and to improve performance. Software is a model of the real
world. When the real world changes, the software require alteration wherever possible.
Software Maintenance is an inclusive activity that includes error corrections, enhancement of capabilities,
deletion of obsolete capabilities, and optimization.

There are number of reasons, why modifications are required, some of them are briefly mentioned below:
• Market Conditions - Policies, which changes over the time, such as taxation and newly introduced
constraints like, how to maintain bookkeeping, may trigger need for modification.
• Client Requirements - Over the time, customer may ask for new features or functions in the software.
• Host Modifications - If any of the hardware and/or platform (such as operating system) of the target host
changes, software changes are needed to keep adaptability.
• Organization Changes - If there is any business level change at client end, such as reduction of organization
strength, acquiring another company, organization venturing into new business, need to modify in the original
software may arise.

IMSEC
 Need for Maintenance Adaptive
Maintenance
Software Maintenance is needed for:-
• Correct errors
• Change in user requirement with time
• Changing hardware/software requirements
• To improve system efficiency Classification
Corrective
• To optimize the code to run faster Maintenance Of Software
Preventive
Maintenance
• To modify the components Maintenance
• To reduce any unwanted side effects.

Perfective
Types of Software Maintenance Maintenance

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

Maintenance Activities
IEEE provides a framework for sequential maintenance Identification Analysis
Design
& Tracing
process activities. It can be used in iterative manner and
can be extended so that customized items and processes
can be included. Maintenance
Management
Maintenance Implementations
Activities

Delivery
System
Acceptance Testing
Testing
These activities go hand-in-hand with each of the following phase:
1. Identification & Tracing - It involves activities pertaining to identification of requirement of modification or
maintenance. It is generated by user or system may itself report via logs or error messages.Here, the maintenance type is
classified also.
2. Analysis - The modification is analyzed for its impact on the system including safety and security implications. If probable
impact is severe, alternative solution is looked for. A set of required modifications is then materialized into requirement
specifications. The cost of modification/maintenance is analyzed and estimation is concluded.
3. Design - New modules, which need to be replaced or modified, are designed against requirement specifications set in the
previous stage. Test cases are created for validation and verification.
4. Implementation - The new modules are coded with the help of structured design created in the design step.Every
programmer is expected to do unit testing in parallel.
5. System Testing - Integration testing is done among newly created modules. Integration testing is also carried out between
new modules and the system. Finally the system is tested as a whole, following regressive testing procedures.
6. Acceptance Testing - After testing the system internally, it is tested for acceptance with the help of users. If at this state,
user complaints some issues they are addressed or noted to address in next iteration.
7. Delivery - After acceptance test, the system is deployed all over the organization either by small update package or fresh
installation of the system. The final testing takes place at client end after the software is delivered.
8. Training facility is provided if required, in addition to the hard copy of user manual.
9. Maintenance management - Configuration management is an essential part of system maintenance. It is aided with
version control tools to control versions, semi-version or patch management.
Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software maintenance found that the cost
of maintenance is as high as 67% of the cost of entire software process cycle.
On an average, the cost of software maintenance is more
than 50% of all SDLC phases. There are various factors,
Designing Implementation
which trigger maintenance cost go high, such as: Requirement
There are two types of cost factors involved in
Testing
software maintenance. 3%
8% 7%

These are 15%

• Non-Technical Factors
• Technical Factors Cost Factors

Module
Maintenance
Application Independance 67
Programming
Domain
Language
Staff Stability Programming
Program Style
Non-Technical Technical Program Validation
Lifetime and Testing
Dependency on
External Environment Documentation
Hardware Configuration
Stability Management
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 14/07/21 Absent
Technical Factors include the following: 2,6,7,8,9,11,13,14,15,17,18,19,20,21
Module Independence 22,26,28,29,32,36,38,39,46,48,50,51
It should be possible to change one program unit of a system without affecting any other unit. 54,57,59,
Programming Language
Programs written in a high-level programming language are generally easier to understand than programs written in a low-level language.
Programming Style
The method in which a program is written contributes to its understandability and hence, the ease with which it can be modified.
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.
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.
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.
 Software Re-engineering
When we need to update the software to keep it to the current market, without impacting its functionality, it is
called software re-engineering. It is a thorough process where the design of software is changed and programs are
re-written.
Legacy software cannot keep tuning with the latest technology available in the market. As the hardware become
obsolete, updating of software becomes a headache. Even if software grows old with time, its functionality does
not.
For example, initially Unix was developed in assembly language. When language C came into existence, Unix
was re-engineered in C, because working in assembly language was difficult.
Other than this, sometimes programmers notice that few parts of software need more maintenance than others
and they also need re-engineering.
Re-Engineering Process
• Decide what to re-engineer. Is it whole software or a part of
Existing Reverse it?
• Perform Reverse Engineering, in order to obtain
Engineering
Software
specifications of existing software.
Re- • Restructure Program if required. For example, changing
Structuring
function-oriented programs into object-oriented programs.
• Re-structure data as required.
Forward
Re-engineered
• Apply Forward engineering concepts in order to get re-
Engineering
Software engineered software.
 How is Software Re-engineering Done?
The Software Reengineering process basically undergoes three main phases.
These are
(1) reverse engineering,
(2) restructuring, and
(3) forward engineering.

Reverse Engineering
A simple Google search would tell us that reverse engineering is “the reproduction of another manufacturer’s
product following a detailed examination of its construction or composition”. However, it is not only limited to
applying this process to another manufacturer’s product but also to your own.
This is done by thoroughly analyzing and inspecting the system specifications and understanding the
existing processes. Systematically, reversing the software development life cycle of software implementation
best fits this procedure as it ordinally unravels each layer from a higher level to lower-level views of the system

Software Reverse Engineering –

Software Reverse Engineering is the process of recovering the design and the requirements specification of a
product from an analysis of it’s code. Reverse Engineering is becoming important, since several existing software
products, lack proper documentation, are highly unstructured, or their structure has degraded through a series of
maintenance efforts.
 Why Reverse Engineering?
•Providing proper system documentation.
•Recovery of lost information.
•Assisting with maintenance.
•Facility of software reuse.
•Discovering unexpected flaws or faults.

Used of Software Reverse Engineering –

•Software Reverse Engineering is used in software design, reverse engineering enables the developer or
programmer to add new features to the existing software with or without knowing the source code.
•Reverse engineering is also useful in software testing, it helps the testers to study the virus and other malware
code .
Restructuring
Once the reverse engineering is done and the appropriate specifications are identified, restructuring is performed.
Restructuring deals with rearranging or reconstructing the source code and deciding whether to retain or change
the programming conventions. Still, this shouldn’t impact the existing functionalities of the software. Instead, this
process enhances them for more reliable performance and maintainability.
Another part of this procedure is the elimination or reconstruction of the parts of the source code that often cause
errors in the software (may also be debugging). Aside from that, eliminating obsolete or older versions of certain
parts of the system (such as programming implementation and hardware components) should keep the system
updated.
 Re-structuring does not impact the functionality of the software but enhance reliability and maintainability.
Program components, which cause errors very frequently can be changed, or updated with re-structuring.
The dependability of software on obsolete hardware platform can be removed via re-structuring.

Forward Engineering

The flow ends with forward engineering. This is the process of integrating the latest specifications based on the
results of the evaluations from reverse engineering and restructuring. In relation to the entirety of the process, this
is defined relative to reverse engineering, where there is an effort to build backward, from a coded set to a model,
or to break down the process of how software was integrated. There is no specific SDLC model to follow in
software reengineering. The model will always depend on what fits best with the environment and implementation
of your product. However, like software engineering, this is a systematic development that involves processes
within processes and requires thorough inspection for seamless results.

Forward engineering is same as software engineering process with only one difference – it is carried out always
after reverse engineering.
 Software Configuration Management in Software Engineering

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.
When we develop software, the product (software) undergoes many changes in their maintenance phase; we
need to handle these changes effectively.
Several individuals (programs) works together to achieve these common goals. This individual produces several
work product (SC Items) e.g., Intermediate version of modules or test data used during debugging, parts of the
final product.
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
 SCM Process

It uses the tools which keep that the necessary change has been implemented adequately to the appropriate
component. The SCM process defines a number of tasks:
• Identification of objects in the software configuration Identification
• Version Control
• Change Control
• Configuration Audit
SCM
• Status Reporting
Process

Identification
Basic Object: Unit of Text created by a software engineer
during analysis, design, code, or test.
Aggregate Object: A collection of essential objects and other
aggregate objects. Design Specification is an aggregate object.
Each object has a set of distinct characteristics that identify it
uniquely: a name, a description, a list of resources, and a
"realization."
The interrelationships between configuration objects can be
described with a Module Interconnection Language (MIL).
Version Control
Version Control combines procedures and tools to handle different version of configuration objects that are generated during
the software process.
Clemm defines version control in the context of SCM: Configuration management allows a user to specify the alternative
configuration of the software system through the selection of appropriate versions. This is supported by associating attributes
with each software version, and then allowing a configuration to be specified [and constructed] by describing the set of desired
attributes.

Change Control
James Bach describes change control in the context of SCM is: Change Control is Vital. But the forces that make it
essential also make it annoying.
We worry about change because a small confusion in the code can create a big failure in the product. But it can also
fix a significant failure or enable incredible new capabilities.
The "check-in" and "check-out" process implements two necessary elements of change control-access
control and synchronization control.
Access Control governs which software engineers have the authority to access and modify a particular
configuration object.
Synchronization Control helps to ensure that parallel changes, performed by two different people, don't overwrite
one another.
Configuration Audit
SCM audits to verify that the software product satisfies the baselines requirements and ensures that what is built and what is
delivered.
SCM audits also ensure that traceability is maintained between all CIs and that all work requests are associated with one or more
CI modification.
SCM audits are the "watchdogs" that ensures that the integrity of the project's scope is preserved.
Status Reporting
Configuration Status reporting (sometimes also called status accounting) providing accurate status and current configuration
data to developers, testers, end users, customers and stakeholders through admin guides, user guides, FAQs, Release Notes,
Installation Guide, Configuration Guide, etc.
Project Manager:
Participant of SCM process: • Ensure that the product is developed within a certain time
Following are the key participants in frame
SCM • Monitors the progress of development and recognizes
issues in the SCM process
Configuration
Manager Developer • Generate reports about the status of the software system
• Make sure that processes and policies are followed for
creating, changing, and testing

Configuration Manager
SCM Operational • Configuration Manager is the head who is Responsible
Scenario for identifying configuration items.
• CM ensures team follows the SCM process
Project Manager User • He/She needs to approve or reject change requests
Developer
• The developer needs to change the code as per standard development activities or change requests. He is responsible for
maintaining configuration of code.
• The developer should check the changes and resolves conflicts

User
The end user should understand the key SCM terms to ensure he has the latest version of the software

Software Configuration Management Tools

Any Change management software should have the following 3 Key features:

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.
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.
 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 is useful in calculating effort, time and cost of a
software project.

COCOMO Model
Barry Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981and is based on the study of 63
projects. COCOMO is one of the most generally used software estimation models in the world.
COCOMO is useful to predicts the efforts, time and Cost of a software product based on the size of the software.
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

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.
The necessary steps in this model are:
1. Get an initial estimate of the development effort from evaluation of thousands of delivered lines of source code (KDLOC).
2. Determine a set of 15 multiplying factors from various attributes of the project.
3. Calculate the effort estimate by multiplying the initial estimate with all the multiplying factors i.e., multiply the values in
step1 and step2.
The initial estimate (also called nominal estimate) is determined by an equation of the form used in the static single variable
models, using KDLOC as the measure of the size. To determine the initial effort Ei in person-months the equation used is of the
type is shown below
Ei=a*(KDLOC)b
The value of the constant a and b are depends on the project type.

Boehm’s definition of organic, semidetached, and embedded systems. In COCOMO, projects are categorized
into three types:
1. Organic
2. Semidetached
3. Embedded

1. Organic: A development project can be treated of the organic type, if the project deals with developing a
well-understood application program, the size of the development team is reasonably small, and the team
members are experienced in developing similar methods of projects. Examples of this type of projects
are simple business systems, simple inventory management systems, and data processing systems.
2. Semidetached: A development project can be treated with semidetached type if the development consists of
a mixture of experienced and inexperienced staff. Team members may have finite experience in related
systems but may be unfamiliar with some aspects of the order being developed. Example of Semidetached
system includes developing a new operating system (OS), a Database Management System (DBMS), and
complex inventory management system.

3. Embedded: A development project is treated to be of an embedded type, if the software being developed is
strongly coupled to complex hardware, or if the stringent regulations on the operational method exist. For
Example: ATM, Air Traffic control.
Model Project size Nature Of
Project
Organic < = 50 Small size
Semi-Detached 50-300 Medium
Embedded >300 Large

Note: One Person-month (PM) is the effort an individual can typically put in a month.

According to Boehm the unit for effort is Person-month (PM) and for development time the unit is month.

Effort is represented by E and Development Time by Tdev .

According to Boehm, software cost estimation should be done through three stages:
1. Basic Model
2. Intermediate Model
3. Detailed Model
Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project parameters. The following
expressions give the basic COCOMO estimation model:

Effort = a*(KLOC) b PM
Tdev = c*(efforts)d Months
Where
KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
a,b,c,d are constants for each group of software products,
Tdev is the estimated time to develop the software, expressed in months,
Effort is the total effort required to develop the software product, expressed in person months (PMs).
Estimation of development effort

Software Project a b c d
Organic 2.4 1,05 2.5 0.38
Semi-Detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
 In Basic COCOMO, only one factor “Size of software in KLOC” is considered while calculating Effort,
Development time and cost of project.

In COCOMO, Size is always measured in KLOC (Kilo Lines of Code).

1KLOC = 1000 LOC Estimation of Staff:

Staff = Effort/Tdev Persons
Estimation of Productivity:
Productivity=Size/Effort KLOC/PM
Estimation of Cost:
Cost=No. of Staffs*Tdev*Salary of a staff in a month
Or Cost=Effort* Salary of a staff in a month
Example:
Suppose that a project was estimated to be 400 KLOC. Calculate the effort and development time for each of the
three
modes i.e., organic, semidetached and embedded

Solution
The basic COCOMO equation take the form:
E = a (KLOC)b
D = c (KLOC)d
Estimated size of the project = 400 KLOC

(i) Organic mode

(ii) Semidetached mode
E = 2.4(400)1.05 = 1295.31 PM
E = 3.0(400)1.12 = 2462.79 PM
D = 2.5(1295.31)0.38 = 38.07 PM
D = 2.5(2462.79)0.35 = 38.45 PM

(iii) Embedded mode

E = 3.6(400)1.20 = 4772.81 PM
D = 2.5(4772.8)0.32 = 38 PM
Example-1: - Let us determine Effort, Development Time, Number of average Staffs,
Productivity and Development Cost of a software project for the following given data by using
Basic COCOMO Model:
Size of the software Project= 10000 LOC
Development Type = Semidetached
Salary of each Staff = Rs. 10000 per Month

Solution: By using Basic COCOMO Model:

Effort = 3.0*(size of the s/w project in KLOC) 1.12 PM
= 3.0 * (10) 1.12 PM
= 39.547 PM
Tdev = 2.5 * (Effort) 0.35 Months
= 2.5 * (39.547) 0.35 Months
= 9.055 Months
No of Staff (SS) = Effort/Tdev
Cost of Project =No. of Staffs* Tdev*Salary
= 39.547/9.055
= 4.367 * 9.055 * 10000
= 4.367 Persons 4 Persons = Rs. 395431.85

Productivity (P) = Size/Effort

= 10/39.547
= 0.25 KLOC/PM

2-Intermediate COCOMO Model:-

Besides the product size there are some other parameters/factors should be also used/considered for accurate
estimation of effort and development time.
And there are 15 different parameters are used to calculate effort and time in case of Intermediate COCOMO.
These are also called as Cost Drivers (or Cost Multipliers).
These Cost Drivers are classified into four Categories: -
(a) Product attributes:
RELY (Required Software Reliability)
DATA (Database Size)
CPLX (Product Complexity)
(b) Computer attributes:

TIME (Execution time constraint)

(d) Project attributes:
STOR (Main storage constraint)
MODP (Modern programming practices)
VIRT (Virtual machine volatility)
TOOL (Use of software tools)
TURN (Computer turnaround time)
SCED (Required development Schedule)

(c) Personnel attributes:

ACAP (Analyst capability)

AEXP (Application Experience)

VEXP (Virtual machine Experience)

LEXP Programming language Experience)

PCAP (Programmer capability)

Note-1: These Cost Drivers (or Cost Multipliers) use rating scale as Very Low, Low, Nominal High, Very High and Extra High
and their values changes from 1 to 3.

Note-2: The multiplication of all 15 Cost drivers is called as Cost Driver Multiplier (CDM) or Effort Adjustment Factor (EAF).

Effort Adjustment Factor (EAF) = CDM = C = C1*C2*C3…….....................C14*C15

Estimation of Effort by “Intermediate COCOMO”:

Effort (E) = a* (size)b * EAF PM

Organic:
Effort= 3.2*(KLOC)1.05 *EAF PM
Semidetached:
Effort= 3.0*(KLOC)1.12 *EAF PM
Embedded:
Effort= 2.8*(KLOC)1.20 *EAF PM
Estimation of Development Time in “Intermediate COCOMO”:
Tdev = c*(E)d Months
Organic:
Tdev =2.5*(Effort)0.38 Months
Semidetached:
Tdev =2.5*(Effort)0.35 Months
Embedded:
Tdev =2.5*(Effort)0.32 Months
3-Complete or Detailed COCOMO Model: -
The Basic and Intermediate COCOMO models consider a software product as a single homogeneous
entity. But large systems are made up of several smaller sub-systems and these smaller sub-systems some
may be considered as organic, some may be considered as semidetached and some may be considered as
embedded.
In Complete COCOMO, the effort and time are calculated for a System by taking the total Sum of the
effort and time of the each and every Sub-system.
Note: - This approach reduces the margin of error in the final estimation.
For Example: -
A distributed Management Information System for an organization having offices at several places across
the country can have the following sub-systems:
1. GUI part (considered as organic software)
2. Database part (considered as semidetached software)
3. Communication part (considered as embedded software)
Then according to Detailed COCOMO Model the Total Effort and Total Cost required for the
development of complete system are calculated by adding (i.e. summing) the effort and total cost
required for the development of these three components individually.
What is Risk?
"Tomorrow problems are today's risk." Hence, a clear definition of a "risk" is a “problem that could cause some
loss or threaten the progress of the project, but which has not happened yet”.
These potential issues might harm cost, schedule or technical success of the project and the quality of our
software device, or project team morale.
Risk Management is the system of identifying addressing and eliminating these problems before they can damage
the project.
We need to differentiate risks, as potential issues, from the current problems of the project.
Different methods are required to address these two kinds of issues.
For example, staff storage, because we have not been able to select people with the right technical skills is a
current problem, but the threat of our technical persons being hired away by the competition is a risk.

Risk Management
A software project can be concerned with a large variety of risks. In order to be adept to systematically identify
the significant risks which might affect a software project, it is essential to classify risks into different classes.
The project manager can then check which risks from each class are relevant to the project.
 There are three main classifications of risks which can affect a software project:
1.Project risks
2.Technical risks
3.Business risks
1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel, resource, and customer-related
problems. A vital project risk is schedule slippage. Since the software is intangible, it is very tough to monitor and control a
software project. It is very tough to control something which cannot be identified. For any manufacturing program, such as
the manufacturing of cars, the plan executive can recognize the product taking shape.
2. Technical risks: Technical risks concern potential method, implementation, interfacing, testing, and maintenance issue. It
also consists of an ambiguous specification, incomplete specification, changing specification, technical uncertainty, and
technical obsolescence. Most technical risks appear due to the development team's insufficient knowledge about the
project.
3. Business risks: This type of risks contain risks of building an excellent product that no one need, losing budgetary or
personnel commitments, etc.

Other risk categories

1. Known risks: Those risks that can be uncovered after careful assessment of the project program, the business and
technical environment in which the plan is being developed, and more reliable data sources (e.g., unrealistic delivery
date)
2. Predictable risks: Those risks that are hypothesized from previous project experience (e.g., past turnover)
3. Unpredictable risks: Those risks that can and do occur, but are extremely tough to identify in advance.
Principle of Risk Management
1.Global Perspective: In this, we review the bigger system description, design, and implementation. We look at
the chance and the impact the risk is going to have.
2.Take a forward-looking view: Consider the threat which may appear in the future and create future plans for
directing the next events.
3.Open Communication: This is to allow the free flow of communications between the client and the team
members so that they have certainty about the risks.
4.Integrated management: In this method risk management is made an integral part of project management.
5.Continuous process: In this phase, the risks are tracked continuously throughout the risk management
paradigm.
Risk Identification

Risk Assessment Risk Analysis

Risk Prioritization

Risk Management Risk Management

Planning

Risk Monitoring
Risk Control

Risk Resolution
Risk Assessment
The objective of risk assessment is to division the risks in the condition of their loss, causing potential. For risk
assessment, first, every risk should be rated in two methods:
•The possibility of a risk coming true (denoted as r).
•The consequence of the issues relates to that risk (denoted as s).
Based on these two methods, the priority of each risk can be estimated:
p=r*s
Where p is the priority with which the risk must be controlled, r is the probability of the risk becoming true, and s
is the severity of loss caused due to the risk becoming true. If all identified risks are set up, then the most likely
and damaging risks can be controlled first, and more comprehensive risk abatement methods can be designed for
these risks.

1. Risk Identification: The project organizer needs to anticipate the risk in the project as early as possible so that
the impact of risk can be reduced by making effective risk management planning.
A project can be of use by a large variety of risk. To identify the significant risk, this might affect a project. It is
necessary to categories into the different risk of classes.
There are different types of risks which can affect a software project:
1.Technology risks: Risks that assume from the software or hardware technologies that are used to develop the system.
2.People risks: Risks that are connected with the person in the development team.
3.Organizational risks: Risks that assume from the organizational environment where the software is being developed.
4.Tools risks: Risks that assume from the software tools and other support software used to create the system.
5.Requirement risks: Risks that assume from the changes to the customer requirement and the process of managing the
requirements change.
6.Estimation risks: Risks that assume from the management estimates of the resources required to build the system

Risk Analysis: During the risk analysis process, you have to consider every identified risk and make a
perception of the probability and seriousness of that risk.
There is no simple way to do this. You have to rely on your perception and experience of previous projects
and the problems that arise in them.
It is not possible to make an exact, the numerical estimate of the probability and seriousness of each risk.
Instead, you should authorize the risk to one of several bands:
1. The probability of the risk might be determined as very low (0-10%), low (10-25%), moderate (25-
50%), high (50-75%) or very high (+75%).
2. The effect of the risk might be determined as catastrophic (threaten the survival of the plan), serious
(would cause significant delays), tolerable (delays are within allowed contingency), or insignificant.
 2. Risk Control
It is the process of managing risks to achieve desired outcomes. After all, the identified risks of a plan are
determined; the project must be made to include the most harmful and the most likely risks. Different risks need
different containment methods. In fact, most risks need ingenuity on the part of the project manager in tackling
the risk.

There are three main methods to plan for risk management:

1.Avoid the risk: This may take several ways such as discussing with the client to change the requirements
to decrease the scope of the work, giving incentives to the engineers to avoid the risk of human resources
turnover, etc.
2.Transfer the risk: This method involves getting the risky element developed by a third party, buying
insurance cover, etc.
3.Risk reduction: This means planning method to include the loss due to risk. For instance, if there is a risk
that some key personnel might leave, new recruitment can be planned.
Risk Leverage: To choose between the various methods of handling risk, the project plan must consider the
amount of controlling the risk and the corresponding reduction of risk. For this, the risk leverage of the various
risks can be estimated.
Risk leverage is the variation in risk exposure divided by the amount of reducing the risk.
Risk leverage = (risk exposure before reduction - risk exposure after reduction) / (cost of reduction)
1. Risk planning: The risk planning method considers each of the key risks that have been identified and
develop ways to maintain these risks.
For each of the risks, you have to think of the behavior that you may take to minimize the disruption to the plan
if the issue identified in the risk occurs.
You also should think about data that you might need to collect while monitoring the plan so that issues can be
anticipated.
Again, there is no easy process that can be followed for contingency planning. It rely on the judgment and
experience of the project manager.
2. Risk Monitoring: Risk monitoring is the method king that your assumption about the product, process, and
business risks has not changed.

16/07/21 Absent
2,6,9,11,13,16,17,18,21,25,26,28,30,32,33,35,36,37,39,
44,45,46,51,53,56,57,59,63,