UNIT-IV

What is Software Quality?

Software Quality shows how good and reliable a product is. To convey an associate degree
example, think about functionally correct software. It performs all functions as laid out in
the SRS document. But, it has an associate degree virtually unusable program. Even though
it should be functionally correct, we tend not to think about it to be a high-quality product.
Another example is also that of a product that will have everything that the users need but
has an associate degree virtually incomprehensible and not maintainable code. Therefore,
the normal construct of quality as “fitness of purpose” for code products isn't satisfactory.

Software Quality – Definition:-

Software Quality means how well a software product meets user requirements, functions
correctly, and is free from defects.

In simple words:

“Software quality is the degree to which software satisfies the needs and expectations of its
users.”

Objectives of Software Quality

1. Ensure the software is reliable and error-free.
2. Make the software easy to use, maintain, and update.
3. Deliver software that meets performance and security standards.
4. Improve user satisfaction and reduce maintenance cost.

Two Aspects of Software Quality

Aspect Description
How well the product is planned — includes requirement analysis,
Quality of Design
design specifications, and architecture.
Quality of How well the actual product follows the design — includes coding
Conformance standards, testing, and error control.

Factors of Software Quality

The modern read of high-quality associates with software many quality factors like the
following:
1. Portability: A software is claimed to be transportable, if it may be simply created to
figure in several package environments, in several machines, with alternative code
products, etc.
2. Usability: A software has smart usability if completely different classes of users (i.e.
knowledgeable and novice users) will simply invoke the functions of the products.
3. Reusability: A software has smart reusability if completely different modules of the
products will simply be reused to develop new products.
4. Correctness: Software is correct if completely different needs as laid out in the SRS
document are properly enforced.
5. Maintainability: A software is reparable, if errors may be simply corrected as and once
they show up, new functions may be simply added to the products, and therefore the
functionalities of the products may be simply changed, etc
6. Reliability: Software is more reliable if it has fewer failures. Since software engineers
do not deliberately plan for their software to fail, reliability depends on the number and
type of mistakes they make. Designers can improve reliability by ensuring the software
is easy to implement and change, by testing it thoroughly, and also by ensuring that if
failures occur, the system can handle them or can recover easily.
7. Efficiency. The more efficient software is, the less it uses of CPU-time, memory, disk
space, network bandwidth, and other resources. This is important to customers in order
to reduce their costs of running the software, although with today’s powerful
computers, CPU time, memory and disk usage are less of a concern than in years gone
by.

Software Quality Assurance

Software Quality Assurance (SQA) is simply a way to assure quality in the software. It is the
set of activities that ensure processes, procedures as well as standards are suitable for the
project and implemented correctly. It is a process that works parallel to Software
Development. It focuses on improving the process of development of software so that
problems can be prevented before they become major issues. Software Quality Assurance is
a kind of Umbrella activity that is applied throughout the software process.
Quality
Quality in a product or service can be defined by several measurable characteristics. Each
of these characteristics plays a crucial role in determining the overall quality.
Generally, the quality of the software is verified by third-party organizations
like international standard organizations .
Elements/Formal Approaches of Software Quality Assurance (SQA):-
 Standards: The IEEE, ISO, and other standards organizations have produced a broad
array of software engineering standards and related documents. The job of SQA is to
ensure that standards that have been adopted are followed and that all work products
conform to them.
 Reviews and audits: Technical reviews are a quality control activity performed by
software engineers for software engineers. Their intent is to uncover errors. Audits are a
type of review performed by SQA personnel (people employed in an organization) with
the intent of ensuring that quality guidelines are being followed for software
engineering work.
 Testing: Software testing is a quality control function that has one primary goal to find
errors. The job of SQA is to ensure that testing is properly planned and efficiently
conducted for primary goal of software.
 Error/defect collection and analysis : SQA collects and analyzes error and defect data
to better understand how errors are introduced and what software engineering activities
are best suited to eliminating them.
 Change management: SQA ensures that adequate change management practices have
been instituted.
 Education: Every software organization wants to improve its software engineering
practices. A key contributor to improvement is education of software engineers, their
managers, and other stakeholders. The SQA organization takes the lead in software
process improvement which is key proponent and sponsor of educational programs.
 Security management: SQA ensures that appropriate process and technology are used
to achieve software security.
 Safety: SQA may be responsible for assessing the impact of software failure and for
initiating those steps required to reduce risk.
 Risk management : The SQA organization ensures that risk management activities are
properly conducted and that risk-related contingency plans have been established.

Focus of Software Quality Assurance (SQA)

The Software Quality Assurance (SQA) focuses on the following :
 Software's Portability: Software's portability refers to its ability to be easily
transferred or adapted to different environments or platforms without needing
significant modifications. This ensures that the software can run efficiently across
various systems, enhancing its accessibility and flexibility.
 Software's Usability: Usability of software refers to how easy and intuitive it is for
users to interact with and navigate through the application. A high level of usability
ensures that users can effectively accomplish their tasks with minimal confusion or
frustration, leading to a positive user experience.
 Software's Reusability: Reusability in software development involves designing
components or modules that can be reused in multiple parts of the software or in
different projects. This promotes efficiency and reduces development time by
eliminating the need to reinvent the wheel for similar functionalities, enhancing
productivity and maintainability.
 Software's Correctness: Correctness of software refers to its ability to produce the
desired results under specific conditions or inputs. Correct software behaves as
expected without errors or unexpected behaviors, meeting the requirements and
specifications defined for its functionality.
 Software's Maintainability: Maintainability of software refers to how easily it can be
modified, updated, or extended over time. Well maintained software is structured and
documented in a way that allows developers to make changes efficiently without
introducing errors or compromising its stability.
 Software's Error Control: Error control in software involves implementing
mechanisms to detect, handle, and recover from errors or unexpected situations
gracefully. Effective error control ensures that the software remains robust and reliable,
minimizing disruptions to users and providing a smoother experience overall.

Major Activities in Software Quality Assurance (SQA)

 SQA Management Plan: Make a plan for how you will carry out the SQA throughout
the project. Think about which set of software engineering activities are the best for
project. check level of SQA team skills.
 Set The Check Points: SQA team should set checkpoints. Evaluate the performance of
the project on the basis of collected data on different check points.
 Measure Change Impact: The changes for making the correction of an error
sometimes re introduces more errors keep the measure of impact of change on project.
Reset the new change to check the compatibility of this fix with whole project.
 Multi testing Strategy: Do not depend on a single testing approach. When you have a
lot of testing approaches available use them.
 Manage Good Relations: In the working environment managing good relations with
