LECTURE NOTES ON

SUBJECT: SOFTWARE ENGINEERING

SUBJECT CODE: BCS-601
Unit-5
B.TECH
BRANCH: CSE
YEAR- 3RD SEMESTER- 6th

(AKTU)

Mr. Sandeep Kumar

(Assistant Professor)

Department of Computer Science & Engineering

Maharana Pratap Engineering College, Kanpur

 Unit-5
Software Maintenance and Software Project Management

Software as an Evolutionary Entity

Software Evolution is a term which refers to the process of developing software initially,
then timely updating it for various reasons, i.e., to add new features or to remove obsolete
functionalities etc. The evolution process includes fundamental activities of change analysis,
release planning, system implementation and releasing a system to customers.

The cost an impact of these changes is accessed to see how much system is affected by the
change and how much it might cost to implement the change. If the proposed changes are
accepted, a new release of the software system is planned. During release planning, all the
proposed changes (fault repair, adaptation, and new functionality) are considered. A design
is then made on which changes to implement in the next version of the system. The process
of change implementation is an iteration of the development process where the revisions to
the system are designed, implemented and tested.

Laws used for Software Evolution

1. Law of continuing change: This law states that any software system that represents
some real-world reality undergoes continuous change or become progressively less
useful in that environment.
2. Law of increasing complexity: As an evolving program changes, its structure
becomes more complex unless effective efforts are made to avoid this
phenomenon.
Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
 3. Law of conservation of organization stability: Over lifetime of s program, the rate
of development of that program is approximately constant and independent of the
resources devoted to system development.
4. Law of conservation of familiarity: This law states that during active lifetime of
program changes made in the successive release are almost constant.
Software Maintenance

1. Software maintenance is recognized as an important part of software life cycle. It is

process of changing system software after it has been delivered to the customer.
2. Maintenance is the process in which changes are implemented by either modifying
the existing system architecture or by adding new components to the system.
3. Analysts and programmers spend more time in maintaining software programs. Then,
they spend time writing the program and so the cost of software maintenance is quite
high.

Thus, "Software maintenance is modification of software product after delivery to

customer in order to correct faults, to improve performance, or to adopt the product
in the modified environment."

NEED FOR Software Maintenance

1. Usually the system requirements are changing, and to meet these requirements, some
changes are incorporated in the system.
2. The maintained system remains useful in their working environment.
3. Maintenance is applicable to software developed using any software life cycle
model. The system changes / enhancement maintenance must be done in order to:
(a) Correct faults
(b) Improve the design
(c) Implement enhancements
(d) Adoption of environments (different H/W or SOFTWARE)
(e) Replacement of old software by new software
4. Errors undetected during software development may be found during the use and
require correction.
5. With time, new technologies are introduced such as new H/W, operating system, etc.
The software therefore must be modified to adopt the new modified environments.

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
Types of Software Maintenance

Software maintenance can be categorized into the following four types:

1. Corrective Maintenance
2. Adaptive Maintenance
3. Perfective Maintenance
4. Preventive Maintenance

1. Corrective Maintenance
Corrective maintenance includes modifying a software application to remove errors
and bugs that were not identified during initial development even with thorough
testing, some bugs may surface only after deployment.

Types of Errors:
(i) Coding errors: Errors in coding procedures; relatively inexpensive to fix.
(ii) Design errors: These occur in design and are costlier to fix, as they often
require rewriting several program components.
(iii) Requirement errors: These stem from incomplete requirement
specifications and are the most expensive, often requiring major redesign.

2. Adaptive Maintenance
It includes modifying the software to match changes in the ever-changing
environment, such as:
i. New hardware
ii. New operating systems
iii. Different computing environments
iv. Business rules
v. Government policies, etc.

3. Perfective Maintenance
Perfective maintenance is an activity that is undertaken to improve the processing
efficiency or performance of the application. It means modifying or enhancing the
system to meet the new requirements. It includes all changes (insertion, deletion,
modification) made to the application to extend and expand it to meet evolving user
needs. User requirements can take the form of enhancement of existing system
functionality.
Thus, perfective maintenance makes the product better, faster, smaller, better
documented with more reports and functions.
Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
 4. Preventive Maintenance

Preventive maintenance is required to reduce complexity of the code that may results
from corrective, adaptive and perfective maintenance. This activity s usually initiated
from within the maintenance organization with the intention of making program
easier to understand. This includes code restructuring, code optimization and
documentation updating.

