Software Configuration Management Plan

Software Configuration Management Plan

Introduction
This Software Configuration Management Plan (SCMP) outlines the procedures and activities
necessary to manage software configurations for the Hotel Booking System. The plan ensures
the identification, control, implementation, and reporting of changes to maintain system integrity
and traceability throughoutits lifecycle.

1. Scope and Intent of SCM Activities

The primary focus of Software Configuration Management (SCM) is to identify and control
majorsoftware changes, ensure that changes are properly implemented, and report changes to
relevant personnel or clients. The objectives of SCM are to:
• Limit the impact of changes on the system.
• Eliminate unnecessary changes.
• Monitor and control necessary changes.
• Allow continuous software development with minimal backtracking, reducing
development timeand improving product quality.
The SCM team will oversee these activities, and any changes to existing code or architectural
designmust pass their inspection before implementation.

2. SCM Organizational Role

The SCM team will work closely with the Software Quality Assurance (SQA) team, cross-
examining documents and software change requests. Software engineers will submit change
requests directly to theSCM team for inspection and approval.
An SCM leader will be appointed to oversee all SCM activities. The SCM leader will:
• Receive all change requests.
• Make final decisions regarding changes.
• Assign approved changes to software engineers.
• Maintain a library of all submitted requests, including denied ones.

3. SCM Tasks
3.1 Identification
• Program Title: SCM
• Teams: SQA Team, SCM Team, Software Engineers
Description: The SCM leader will analyze all current design specifications and break down
the software into subsystems. Any submitted changes will be traced backward through the
system todetermine their impact.
Work Products: An SCI document will contain the breakdown of subsystems and their
interrelations.Approved changes will be returned to the software engineer with a change
approval sheet, listing all possible affected subsystems and any additional necessary
information.
3.2 Configuration Control
Description: Software engineers will submit change requests to the SCM leader. The SCM leader
willanalyze requests using the SCI document, project design document, and current software
prototype. Decisions will be based on the impact of changes on the entire system and
corresponding subsystems.Tasks:
3.2.1 Submitting Change Requests: Software engineers submit change requests via
email or word ofmouth, which the SCM leader documents. All requests are
recorded in the SCM Request
Library, including the requesting engineer’s name, date, request subject, and approval
status.
3.2.2 Request Analysis: The SCM leader analyzes the request using relevant
documents andprototypes to assess its impact on the system.
3.2.3 Request Disapproval: If deemed unnecessary, the SCM leader explains the
decision to therequesting engineer, who may discuss and resubmit a
modified request.
3.2.4 Request Approval: If approved, the SCI document is updated, and the software
engineer is notified of all possible affected subsystems. Drastic changes may
require client approval beforeimplementation.

Work Products and Documentation:

3.2.5 SCM Library: Updated with request status and changes.

3.2.6 SCI Document: Amended to reflect approved changes.
3.3 Version Control
Description: System updates will result in version number changes following a standard
format (x.x.x). The version number reflects the severity of changes, with minor changes
updating the hundredths place, substantial changes updating the tenths place, and severe
changes updating theones place.
Tasks:
3.3.1 Minor Version Change: Documented in the SCM library, noting the bug fix.
3.3.2 Substantial Version Change: Documented in the SCM library and SCI
document, noting bugsfixed or design changes.
3.3.3 Severe Version Change: Documented in the SCM library and SCI document,
noting designdecisions and affected subsystems.
Critique: Automated version control systems are recommended for industry projects, but
manualcontrol is acceptable in this context.

4.Configuration Status Accounting (CSA)

4.1 Description
Configuration Status Accounting (CSA) is the process of recording and reporting the status of
configuration items (CIs) and any changes made to them. CSA provides visibility into the state
of the CIs and the progress of change requests, ensuring that stakeholders are informed about the
configurationand status of the system.
 4.1.1 Date: 3-06-2024
4.1.2 Program Title: SCM
4.1.3 Teams: SQA Team, SCM Team, Software Engineers
Description: The SCM leader will analyze all current design specifications and break down
the software into subsystems. Any submitted changes will be traced backward through the
system todetermine their impact.
4.2 Tasks
• Maintain Configuration Records: The SCM team will maintain up-to-date records of all
CIs, including their current versions, locations, and status. This includes documenting
the history ofchanges made to each CI.
• Track Change Requests: All change requests will be tracked from submission to
resolution. This includes recording the date of submission, the details of the change, the
status of the request, andthe final outcome.
• Generate Status Reports: The SCM team will generate regular status reports that provide
detailedinformation about the current configuration of the system, the status of change
requests, and anyoutstanding issues. These reports will be distributed to relevant
stakeholders, including project managers, developers, and clients.
• Notify Stakeholders: The SCM leader will notify relevant stakeholders of any significant
changes tothe system configuration. This includes informing software engineers of
approved changes, updating the SCI document, and communicating with clients if changes
impact the software's functionality or user interface.
4.3 Work Products and Documentation
• Configuration Status Reports: Regular reports detailing the status of all CIs, change
requests, andany issues.
• Updated SCI Documents: Documentation reflecting approved changes and the current
state of thesystem.
• Change Notification: Communications sent to stakeholders informing them of significant
changes.