other teams involved in the project development is mandatory. Bad relation of SQA
team with programmers team will impact directly and badly on project.
 Maintaining records and reports: Comprehensively document and share all QA
records, including test cases, defects, changes, and cycles, for stakeholder awareness
and future reference.
 Reviews software engineering activities: The SQA group identifies and documents the
processes. The group also verifies the correctness of software product.
 Formalize deviation handling: Track and document software deviations meticulously.
Follows established procedures for handling variances.

Benefits of Software Quality Assurance (SQA)

 SQA produces high quality software.
 High quality application saves time and cost.
 SQA is beneficial for better reliability.
 SQA is beneficial in the condition of no maintenance for a long time.
 High quality commercial software increase market share of company.
 Improving the process of creating software.
 Improves the quality of the software.
 It cuts maintenance costs. Get the release right the first time, and your company can
forget about it and move on to the next big thing. Release a product with chronic issues,
and your business bogs down in a costly, time consuming, never-ending cycle of
repairs.

Disadvantage of Software Quality Assurance (SQA)

There are a number of disadvantages of quality assurance.
 Cost: Some of them include adding more resources, which cause the more budget its
not, addition of more resources for betterment of the product.
 Time Consuming: Testing and Deployment of the project taking more time which
cause delay in the project.
 Overhead : SQA processes can introduce administrative overhead, requiring
documentation, reporting, and tracking of quality metrics. This additional administrative
burden can sometimes outweigh the benefits, especially for smaller projects.
 Resource Intensive : SQA requires skilled personnel with expertise in testing
methodologies, tools, and quality assurance practices. Acquiring and retaining such
talent can be challenging and expensive.
 Resistance to Change : Some team members may resist the implementation of SQA
processes, viewing them as bureaucratic or unnecessary. This resistance can hinder the
adoption and effectiveness of quality assurance practices within an organization.
 Not Foolproof : Despite thorough testing and quality assurance efforts, software can
still contain defects or vulnerabilities. SQA cannot guarantee the elimination of all bugs
or issues in software products.
 Complexity : SQA processes can be complex, especially in large-scale projects with
multiple stakeholders, dependencies, and integration points. Managing the complexity
of quality assurance activities requires careful planning and coordination.

Statistical Software Quality Assurance (Statistical SQA)

Statistical Software Quality Assurance (SQA) is a quantitative approach that uses
statistical and mathematical techniques to measure, control, and improve the quality of
software products and processes.
It focuses on collecting data about defects, failures, and performance, and using statistical
analysis to make informed decisions for quality improvement.
Key Concepts in Statistical SQA:

1. Error and Defect Collection:

o Data is collected during each phase of software development (requirements,
design, coding, testing).
o Includes number, type, and cause of errors/defects.

Example: Counting the number of logic errors or syntax errors per module.

2. Error Categorization:
  Defects are grouped into categories (e.g., requirements errors, design errors, coding
errors).
 Helps identify the most error-prone areas in software.

Example:

 40% errors from design

 30% from coding
 20% from requirements
 10% from documentation

3. Statistical Analysis:

 Collected data is analyzed using statistical techniques such as:

o Mean, median, mode (central tendency)
o Standard deviation, variance (dispersion)
o Control charts
o Pareto analysis
o Regression analysis

Goal: Identify trends, patterns, and root causes of defects.

4. Process Metrics and Control:

 Metrics are used to measure software quality and process performance.

Examples:
o Defects per KLOC (thousand lines of code)
o Mean Time Between Failures (MTBF)
o Defect Removal Efficiency (DRE)
 Control charts are used to determine if the process is within acceptable limits or
needs correction.

5. Feedback and Process Improvement:

o The results from statistical analysis guide process adjustments to reduce
future defects.
o Continuous feedback ensures quality improvement and process
optimization.

Advantages of Statistical SQA:

 Provides objective and measurable data on software quality.

 Helps in early detection of quality issues.
 Supports continuous process improvement.
 Reduces cost and rework by identifying recurring problems.

Disadvantages:

 Requires consistent and accurate data collection.

 Needs trained personnel for statistical analysis.
 Not useful if project data is insufficient or inconsistent.
Statistical SQA applies statistical techniques to collect, analyze, and interpret data related to
software errors and defects, ensuring that software processes remain under control and
continuously improve in quality.

Capability Maturity Model (CMM)

Definition:

The Capability Maturity Model (CMM) is a framework developed by the Software

Engineering Institute (SEI) at Carnegie Mellon University.
It is used to assess and improve the maturity of software development processes within an
organization.

CMM provides a structured path for process improvement, helping organizations move
from ad hoc and chaotic processes to disciplined and optimized ones.

Purpose of CMM:

 To evaluate the capability of an organization’s software processes.

 To guide process improvement in a step-by-step manner.
 To ensure consistent quality and predictable results in software projects.

CMM Structure:

CMM defines five maturity levels, each representing a different stage in process maturity.

Level 1: Initial (Ad hoc)

 Processes are undefined and chaotic/scattered

 Success depends on individual effort, not on a structured process.
 No stable environment for software development.

Example: Projects succeed due to talented individuals, not repeatable methods.

Level 2: Repeatable

 Basic project management practices are established.

 Processes can be repeated for similar projects.
 Focus on requirements management, project tracking, and quality assurance.

Key Processes:

 Requirements Management
 Project Planning and Tracking
 Configuration Management

Level 3: Defined

 Processes are well-documented, standardized, and integrated into the organization.

 There is a defined process framework for all projects.
 Focus on process standardization and organization-wide consistency.
Key Processes:

 Organizational Process Focus

 Training Program
 Product Engineering

🔹 Level 4: Managed

 Processes are quantitatively measured and controlled.

 Uses metrics and statistical techniques to manage process performance.
 Focus on quantitative quality goals.

Key Processes:

 Quantitative Process Management

 Software Quality Management

🔹 Level 5: Optimizing

 Focus on continuous process improvement.

 Uses feedback and innovation to refine processes.
 Emphasis on defect prevention and technology change management.

Key Processes:

 Process Change Management

 Technology Innovation

Diagram: CMM Maturity Levels

Level 5 – Optimizing

Level 4 – Managed

Level 3 – Defined

Level 2 – Repeatable

Level 1 – Initial

Each higher level builds on the previous one, improving consistency and control.

Benefits of CMM:

 Improves software quality and productivity.

 Increases customer satisfaction.
 Reduces cost and rework.
  Helps in project predictability and risk management.