Cost of Maintenance
The cost of system maintenance represents a large proportion of the budget of most
organizations that use a software system. More than 65% of software lifecycle cost is
expanded in the maintenance activities. The cost and effort of software maintenance can vary
depending on the type of maintenance being performed and the complexity of the software
system.

Cost of software maintenance Include:

• Labor costs: This includes the cost of the personnel who perform the maintenance,
such as software developers, engineers, and technicians.
• Hardware and software costs: This includes the cost of hardware and software tools
used for maintenance, such as servers, software licenses, and development tools.
• Training costs: This includes the cost of training personnel to perform
maintenance tasks, such as software developers, engineers, and technicians.

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
Software Re-Engineering

Re-engineering means having a re-look at an entity such as a process, task, design,

approach, or strategy using engineering principles to bring improvement. In other words,
Re-engineering means the use of new technology to gain significant improvements in:

• Quality
• Reliability
• Performance
• Robustness
• Usability

Old systems that must still be maintained are sometimes called legacy systems. Most
legacy systems may be poorly structured, and their documentation may be either out-of-
date or non-existent. The developers of these systems may have left the organization,
and there may be very few people who understand them in detail.

“Software re-engineering is concerned with taking existing legacy systems and Re-
implementing them to make them more maintainable.”

IBM user group defines software re-engineering as:

"The process of modifying the internal mechanism of a system or program or the data
structure of a system or program without changing its functionality.

Techniques of Re-engineering

In this, two technologies are used:

1. Reverse Engineering
2. Forward Engineering

1) Reverse Engineering

In reverse engineering, we disintegrate the software into parts and components to

understand its design, architecture, and application from all angles.
• In reverse engineering, we analyse the software by breaking it down to suggest
improvements.
• The reverse engineering process removes problems, difficulties, and identifies
areas of improvement by suggesting better technology, design methods, and
tools.
Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
2) Forward Engineering

In forward engineering, we take the existing software product and re-design it as a new
system by:
• Driving it forward to a new architecture or new platform.
• Making efforts to improve overall behavioural quality such as:
o Performance
o Recovery
o Reliability, etc.

Activities Involved in Re-engineering Phase

1️. Source Code Translation: In this the program is converted from an old programming
language to a more modern programming language, or to a different language. Source-level
translation may be required for the following reasons:

(i) Hardware platform update

(ii) Staff skill shortage
(iii) Organizational policy changes

2. Program Structure Improvement: In this the control structure of the program is

analysed and modified to make it easier to understand. It involves transforming a system
from one representation to another without changing functionality.

Types of restructuring techniques:

(i) Control flow driven restructure

(ii) Efficiency driven restructure
(iii) Adaption driven restructuring

3. Program Modularization

Related parts of a program are grouped together, and where appropriate, redundancy is
eliminated. In some cases, this stage may involve architectural transformation. Example
A centralized system intended for a single computer is modified to run on a distributed
platform.

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
4. Data Re-engineering

Data Re-engineering provides an automated means to transform imperfect data from

multiple legacy and external sources into an accurate view of the business system.

It helps in:

• Improving accuracy, timeliness, customer service, and data validation.

• Reducing cost
• Performing cleanup and restructuring of data

Benefits of Software Re-engineering

1. Cost
Evidence from a number of U.S. projects suggests that re-engineering an existing
software system costs significantly less than developing new systems from scratch.
2. Lower Risk
Software re-engineering is based on incremental improvement of the system
rather than total system replacement. This reduces the risk of losing critical
software knowledge.
3. Better Use of Existing Staff
The skills of existing staff can be better utilized through re-engineering.
4. Incremental Development
The development is carried out incrementally rather than as a whole

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
Reverse Engineering
The process of reverse engineering is to extract the information from existing software.
Software reverse engineering is a process of analysing a system in order to:
• Identify its components and their relationships
• Produce a representation of the system in another form or at a higher level of
abstraction
The areas where reverse engineering is applicable include:
• Program comprehension
• Redocumentation and/or document generation
• Recovery of design approach
• Identifying reusable components
• Recovering business rules
• Understanding high level system description
There are some problems in re-implementation of existing software in new technology.
Following three approaches can be used to solve these problems:
1️. Re-writing the existing system manually
This approach allows precise changes to program structure but it is very time-consuming.
2. Use of Automated Source Translators
Use automated large translators to converts code quickly. But it results in poor structure,
poor quality, difficult to understand, and leads to higher maintenance costs
3️. Re-designing & Re-implementing the System
It produces high-quality software with lower maintenance cost.

