1|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Unit – V
Risks and Configuration Management
This PDF is watermarked and traceable. Unauthorized sharing will result in
permanent access ban and legal action.
Su

1. Risk Management
dh
an

Risk Management is the process of identifying, assessing, and controlling potential problems
(risks) that might affect the success of a software project. It helps project teams to prepare for
sh

uncertainties and minimize negative impacts on cost, schedule, performance, or quality.

u

Why Risk Management is Important?

De

 Software development is complex and uncertain.

sh

 Risks, if not handled early, can lead to project failure.

m

 Helps in proactive planning and better decision-making.

uk

Objectives of Risk Management:

h

1. Identify risks before they become problems.

-+

2. Analyze and understand their impact and likelihood.

91

3. Prioritize based on severity.

90

4. Plan mitigation strategies to reduce or eliminate the risks.

75

5. Monitor and review the risks continuously throughout the project.

61

1.1 Software Risks

62

Software risks are potential problems that could negatively impact the success of a software
64

project. These risks can lead to project delays, increased costs, reduced quality, or even
project failure if not identified and managed early.

Types of Software Risks:

1. Project Risks:
 2|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

o Related to scheduling, budget, resources, or staffing.

o Example: Inadequate time estimation or unavailability of skilled developers.

2. Technical Risks:

o Arise from technology or tools used in the project.

Su

o Example: New or unproven technology, integration failures, performance issues.

dh

3. Business Risks:
an

o Impact the value or market success of the software.

Example: Product may not meet customer needs or may become obsolete.
sh

4. Operational Risks:
u
De

o Issues with deployment, support, or maintenance.

Example: Lack of proper infrastructure or operational support post-deployment.

sh

5. External Risks:
m
uk

o Outside the control of the project team.

h

o Example: Changes in government regulations or market conditions.

-+

1.2 Risk Identification

91

Risk identification is the process of recognizing potential threats that could impact the software
project. It is usually carried out by the project manager using two main approaches:
90

1. Generic Risk Identification

75

 Focuses on general threats that could affect any software project.

61

2. Product-Specific Risk Identification

62

 Targets threats specific to the current project, based on:

64

o The people involved

o The technology used

o The development environment

Steps for Risk Identification

 3|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Step 1: Preparation of Risk Item Checklist

The project manager identifies known and predictable components to form a checklist of
potential risks:

Category Description

Product Size Risks based on the overall size and complexity of the
Su

software product.
dh

Business Impact Risks related to market conditions or management issues.

an

Customer Characteristics Risks in customer-developer communication and expectation

sh

handling.
u

Process Definition Risks arising from flaws or changes in the software process
De

being followed.

Development Environment Risks linked to tools, platforms, and technology being used.
sh
m

Staff Size & Experience Risks related to the availability of skilled and experienced
personnel.
uk

Technology to be Built Risks due to system complexity and innovation requirements.

h
-+

Once the checklist is prepared, a questionnaire is created. The answers to these questions help
91

assess the impact and seriousness of each risk item.

Step 2: Creating Risk Components and Drivers List:

90
75
61
62
64

The U.S. Air Force defines four key risk components for software projects:

1. Performance Risk: Uncertainty that the software will meet all required specifications
and perform as expected.
 4|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

2. Cost Risk: Risk that the project will exceed its budget due to poor estimation or
unexpected changes.

3. Support Risk: Risk that the software will be hard to maintain, correct, or adapt after
delivery.

4. Schedule Risk: Uncertainty that the project will be completed on time, possibly due to
Su

delays or scope changes.

dh

Risk Assessment
an

Risk assessment is the process of analyzing and evaluating the identified risks to understand
their potential impact on a software project.
sh

It helps in prioritizing risks based on two key factors:

u
De

 Probability: How likely is the risk to occur?

 Impact: What will be the effect if the risk occurs?

sh

Steps in Risk Assessment:

m
uk

1. Estimate Probability and Impact for each risk.

2. Assign Risk Exposure: Risk Exposure = Probability × Impact

h
-+

3. Prioritize Risks based on exposure.

91

4. Use a Risk Matrix (High/Medium/Low) to visualize risk severity.

90

This helps in deciding which risks need mitigation plans and which ones can be monitored or
accepted.
75