Limitations of CMM:

 Time-consuming and expensive to implement.

 Rigid structure may not fit all organizations.
 Focuses more on process than innovation or people skills.

The Capability Maturity Model (CMM) is a five-level framework that helps organizations
evaluate, control, and improve their software development processes — moving from
chaotic (Level 1) to continuously improving (Level 5) maturity.

ISO/IEC 9126
The International Organization for Standardization (ISO) has established a series of ISO and
ISO/IEC standards for software quality. Starting with the ISO 9000-3 instructions for
implementing the ISO 9001 standard, which is concerned with quality assurance processes,
to the creation, supply, installation, and maintenance of computer software. The ISO/IEC
9126 standard for software product quality should be used in conjunction with ISO/IEC
14598 for evaluating software products.

What is ISO/IEC 9126?

ISO/IEC 9126 is an international standard proposed to make sure 'quality of all software-
intensive products' which includes a system like safety-critical where in case of failure of
software lives will be in jeopardy. ISO i.e. International Organization for
Standardization and IEC i.e. International Electrotechnical Commission have developed
ISO/IEC 9126 standards for software engineering → Product Quality to provide an all-
inclusive specification and evaluation model for the quality of the software product.

ISO/IEC 9126 is an international standard for evaluating software quality.

It defines a framework for assessing software based on a set of quality characteristics and
their sub-characteristics.

Developed by the International Organization for Standardization (ISO) and the

International Electrotechnical Commission (IEC), this model ensures that software meets
user needs and performs reliably under all conditions.

Parts of ISO/IEC 9126

The standard is divided into 4 parts as depicted in the following figure:

1. ISO/IEC 9126-1: Quality Model

2. ISO/IEC 9126-2: External Metrices
 3. ISO/IEC 9126-3: Internal Metrices
4. ISO/IEC 9126-4: Quality in use Matrices

The Four Parts of ISO/IEC 9126

The standard was divided into four parts:

1. Quality Model: Defined the 6 characteristics and 27 sub-characteristics described above.

2. External Metrics: Defined metrics for measuring the behavior of the software when tested in
a simulated or real environment (i.e., "black-box" testing).
3. Internal Metrics: Defined metrics for measuring the software itself, typically applied during
the design and code phases (i.e., "white-box" testing). Internal metrics are meant to predict
external quality.
4. Quality in Use Metrics: Defined metrics for measuring the effect of using the software in a
specific context of use, focusing on the user's outcome (effectiveness, productivity, safety,
and satisfaction).

Quality Model
Quality Model describes the quality model framework which explains relationships between
different approaches to quality as well as identifying quality characteristics and sub-
characteristics of software products.

Classification of Quality Model

Furthermore, the first part i.e. the Quality model is concerned classified into two categories
as depicted in the following figure:

Internal External Quality Part

Internal External Quality Part determines the quality of a software product through six
characteristics which are Functionality, Reliability, Usability, Efficiency, Maintainability,
and Portability.
Functionality
The functions are those that will satisfy implied needs.
 Suitability
 Accuracy
 Interoperability
 Security
 Functionality Compliance

Reliability
A set of attributes that will bear on the capability of software to maintain the level of
performance.
 Maturity
 Fault Tolerance
 Recoverability
 Reliability Compliance

Usability
A set of attributes that bear on the effort needed for use by an implied set of users.
 Understandability
 Learnability
 Operability
 Attractiveness
 Usability Compliance
Efficiency
A set of attributes that bear on the relationship between the level of performance of the
software under stated conditions.
 Time Behavior
 Resource Utilization
 Efficiency Compliance
Maintainability
A set of attributes that bear on the effort needed to make specified modifications.
 Analyzability
 Changeability
 Stability
 Testability
 Maintainability Compliance
Portability
A set of attributes that bear on the ability of software to be transferred from one
environment to another.
 Adaptability
 Installability
 Co-existence
 Replaceability
 Portability Compliance
Quality in Use Model
It identifies the four quality characteristics.
 Effectiveness
 Productivity
 Safety
 Satisfaction
External Metrics
External Metrices is used to describe external metrics that are used to measure
characteristics and sub-characteristics which are identified in quality model.

Internal Metrics
Internal Metrices is used to describe internal metrics that are used to measure
characteristics and sub-characteristics which are identified in quality model.

Quality in use metrics

Quality in use metrices is used to identify metrics that are used to measure the effects of
combined quality characteristics for users.

History of ISO/IEC 9126

Below are some points related to history of ISO/IEC 9126
 Release date of ISO/IEC 9126: December 19, 1991.
 ISO/IEC 9126:2001 (four parts, 9126–1 to 9126–4) took the place of ISO/IEC
9126:1991 on June 15, 2001.
 ISO/IEC 25010:2011 Systems and software engineering - Systems and software Quality
Requirements and Evaluation (SQuaRE) - System and software quality models took the
role of ISO/IEC 9126 on March 1, 2011. "Security" and "compatibility" were
introduced as primary features in comparison to 9126.

Benefits of ISO 9126:

 Provides a universal framework for measuring software quality.

 Helps in objective software evaluation.
 Improves customer satisfaction by ensuring quality across all attributes.
 Supports software comparison and quality assurance processes.

Limitations:

 Implementation can be complex and time-consuming.

 Focuses on product quality, not the development process.
 Later replaced and expanded by ISO/IEC 25010.

ISO 9126 defines six key software quality characteristics—Functionality, Reliability,

Usability, Efficiency, Maintainability, and Portability—that provide a standardized
framework for evaluating and improving software quality.

SCM – Software Configuration Management

Definition:
Software Configuration Management (SCM) is a systems engineering process for
establishing and maintaining consistency of a software product's performance, functional,
and physical attributes with its requirements, design, and operational information throughout
its life.
In simpler terms, it's the discipline of identifying, organizing, controlling, and tracking
changes to the software and its components (code, documents, etc.) throughout the
development lifecycle.

Think of it as the "source code traffic cop" for a software project.

🔹 Objective of SCM:

 To control and manage software changes efficiently.

 To ensure consistency among all versions of software artifacts (code, documents,
design, etc.).
 To maintain traceability of all modifications made during the software life cycle.

🔹 Key Activities of SCM:

1. Configuration Identification
o Identifies and defines the components (items) that need to be managed.
o Each item (source code file, design document, test case, etc.) is assigned a
unique identifier.
o These items are grouped into configuration items (CIs) or baselines.

Example: Version numbers like v1.0, v1.1, etc.

2. Configuration Control (Change Control)