Goals of Reverse Engineering

1️. Facilitating Software Reuse

Reverse engineering can help detect candidates for reusable software components from
the present system.
2. Generating Alternate Views
Reverse engineering tools help generate graphical representations from other forms such
as - Data flow diagrams, Control flow diagrams, Structure charts, E-R diagrams.
3. Recovery of Lost Information
Helps in recovering lost information from the existing system.
4. Detecting Side Effects
Identifies initial designs that might cause side effects harming system performance. Helps
detect issues early before users report them as bugs.

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
SOFTWARE CONFIGURATION MANAGEMENT ACTIVITIES

Software Configuration Management

Software configuration management deals with effectively tracking and controlling the
configuration of a software during its life cycle. The software may be considered as
configurations of software components. These software components are released in the form
of executable code whereas supplier organization work with the source code. This source
code is the representation of an executable equivalent, but not itself executable. Source Code
can be modified without there being any effect upon executable version. If care is not used,
if strict controls are not kept, the source code which is the exact representation of the earlier
executable version may no longer exist. The means by which the process of software
development and maintenance is controlled is called configuration management.

Thus, configuration management is concerned with the development of procedures and

standards for cost effective managing and controlling changes in an evolving software
system.

Configuration Management Activities

The activities are divided into four broad categories-

1. The identification of the components and changes.
2. The control of the way by which the changes are made.
3. Auditing the changes.
4. Status accounting - recording and documenting all the activities that have taken
place.

The following documents are required for these activities:

• Project plan
• Software requirements specification document
• Software design description document
• Source code listings
• Test plans/procedures/test cases
• User manuals

All components of the system configuration are recorded along with all relationships and
dependencies between them. Any changes and corrections should be checked and tested
and then recorded and fed back upon the rest of the configuration.

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
Software Versions
During software maintenance, there will be at least two versions of the software system: the
operational software system and the software system on which changes are being carried out.
During the process of software evolution, several versions of software documents, source
code, executable code and test data are produced. It's important to maintain a detailed record
of every version of the software and its revisions. One task in place is to ensure a detailed
record of the variations and revisions. This comprises:

• The versions of the software compiler and linkers used.

• Name of the software staff who constructed the component.
• The date and the time at which it was constructed.

Change Control Process

It will be appropriate if changes to software can be predicted. The software and associated
documentation are delivered to configuration management change request form, which
should record the proposed change, the supporting cost and how the change should be
implemented. This form is submitted to the Change Control Authority (CCA), which decides
whether or not the changes are to be accepted. If change is approved by the CCA, it is applied
to the software. The revised software is revalidated by the Software Quality Assurance
(SQA) team to ensure that the change has not adversely affected other parts of the software.
The changed software is handed over to the software configuration team and is incorporated
in a new version of the system.

The change control process ensures that changes to the system are controlled and their
effects on the system can be predicted.

The change control can be carried out using the following steps:

(i) A change request initiates a change.

(ii) The configuration object is "checked out" of the database.
(iii) The change is applied to the object.
(iv) The object is then checked in to the database where automatic version
control is applied.

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
An Overview of CASE Tools

CASE tools (Computer-Aided Software Engineering tools) automate the project

management activities and manage all the work products. They assist in performing various
software development tasks such as:
• Analysis
• Design
• Coding
• Testing

The use of CASE tools in the software development process reduces the significant amount
of effort and help to produce high-quality software efficiently.

CASE Environment

CASE tools are characterized by the stage or stages of SDLC on which they focus. Since
different toots covering different stages are share common information, it is required that
they integrate through some central repository. Through this all the CASE tools in CASE
environment share common information among themselves. Thus, a CASE environment
facilitates the automation of step-by-step methodologies for software development.

A central repository (data dictionary), which connects with the following tools:

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
Architecture of CASE Environment

The figure given previously shows a general architecture of a CASE environment. The
central component of this architecture is the repository, which is the most critical and
important feature of a CASE environment. The repository stores complete information
about Meta-models, Methods, Fuse lines, Process models. This information is shared
across different team members, improving efficiency and project management.

