公司SCM供應(yīng)鏈管理

1、Software Configuration Management (SCM)Document Number: nnDate: Day, Month Day, YearProject NameAuthor 1Author 2 - if none, leave blank lineAuthor 3 - if none, leave blank lineAuthor 4 - if none, leave blank lineProfessor NameSoftware Engineering Department Monmouth UniversityWest Long Branch, NJ 07

2、764-1898Table of Contents TOC o 1-3 1. Scope PAGEREF _Toc469716150 h 31.1. Identification PAGEREF _Toc469716151 h 31.2. System Overview PAGEREF _Toc469716152 h 31.3. Document Overview PAGEREF _Toc469716153 h 32. Referenced Documents PAGEREF _Toc469716154 h 33. Requirements Summary PAGEREF _Toc469716

3、155 h 33.1. Background, Objectives, and Scope PAGEREF _Toc469716156 h 43.2. Operational Policies and Constraints PAGEREF _Toc469716157 h 43.3. Description of Current System or Situation PAGEREF _Toc469716158 h 53.4. Users or Involved Personnel PAGEREF _Toc469716159 h 53.4.1 Configuration Requirement

4、s PAGEREF _Toc469716160 h 63.5. Software Configuration Management Criteria PAGEREF _Toc469716161 h 64. Justification PAGEREF _Toc469716162 h 94.1 Assumptions and Constraints PAGEREF _Toc469716163 h 94.2 Additional Items for consideration: PAGEREF _Toc469716164 h 95. Notes PAGEREF _Toc469716165 h 10

5、1 ScopeThis section shall be divided into the following paragraphs.1.1 IdentificationThis 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

6、 release number(s).1.2 System OverviewThis 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 p

7、roject sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.1.3 Document OverviewThis paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations ass

8、ociated with its use.2 Referenced DocumentsThis 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 SummaryThis section shall be divided into the following paragraphs

9、to describe the risk management requirements as it currently exists.3.1 Background, Objectives, and ScopeThis 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 ar

10、ena. 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 identificationConfiguration controlConfiguration status accoun

11、tingConfiguration auditsPackaging, storage, handling, and delivery3.2 Operational Policies and ConstraintsThis 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, an

12、d/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

13、at the start of the build.3.3 Description of Current System or SituationThis 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, alt

14、ernative-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

15、 so state, without the need to create artificial distinctions. 3.4 Users or Involved PersonnelThis 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, activi

16、ties, 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 pertainin

17、g 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 softwa

18、re 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 ent

19、ity 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 a

20、ccordance 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 re

21、cords 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

22、 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 t

23、he standard.3.4.1 Configuration RequirementsThis 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

24、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 CriteriaThis paragraph describes the software configuration management criteria to be followe

25、d 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

26、 specified in documents associated with particular development activities)Software development filesProject control:Source code files, data files, installation softwareInformation in documents agreed upon by the project to be correctReuse librariesEvaluation recordsOrganizational control:General pur

27、pose software - operating systems, database management systems, e-mail, word processors, spreadsheetsEngineering and development tools - CASE tools, editors, compilers, debuggers, SCM tools, test softwareComputer system administrative tools and products - diagnostic software, network managers, archi

28、ves, backupsEvaluation recordsAcquirer control:SpecificationsSome 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

29、 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 pl

30、aced 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-

31、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 cha

32、nges 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

33、 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 ac

34、tivity. 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 wil

35、l 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 ConstraintsThis 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