5.Audits and Reviews

5.1 Description
Software configuration audits and formal technical reviews are conducted to ensure that
changes are properly implemented and that the SCM process is being followed correctly. These
audits and reviewshelp maintain the quality and integrity of the software by verifying that
changes conform to requirements and do not introduce new defects.
5.2 Tasks
• Conduct Configuration Audits: The SCM team will periodically audit the system to verify
that all CIs conform to their specifications and that changes have been implemented
correctly. Audits willcheck for consistency between the SCI document, the project design
document, and the actual software.
• Perform Technical Reviews: Formal technical reviews will be held to examine the details of
changesand ensure they meet quality standards.
5.3 Work Products and Documentation
• Audit Reports: Detailed reports documenting the findings of configuration audits,
including anydiscrepancies and recommended actions.
• Review Documents: Records of technical reviews, including meeting minutes, decisions
made, andany issues identified.
 White Box testing

a. Preparation
1. Understand the Code:
o Code Review: Conduct thorough code reviews to understand the application’s
architecture and logic.
o Documentation: Ensure that the code is well-documented and understand the
functionality of each module.
2. Identify Test Cases:
o Path Testing: Identify all possible paths through the code to create comprehensive
test cases.
o Branch Testing: Focus on testing all decision branches to ensure they work as
expected.
o Statement Testing: Ensure that every statement in the code is executed at least once
during testing.

b. Testing Process

1. Unit Testing:
o Modular Testing: Test individual modules in isolation to ensure they function
correctly.
o Mocking: Use mocking frameworks to simulate interactions with external systems or
dependencies.
2. Integration Testing:
o Interface Testing: Test the interfaces between different modules to ensure they
interact correctly.
o System Integration Testing: Ensure that integrated modules work together as
expected.
c. Tools
1. Unit Testing Frameworks:

o JUnit (Java)

o NUnit (C#/.NET)

o PyTest (Python)

o RSpec (Ruby)

o Mocha (JavaScript)

2. Code Coverage Tools:

o JaCoCo (Java)

o Cobertura (Java)

o Coveralls (multiple languages)

o Istanbul (JavaScript)

3. Static Analysis Tools:

o SonarQube

o PMD (Java)

o Checkstyle (Java)
 Black Box Testing
Black box testing involves testing the application's functionality without looking at the
internal code structure. The tester is unaware of the internal workings of the application and
focuses on testing the inputs and outputs. Here’s a detailed breakdown:

a. Preparation
1. Understand Requirements:
o Requirement Analysis: Review functional and non-functional requirements to
understand what needs to be tested. This includes understanding the user stories, use
cases, and business rules.
o Specification Documents: Use requirement specification documents, user manuals,
and design documents to gather information about the expected behavior of the
application.

2. Identify Test Scenarios:

o Functional Scenarios: Create test scenarios that cover all functional aspects of the
application. This includes testing each feature and user interaction.
o Edge Cases: Identify and create test scenarios for edge cases and unusual situations.
This helps in testing the robustness of the application.
o Equivalence Partitioning: Divide input data into equivalence classes and create test
cases for each class. This helps in reducing the number of test cases while ensuring
good coverage.
o Boundary Value Analysis: Focus on testing the boundary values of input ranges. This
helps in identifying errors at the boundaries.

b. Testing Process
1. Functional Testing:
o Manual Testing: Perform manual testing for scenarios that require human judgment,
such as user interface testing and usability testing.
o Automated Testing: Use automation tools to repeatedly test common and critical
scenarios. This helps in saving time and ensuring consistency.

2. Non-Functional Testing:

o Performance Testing: Use tools like JMeter or LoadRunner to test the application’s
performance under various conditions. This includes load testing, stress testing, and
endurance testing.
o Usability Testing: Conduct usability tests to ensure the application is user-friendly.
This involves testing the application's ease of use, navigation, and overall user
experience.