The repository must maintain the data required by various tools that support different
stages of the software life cycle.

Examples of CASE Tools Supporting at the Software Life Cycle

(i) Software Requirement Tool

These tools are used for modelling, tracing, and analysing requirements. Examples-
Turbo Analyst, Oracle Designer, Z2000, Relational Workbench, MS-Access etc.

(ii) Software Design Tool

These tools support system design stages such as- Design, Verification, Optimization.

(iii) Software Construction Tool

These are tools used to code/implement software and transform requirements into
working software. They include program editors used to create or modify software.
Example: Visual Studio

Additional CASE Tools

Compilers
These are the software tools that translate high-level language into executable code.
Interpreters
Tools that support line-by-line execution of a program.
Debuggers
Tools used for debugging programs.

(iv) Software Testing Tool

Automated tools that support various testing activities in the software testing phase of
the SDLC:
(A) Test generators
(B) Test execution & evolution tools
(C) Test management tools

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
(v) Software Maintenance Tool
Supports the maintenance of software post-deployment.

(vi) Software Quality Tool

Ensures software meets quality standards.

(vii) Configuration Management Tool

Helps manage system changes and version control.

(viii) Project Management Tool

Assists with planning, tracking, and managing software development projects.

Estimation of Various Parameters such as Cost, Efforts, Schedule/Duration

Software Cost Estimation is a process top predict/estimate approximate cost of software

project before development starts i.e. it describes approximate requirements of effort,
development time and resources to complete the software project.

Cost Estimation

• Bottom-Up Estimation: This approach involves estimating the cost of individual

project components or work packages and then aggregating them to determine the
total project cost. It requires detailed knowledge of the project scope, resources,
and activities.
• Analogous Estimation: Analogous estimation relies on historical data from similar
projects to estimate the cost of the current project. This approach is based on the
assumption that past projects with similar characteristics will have similar costs.
• Parametric Estimation: Parametric estimation uses mathematical models and
statistical techniques to estimate project costs based on specific project
parameters, such as size, complexity, and productivity metrics.
• Expert Judgment: Expert judgment involves soliciting input from experienced
project managers, software engineers, and domain experts to estimate project costs
based on their knowledge and expertise.

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
Effort Estimation:

• Expert Judgment: Similar to cost estimation, expert judgment is commonly used for
effort estimation. Experienced team members assess the tasks involved in the
project and provide estimates based on their knowledge and past experiences
• Work Breakdown Structure (WBS): Effort estimation can be done using a WBS,
which breaks down the project into smaller, manageable tasks. Effort estimates are
then assigned to each task based on its complexity and required resources.
• Function Point Analysis: Function point analysis quantifies the functionality
provided by a software system based on user requirements. Effort estimates are
derived by converting function points into person-hours using productivity metrics.
• COCOMO (Constructive Cost Model): COCOMO is a parametric estimation model
that estimates effort based on project size, complexity, and other factors. It
provides different variants (e.g., Basic COCOMO, Intermediate COCOMO, and
Detailed COCOMO) for projects of varying sizes and complexities.

Schedule/Duration Estimation:

• Critical Path Method (CPM): CPM is a project management technique used to

estimate the duration of a project by identifying the critical path—the longest
sequence of dependent tasks that determines the shortest possible duration of the
project.
• PERT (Program Evaluation and Review Technique): PERT is another project
management technique that uses three estimates for each task—optimistic,
pessimistic, and most likely—to calculate the expected duration of the project.
• Gantt Charts: Gantt charts visually represent project schedules by listing tasks on
the y-axis and time periods on the x-axis. Each task is represented by a horizontal
bar, allowing project managers to visualize task dependencies and allocate
resources effectively.
• Agile Estimation Techniques: In Agile methodologies, estimation is often done
using techniques such as story points, which represent the relative complexity of
user stories or features. Sprint planning and iteration reviews help refine schedule
estimates throughout the project.

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
Constructive Cost Models (COCOMO)

It stands for Constructive Cost Models. COCOMO is a regression model based on number
of Lines of Code (LOC). It is a procedural cost estimate model for software projects and is
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
1981 and is based on the study of 63 projects, which makes it one of the best-documented
models. COCOMO is a hierarchy of software cost estimation models, which include Basic,
Intermediate, and detailed sub models.

Basic Model

The basic model estimates most of the small to medium sized projects. Software projects are
classified into three categories:

