Software Change Control (SCR) - Work Instruction

Provide a Software Change Control work instruction that covers all change management from planning through testing, build and release


Here's a detailed Software Change Control Work Instruction that covers the entire change management lifecycle, from planning through testing, build, and release. This work instruction ensures that changes are managed in a controlled manner while maintaining quality, integrity, and traceability.


Software Change Control Work Instruction

1. Purpose

This work instruction describes the process for managing software changes from initial request through planning, implementation, testing, build, and release. It ensures that all changes are properly documented, approved, tested, and incorporated into the software product.


2. Scope

This instruction applies to all software change requests (SCCRs) that affect software components, documents, or other configuration items. The tools used in this process include IBM ClearQuest for change request tracking and IBM ClearCase for version control.


Change Control Process Steps

3. Initiation and Planning


3.1 Submit Software Change Control Request (SCCR)

• Any team member (developer, tester, or project manager) may submit a Software Change Control Request (SCCR) to initiate the process.

• The SCCR should include the following:

○ Description of the change

○ Reason for the change

○ Impact on other components (software, documentation, hardware, etc.)

○ Affected configuration items

○ Initial risk assessment

• The SCCR is logged in IBM ClearQuest.


3.2 Initial Review by Software Change Control Board (SCCB)

• The SCCB reviews the SCCR for validity and feasibility.

• The SCCB may include project leads, configuration managers, quality assurance representatives, and key stakeholders.

• The SCCB approves or rejects the SCCR. If approved, it assigns a priority and schedule for the change.

• The SCCB may request additional information or clarify requirements before proceeding to planning.


4. Change Planning


4.1 Impact Analysis

• The assigned team conducts an impact analysis on the change request:

○ Identifies components affected (software modules, test cases, documentation, etc.).

○ Analyzes the impact on schedule, resources, and costs.

○ Assesses potential risks (e.g., performance degradation, security risks).

• Impact analysis results are updated in ClearQuest and submitted for SCCB review.


4.2 SCCB Approval for Implementation

• The SCCB reviews the impact analysis, finalizes the decision, and assigns the task for implementation.

• Once the SCCB gives final approval, the change is planned into the development schedule.


5. Implementation


5.1 Development of the Change

• The assigned developer(s) implement the changes in a separate branch of the code base using IBM ClearCase.

• The developer ensures that any affected components (e.g., documentation, test cases) are updated to reflect the change.

• Code is developed following the project’s coding standards and guidelines, ensuring maintainability and performance.


5.2 Developer Unit Testing

• The developer conducts unit testing on the modified code to ensure it works as intended and does not introduce new defects.

• Test results are recorded, and the developer updates the SCCR with testing details in ClearQuest.


5.3 Code Review and Approval

• The code is submitted for peer review following the project’s code review standards.

• Reviewers check for code quality, adherence to design, and alignment with requirements.

• Upon approval, the code is merged into the appropriate branch of ClearCase.


6. Build and Integration


6.1 Integration into Main Build

• The approved changes are integrated into the main code branch using ClearCase.

• A build engineer or assigned developer prepares the build, ensuring all changes are correctly merged and the build process is successful.


6.2 Build Verification Testing

• Build verification testing (BVT) is conducted to ensure the stability of the build.

• Testers validate that the changes do not introduce new issues and that the build functions as expected.

• If BVT fails, the change is sent back to the developer for further modification. Otherwise, the SCCR is updated in ClearQuest to reflect successful integration.


7. Formal Testing


7.1 System Testing

• The software, with the applied changes, is handed over to the testing team for system-level testing.

• Testing may include functional, regression, performance, and security tests.

• All test results, including any defects discovered, are documented in ClearQuest.

• If defects are found, the SCCR is returned to the developer for fixes, and the process restarts at the implementation phase.


7.2 User Acceptance Testing (UAT)

• Once system testing is complete and passes, the change is moved to the User Acceptance Testing (UAT) phase (if applicable).

• UAT ensures the change meets the customer’s or end-user’s requirements.

• Feedback from UAT is reviewed by the SCCB, and final decisions are made on any necessary adjustments.


8. Release


8.1 Pre-Release Approval

