公司SCM供应链管理样本.doc

Software Configuration Management (SCM)
Document Number: [nn]
Date: Day, Month Day, Year
[Project Name]
[Author 1]
[Author 2 - if none, leave blank line]
[Author 3 - if none, leave blank line]
[Author 4 - if none, leave blank line]

Professor [Name]
Software Engineering Department
Monmouth University
West Long Branch, NJ 07764-1898

Table of Contents
1. SCOPE 3
1.1. Identification 3
1.2. System Overview 3
1.3. Document Overview 3
2. REFERENCED DOCUMENTS 3
3. REQUIREMENTS SUMMARY 3
3.1. Background, Objectives, and Scope 4
3.2. Operational Policies and Constraints 4
3.3. Description of Current System or Situation 5
3.4. Users or Involved Personnel 5
3.4.1 Configuration Requirements 6
3.5. Software Configuration Management Criteria 6
4. JUSTIFICATION 9
4.1 Assumptions and Constraints 9
4.2 Additional Items for consideration: 9
5. NOTES 10

1 Scope
[This section shall be divided into the following paragraphs.]
1.1 Identification
[This paragraph shall contain a full identification of the system and the software to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).]
1.2 System Overview
[This paragraph shall briefly state the purpose of the system and the software to which this document applies. It shall describe the general nature of the system and software; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.]
1.3 Document Overview
[This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.]
2 Referenced Documents
[This section shall list the number, title, revision, and date of all documents referenced in this specification. This section shall also identify the source for all documents.]
3 Requirements Summary
[This section shall be divided into the following paragraphs to describe the risk management requirements as it currently exists.]
3.1 Background, Objectives, and Scope
[This paragraph shall describe the background, mission or objectives, and scope of the product or situation.]
[Example: Requirements regarding software configuration management (SCM) cover a broad arena. SCM is considered one of the integral processes that support the other activities in the standard. The developer's approach, described in the project's SDP, is to address all applicable contract clauses for SCM including:

Ÿ Configuration identification

Ÿ Configuration control

Ÿ Configuration status accounting

Ÿ Configuration audits

Ÿ Packaging, storage, handling, and delivery

3.2 Operational Policies and Constraints
[This paragraph shall describe any operational policies and constraints that apply to the current system or situation.]
[Example: SCM activities apply to all software products prepared, modified, and/or used to develop software products as well as to the products under development, modification, reengineering, or reuse. If a system/subsystem or SWI is developed in multiple builds, SCM in each build is to be understood to take place in the context of the software products and controls in place at the start of the build.]
3.3 Description of Current System or Situation
[This paragraph shall provide a description of the current system or situation, identifying differences associated with different states or modes of operation (for example, regular, maintenance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this paragraph shall so state, without the need to create artificial distinctions. ]

3.4 Users or Involved Personnel
[This paragraph shall describe the types of users of the system, or personnel involved in the current situation, including, as applicable, organizational structures, training/skills, responsibilities, activities, and interactions with one another.]
[Example: Developer's key activities related to Software configuration management:
Describe the approach to be followed for software configuration management, identifying risks/uncertainties and plans for dealing with them. Cover all contractual clauses pertaining to software configuration management.
Participate in selecting CSCIs during system (architectural) design. Identify entities to be placed under configuration control. Assign a project-unique identifier to each SWI and each additional entity to be placed under configuration control, including software products to be developed or used and the elements of the software development environment. Use an identification scheme that identifies entities at the level of control and include version/revision/release status.
Establish and implement procedures designating levels of control each identified entity must pass through, the persons or groups with authority to authorize changes and to make changes at each level, and the steps to be followed to request authorization for changes, process change requests, track changes, distribute changes, and maintain past versions. Propose to the acquirer, in accordance with contractually established forms and procedures, changes that affect an entity already under acquirer control.
Prepare and maintain records of configuration status of all entities that have been placed under project-level or higher configuration control. Maintain configuration status records for the life of the contract. Include, as applicable, version/revision/release, changes since being placed under project-level or higher configuration control, and status of associated problem/change reports.
Support acquirer-conducted configuration audits as specified in the contract.
Establish and implement procedures for packaging, storage, handling, and delivery of deliverable software products. Maintain master copies of delivered software products for the duration of the contract.
Prepare a version description for the system.
Meet general requirements and perform integral processes of the standard.]

3.4.1 Configuration Requirements
[This paragraph describes the configuration management requirements for the project.]
[Example: SCM requirements task the developer to "keep track of" everything during the course of the development. SCM is an activity, not an organization. SCM may be performed by members of the development team, individuals within a project tasked with that responsibility, a separate organization, or other arrangement suitable for the project.]

3.5 Software Configuration Management Criteria
[This paragraph describes the software configuration management criteria to be followed during the project.
[Example: The standard requires the developer to establish levels of control for all work products. Some examples of possible levels of control and of things the developer might identify and control are:

Author control:

Ÿ Engineering data -- notes, records, workinprogress (i.e., data specified in documents associated with particular development activities)

Ÿ Software development files

Project control

Ÿ Source code files, data files, installation software

Ÿ Information in documents agreed upon by the project to be correct

Ÿ Reuse libraries

Ÿ Evaluation records

Organizational control:

Ÿ General purpose software -- operating systems, database management systems, e-mail, word processors, spreadsheets

Ÿ Engineering and development tools -- CASE tools, editors, compilers, debuggers, SCM tools, test software

Ÿ Computer system administrative tools and products -- diagnostic software, network managers, archives, backups

Ÿ Evaluation records

Acquirer control:

Ÿ Specifications

Some key goals of SCM requirements are to ensure that the developer: keeps track of all software and software product descriptions associated with the project; implements only authorized changes to requirements; and knows what software and associated products match a specific set of requirements or changes to those requirements.

To implement changes to requirements, the acquirer and developer must agree upon what those changes are. When requirements have been defined and recorded as specifications and those specifications have been placed on contract, changes are implemented through contract modifications. When specifications have not been made a part of the contract, the acquirer and developer will need to provide a means for controlling and making changes to requirements. These means can be as informal as a phone call or hand-shake, or as formal as documents signed by authorized acquirer and developer representatives. The standard does not provide contractual forms or notices concerning changes in requirements, such as Engineering Change Proposals (ECPs), Engineering Change Notices (ECNs), or notification to users of changes in a particular version of the software. Although the standard does provide a reminder in the form of two "shell" requirements to support acquirer configuration management activities for (1) proposing changes to acquirer controlled entities, and (2) supporting configuration audits, these activities may not apply to all projects.
All work products (including computerized files, the software products that constitute the development environment, and hardware), not just deliverables, are to be identified and controlled during the development and under developer software configuration management activity. The physically controlled items can include: computer files, magnetic media (tapes, diskettes, video cassettes), paper documents, books, manuals, and drawings.

The standard leaves it up to the developer to describe what software configuration management records will be produced, when they will be produced, the level of detail of information that will be contained in each record and who is responsible for performing these activities.
4 Justification
[This section shall be divided into the following paragraphs.]
4.1 Assumptions and Constraints
[This paragraph shall identify any assumptions and constraints applicable to the changes identified in this section.]
4.2 Additional Items for consideration:
[This paragraph shall identify additional items that should be taken into consideration.]
[Example: Additional items that should be taken into consideration are:
Ÿ Describe the approach to be followed for software product evaluation, identifying risks/uncertainties and plans for dealing with them. Cover all contractual clauses pertaining to software product evaluation.
Ÿ Perform in-process evaluations of the software products generated. Perform a final evaluation of each deliverable software product before its delivery.
Ÿ Prepare and maintain records of each software product evaluation. Maintain these records for the life of the contract. Handle problems in software products under project-level or higher configuration control in accordance with paragraph 5.17 of the standard.
Ÿ Maintain independence in software product evaluation. The persons responsible for evaluating a software product are not to be the same persons who developed the product.
Ÿ Meet general requirements and perform integral processes of the standard.
5 Notes
[This section shall contain any general information that aids in understanding this document (e.g., background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of terms and definitions needed to understand this document.]