• Organic: In the organic type, the project size typically from 2 to 50 KLOC; the
project deals with developing a well-understood application program; the team size
is generally small. This category is for the small to medium size software product. In
this type, team members have good experience and knowledge.
• Semi-detached: In the semi-detached type, the project size typically from 50 to 300
KLOC; the essential elements are team-size, experience, and knowledge of the
multiple programming languages. The projects that come under the semi-detached
are less familiar and hard to develop. It also requires better guidance, more
experienced developers.
• Embedded: In the embedded type, the project size over 300 KLOC; a software
project requires the highest level of complexity, creativity, and experience. In this
category, the larger team size is needed as compared to the previous models.

Depending on the problem the team might include a mixture of experienced and less
experienced people with only a recent history of working together. The Basic COCOMO
equations are -
• Effort (E): E = ab × (KLOC)bb
• Duration (D): D = cb × (E)db
• Staff Size (SS): SS = E / D
• Productivity (P): P = KLOC / E
Where:
• KLOC = Thousands of Lines of Code P: Productivity
• ab, bb, cb, db = constants based on project type E: Effort in person-months
• D: Development time in months SS: Team size (total number of people)
Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
The coefficients ab, bb, cb, db are given as -

Project ab bb cb db
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

Intermediate Model:

Intermediate COCOMO is an extension of Basic COCOMO that incorporates additional ser

of 15 factors called cost drivers that are divided into 4 groups - product attributes, hardware
constraints (Computer attributes), personnel capability (Personal attributes), and software
reliability (Project attributes). It provides more accurate estimates by considering these
additional parameters and is suitable for projects with moderate complexity. The effort
adjustment factor (EAF) is calculated by multiplying factors for all 15 cost drivers that ranges
from 0.9 to 1.4.

The Intermediate COCOMO equations are -

• Effort (E): E = ai × (KLOC)bi
• Duration (D): D = ci × (E)di
• Staff Size (SS): SS = E / D
• Productivity (P): P = KLOC / E

The coefficients ai, bi, ci, di are given as -

Project ai bi ci di
Organic 3.2 1.05 2.5 0.38
Semi detached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32

Detailed COCOMO Model

It offers a means for processing all the project characteristics to construct a software estimate.
The detailed model introduces two more capabilities:

1. Phase-sensitive effort multipliers:

Some phases (design, programming, integration/test) 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.
Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
 2. 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; that is, the level at
which it is most susceptible to variation.

Resource Allocation Models

Resource allocation models in software engineering refer to the approaches and techniques
used to effectively distribute and manage resources, such as human resources, time, budget,
and equipment, throughout the software development process. These models aim to optimize
resource utilization, minimize costs, and ensure project success.

Here are some common resource allocation models:

1. Waterfall Model: In the traditional waterfall model, resources are allocated

sequentially to different phases of the software development lifecycle (SDLC), such
as requirements gathering, design, implementation, testing, and maintenance. Each
phase has dedicated resources, and the allocation is predetermined based on
project plans and schedules.
2. Agile Resource Allocation: Agile methodologies, such as Scrum and Kanban,
emphasize flexible resource allocation based on evolving project needs and
priorities. Resources are allocated iteratively in short timeframes, known as sprints
or iterations, with the flexibility to adapt and reprioritize based on feedback and
changing requirements.
3. Critical Path Method (CPM): CPM is a project management technique used to
identify the critical path—the longest sequence of dependent tasks—in a project
schedule. By focusing resources on critical path activities, project managers can
optimize resource allocation to minimize project duration and ensure timely
completion.
4. Earned Value Management (EVM): EVM is a project management technique that
integrates project scope, schedule, and cost to assess project performance and
forecast future outcomes. By tracking the value of work completed against planned
costs and schedules, project managers can optimize resource allocation to achieve
project objectives efficiently.
5. Resource Leveling: Resource leveling is a technique used to optimize resource
allocation by smoothing out resource utilization over time. It involves redistributing

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
 resources to avoid peaks and valleys in resource demand, thereby minimizing