o Controls changes to configuration items after they are formally approved.
o Changes are reviewed, approved, and documented through a Change Control
Board (CCB).
o Ensures only authorized changes are made.

Example: Using a formal process for updating source code after testing approval.

3. Configuration Status Accounting

o Records and reports the status of configuration items and changes.
o Maintains history, version records, and change logs.
o Provides clear visibility of what version is currently in use.

Example: Maintaining logs of which version is deployed and who approved it.

4. Configuration Auditing
o Verifies that configuration items conform to their specifications.
o Checks that all approved changes have been implemented correctly.
o Ensures software baseline integrity.

Example: Reviewing the source repository to confirm no unauthorized code was

added.

🔹 SCM Process Flow:

Identification → Control → Status Accounting → Auditing

These activities ensure complete control over software evolution.

🔹 SCM Tools:

 Git
 SVN (Subversion)
 CVS (Concurrent Versions System)
 Microsoft Team Foundation Server (TFS)
 ClearCase, Bitbucket, GitHub, GitLab

🔹 Benefits of SCM:

 Prevents loss of data or confusion in multiple versions.

 Enables team collaboration on shared codebases.
 Helps in bug tracking and rollback to previous stable versions.
 Ensures accountability and traceability of every change.
 Supports continuous integration and deployment (CI/CD).

🔹 Example Scenario:

If multiple developers work on a project:

 Developer A adds a feature.

 Developer B fixes a bug.
 SCM keeps track of both changes, merges them properly, and prevents overwriting
each other’s work.

Software Configuration Management (SCM) is the discipline of controlling, tracking, and

managing changes in software to ensure consistency, accuracy, and integrity across all
project versions and artifacts.

Re-engineering:-
Software Re-engineering is a process of software development that 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, also known as software re-engineering, is the process of analysing,

designing, and modifying existing software systems to improve their quality, performance,
and maintainability.
1. This can include updating the software to work with new hardware or software
platforms, adding new features, or improving the software's overall design and
architecture.
2. Software re-engineering, also known as software restructuring or software renovation,
refers to the process of improving or upgrading existing software systems to improve
their quality, maintainability, or functionality.
3. It involves reusing the existing software artifacts, such as code, design, and
documentation, and transforming them to meet new or updated requirements.
Objective of Re-engineering
The primary goal of software re-engineering is to improve the quality and maintainability of
the software system while minimizing the risks and costs associated with the redevelopment
of the system from scratch. Software re-engineering can be initiated for various reasons, such
as:
1. To describe a cost-effective option for system evolution.
2. To describe the activities involved in the software maintenance process.
3. To distinguish between software and data re-engineering and to explain the problems of
data re-engineering.
Overall, software re-engineering can be a cost-effective way to improve the quality and
functionality of existing software systems, while minimizing the risks and costs associated
with starting from scratch.

Process of Software Re-engineering

The process of software re-engineering involves the following steps:

1. Planning: The first step is to plan the re-engineering process, which involves
identifying the reasons for re-engineering, defining the scope, and establishing the goals
and objectives of the process.
2. Analysis: The next step is to analyze the existing system, including the code,
documentation, and other artifacts. This involves identifying the system's strengths and
weaknesses, as well as any issues that need to be addressed.
3. Design: Based on the analysis, the next step is to design the new or updated software
system. This involves identifying the changes that need to be made and developing a
plan to implement them.
4. Implementation: The next step is to implement the changes by modifying the existing
code, adding new features, and updating the documentation and other artifacts.
5. Testing: Once the changes have been implemented, the software system needs to be
tested to ensure that it meets the new requirements and specifications.
6. Deployment: The final step is to deploy the re-engineered software system and make it
available to end-users.
Why Perform Re-engineering?
Re-engineering can be done for a variety of reasons, such as:
1. To improve the software's performance and scalability: By analyzing the existing
code and identifying bottlenecks, re-engineering can be used to improve the software's
performance and scalability.
2. To add new features: Re-engineering can be used to add new features or functionality
to existing software.
3. To support new platforms: Re-engineering can be used to update existing software to
work with new hardware or software platforms.
4. To improve maintainability: Re-engineering can be used to improve the software's
overall design and architecture, making it easier to maintain and update over time.
5. To meet new regulations and compliance: Re-engineering can be done to ensure that
the software is compliant with new regulations and standards.
6. Improving software quality: Re-engineering can help improve the quality of software
by eliminating defects, improving performance, and enhancing reliability and
maintainability.
7. Updating technology: Re-engineering can help modernize the software system by
updating the technology used to develop, test, and deploy the system.
8. Enhancing functionality: Re-engineering can help enhance the functionality of the
software system by adding new features or improving existing ones.
9. Resolving issues: Re-engineering can help resolve issues related to scalability, security,
or compatibility with other systems.

Steps involved in Re-engineering

1. Inventory Analysis
2. Document Reconstruction
3. Reverse Engineering
4. Code Reconstruction
5. Data Reconstruction
6. Forward Engineering
 Re-engineering Cost Factors
1. The quality of the software to be re-engineered.
2. The tool support available for re-engineering.
3. The extent of the required data conversion.
4. The availability of expert staff for re-engineering.

Benefits of Software Reengineering

Reengineering is undertaken to achieve significant long-term advantages for both the
software product and the business that depends on it.

1. Improved Maintainability & Reduced Costs

o Benefit: The primary goal. By cleaning up spaghetti code, improving structure, and updating
documentation, the system becomes much easier to understand, debug, and modify.
o Result: This dramatically reduces the time, effort, and cost required for future maintenance
and enhancements.
2. Extended System Lifespan
o Benefit: Reengineering breathes new life into critical legacy systems that are too expensive
to replace but are becoming unstable or costly to maintain.
o Result: The business can continue to use its proven, core business logic for many more years,
protecting its initial investment.
3. Enhanced Performance and Reliability
o Benefit: The process often includes optimizing algorithms, restructuring data, and removing
redundant code.
o Result: The system can run faster, use fewer resources, and experience fewer crashes,
leading to increased user satisfaction and productivity.
4. Migration to Modern Platforms
o Benefit: Allows a business to move a critical application from an outdated, expensive
platform (e.g., a mainframe) to a modern, cost-effective one (e.g., cloud services like AWS or
Azure).
o Result: Reduces operational costs (e.g., hardware, software licenses) and unlocks new
capabilities like scalability and elasticity.
5. Improved Documentation and Understanding
o Benefit: The reverse engineering phase recovers the system's design and logic, creating
accurate, up-to-date documentation.
o Result: Reduces dependency on a few "expert" developers and makes it easier to onboard
new team members.
6. Better Alignment with Business Needs
o Benefit: A more maintainable system can be adapted more quickly to changing business
requirements.
o Result: Increased business agility and the ability to compete more effectively in the market.

