SOFTWARE CONFIGURATION MANAGEMENT PLAN
OVERVIEW
The purpose of the SCM Plan is to have a defined process to manage changes. This task is accomplished by executing the following activities:
- Identify the documents that require change control (Configuration Items).
- Control the changes to baselined configuration items.
- Auditing of all changes to verify they made correctly.
- Status reports for all configuration items.
- Managing different versions of configuration items.
SOFTWARE CONFIGURATION ITEMS
During the process of producing the spreadsheet software, each of the following objects are to be identified, approved, made into baselines and then stored in the project database.
2.1 Software Configuration Management
Documentation for control of changes during the process, includes this SCI identification document, version control, change control, status reporting, and auditing.
2.2 Software Requirement Specification
Detail definition of the software features, functions, and capabilities.
Describes design constraints, expected software response, and special
consideration, etc.
2.3 System Test Plan
Description of the software testing strategy and approaches to be used in testing the software. Includes information about testing methods, principles, and tools.
2.4 Design Specification
Documentation of design principles and concepts that closely interact with the requirement specification. Description of design architecture, patterns, notation, and tools.
2.5 Unit Test
Programs and data to be used in testing of the functionality of the software.
2.6 Executables
Final product of the software project, including on-line help, data, and configuration files, etc.
2.7 User’s Manual
Written document for both technical and non-technical user.
Documentation for control of changes during the process, includes this SCI identification document, version control, change control, status reporting, and auditing.
2.2 Software Requirement Specification
Detail definition of the software features, functions, and capabilities.
Describes design constraints, expected software response, and special
consideration, etc.
2.3 System Test Plan
Description of the software testing strategy and approaches to be used in testing the software. Includes information about testing methods, principles, and tools.
2.4 Design Specification
Documentation of design principles and concepts that closely interact with the requirement specification. Description of design architecture, patterns, notation, and tools.
2.5 Unit Test
Programs and data to be used in testing of the functionality of the software.
2.6 Executables
Final product of the software project, including on-line help, data, and configuration files, etc.
2.7 User’s Manual
Written document for both technical and non-technical user.
VERSION CONTROL
Version Control combines procedures and tools that manage different versions of configuration object that are created during the software engineering process with respect to the VT100 Spreadsheet project. Each version of the software is a collection of Software Configuration Items (source code, documents, data) and each version may be composed of different variants.
3.1 Identifying New Versions
A Software Configuration Item (SCI) will receive a new version number when there has been a change to its established baseline. Each previous version will be stored in a corresponding directory such Version0, Version1, Version2, etc.
3.2 Numbering Scheme
The numbering scheme will have the following format:
Version X.Y.Z The first letter(X) represents the entire SCI. Therefore, changes made to the entire Configuration Item, or changes large enough to warrant a completely new release of the Item, will cause the first digit to increase.
The second letter(Y) represents a component of the SCI. This digit will sequentially increase if a change is made to a component, or small changes to multiple components.
The third letter(Z) represents a section of the component of a SCI. This number will only be visible if a component of an SCI can be broken down into individual sections. Changes made at this level of detail will require a sequential change of the third digit.
Version Control numbering could, in theory, continue even further, but for the purposes of this project three digit tracking should suffice.
3.3 Visibility
The version number will be visible either in a frame, or below the title. The decision for this depends upon the group decision to code all documents for a frames capable browser or allow for non-frames capable browsers. In either case, the number will always be made available.
3.4 Tracking
The best way to keep track of the different versions is with a Evolution Graph (Figure 1).
Fig 1 – Evaluation Graph
For example, if we wanted to keep track of every updated project schedule then we could assign a version number each time a change was made. Using figure 1 and applying it to this situation, you would see that the schedule evolved from the original (Version 1) to the most current draft (Version 2) with many different versions in between.
CHANGE CONTROL
Summarized in the Fig 2 – The Change Flow Diagram
4.1 Controlling Change
In most projects changes are inevitable. In order to insure that changes are necessary and that all impacted aspects of the project are informed of a change in a concise and timely fashion it is important to have a change control policy in force. Informal changes are made to documents, which have not been baselined. Once a document has been baselined, the following steps must be completed in order to guarantee that all changes are tracked, documented and, if necessary, implemented properly:
4.2 Request For Change
When the need for a change is perceived, the first step is to submit a Request for Change. This is done via SCM tools. The request information is entered into SCM tools and saved. The Software is then notified of a change request. A committee of at least three people is formed to review the request.
4.3 Review Results
The committee evaluates the Change Request and a Change Report is generated using SCM. The Change Report will include the impact on the schedule and a possible solution. This form will be completed by the committee and forwarded for further evaluation.
4.4 Change Control Authority — Evaluation
The Change Report Form is evaluated by the CCA. The CCA makes all final decision on any proposed changes. If the CCA denies the change request software will be notified and will in turn notify the requester. If the CCA deems the change necessary an Engineering Change Order (ECO) is generated in SCM tools by the CCA.
4.5 Change Implementation
When an ECO is received all impacted parties will be notified along with the requester of the change. SCM Software will then assign personnel to implement the change. The assigned personnel begin work on the configuration item. When the work is completed the item is subject to a Change Review Audit. The results of the audit are then documented in SCM tools. All normal procedures for baselining a configuration item are followed, including a Formal Technical Review.
4.6 Baselined Change
Once the change has passed QA and testing procedures the changed configuration item is baselined. The changed configuration item is set for inclusion into the next revision of the software. When the revision is built a Review Audit takes place in order to confirm the change, and to check for impact in the project. If the audit is completed successfully the change is included in the new version and the new version is distributed.
SOFTWARE CONFIGURATION AUDITING PLAN
Software configuration audits will be conducted by the software quality assurance group and will concentrate their efforts in two main auditing areas: engineering change order auditing for projects in development and the final end of project audit.
5.1 Engineering Change Order Auditing
Engineering change order (ECO) auditing verifies the following items:
- That the ECO change has been made and that only this modification has been incorporated into the specified configuration item.
- That a formal technical review (FTR) has been conducted to assess the impact of this change.
- That the changed configuration item has been properly documented with the change date and change owner and that the change is what was specified in the ECO.
- That any other configuration items related to this ECO have been updated to reflect that change(s) made.
- That the auditing documentation was done in SCM tools for the ECO and was approved by the quality assurance group.
FINAL PROJECT AUDIT
6.1 Physical Configuration Audit (PCA)
This audit verifies that the product delivered adheres to all the standards in the software quality assurance plan and that all the require deliverables have been completed. This audit is implemented by reviewing the product components by the software quality assurance group and determining if all the components have been completed and approved in prior FTR and SCA meetings.
6.2 Functional Configuration Audit (FCA)
This audit verifies that the product delivered meets the functional requirements outlined in the software reqspecification (SRS). This audit verifies the product features have been created and passed unit and system testing. The software quality assurance group generates a final feature and test report that is delivered to the customer along with the product itself.
6.3 Status Report
The status report will be updated whenever a change has occurred.
This plan is copy of the plan found at this address: