D R A F T. Resource Ordering and Status System (ROSS) Software Configuration Management Guidelines

Transcription

1 TO #GA81 Resource Ordering and Status System (ROSS) D R A F T Resource Ordering and Status System (ROSS) Software Configuration Management Guidelines June 28, 2000 Version 1.1 Contract: GS-35F-4863G Delivery Order Number: GA81 Configuration Management & Control 1

2 1.0 Software Configuration Management Overview Software Configuration Management (SCM) is the effective management of the evolving configuration of a software product or system, and its related documentation. SCM controls and monitors the evolving software products, their technical requirements, and conformance to these requirements. Control over the evolving product s characteristics is maintained by establishing reference points or baselines. The SCM discipline applies technical and administrative direction to each phase of the software lifecycle to: 1. Identify all documents and physical media for each major module 2. Control changes to the software 3. Record and report change processing and implementation status 4. Changes are tracked via SP/CRs (Software Problem/Change Reports), Discrepancy Reports/Notices 1.1 Software Configuration Management - Organization and Responsibility During the performance of this Task Order, the ROSS Program s Software Configuration Management will be established and maintained by the selected members of the ROSS team. Specific responsibilities are identified in the Program Management Plan. 2.0 Configuration Identification All functional and physical characteristics of the ROSS major modules identified in the ROSS Specification Tree and in the Deliverables Mapping Spreadsheet, including the Software Requirements Specification, the RTM, the System Design Document, files and code, will be tracked and updated throughout the ROSS life cycle. All customer-furnished software and vendor-supplied COTS software will be uniquely identified and tracked. 3.0 Flow of Configuration Control Configuration control is the process by which changes to customer-approved baseline items and to internal baseline items are initiated, clarified, evaluated, approved, documented, implemented, and verified. ROSS Configuration control will: 1. Establish a developmental configuration for each module. 2. Maintain current copies of the deliverables. 3. Provide the customer with documentation and code access under configuration control. 4. Control and preparation and dissemination of changes to the master copies of deliverable software and documentation that has been placed under configuration control so that they reflect only the approved changes. 5. Maintain current copies of vendor COTS software media, licensing information, and related documentation. Figure 3.0 depicts the flow of control through the configuration management process. Software changes, enhancements, and problems can originate from any ROSS team member or the customer. These changes are tracked through Software Problem Change Reports, Discrepancy Reports, or Discrepancy Notices. 3.1 Classifications of SCM Changes Changes to software or documentation can be placed into one of three classifications: 1. Class I This type of change alters the operation or physical characteristics of a configured item or customer-approved baseline beyond the scope of intent under the current design requirements. These include: Configuration Management & Control 2

3 a. Compatibility Changes those changes to correct a deficiency that prevents the product from performing within contractual requirements. b. Design Changes those changes resulting from new or modified requirements outside the scope of the existing contract Class I changes require approval by the project and the customer prior to implementation. Ross identified Class 1 Change Prepare Proposed Specification Changes Prepare ECP/SCN Pkg & circulate for Review Approval Yes ECP/SCN Pkg Logged & sent to Contract Admin/submits to Customer No Customer Approval No ROSS notified of disposition Yes Returns to ROSS Contract Admin Conditionally Approved ECPs to CM ROSS Team incorporates changes Approved Proposed changes to CM Approval Yes Specification revised CM updates log & forwards to document release Document release Internal distribution No Submit revision to Customer Figure 3.0 Flow of Configuration Control 2. Class II These types of changes are usually non-technical, affecting ONLY the documentation. Class II changes do not require project or customer approval prior to implementation. Copies of Class II changes must be forwarded to the customer for concurrence of the change classification. 3. Internal Are changes to software or documentation that have not been classified as Class I or Class II changes. Changes released during development testing are treated as Internal Changes unless the change affects the documentation representing the Baseline. Configuration Management & Control 3