Limitations and Risks of Software Reengineering

Despite its benefits, reengineering is not a silver bullet and comes with its own set of
challenges and risks.
1. High Initial Cost and Resource Investment
o Limitation: Reengineering is a significant project that requires time, money, and skilled
personnel. It is a substantial upfront investment.
o Risk: The cost may be difficult to justify to management, especially when compared to the
seemingly lower short-term cost of simple maintenance.
2. Risk of Introducing New Defects
o Limitation: When restructuring code and data, there is a genuine risk of introducing new
bugs that weren't in the original system.
o Risk: This can lead to a period of instability after the reengineered system is deployed,
damaging user confidence.
3. Not a Solution for Fundamentally Flawed Systems
o Limitation: If the core architecture or underlying business logic of the original system is
deeply flawed or no longer relevant, reengineering may just be "polishing a turd."
o Risk: In such cases, a complete rewrite might be a more effective long-term solution, even
though it's more expensive and risky.
4. Requires Specialized Skills and Tools
o Limitation: The team needs expertise in both the old system's technology and the new target
technologies. Reverse engineering tools can also be complex and expensive.
o Risk: Finding developers who understand legacy systems (e.g., COBOL, PowerBuilder) can
be difficult and costly.
5. Disruption to Ongoing Operations
o Limitation: The reengineering process can divert key personnel from normal maintenance
and new development projects.
o Risk: This can slow down the organization's overall development velocity and
responsiveness during the project.
6. "It Worked Fine Before" Mentality
o Limitation: There can be significant resistance from users and even management who are
accustomed to the old system and see no immediate problem with it.
o Risk: A lack of organizational buy-in can lead to project failure or underfunding.

Reverse Engineering
Reverse engineering can extract design information from source code, but the abstraction
level, the completeness of the documentation, the degree to which tools and a human analyst
work together, and the directionality of the process are highly variable

Objective of Reverse Engineering:

1. Reducing Costs: Reverse engineering can help cut costs in product development by
finding replacements or cost-effective alternatives for systems or components.
2. Analysis of Security: Reverse engineering is used in cybersecurity to examine exploits,
vulnerabilities, and malware. This helps in understanding of threat mechanisms and the
development of practical defenses by security experts.
3. Integration and Customization: Through the process of reverse engineering, developers
can incorporate or modify hardware or software components into pre-existing systems to
improve their operation or tailor them to meet particular needs.
4. Recovering Lost Source Code: Reverse engineering can be used to recover the source
code of a software application that has been lost or is inaccessible or at the very least, to
produce a higher-level representation of it.
5. Fixing bugs and maintenance: Reverse engineering can help find and repair flaws or
provide updates for systems for which the original source code is either unavailable or
inadequately documented.

Reverse Engineering Goals:

1. Cope with Complexity: Reverse engineering is a common tool used to understand and
control system complexity. It gives engineers the ability to analyze complex systems and
reveal details about their architecture, relationships and design patterns.
2. Recover lost information: Reverse engineering seeks to retrieve as much information as
possible in situations where source code or documentation are lost or unavailable.
Rebuilding source code, analyzing data structures and retrieving design details are a few
examples of this.
3. Detect side effects: Understanding a system or component's behavior requires analyzing
its side effects. Unintended implications, dependencies, and interactions that might not be
obvious from the system's documentation or original source code can be found with the
use of reverse engineering.
4. Synthesis higher abstraction: Abstracting low-level features in order to build higher-level
representations is a common practice in reverse engineering. This abstraction makes
communication and analysis easier by facilitating a greater understanding of the system's
functionality.
5. Facilitate Reuse: Reverse engineering can be used to find reusable parts or modules in
systems that already exist. By understanding the functionality and architecture of a
system, developers can extract and repurpose components for use in other projects,
improving efficiency and decreasing development time.

Re Engineering

Steps of Software Reverse Engineering:

1. Collection Information: This step focuses on collecting all possible information (i.e.,
source design documents, etc.) about the software.
2. Examining the Information: The information collected in step-1 is studied so as to get
familiar with the system.
 3. Extracting the Structure: This step concerns identifying program structure in the form
of a structure chart where each node corresponds to some routine.
4. Recording the Functionality: During this step processing details of each module of the
structure, charts are recorded using structured language like decision table, etc.
5. Recording Data Flow: From the information extracted in step-3 and step-4, a set of
data flow diagrams is derived to show the flow of data among the processes.
6. Recording Control Flow: The high-level control structure of the software is recorded.
7. Review Extracted Design: The design document extracted is reviewed several times to
ensure consistency and correctness. It also ensures that the design represents the
program.
8. Generate Documentation: Finally, in this step, the complete documentation including
SRS, design document, history, overview, etc. is recorded for future use.

Reverse Engineering Tools:

Reverse engineering tools accept source code as input and produce a variety of structural,
procedural, data, and behavioral design. Reverse engineering if done manually would
consume a lot of time and human labor and hence must be supported by automated tools.
Some of the tools are given below:
1. CIAO and CIA: A graphical navigator for software and web repositories and a
collection of Reverse Engineering tools.
2. Rigi: A visual software understanding tool.
3. Bunch: A software clustering/modularization tool.
4. GEN++: An application generator to support the development of analysis tools for the
C++ language.
5. PBS: Software Bookshelf tools for extracting and visualizing the architecture of
programs.

Restructuring
Restructuring (also known as Refactoring) is the process of modifying the internal structure
of existing software code without changing its external behavior. The primary goal is to
improve non-functional attributes such as:

 Readability and Understandability

 Maintainability
 Testability
 Extensibility (reducing the cost of future changes)
 Reducing Complexity

The fundamental rule is: The software must behave exactly the same way after
restructuring as it did before.

Why is Restructuring Necessary? (The "Why")

Software naturally degrades in design quality over time due to continuous changes, a
phenomenon known as "Architectural Decay" or "Technical Debt." This happens because
of:

 Rushed Deadlines: Quick fixes and "hacks" are implemented to meet a release date.
 Evolving Requirements: The original design is stretched to accommodate features it wasn't
built for.
 Lack of Understanding: Developers modifying code they don't fully understand.
 Accumulated Patches: Over years, small changes compound into a tangled mess.

This results in code that is brittle (small changes break unrelated things), hard to
understand, and risky to modify.

Key Goals and Benefits

Goal Benefit