1.3 Risk Projection

61

Risk projection is the process of estimating:

62

 Likelihood (probability) of each identified risk.

64

 Impact (consequences) if the risk occurs.

It helps in prioritizing risks by evaluating:

1. Risk probability – How likely the risk is to occur (e.g., high, medium, low).

2. Risk impact – How severe the consequences will be (e.g., minor, moderate, major).
 5|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

3. Risk exposure – Calculated as: Risk Exposure = Probability × Impact

Using risk projection, project managers decide which risks need immediate attention and plan
mitigation strategies accordingly.

How Risk Projection is Carried Out Using a Risk Table

A Risk Table is used to organize and analyze identified risks based on their likelihood and
Su

impact.
dh

Risk ID Risk Description Probability (P) Impact (I) Exposure (P × I)

an

R1 Team lacks experience High (0.7) High (60) 42

sh

R2 Delay in hardware Medium (0.5) Medium (40) 20

u

R3 Scope changes Low (0.3) High (50) 15

De

 Probability (P): Assigned a value between 0 (no chance) and 1 (certainty).

sh

 Impact (I): Numerical value based on how much damage the risk could cause.
m
uk

 Risk Exposure: P × I, gives a measurable value to help prioritize.

High exposure risks are given more attention and handled early with mitigation, monitoring,
h

or contingency plans.
-+

1.4 Risk Refinement

91

Risk refinement is the process of breaking down high-level or general risks into more specific,
90

detailed, and manageable sub-risks. It helps in better understanding the cause, effect, and
75

possible solutions for a risk.

61

Example:

General Risk: Project may be delayed

62

After refinement:
64

 Risk 1: Requirements may change frequently.

 Risk 2: Key team members may leave.

 Risk 3: Tools may fail during development.

 6|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

This step-by-step breakdown allows for:

 More accurate risk analysis,

 Better planning for mitigation,

 Easier monitoring and control.

Su

1.5 Risk Planning

dh

Risk Planning in project development involves preparing for potential risks by identifying,
assessing, and creating strategies to address them. It is the foundational step for effective risk
an

management. Here’s a brief breakdown of the process:

sh

1. Risk Identification: Identify potential risks that could affect the project.
u

2. Risk Assessment: Evaluate the likelihood and impact of each risk.

De

3. Mitigation Strategy: Develop strategies to minimize or eliminate risks.

sh

4. Risk Allocation: Assign responsibility for managing specific risks.

m

5. Contingency Planning: Prepare alternative plans if risks occur.

uk

6. Risk Monitoring: Set up continuous monitoring and review to track risks throughout
h

the project.
-+

Risk planning helps ensure the project team is prepared to handle any challenges that may arise,
91

reducing the chances of project failure.

90

1.6 Risk Mitigation

Risk mitigation refers to the strategies and actions taken to reduce the probability or impact
75

of identified risks in a software project.

61

It is part of the risk management process and helps ensure smoother project progress.
62

Common Risk Mitigation Strategies:

64

1. Avoidance: Modify project plans or strategies to eliminate risks altogether. For

example, changing the technology stack to avoid performance issues.

2. Reduction: Implement actions to reduce the likelihood or impact of a risk. For instance,
breaking down a large project into smaller, manageable phases to reduce schedule risks.
 7|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

3. Transfer: Shift the risk to a third party, such as outsourcing part of the development or
purchasing insurance to cover potential financial losses.

4. Acceptance: Acknowledge the risk and prepare contingency plans in case it occurs. For
example, setting aside extra resources or time to deal with unexpected issues.

5. Contingency Planning: Prepare specific responses for high-priority risks in case they
Su

materialize. This ensures that the team is ready to act quickly and effectively.
dh

Importance:
an

 Mitigation helps minimize project disruptions by addressing risks proactively.

sh

 Reduces uncertainties, allowing the project team to focus on achieving objectives.

u

 Provides confidence to stakeholders that risks are being managed effectively.

De

1.7 Risk Monitoring

sh

Risk monitoring is the continuous process of tracking identified risks, checking for new risks,
and evaluating the effectiveness of risk mitigation strategies throughout the software
m

development lifecycle.
uk

Key Activities:
h

1. Track Identified Risks: Monitor current risks to ensure proper management.