• After successful testing and UAT, the SCCB reviews all documentation (testing results, code reviews, etc.) and gives approval for release.

• The SCCR is marked as Ready for Release in ClearQuest.


8.2 Final Build and Packaging

• The final software build is created, including all changes approved by the SCCB.

• The release package is prepared, including executables, installation scripts, release notes, and updated documentation.

• Versioning information is updated in ClearCase, and the build is stored in the release repository.


8.3 Release to Production

• The release is deployed to the production environment.

• Any issues or post-deployment tasks are tracked in ClearQuest as post-release items.


9. Post-Release Review and Audit


9.1 Configuration Audit

• A configuration audit is conducted to ensure that all changes were correctly implemented and documented.

• ClearCase and ClearQuest are used to track versions, SCCRs, and audits.


9.2 Retrospective

• The SCCB conducts a retrospective to evaluate the effectiveness of the change control process and gather lessons learned.

• The findings are used to improve future change control processes.


10. Tools

• IBM ClearQuest: Used to track SCCRs, changes, testing results, and audit history.

• IBM ClearCase: Used to manage version control, maintain baselines, and integrate changes into the build.


11. Conclusion

This Software Change Control Work Instruction provides a structured approach to managing changes from initiation through testing, build, and release, ensuring that all changes are properly tracked, tested, and integrated using SCCRs, the SCCB, IBM ClearQuest, and ClearCase.


This work instruction ensures that all phases of change control are aligned with best practices, maintaining product integrity and minimizing risks associated with untracked or improperly tested changes.

Comments

Post a Comment

Popular posts from this blog

Project Process Documentation Required for CMMI-DEV Level 3 Assessment

List the various process documents that a CMMI assessor would expect to see for process area Technical Solution. A CMMI assessor evaluating the Technical Solution process area would typically expect to see the following key process documents or work products to demonstrate that requirements are being effectively transformed into designed and implemented product solutions: 1. Alternative Solution Analysis and Selection Criteria: This includes a list of alternative solutions evaluated, the criteria for selection, and the analysis methods used to support selection decisions. Work products might include: ○ Evaluation reports of alternative solutions and new technologies ○ Criteria used for selecting final solutions ○ Records of analyses or trade studies conducted for alternative solutions​​. 2. Product Component Requirements and Design Allocations: Documentation specifying how requirements are allocated to product components, as well as any derived requirements or constraints ...
Read more

Software Configuration Management - Procedure

Provide a procedures document for planning a release, processing of software change requests, IBM Clear Quest and Clear Case tools, a Software Change Control Board, and the requirements, design, implementation, testing, peer review, change commitment, build and formal verification Here is a general outline for a procedures document that addresses planning a release, processing software change requests, using IBM ClearQuest and ClearCase tools, and conducting Software Change Control Board (SCCB) activities within the software development lifecycle. This template will include sections for requirements, design, implementation, testing, peer review, change commitment, build, and formal verification. Software Release and Change Management Procedures 1. Purpose Define the purpose of this document, such as managing software release planning and processing software changes. This includes coordinating tasks among stakeholders, using tools like IBM ClearQuest and ClearCase for tracking changes, ...
Read more

Document Assessment for Compliance to NASA Standards

https://chatgpt.com/g/g-a50IW7mkP-cmmi-dev-v1-3/ Knowledge Base: CMMI-DEV v1.3 (.pdf) A NASA provider has submitted a Software Configuration Management Plan in the attached file SCMP_Text_GEND.txt. In assessing the provider plan against your CMMI-DEV v1.3 knowledge base, perform the following two tasks: 1) List and describe the elements of process area Configuration Management that are covered by the provider document, and 2) list and describe the elements of process area Configuration Management that are not covered by the provider document. Assessment of NASA Provider’s Software Configuration Management Plan (SCMP) in Relation to CMMI-DEV v1.3 Configuration Management Process Area The NASA provider’s Software Configuration Management Plan (SCMP) has been evaluated against the CMMI-DEV v1.3 Configuration Management (CM) process area to determine coverage of its specific practices (SPs) and specific goals (SGs). Below are the findings for each category. 1) Elements of the Configuration...
Read more