Improve Code Makes the code easier for current and future developers to understand,
Readability reducing onboarding time.

Simplifies the control flow and data structures, making the code less
Reduce Complexity
prone to bugs.

Improve
Makes it faster and cheaper to fix bugs and add new features.
Maintainability

Identifies and extracts reusable components from within monolithic

Facilitate Reuse
code.

Prepare for Cleans up the architecture to make the next major feature easier to
Extension implement.

Reduce Technical Proactively pays down the "interest" that makes future changes
Debt difficult.

The Restructuring Process

Restructuring is not a haphazard activity. It follows a disciplined approach:

1. Identify a "Code Smell": Recognize a part of the code that is problematic (e.g., a very long
function, duplicated code, a class that does too much).
2. Choose a Specific Restructuring Technique: Select a well-defined, small-scale
transformation to address the smell (e.g., "Extract Method," "Rename Variable").
3. Apply the Technique: Make the change.
4. Run Tests: Execute the test suite immediately to ensure no behavior has changed. This is the
safety net.

This process is typically done in small, incremental steps rather than in a massive, "big bang"
rewrite.

Forward Engineering
Forward Engineering is the traditional process of moving from high-level abstractions and
logical designs to the physical implementation of a system. It's the "from scratch"
development approach where you progress through well-defined stages from concept to
concrete system.

In simple terms, it's building the software from the idea to the code.

The Classic Paradigm: "Plan and Build"

Forward engineering is characterized by a systematic, sequential (or iterative) flow from
requirements to deployment. It's what most people think of when they imagine "software
development."

Key Goals and Objectives

The primary goal is to systematically transform a set of requirements into a functional, high-
quality software system.

Goal Description

Systematic To create a predictable and repeatable process for building

Implementation software.

To ensure the final product correctly implements all specified

Requirement Fulfillment
requirements.

To build quality into the product from the beginning through

Quality by Design
careful planning and design.

To create comprehensive documentation (design specs,

Documentation
architecture diagrams) that aligns with the final system.

Scalability & To create a system with a solid architectural foundation that is

Maintainability easy to extend and maintain.
 The Forward Engineering Process (Traditional Workflow)

This is often embodied in models like the Waterfall Model or the phases within an iteration
of an Iterative Model or Spiral Model.

1. Requirements Gathering & Analysis:

o What: Understanding and documenting what the system must do.
o Output: Software Requirements Specification (SRS), user stories, use cases.
2. System Design:
o What: Deciding how the system will meet the requirements. This involves defining the
overall architecture, components, databases, and interfaces.
o Output: System Design Document (SDD), architecture diagrams, technology stack
decisions.
3. Implementation (Coding):
o What: Translating the design into executable code. This is the core "construction" phase.
o Output: Source code, executable modules.
4. Testing:
o What: Verifying that the implemented code works as expected and is free of defects.
o Output: Test reports, bug logs, a validated system.
5. Deployment:
o What: Releasing the system for end-users to operate.
o Output: Live, operational system.
6. Maintenance:
o What: Fixing bugs, providing updates, and making enhancements after deployment.
o Output: Patches, new versions.

Software Project Management (SPM)

Software Project Management (SPM) is a proper way of planning and leading software
projects. It is a part of project management in which software projects are planned,
implemented, monitored, and controlled.
Software Project Management (SPM) is all about planning, organizing, and observing the
software development process to make sure the project is completed successfully, on time,
and within budget. It involves tasks like planning, defining the project scope, calculating
how much time and resources are needed, scheduling tasks, allocating resources, and
tracking progress.
The ultimate goal is to deliver a high-quality software product that meets the needs and
expectations of the users.

Need for Software Project Management

The need for Software Project Management (SPM) arises because developing software is a
complex, time-bound, and resource-intensive process that requires careful planning,
organization, coordination, and control. Below are the key reasons why SPM is essential:-
1. To Handle Project Complexity
2. To Manage Time, Cost, and Resources
3. To Coordinate Team Efforts
4. To Achieve Quality and Customer Satisfaction
5. To Manage Risks
6. To Improve Predictability and Control
7. To Handle Changing Requirements
8. To Ensure Better Documentation and Learning
Software Project Management is essential to ensure that software is developed efficiently,
within time and budget constraints, meets quality standards, and satisfies customer
expectations.

Software Project Planning

Software Project Planning is the initial and most crucial phase of software project
management. It involves defining the scope, objectives, resources, schedule, and
procedures required to complete the software project successfully.
Software Project Planning is the process of deciding in advance what, when, how, and by
whom the software will be developed.
It provides a blueprint or roadmap for the entire development process.

Objectives of Software Project Planning

 To define project scope and goals clearly.

 To estimate time, cost, and resources accurately.
 To identify and minimize risks.
 To ensure efficient use of resources.
 To achieve quality software within time and budget limits.

Steps in Software Project Planning

a) Project Scope Definition

 Identify the objectives, deliverables, and boundaries of the project.

 Understand customer requirements clearly.

b) Feasibility Study

 Analyze the project’s technical, economic, and operational feasibility to check if it

is achievable.

c) Project Estimation

 Estimate:
o Effort (person-hours or person-months)
o Cost (hardware, software, manpower)
 o Schedule (time duration for each activity)
 Estimation techniques: COCOMO Model, Function Point Analysis.

d) Scheduling

 Divide the project into tasks and milestones.

 Use tools like Gantt Charts or PERT/CPM Charts for timeline representation.

e) Resource Allocation

 Assign team members, tools, and technologies for different tasks based on their
expertise.

f) Risk Management

 Identify potential risks (technical, financial, or personnel).

 Prepare risk mitigation and contingency plans.

g) Quality Assurance Planning

 Define quality standards, testing strategies, and validation methods.

h) Communication Planning

 Establish a communication plan for regular progress reporting and coordination

among stakeholders.

Importance of Software Project Planning

 Provides a clear direction and structured workflow.

 Prevents cost overruns and schedule delays.
 Helps in monitoring and controlling project progress.
 Reduces risks and uncertainties.
 Ensures successful and timely delivery of quality software.

Software Project Planning is the backbone of software development.

It ensures that all project activities are properly organized, resources are efficiently used, and
the software is delivered on time, within budget, and with the desired quality.

Software Estimation:-
Software estimation is an essential part of software project planning. It involves
predicting the effort, time, and cost required to develop a software product.
Accurate estimation helps in effective budgeting, scheduling, and resource allocation.