4 Internal changes do not require project approval, customer approval, or customer concurrence. 3.2 Reporting Documentation The documentation used to report and track changes in the developmental configuration or formal baseline are the Software Problem/Change Report (SP/CR), Discrepancy Notice (DN), Engineering Change Proposal (ECP), and Specification Change Notice (SCN). The Issue Weaver application will be used to input, track, and update SP/CRs and DNs Software Problem/Change Report (SP/CR) The SP/CR is the vehicle used internally to report a known or suspected anomaly in the developmental configuration. If a software problem results in changes to an approved baseline, an SP/CR is prepared with accompanying redlined specification change pages and forwarded to the project officer for disposition. Following project officer approval of SP/CRs, the work to correct the problem and the work on the supporting ECP with SCNs are started. Final approval will be with the acceptance of the ECP and SCNs Discrepancy Notice (DN) The DN form is the vehicle used during Formal Test by for tracking and reporting hardware/software problems that occur during validation testing. If the problem is in software, an SP/CR(s) is filed, the problem is fixed, the software is retested to the extent necessary, and the SP/CR and DN are closed Engineering Change Proposal (ECP) The ECP is used to propose Class I changes to the customer and for the customer to finalize Class II changes. It describes the merits of the proposed change, the desirability of authorizing the required funding, and the available alternatives. It gives the customer the information needed to evaluate changes that have performance, cost and schedule implications. The ECP is approved by the and coordinated through the Project Officer prior to formal submittal Specification Change Notice (SCN). The SCN is used to propose, transmit, and record Class I and Class II changes to base-lined specifications. Changes shall be made upon completion of a review or made as a normal update of the specification. The SCN, which documents the exact changes to the specifications, shall be required as part of an ECP. 4.0 Review Procedures If the base-lined specifications are impacted, the ROSS internal processing of ECPs/SCNs by the Configuration Control Board () is initiated. The reviews the ECP change. If approved, the ECP/SCN is submitted to the customer for review and approval. When the ROSS customer approval is received, approved changes are implemented. If required, deviations and waivers are requested. Upon customer approval of the ECP, the associated SCN with specification change pages (or specification revision) will be processed. The Configuration Management system for major systems is composed of a hierarchy of control boards that can interface with the customer s control boards. These formal control boards are the Configuration Control Board and the Software Configuration Review Board. For this Task Order, the, ERB and SCRB Boards are merged, with the Program Manager acting as the Chair for all three. The ROSS Program Management and Key Lead Personnel will represent the ROSS /SCRB. Weekly board meetings are held each Tuesday for the purpose of reviewing any Class I, Class II or Internal Changes. 4.1 Configuration Control Board () The is the forum through which the impact of changes to the program's technical requirements are evaluated, then transmitted to the implementation team members. The assesses the necessity for, and reviews the proposed changes to, the authenticated baseline. The release (submittal) of specifications and changes to approved baselines requires approval of the. The is composed of senior members of the program and is chaired by the Program Manager. The chairman may request that customer Configuration Management & Control 4

5 representatives, or other contractor/subcontractor representatives support any meeting. Members of the advise the Chairman of the impact of proposed changes in the areas of cost, production, development, reliability, maintainability, training, logistical support, and specifications. Changes are initiated as ECPs or SP/CRs based on classification. The authorizes submittal of only those changes for which a requirement exists. Customer approval is required prior to implementing any change to a controlled baseline. 4.2 Software Configuration Review Board (SCRB) The SCRB interacts and coordinates with the to affect configuration control of internal baselines and provide inputs to formal baselines. The SCRB ensures that the procedures and mechanisms for updating and maintaining the software baseline are adequate and rigidly enforced. The SCRB analyzes SP/CRs generated by the test team or other originators and initiates action as appropriate. The SCRB is chaired by the ROSS Program Manager. The Documentation Management & Control Function records the minutes. Participating members are Software Team members, Test Team representative(s), Software Quality Assurance, Configuration Management, and as needed, participants from other functional disciplines. The SCRB is chartered to implement the resolution of software issues and maintain software baselines. To this end, the SCRB reviews all SP/CRs to determine the technical aspects, identify the need for change, assess the impact of software performance, and determine the ability to provide required technical support to resolve the discrepancy. The objectives of the SCRB are identified below: a. To resolve (or coordinate the resolution of) all issues against baselines of deliverable software. Issues include errors, deficiencies, and interface changes as well as failure to meet quality standards. b. To administer the software SP/CR process. The SCRB is authorized to proceed unilaterally on internal changes. c. To effect such changes to any established software baseline as are detailed by the resolution of SP/CRs. d. To manage changes to software which reside in multiple baselines. e. To establish, review, and approve all software configurations for the software development environment. g. In terms of Software Configuration Management, to: 1. Administer configuration control, consisting of the management of the software SP/CR process, and the capturing of baselines for new software releases. 2. Provide configuration status accounting and SCM metrics. The ROSS SCRB will meet with the on a weekly basis, as determined by the chairman. An SP/CR Status Report, which will serve as the agenda, will be prepared and distributed by the SCRB Recorder in a timely manner to adequately support the functions of the boards. The relationship of the, ERB, and SCRB review boards is shown in Figure 4.0. Configuration Management & Control 5

