某公司SCM供应链管理(英文版)

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. SCOPE3 1.1. IDENTIFICATION3 1.2. SYSTEM OVERVIEW3 1.3. DOCUMENT OVERVIEW3 2. REFERENCED DOCUMENTS3 3. REQUIREMENTS SUMMARY3 3.1. BACKGROUND, OBJECTIVES, AND SCOPE4 3.2. OPERATIONAL POLICIES AND CONSTRAINTS4 3.3. DESCRIPTION OF CURRENT SYSTEM OR SITUATION5 3.4. USERS OR INVOLVED PERSONNEL5 3.4.1 CONFIGURATION REQUIREMENTS6 3.5. SOFTWARE CONFIGURATION MANAGEMENT CRITERIA6 4. JUSTIFICATION9 4.1 ASSUMPTIONS AND CONSTRAINTS9 4.2 ADDITIONAL ITEMS FOR CONSIDERATION:9 5. NOTES10 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 developers approach, described in the projects 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: Developers 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, work-in-progress (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 softwar