Software Estimation is the process of approximating the resources (such as time, effort,
cost, and manpower) needed to complete all activities of a software project successfully.
In simple terms:
Software estimation means “predicting how long it will take, how much it will cost, and how
many people will be needed to build the software.”

Objectives of Software Estimation

 To determine project feasibility.
 To prepare budget and schedule accurately.
 To help in resource planning and allocation.
 To provide a basis for monitoring and control.
 To avoid cost overruns and delays.

Types of Software Estimation:-

a) Effort Estimation

 Determines the total amount of work needed.

 Usually measured in person-hours or person-months.

b) Time Estimation

 Predicts the total duration required to complete the project.

 Depends on effort, available manpower, and productivity.

c) Cost Estimation

 Calculates the total cost including:

o Labor cost
o Hardware and software cost
o Overheads and training costs

4. Estimation Techniques
1. Expert Judgment

 Estimates are based on experience and intuition of experts or past projects.

 Simple but may be subjective.

2. Delphi Technique

 Group of experts provide estimates anonymously; results are discussed and refined
until a consensus is reached.

3. Work Breakdown Structure (WBS)

 The project is divided into smaller tasks, and estimates are made for each task, then
summed up.
4. Analogy-Based Estimation

 Uses data from similar past projects to estimate current project effort and cost.

5. Algorithmic Models

 Use mathematical formulas and project parameters for estimation.

 Common models include:
o COCOMO (Constructive Cost Model)
o Function Point Analysis (FPA)

Importance of Software Estimation

 Ensures realistic planning and scheduling.
 Prevents overestimation or underestimation of resources.
 Improves project management and decision-making.
 Helps in maintaining customer satisfaction through accurate delivery timelines.

Software Estimation is the foundation for planning and managing a successful software
project.
It helps predict how much effort, time, and money will be needed, ensuring the project is
feasible, well-planned, and delivered efficiently.

COCOMO Model (Constructive Cost Model)

The COCOMO Model is one of the most widely used software estimation models,
developed by Barry W. Boehm in 1981.
It helps estimate the effort, time, and cost required to develop a software project based on
the size of the software (measured in KLOC – Kilo Lines of Code).
COCOMO (Constructive Cost Model) is an algorithmic software cost estimation model
that uses a mathematical formula to estimate the amount of effort (person-months) and
development time needed to complete a software project.
Objectives of COCOMO

 To estimate the effort, development time, and staffing requirements.

 To help in project planning, budgeting, and scheduling.
 To improve accuracy in predicting software development cost.

Basic COCOMO Formula

Where:

 E = Effort (in person-months)

 D = Development time (in months)
 KLOC = Size of the project (in thousand lines of code)
 a, b, c, d = Constants depending on the project type.

Structure of COCOMO 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.
In detailed COCOMO, 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:

1. Planning and requirements: This initial phase involves defining the scope, objectives,
and constraints of the project. It includes developing a project plan that outlines the
schedule, resources, and milestones
2. System design: : In this phase, the high-level architecture of the software system is
created. This includes defining the system’s overall structure, including major
components, their interactions, and the data flow between them.
 3. Detailed design: This phase involves creating detailed specifications for each
component of the system. It breaks down the system design into detailed descriptions of
each module, including data structures, algorithms, and interfaces.
4. Module code and test: This involves writing the actual source code for each module or
component as defined in the detailed design. It includes coding the functionalities,
implementing algorithms, and developing interfaces.
5. Integration and test: This phase involves combining individual modules into a
complete system and ensuring that they work together as intended.
6. Cost Constructive model: The Constructive Cost Model (COCOMO) is a widely used
method for estimating the cost and effort required for software development projects.
Different models of COCOMO 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
the constant to be used in subsequent calculations. These characteristics of different system
types are mentioned below. Boehm’s definition of organic, semidetached, and embedded
systems:
Importance of the COCOMO Model
1. Cost Estimation: To help with resource planning and project budgeting, COCOMO
offers a methodical approach to software development cost estimation.
2. Resource Management: By taking team experience, project size, and complexity into
account, the model helps with efficient resource allocation.
3. Project Planning: COCOMO assists in developing practical project plans that include
attainable objectives, due dates, and benchmarks.
4. Risk management: Early in the development process, COCOMO assists in identifying
and mitigating potential hazards by including risk elements.
5. Support for Decisions: During project planning, the model provides a quantitative
foundation for choices about scope, priorities, and resource allocation.
6. Benchmarking: To compare and assess various software development projects to
industry standards, COCOMO offers a benchmark.
7. Resource Optimization: The model helps to maximize the use of resources, which
raises productivity and lowers costs.

Staffing in software estimation

Staffing in software estimation is the process of determining the human resource needs for a
software project to be completed within its time and budget constraints. It involves analyzing
project requirements, identifying necessary skill sets, and allocating the right number of people
with appropriate expertise to different project phases, often with staffing levels peaking during
implementation and testing.

Key Concepts
 Effort Estimation Precedes Staffing: The total effort (usually in person-months or person-
hours) required to complete a project is estimated first (using techniques like COCOMO,
Function Points, or expert judgment), and then this effort is used to determine staffing levels
over the project's duration.
 Dynamic Staffing Levels: Contrary to a constant number of staff, optimal software
development staffing typically follows a Rayleigh distribution curve (Putnam-Norden-
Rayleigh curve). This means:

o Fewer staff are needed during the initial planning and requirements analysis phases.

o The team size ramps up to a peak during detailed design and coding.

o Staffing levels decrease during integration, testing, and deployment phases.

 Impact of Staffing Decisions:

o Understaffing can lead to missed deadlines, increased workloads, and team burnout.