-+

2. Detect New Risks: Identify new risks arising from changes in the project.
91

3. Assess Risk Status: Reevaluate existing risks and their current impact.
90

4. Evaluate Mitigation Effectiveness: Review the success of mitigation strategies.

75

5. Document and Report: Keep records and report the risk status to stakeholders.
61

Importance:
62

 Proactive Action: Helps address issues early.

64

 Improves Control: Ensures the project stays on schedule, within budget, and in scope.

 Supports Decision Making: Provides valuable data for better project decisions.
 8|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

1.8 Risk Management

Risk Management in software engineering involves identifying, assessing, and mitigating

risks to ensure the success of a project. It aims to reduce the likelihood of negative outcomes
and manage risks effectively.

Key Steps:
Su

1. Risk Identification: Recognize potential risks like technical issues or delays.

dh

2. Risk Assessment: Evaluate the likelihood and impact of each risk.

an

3. Risk Mitigation: Develop strategies to reduce or eliminate risks.

sh

4. Risk Monitoring: Track risks and monitor mitigation efforts.

u

5. Risk Control: Implement plans and take corrective actions when needed.
De

Importance of Risk Management:

sh

 Proactive Approach: Helps prevent problems before they escalate.

m

 Improves Project Success: Minimizes disruptions and enhances the chances of

uk

completing the project on time and within budget.

h

 Informed Decision Making: Provides insight into potential challenges and supports
-+

better decision-making throughout the project.

91

Project Example: Mobile Banking App Development

90

Risk Identification:
75

 Technical Risk: Payment gateway integration complexity.

Schedule Risk: Potential delays in testing.

61

 Security Risk: Vulnerabilities in handling sensitive data.

62

Risk Assessment:
64

 Technical Risk: Likelihood 70%, Impact 50%.

 Schedule Risk: Likelihood 50%, Impact 80%.

 Security Risk: Likelihood 60%, Impact 90%.

 9|Page © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Risk Mitigation:

 Technical Risk: Use experienced developers and conduct feasibility studies.

 Schedule Risk: Add time buffers for testing.

 Security Risk: Implement strong encryption and security audits.

Su

Risk Monitoring:
dh

 Monitor API progress, track project timeline, and review security regularly.
an

1.9 The RMMM (Risk Mitigation, Monitoring, and Management) Plan

The RMMM Plan is a strategy used in software projects to address potential risks by outlining
sh

ways to mitigate, monitor, and manage risks throughout the project lifecycle.
u

Typical template for RMMM plan or Risk information sheet can be:
De
sh
m
uk
h
-+
91
90
75
61
62
64

Project: Launch of a New E-Commerce Website

1. Risk Mitigation Strategies:

 10 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

Risk: Delays in website launch due to technical issues (payment gateway integration).

Mitigation Actions:

 Conduct pre-launch trials and hire experts for critical tasks.

 Use documented libraries and frameworks to reduce complexity.

Su

Risk: Poor website performance under high traffic.

dh

Mitigation Actions:
an

 Optimize backend, implement caching, and use CDN.

 Perform load testing and use cloud hosting for scalability.

sh

2. Risk Monitoring Strategies:

u
De

Risk: Scope creep (additional features requested post-project start).

Monitoring Actions:
sh

Define clear project scope and track with project management tools (e.g., Jira).
m


uk

 Hold regular status meetings with stakeholders to ensure alignment.

h

Risk: Security vulnerabilities.

-+

Monitoring Actions:
91

 Conduct regular security assessments and penetration testing.

90

 Stay updated with security patches and use secure coding practices.
75

3. Risk Management Strategies:

61

Risk: Delays due to resource constraints.

Management Actions:
62

 Hire additional staff or temporary workers.

64

 Break down tasks into milestones for efficient progress.

Risk: Loss of customer trust due to downtime.

Management Actions:
 11 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Implement disaster recovery plan and ensure high availability.

 Communicate transparently with customers during issues.

1.10 Evaluating Risk Impact on Project Schedule Using PERT

PERT (Program Evaluation and Review Technique) is used to evaluate risks by estimating
task durations with uncertainty. It helps identify how risks can affect the project timeline.
Su

Key Steps:
dh