overallocation and under allocation of resources.
6. Resource Allocation Matrices: Resource allocation matrices provide a visual
representation of resource assignments across different project tasks or activities.
These matrices help project managers identify resource conflicts, balance
workloads, and optimize resource allocation based on skills, availability, and
dependencies.
7. Capacity Planning: Capacity planning involves estimating future resource
requirements based on project forecasts, historical data, and business objectives.
By proactively planning resource allocation, organizations can ensure they have the
necessary resources in place to support current and future projects effectively.
8. Resource Pooling: Resource pooling involves centralizing resources, such as
development teams, tools, and infrastructure, to maximize resource utilization and
efficiency across multiple projects. By sharing resources across projects,
organizations can reduce costs, improve collaboration, and achieve economies of
scale.

Software Risk Analysis and Management

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.

Software risk analysis

In Software Development risk analysis involves identifying which application risks should
be tested first. Risk can include issues like project management, technical challenges,
resource constraints, changes in requirements, and more Finding every possible risk and
estimating are the two goals of risk analysis. Think about the potential consequences of
testing your software and how it could impact your software when creating a test plan. Risk
detection during the production phase might be costly. Therefore, risk analysis in testing is
the best way to figure out what goes wrong before going into production.

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
Software Risk Management

Risk Management is the system of identifying addressing and eliminating these problems
(risks) before they can damage the project. Capers Jones has identified the top five factors
that threaten projects in different applications. These are-

Dependencies
Many risks arise due to dependencies of project on outside agencies or factors. It is not
easy to control these partly experienced people. Some dependency-related risk factors are:
• Availability of trained, experienced people
• Intercomponent or inter-group dependencies
• Customer-furnished items or information
• Internal and external subcontractor relationships

Requirement Issues
Many projects face uncertainty and turmoil around the product’s requirements. If we do not
control requirement-related risk factors well, then either we build the wrong product or the
right project badly—either situation results in unpleasant surprises and unhappy customers.
Some typical factors are:
• Lack of clear product vision
• Lack of agreement on product requirements
• Unprioritized requirements
• New market with uncertain needs
• Rapidly changing requirements
• Inadequate impact analysis of requirements changes

Management Issues
Project Managers usually write the risk management plan, and most people do not wish to
air their weaknesses (assuming they even recognize them) in public. Nonetheless, issues
like those listed below can make it harder for projects to succeed.
• Inadequate planning and task identification
• Inadequate visibility into actual project status
• Unclear project ownership and decision making
• Unrealistic commitments made, sometimes for the wrong reasons
• Managers or customers with unrealistic expectations
• Staff personality conflicts
• Poor communication

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
Lack of Knowledge

The rapid rate of change of technologies, and the increasing change of skilled staff, mean
that our project teams may not have the skills we need to be successful. The key is to
recognize the risk areas early enough so that we can take appropriate preventive actions.
Some of the factors are:

• Inadequate training
• Poor understanding of methods, tools, and techniques
• Inadequate application domain experience
• New technologies
• Ineffective, poorly documented, or neglected processes

Other Risk Categories

Some of the critical areas are:

• Unavailability of adequate testing facilities

• Turnover of essential personnel
• Unachievable performance requirements
• Technical approaches that may not work

Risk Management Activities:

Risk management involves several important steps, each of which are-

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)
Risk Assessment includes:

• Risk Identification
• Risk Analysis
• Risk Prioritization

Risk Control includes:

• Risk Management Planning

• Risk Monitoring
• Risk Resolution

Risk Assessment

It is the process of examining a project and identifying areas of potential risk. Risk
identification can be facilitated with the help of a checklist of common risk areas of software
projects; or by examining the contents of an organizational database of previously identified
risks. Risk analysis involves examining how project outcomes might change with
modification of risk input variables. Risk prioritization helps the project focus on its most
severe risks by assessing the risk exposure.

It may be easier to simply estimate both probability and impact as High, Medium, or Low.
Those items having at least one dimension rated as High are the ones to worry about first.

Another way of handling risk is the risk avoidance. Do not do the risky things! We may
avoid risks by not undertaking certain projects, or by relying on proven rather than cutting-
edge technologies.

Risk Control

It is the process of managing risks to achieve the desired outcomes. Risk management
planning produces a plan for dealing with each significant risk. It is useful to record decisions
in the plan, so that both customer and developer can review how problems are to be avoided,
as well as how they are to be handled when they arise. Risk monitoring involves monitoring
of the project as development progresses, periodically reevaluating the risks, their
probability, and likely impact. Risk resolution is the execution of the plans for dealing with
each risk.

Prepared By:
Mr. Sandeep Kumar
Assistant Professor (MPEC)