o Overstaffing results in unnecessary costs and inefficient use of manpower, and a rapid build-
up of staff can actually cause schedule slippage (Brooks's Law: "Adding manpower to a late
software project makes it later").

Factors Influencing Staffing Estimation

Accurate staffing estimation depends on several factors:

 Project Scope and Complexity: Larger, more complex projects naturally require more staff
with diverse skill sets.

 Required Skills and Expertise: Identifying the specific technical skills (e.g., programming
languages, databases, machine learning expertise) and soft skills (communication, teamwork)
needed is vital for recruitment and placement.

 Project Timeline/Schedule: Aggressive schedules often require more effort (and thus more
people), but compressing the schedule too much can drastically increase costs and lead to
quality issues.

 Team Experience and Productivity: The experience level of the team members
significantly impacts productivity and estimation accuracy. Experienced teams may require
fewer people to accomplish the same tasks as less experienced ones.

 Development Methodology: Agile methodologies, for instance, often recommend specific

team sizes (e.g., 3-9 members in Scrum) and continuous planning, which influences staffing
structure and planning.

 Organizational Structure: The chosen team structure (e.g., chief programmer team,
democratic team, mixed control) influences communication paths and staff allocation.
 Risks and Uncertainties: Potential risks like changing requirements or skill shortages must
be factored into the staffing plan, often by including buffers or contingency plans.

Methods for Staffing Level Estimation

 Algorithmic Models (Parametric Estimation): Models like the COCOMO (Constructive
Cost Model) use formulas and historical data, considering project size and various attributes
(including personnel attributes), to estimate effort and, subsequently, the number of people
required.

 Expert Judgment: Experienced project managers and subject matter experts provide insights
and estimates based on their extensive experience with similar projects.

 Historical Data Analysis (Analogous Estimation): Using data from past, similar projects to
determine staffing needs for the current one.

 Bottom-Up Estimation: Breaking down the project into small tasks, estimating the effort for
each, and then aggregating to determine total staffing needs.

 Putnam-Norden-Rayleigh (PNR) Curve: A mathematical model used specifically to

predict the optimal pattern of staff build-up and decline over the project lifecycle.

Ultimately, effective staffing requires a combination of robust estimation techniques and

sound management principles to ensure the right talent is in the right place at the right time.

Team Structure in Software Estimation

In software project estimation, the team structure plays an important role in determining
how effectively resources are used and how accurately time and cost are estimated. The
structure defines roles, responsibilities, communication flow, and coordination among
members during the estimation and development process.
1. Types of Team Structures

There are generally three main types of team structures used in software projects:

a. Democratic Decentralized (DD) Team

 Structure: No permanent leader; decisions are made collectively.

 Communication: Horizontal — open and frequent among all members.
 Advantages:
o Encourages creativity and participation.
o Suitable for research or exploratory projects.
 Disadvantages:
o Slower decision-making.
o Can lead to confusion in large teams.
b. Controlled Decentralized (CD) Team

 Structure: There is a project leader who coordinates tasks, but problem-solving is

done collectively.
 Communication: Mixed — some vertical (leader to members) and some horizontal
(member to member).
 Advantages:
o Balanced control and flexibility.
o Efficient for medium-sized projects.
 Disadvantages:
o Slight delay in decisions due to discussions with the leader.

c. Controlled Centralized (CC) Team

 Structure: Strong leader or manager directs all activities.

 Communication: Vertical — leader to team members.
 Advantages:
o Fast decision-making.
o Works well for small or well-defined projects.
 Disadvantages:
o Less creativity.
o Team morale may be lower due to strict control.

2. Role of Team Structure in Software Estimation

Team structure impacts estimation accuracy through:

Factor Influence on Estimation

Experience of Team More experienced teams can give better and more realistic
Members estimates.

Efficient communication reduces misunderstandings and

Communication Flow
rework.

A clear structure ensures faster approval of estimation

Decision-making Process
changes.

Well-defined roles help in accurate work breakdown and effort

Responsibility Distribution
estimation.

3. Team Roles in Estimation Process

 Project Manager: Oversees the estimation process and ensures alignment with
project goals.
 Software Engineer/Developer: Provides technical input for time and effort needed.
 System Analyst: Defines requirements and identifies possible risks.
 QA/Test Engineer: Estimates testing time and resources.
 Configuration Manager: Handles tools, resources, and environment costs.
4. Choosing the Right Team Structure

The choice depends on:

 Project size and complexity

 Team experience
 Project duration
 Customer involvement

For example:

 Small project: Controlled Centralized

 Medium project: Controlled Decentralized
 Research/Innovative project: Democratic Decentralized

Risk Analysis and Management in Software Engineering

Risk Analysis and Management is a systematic process of identifying, assessing, and
controlling potential risks that could negatively impact a software project’s success in terms
of cost, schedule, quality, or performance.

What is Risk?

A risk is a potential problem that might occur in the future.

It has:

 Uncertainty – It may or may not happen.

 Loss – If it happens, it causes damage (delay, cost overrun, quality issue).

Example: A key developer leaving the project, requirement changes by client, or hardware
failure.

Types of Risks

Risks in software projects can be categorized as:

a. Project Risks

 Affect project schedule, budget, or resources.

 Examples:
o Unrealistic deadlines
o Lack of skilled staff
o Poor project management

b. Technical Risks

 Related to design, implementation, or technology.

 Examples:
o New or untested technology
o Integration problems
o Performance issues
c. Business Risks

 Affect organization or business goals.

 Examples:
o Market changes
o Product not meeting customer needs
o Change in government policy or law

d. Operational Risks

 Related to infrastructure, people, and processes.

 Examples:
o Server failure
o Data loss
o Poor communication among team members

Risk Management Process

The risk management process involves five key steps:

Step 1: Risk Identification

Identify possible risks that can affect the project.

Common techniques:

 Brainstorming
 Checklists
 Past project data
 Interviews with team members

Example: "If our software depends on a third-party API, what if the API stops working?"

Step 2: Risk Analysis (Assessment)

Determine the likelihood and impact of each risk.

Risk Probability (P) Impact (I) Risk Exposure = P × I

Developer leaving 0.4 High 0.4 × High = Medium/High

Requirement change 0.6 Medium 0.36 = Medium

Risks are then classified as:

 High risk → needs immediate attention

 Medium risk → monitor regularly
 Low risk → record and review occasionally
Step 3: Risk Prioritization

Rank the risks based on severity to decide which ones to handle first.
Tools:

 Risk matrix
 Risk exposure charts

Step 4: Risk Planning (Mitigation & Contingency)

Develop plans to:

 Avoid the risk (e.g., choose proven technology)

 Reduce the impact (e.g., provide training)
 Transfer the risk (e.g., insurance or outsourcing)
 Accept the risk (and prepare contingency plan)

Example:
Risk: Delay due to staff shortage
Mitigation: Hire temporary developers
Contingency: Extend project deadline by 2 weeks

Step 5: Risk Monitoring and Control

 Track identified risks regularly.

 Detect new risks.
 Update risk plans as the project progresses.

Tools used:

 Risk Register
 Risk Tracking Sheet
 Status Reports

4. Risk Management Tools

 Risk Register / Log: A document containing list of risks, probability, impact, and
mitigation actions.
 Risk Matrix: Visual chart mapping impact vs likelihood.
 PERT / Monte Carlo Simulation: Used for quantitative risk analysis.
5. Benefits of Risk Management
 Prevents project delays and failures
 Improves decision-making
 Reduces cost and rework
 Increases confidence among stakeholders