6 C CLASS 1 CHANGE APPROVAL CLASS II CHANGE CONCURRENCE PREPARE/SUBMIT ECP DATA SPR/CR ERB CONTRACTORS CHANGE AUTHORITY ECP APPROVAL DEVIATIONS WAIVERS SCRB SPR/CR TECHNICAL CONTROL OF S/W BASELINE REVIEW/APPROVE INTERNAL BASELINE CHANGES IDENTIFY AND ESTABLISH SYSTEM REQUIREMENTS FUNCTIONAL BASELINE ALLOCATED BASELINE C Customer Configuration Control Board Configuration Control Board (chaired by the ROSS Program Manager) ERB Engineering Review Board (combined w/ross ) SCRB Software Configuration Review Board (chaired by the ROSS Program Manager) Figure 4.0 Example Control Board Interaction The ROSS is a merged board having the responsibilities of the, ERB and SCRB combined activities. Weekly meetings are held to review submitted changes for approval. In addition, more frequent meetings are held by the Chair (Program Manager) on an as-needed basis to review requested changes and identified problems in order to maintain the momentum of the development and testing efforts. These changes are captured in a standard format and maintained as historical data. The merged relationship of the, ERB, and SCRB boards are illustrated in Figure 4.0a. Includes responsibilities of ERB, & SCRB C ROSS Merged Class I Change Approval Class II Change Concurrence Prepare/Submit ECP Data SP/CRs Contractors Change Authority Technical Control of Sw Baseline Review/Approve Internal Baseline Changes Establish ROSS System Requirements and Baselines ECP Approval Deviations Waivers Figure 4.0a ROSS Team / Customer problem identification ROSS Control Board Interaction Configuration Management & Control 6

7 5.0 Configuration Status Accounting Configuration Status Accounting is the means through which control and tracking of discrepancies and change requests affecting major modules are reported to the ROSS Program Manager. The Configuration Status Accounting contains an ECP Status log. Approved ECPs to the product baseline developmental configuration are listed, thus providing a status accounting of ECPs against each major module. Each ECP status log contains at least, the following: a. Control number b. Descriptive title c. Origination data d. Author's name e. Priority f. Status change date g. Comments or action assigned 5.1 Configuration Audits The ROSS Configuration Manager will plan, schedule, co chair the audits, and follow up on any resulting actions of any formal configuration audits. The CM will ensure the customer is advised of the status schedule and agenda of pending audits. Records and summary reports will be maintained for all internal reviews and audits conducted during the various phases of the ROSS Program development life cycle. 6.0 Configuration Management Major Milestones Configuration Milestones will be reached as each iterative software life cycle is reached. Milestones will consist of the following baseline controls: a. Functional Baseline. Periodic customer reviews will establish and authenticate the ROSS Functional Baseline. b. Allocated Baseline. The SRS will establish the Allocated Baseline for each major module. c. Product Baseline. Upon successful completion of the functional and physical configuration audits for each major module, and when authenticated by the customer, a Software Product Specification for each major module will be entered into the Product Baseline and the module s developmental configuration will cease to exist. Configuration Management & Control 7