1. Task Duration Estimates:

an

o Optimistic Time (O): Shortest possible time.

sh

o Pessimistic Time (P): Longest possible time.

u

o Most Likely Time (M): Best estimate.

De

2. Calculate Expected Time (TE):

sh

𝑂 + 4𝑀 + 𝑃
m

𝑇𝐸 =
6
uk

This gives the weighted average of the time estimates.

h

3. Risk Impact:
-+

o Risk Identification: Identify risks that could affect durations.

91

o Adjust Estimates: Modify optimistic and pessimistic estimates based on risks.

90

o Recalculate Expected Time: Adjust TE based on the new estimates.

75

4. Critical Path:
61

o Identify the critical path, the longest sequence of tasks. Delays in critical path
tasks will affect the project end date.
62

Example:
64

For Task A:

 Optimistic (O): 2 weeks, Most Likely (M): 3 weeks, Pessimistic (P): 5 weeks.

( )
 Expected Time (TE) = = 3.3 weeks
 12 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

After risk adjustment (due to technical challenges), Task A's new estimates are:

 Optimistic (O): 3 weeks, Most Likely (M): 3 weeks, Pessimistic (P): 6 weeks.

( )
 New Expected Time (TE) = = 4.5 weeks

2. Software Configuration Management

Su

Software Configuration Management (SCM) is the discipline of managing the evolution and
dh

changes in software systems over time. It involves the processes, tools, and techniques used to
an

control and track changes to the software, ensuring that it remains consistent and reliable
throughout its lifecycle.
sh

Key Objectives of SCM:

u
De

1. Version Control: Keeps track of different versions of software components (e.g., code,
documentation) to avoid confusion and ensure that the correct version is always used.
sh

2. Change Control: Manages changes to the software by identifying, approving, and

m

tracking modifications. This helps prevent unauthorized or untracked changes.

uk

3. Configuration Identification: Defines the configuration items (CIs) in the software, such
h

as source code, libraries, configuration files, and documentation, and tracks their status
-+

and version.
91

4. Configuration Auditing: Verifies and ensures that the software meets its required
configuration and that no discrepancies or errors have been introduced.
90

5. Release Management: Controls the process of building, packaging, and deploying

75

software releases to various environments (e.g., development, testing, production).

61

Benefits of SCM:
62

 Consistency: Ensures that the software is consistent, reliable, and reproducible by

tracking changes and maintaining version histories.
64

 Collaboration: Helps teams collaborate efficiently by providing a clear structure for

handling changes, resolving conflicts, and managing the software lifecycle.

 Traceability: Tracks the history of changes, making it easier to debug, maintain, or roll
back to previous versions if needed.
 13 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Quality Control: Enhances software quality by ensuring that changes are tested and
validated before being integrated into the main system.

2.1 The SCM Repository

The SCM Repository is a centralized data storage used to manage and store all configuration
items and related information throughout the software development lifecycle.
Su

Key Components Stored in SCM Repository

dh

1. Source Code Files: All versions of source code modules with version history.
an

2. Documentation: Requirements, design docs, test cases, user manuals, etc.

sh

3. Change Requests: Records of all changes proposed, approved, or implemented.

u

4. Test Data & Results: Data sets, test plans, and outcomes of tests.
De

5. Build Information: Build scripts, logs, release versions.

sh

6. Baselines: Snapshots of the project at significant stages (e.g., after requirement

m

finalization).
uk

Functions of SCM Repository

h

1. Version Control: Maintains a history of changes made to each configuration item. It allows
-+

developers to access previous versions, compare differences, and roll back if needed.
91

2. Access Control: Controls who can view or modify items in the repository. It ensures only
authorized users make changes, helping maintain integrity and security of the software.
90

3. Audit Trails: Records all activities performed on configuration items—who changed what,
75

when, and why. This provides full traceability and helps during project reviews or
61

debugging.

4. Backup and Recovery: Stores copies of important configuration items, allowing recovery
62

in case of data loss or system failure. It acts as a safeguard for project assets.
64

5. Support for Parallel Development: Enables multiple team members to work on different
modules or features simultaneously without overwriting each other's changes. This
improves development speed and collaboration.

