EVOTE Project Plan
Annex 1 - Configuration Management Plan
Annex 1 - Configuration Management Plan
Introduction
The fundamental purpose of Configuration Management (CM) is to establish and maintain the integrity and control of software products throughout a project’s life cycle.
The Software Configuration Management process is comprised of the following integrated activities:
· Configuration identification of artifacts/ work products used or developed by a project
· Configuration change control of information, including the impact of changes to organizations, management practices, schedules, budgets, technical or assurance activities, testing or retest requirements, or project status
· Status accounting of artifacts/ work products used in the development, release, and maintenance of a project
· Configuration reviews and audits that assess the status and acceptability of products controlled or released by CM
The fundamental purpose of Configuration Management
(CM) is to establish and maintain the integrity and control of software products throughout a project’s life cycle.
The Software Configuration Management process is comprised of the following integrated activities:
• Configuration identification of artifacts/ work products used or developed by a project
• Configuration change control of information, including the impact of changes to organizations, management practices, schedules, budgets, technical or assurance activities, testing or retest requirements, or project status
• Status accounting of artifacts/ work products used in the development, release, and maintenance of a project
• Configuration reviews and audits that assess the status and acceptability of products controlled or released by CM.
1.1. Document Items
1.1.1. Identification
All documents prepared in the project will be assigned an EVOTE document identifier and a version number as defined below:
1.1.1.1. Document identifier
The document identifier has a formal format. This format depends on the type of the document. It is described by the following grammar:
<document identifier> ::= EVOTE-<body>-<partner-id>-<serial>
<body> ::= TS<ts-id> | /* Task */
WP<wp-id> | /* Work package */
PCB | /* Management Board */
PTB | /* Technical Board */
…
<ts-id> ::= 1.1,...,9.1
<wp-id> ::= 1,...,9
<partner-id> ::= QRI,CUS,CRM,ESS,AEG,QNR
serial> ::= INTEGER
This document may have as a document identifier EVOTE/TS1.1/QRI/001, since it is a first contribution to TS1.1 from QRI.
Body is the EVOTE body i.e. work package, work area, PCB, and PTB.
Serial: Integer that makes the identifier unique. Since only the partner is part of the identifier, each author should chose a (three digit, zero filled) number that makes the whole identifier unique within the partner company according the Body (and thus unique within the project).
NOTE: Version number: A unique integer used to distinguish between different versions of the same document. First version should be 1. In our definition, a version is meant to be a total replacement for a previous version of the same document, if any. Repeats of studies of a given subject (e.g. Initial Architecture, Final Architecture) are reported in different documents, not different versions, of the same document. Track of ancient history is kept in the history section of the document. Thus it is not necessary (though some partners may find it desirable) to maintain previous versions of a document. Throughout the life of a document, the document type and identifiers will remain unchanged. The version starts from 1 and continues to 2, 3,etc. A document is to be a new version if it is distributed and different from the last distributed version of the document.
Deliverables to the Commission are additionally given a CEC identifier. Details follow:
1.1.1.2. CEC identifier
The CEC identifier consists of seven parts:
Project Identification: The letters “IST”+ the contract number.
Name of the organisation: Acronym.
Unit/Section: Acronym
Type of Document: For the purposes of document distribution amongst the different partners in a project, it is necessary to adopt a uniform set of document designators. The following Table 1 -Distribution Codes may be sufficient to meet the needs within the project:
Table 1 -Distribution Codes
DistributionID /
Recipients
/ ExplanationsAO / Addressees-only / This covers documents, which are intended only for the use by a defined group.
AR / Administrative Report / This includes documents, which are generated in the context of administration of a project, e.g. financial reports and the like.
DS / Deliverable / This represents a document relating to a specific deliverable as opposed to an aggregate report.
DR / Deliverables Report / The results of a project are typically documented in a report describing the Deliverables.
DH / Discussion Note / In the context of concentration meetings, documented contributions are generated. These fall typically in this category.
IN / Information Note / Between partners information will be actively circulated which serve as background and reference.
MR / Management Report / The EVOTE Management Concept foresees specific procedures including Management Reports.
MD / Meeting Documentation / In the context of the execution of EVOTE, meetings take place, some of which will result in substantial documents.
PI / Project Internal / Information, which is intended for use only within a project at a given stage.
RI / Project Internal / Information, which is intended for use between the partners at a given stage.
WA / -Working Assumptions / In developing a Deliverable numerous working assumptions have to be made. Some of these reflect the interdependence with other Deliverables not yet available.
Distribution: One letter code reflecting the confidentiality type of the deliverable (P=Public, R=Restricted, C=Confidential, I=Internal).
Serial Number: The official reference, 3 (zero filled) digits.
Revision Number: Two alphanumeric numbers:
Table 2 - Revision Numbers
For
/ Revision NoDrafts / a + 1 digit
Project approved / b + 1 digit
Concentration / c + 1 digit
EVOTE endorsed / d + 1 digit
E.g. the identifier for the second Deliverable as its report type within the EVOTE Project could be:
EVOTE-QRI-IT-REP-P-D02.1/b1
where:
EVOTE Project identifier
QRI Partner organisation identifier
IT Department identifier of partner organisation
REP Type of deliverable i.e. Report (REP), Demonstration (DEM),
Workshop (WKP), Prototype (PRO)
P Availability of the deliverable (P, R, C, I, as explained above)
D02.1 Official identifier of the deliverable (refer to Contract)
b1 Revision and approval classification number
Each partner organisation shall maintain a register of the documents it has created, with version number, date, status and confidentiality.
A list of the official documents produced by the project (and sent to the Commission) will be maintained by the PM.
1.1.2. Status
Documents are assigned a status of "Draft", "Proposed", "WP Approved" or "Project Approved" as defined below:
Status / Meaning'WP Approved' / Means that the document has successfully completed the approval procedure within a work package set up for that type of document.
`Project Approved' / Means that the document has successfully completed the project approval procedure set up for that type of document.
`Proposed' / Means that the document has entered but not successfully completed the appropriate approved procedure.
`Draft' / Means that the document has not entered the approval procedure.
The EVOTE Release procedure shall be used to release Project Approved documents.
1.1.3. Changes
Changes to released documents shall be initiated and controlled using the EVOTE Problem Reporting and Corrective Action procedure.
A history section at the beginning of documents will trace the different changes.
1.2. Code/Data Items
1.2.1. Identification
Code and data items generated in the project shall be assigned a unique identifier and version number as defined for each work package. Where possible the identifier and version shall be included in the item as a comment or in some other way.
Source Code Control System (SCCS) or equivalent will be used to handle software developed in EVOTE.
1.2.2. Status
WPLs shall keep records, which allow the test status of versions of code and data items to be determined. Use of SCCS will assist this.
1.2.3. Libraries
Libraries of code and data items shall be backed up at least weekly to enable recovery of all but recent work in case of loss. Backups covering at least one month shall be retained.
1.2.4. Media
External media shall be labelled and records kept identifying its contents. (This may be important when it is necessary to regenerate an old version of a code delivery, for instance.)
1.2.5. Changes
Changes to released code and data items will be controlled using the EVOTE Problem Reporting and Corrective action procedure.
Procedures
1.3. EVOTE Standards Control Procedure
1.3.1. Purpose
The purpose of this procedure is to ensure that standards required by EVOTE are kept to the necessary minimum, and are maintained under proper control.
1.3.2. Outline
Standards must be brief and to the point. The Project Manager must review and approve standards, and changes to standards, before they are introduced.
1.3.3. Procedures
1.3.3.1. Identifying the Need for a New or Changed Standard
Only WPLs .may identify the need for a new standard, or changes to one already introduced. A standard can be one of:
1. a document,
2. a procedure, or
3. a form.
Standards will normally only be required for documents and forms, which pass between teams and procedures, which involve more than 1 team.
1.3.3.2. Preparing a Standard
Standards must be concise and to the point. They should not normally be longer than 2 pages. They will be Word 2000 documents. They will clearly identify their status and version number.
1.3.3.3. Approving a Standard
All new standards, and changes to existing standards, must be reviewed and approved by the Project Manager before they are introduced. The Project Manager will only approve a standard when the need for it is demonstrated to his satisfaction. The Project Manager may seek the views of the PCB and/or Technical Coordinator on specific subjects.
1.3.3.4. Distributing Standards
PMO Executive will maintain a directory of current approved standards on a server accessible by EVOTE Web Site. On receipt of a new or changed standard approved by the Project Manager, PMO Executive will place it on the server, and advise all project staff that they may download it by EVOTE Web Site, and should destroy old versions.
1.4. EVOTE ISSUE Report and Corrective Action Procedure
1.4.1. Purpose
To establish control over the raising and resolution of ISSUES with released items, and problems affecting more than one WP.
The same procedure and forms with minor modifications may also be used within a WP to control the raising and resolution of problems confined within the WP.
1.4.2. Outline
An ISSUE reported by the individual identifying it on a standard form by e-mail to the PM in QRI. The PM logs it, assigns a reference number, and advises it to the participant dealing with it and the originator. The participant initiates analysis. When the appropriate action is determined, it is approved by the WPL, and the PM and the originator is informed of the expected completion date. When the action has been completed the participant informs the PM and the originator and the PM closes the issue report.
1.4.3. Procedures
1.4.3.1. Raising by Originator
A project ISSUE report must only be raised if the problem is with a released item, or has an effect outside the immediate WP. Complete the ADMINISTRATION and PROBLEM STATEMENT sections of an EVOTE PROBLEM REPORT. E-mail it to the PM.
1.4.3.2. Logging by PM.
Log the problem report as follows:
q create an entry in the central EVOTE PROBLEM REPORT LOG
q assign the SERIAL #, Innn where n is next available number, and advise originator and local control point
q store the copy problem report in the appropriate folder.
The PM may review the reported severity of a problem report with the originator. If the severity is subsequently modified, the PM will notify originator and the WPL
1.4.3.3. Analysis by PM
Log the problem report in the local EVOTE ISSUES LOG, responding immediately to problem reports with SEVERITY 1 (critical). Initiate analysis and update OWNER on problem report and log. Analyse the problem to determine the action required and the target for completion. E-mail to the local WPL for approval.
1.4.3.4. Approval by WPL
Satisfy yourself that the analysis is correct, that the action proposed is appropriate, and the target for completion reasonable. If not, then link with the analyser. If so, arrange for the action to be carried out, update OWNER to the email address of the person responsible for the action, set STATUS to B, and email the problem report to the local control point to update the local log, copying to the central control point to update the central log.
1.4.3.5. Taking Action
Carry out the action required, recording any significant events as they occur. When complete, update ACTUAL COMPLETION DATE and OWNER and email to local control point.
1.4.3.6. Closing
The local control point updates the local log to reflect closure, and emails to the central control point. The central control point updates the central log to reflect closure by setting the STATUS to C.
1.4.3.7. Monitoring by Central Control Point
The central control point will prepare a report on the status of open problem reports on the last day of each month and email it to the PM and WPLs.
1.4.4. Forms
Project Problem Report Form
Problem Report Log
Problem Status Report
1.5. EVOTE Technical Review Procedure
1.5.1. Purpose
To establish control over technical reviews.
This procedure and the associated forms shall be used for all technical reviews of documents on the EVOTE project, both at the Work Package and Project levels. Technical reviews may be conducted by e-mail, or at a face-to-face meeting, at the discretion of the Moderator.
1.5.2. Outline
This procedure requires 3 distinct roles:
q the MODERATOR is responsible for issuing the invitation, for approving the corrective action proposed by the editor in the light of comments from reviewers, for determining whether a further technical review is necessary, and for approving the corrected document if it is not.
q REVIEWERS are responsible for examining the document and commenting constructively upon it.
q the EDITOR is responsible for analysing the comments from reviewers, proposing any appropriate corrective action, and effecting corrections to the document.