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, and standardizing Software Change Control Board (SCCB) functions.

2. Scope

Outline the document's scope, covering all software development stages, including requirements gathering, design, implementation, testing, change control, and verification for releases.

3. References

List related process documents, standards, and tools:

• Configuration Management (CM) Plan

• Quality Assurance (QA) Plan

• IBM ClearQuest and ClearCase User Guides

• Software Development Lifecycle (SDLC) documentation

4. Definitions and Acronyms

Provide definitions for terms like SCCB, Change Request (CR), release, and formal verification.


5. Roles and Responsibilities

• Release Manager: Oversees release planning and tracking.

• Software Developer: Implements changes, conducts peer reviews.

• Test Lead: Manages testing activities for release changes.

• SCCB Members: Evaluate and approve changes.

• Configuration Management (CM) Administrator: Manages versions and repositories using ClearCase.


6. Release Planning Procedure

• 6.1 Define Release Scope: Identify features, bug fixes, and enhancements to be included. Document the release goals and align them with project objectives.

• 6.2 Timeline and Milestones: Define key milestones, such as code freeze, testing, and deployment dates.

• 6.3 Resource Allocation: Assign developers, testers, and other necessary resources.


7. Processing Software Change Requests

• 7.1 Submission and Logging in ClearQuest: Changes are submitted in IBM ClearQuest as CRs. Each CR should include:

○ Description of the change

○ Priority and severity

○ Impact analysis

○ Dependencies

• 7.2 Initial Review: The SCCB conducts an initial review to assess the request's validity, priority, and potential impact.

• 7.3 Approval for Implementation: Approved CRs are assigned to development for further action. Rejected CRs are documented and closed.


8. Software Change Control Board (SCCB) Process

• 8.1 Scheduling SCCB Meetings: Define frequency (e.g., weekly) and schedule ad-hoc meetings for critical issues.

• 8.2 Agenda and Preparation: Include all open CRs, with emphasis on high-impact and critical changes.

• 8.3 Review and Decision-Making: SCCB evaluates each CR, with outcomes being approved, deferred, or rejected.

• 8.4 Documentation: Update CRs in ClearQuest based on SCCB decisions.


9. Requirements, Design, and Implementation Process

• 9.1 Requirements Analysis: Confirm that all CRs align with project requirements.

• 9.2 Design Documentation: For approved CRs, developers update the design documents to include new features or bug fixes.

• 9.3 Implementation Standards: Follow coding standards. Use ClearCase for source code management to track all changes.


10. Testing and Verification

• 10.1 Test Plan Development: Develop test cases based on CR specifications.

• 10.2 Execution and Documentation in ClearQuest: Execute tests and document results. Failed tests require the developer to address issues before retesting.

• 10.3 Peer Review of Test Results: Conduct peer reviews to confirm test accuracy and thoroughness.


11. Peer Review Process

• 11.1 Code Reviews: Conduct code reviews before testing to ensure quality.

• 11.2 Review Documentation: Document findings in ClearQuest, noting any recommended changes.


12. Change Commitment and Build Procedures

• 12.1 Commit Changes in ClearCase: Approved and tested changes are committed to the ClearCase repository.

• 12.2 Build Process: Conduct builds at predetermined intervals. The build process includes automated checks and versioning.


13. Formal Verification and Validation

• 13.1 Verification Process: Conduct formal verification to ensure that all changes meet functional and performance requirements.

• 13.2 Validation Review: SCCB reviews validation outcomes, authorizing the final deployment upon successful completion.


14. Tools and Configuration Management

• IBM ClearQuest: Used for CR tracking, approval, and status monitoring.

• IBM ClearCase: Used for version control, ensuring traceability of all changes.


15. Approval and Revision History

Document revision dates and approvals for tracking and compliance purposes.


Appendix A: Release Checklist

Include a checklist for all activities from release planning to final verification.

Appendix B: ClearQuest Change Request Template

Provide a template for submitting CRs in ClearQuest, detailing required fields and descriptions.

Appendix C: SCCB Meeting Minutes Template

A template for documenting SCCB discussions, CR status, and decisions made during meetings.


This document structure ensures comprehensive guidance for managing software releases and change requests while utilizing IBM ClearQuest, ClearCase, and SCCB effectively.

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

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