Benefits of SCM Repository

 14 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Enhances collaboration in teams.

 Increases transparency and traceability.

 Prevents loss of data or unauthorized changes.

 Speeds up development and debugging using historical data.

Su

2.2 The SCM Process

dh

The primary objectives of Software Configuration Management process (SCM) are -

an

1. Configuration Identification: Identify the items that define the software configuration.

2. Change Control: Manage changes to one or more items.

sh

3. Version Control: Facilitate to create different versions of the application.

u
De

4. Configuration Audit: To ensure that the quality of the software is maintained as the
configuration evolves over the time.
sh

5. Status Report: Focuses on communication of changes to all people in an organization that

m

involve with changes.

uk

1. Configura on Iden fica on

h

Configuration Identification is the process of identifying, naming, and organizing software

-+

configuration items (SCIs) as objects in the repository.

91

Types of Objects:
90

 Basic Objects: Smallest units (e.g., code files, test cases).

75

 Aggregate Objects: Groups of basic or other aggregate objects (e.g., SRS, design docs).
61

Properties of Each Configuration Object:

62

Each configuration item is uniquely identified by the following:

64

1. Name: A unique string of characters used to identify the object.

2. Description:

o Detailed information describing the object.

o Can include project identifier, version info, and other documentation.

 15 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

3. List of Resources:

o Entities needed for referencing, accessing, or processing the object.

o May include data types, tools, or functionalities used.

4. Realization or Identification: A pointer or link that refers to the actual object.

Su

Purpose:
dh

 Track relationships between objects.

an

 Understand how changes to one item affect others.

 Monitor evolution of each object throughout the software process.

sh

2. Change Control
u
De

Change control is a structured process to handle modifications in a software project. Even

small changes can significantly impact the system — either causing issues or improving the
sh

system’s capabilities.
m

Why is it important?
uk

 Too few changes → Can miss important improvements.

h

 Too many/large changes → Can lead to instability or chaos.

-+

To manage changes effectively, a defined process is used, involving human procedures or

91

automated tools.
90

Steps in the Change Control Process:

75

1. Need for Change Arises: A user or stakeholder identifies a required change.

61

2. Submit Change Request: A formal request is submitted detailing the needed modification.
62

3. Developer Evaluation: Technical team evaluates feasibility, side effects, system impact,
and cost.
64

4. Generate Change Report: A summary of findings is documented and submitted to the

Change Control Authority (CCA).

5. Change Control Authority (CCA) Decision: A group/person reviews the report and
approves or rejects the change.
 16 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

6. Engineering Change Order (ECO): If approved, an ECO is created that defines:

o Description of change

o Constraints

o Review/audit criteria
Su

7. Check-out the Object: The item to be changed is retrieved from the configuration
database.
dh

8. Make the Change & Apply SQA: Modification is made and Software Quality Assurance
an

steps are followed.

sh

9. Check-in & Version Control: The updated object is stored back in the database with a new
u

version.
De

3. Version Control
sh

Version Control is a key activity in SCM that helps manage multiple versions of software
components as they evolve during the development lifecycle.
m
uk

Purpose:
h

 To keep track of every change made to software artifacts (code, documents, etc.)
-+

 To manage different versions of components effectively.

91

 To restore previous versions when needed.

90

 To coordinate team collaboration, especially when multiple people are modifying the
same files.
75

Key Concepts:
61

1. Baseline: A formally reviewed and approved version of a component that serves as a

62

reference point.
64

2. Version: A specific state or revision of a software artifact after a change has been made.

3. Variant: A version that is modified to work in a different environment or fulfill

different requirements.

4. Repository: A central place where all versions of components are stored and managed.
 17 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

5. Check-in / Check-out

o Check-out: A developer extracts a component to make changes.

o Check-in: After changes, the component is saved back to the repository, often
with a new version ID.

Benefits of Version Control:

Su

 Enables team collaboration with reduced conflicts.

dh

 Supports rollback to previous stable versions if needed.

an

 Maintains history of changes for accountability and tracking.

sh

 Helps in auditing and compliance.

u

4. Configura on Audit
De

Configuration Audit is a process used to verify that software configuration items (SCIs)
sh

conform to their specified requirements and have been correctly implemented.

m

Purpose of Configuration Audit:

uk

 To ensure completeness, correctness, and consistency of configuration items.

h

 To confirm that all approved changes have been properly applied and documented.
-+

 To validate that the baseline product matches its configuration records.

91

Types of Configuration Audit:

90

1. Functional Audit
75

o Ensures that the software performs as specified in the requirements.

61

o Confirms all functions and features are implemented and tested.

62

2. Physical Audit
64

o Verifies that all configuration items are present in the software system.

o Confirms documentation (design, code, test results, manuals) is complete and up to date.

Benefits:

 Helps maintain quality and traceability of software.

 18 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Ensures control over changes and versioning.

 Useful during release or handover phases to confirm readiness.

5. Status Repor ng

Status Reporting is the process of tracking and communicating the current state of software
Su

configuration items (SCIs) and their changes throughout the software development lifecycle.

Purpose of Status Reporting:

dh

 To provide visibility into the progress and health of the software configuration
an

management process.
sh

 To track the status of configuration items, changes, and versions.

u

 To facilitate decision-making by providing accurate and timely information to

De

stakeholders.
sh

Key Aspects of Status Reporting:

m

1. Configuration Item Status: Information on whether configuration items are

uk

developed, verified, released, or in revision.

h

2. Change Request Status: Tracks the status of any change requests (whether they are
under review, approved, or rejected).
-+

3. Version Control Status: Tracks which versions of configuration items are checked in,
91

approved, or in progress.
90

4. Issue Tracking: Identifies any problems or defects with configuration items and the
75

progress in resolving them.

61

Types of Status Reports:

62

 Periodic Status Reports: Regular updates on the status of configurations and changes
(e.g., weekly).
64

 Ad-hoc Reports: Reports generated based on specific requests or situations, such as an

urgent change or issue.

Benefits of Status Reporting:

 Keeps all stakeholders informed and aligned.

 19 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

 Enhances transparency and accountability in configuration management.

 Helps identify potential delays or risks early, enabling corrective actions.

2.3 Configuration Management for any suitable software system.

Configuration Management (CM) ensures the integrity, consistency, and traceability of

software products throughout their development and maintenance. It involves managing
Su

changes to software configuration items (CIs) and ensuring the software system functions as
dh

intended despite these changes. Here's how CM works in a mobile application development
project.
an

Steps in Configuration Management for a Mobile Application System

sh

1. Configuration Identification
u
De

o Identifies and defines all components (CIs) to be managed.

o Example: Source code, API endpoints, UI assets, Test scripts,

sh

Documentation.
m

2. Version Control
uk

o Tracks versions of configuration items and manages changes.

h

o Example: Git is used to manage source code versions, branches, and merges.
-+

3. Change Control
91

o Ensures that all changes to CIs are evaluated and authorized before being
90

implemented.
75

o Example: Change requests are reviewed, and the Change Control Authority
61

(CCA) approves or rejects them.

4. Build and Release Management

62

Automates the building, packaging, and releasing of software.

64

o Example: Tools like Jenkins automatically build the app after each change and
release it to test or production environments.

5. Configuration Audits

o Ensures that CIs meet the required standards and are implemented correctly.
 20 | P a g e © Haris Chaus | ALL RIGHTS ARE RESERVED as per copyright act.

o Example: After building the app, a configuration audit checks the code, assets,
and dependencies for correctness.

6. Status Reporting

o Provides ongoing reports on the status of CIs and the project's progress.

Example: Regular reports track current app versions, feature progress, and
Su

change request status.

dh

7. Backup and Recovery Management

an

o Ensures that all CIs are backed up and can be recovered if needed.
sh

o Example: Regular backups are created, and a disaster recovery plan is in place.
u

8. Documentation and Traceability

De

o Ensures changes are documented and traceable for future reference.

sh

o Example: JIRA tracks change requests and their impact on the project.
m

Benefits of Configuration Management

uk

 Consistency: Ensures software consistency across environments and versions.

h

 Collaboration: Allows multiple developers to work on different features

-+

simultaneously.
91

 Quality Control: Maintains software quality through change control, audits, and
90

reporting.

 Traceability: Tracks every change for easy debugging and future reference.
75

 Risk Reduction: Reduces risk through proper change management and backup
61

strategies.
62
64