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 Contents1. SCOPE31.1. Identification31.2. System Overview31.3. Document Overview32. REFERENCED DOCUMENTS33. REQUIREMENTS SUMMARY33.1. Background, Objectives, and Scope43.2. Operational Policies and Constraints43.3. Description of Current System or Situation53.4. Users or Involved Pe

3、rsonnel53.4.1 Configuration Requirements63.5. Software Configuration Management Criteria64. JUSTIFICATION94.1 Assumptions and Constraints94.2 Additional Items for consideration:95. NOTES10 1 ScopeThis section shall be divided into the following paragraphs.1.1 IdentificationThis paragraph shall conta

4、in 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 OverviewThis paragraph shall briefly state the purpose of the system and the soft

5、ware 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;

6、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 associated with its use.2 Referenced DocumentsThis section shall list the number, title, revision, and date of all

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

8、aragraph 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 dev

9、eloper's approach, described in the project's SDP, is to address all applicable contract clauses for SCM including:Configuration identificationConfiguration controlConfiguration status accountingConfiguration auditsPackaging, storage, handling, and delivery3.2 Operational Policies and Constr

10、aintsThis 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, re

11、engineering, 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 SituationThis paragraph shall provide

12、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 m

13、ay 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 PersonnelThis pa

14、ragraph 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 c

15、onfiguration 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 (architectur

16、al) 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. Us

17、e 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 cha

18、nges 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 alr

19、eady 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 si

20、nce 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

21、 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 RequirementsThis paragraph describes the configuration managemen

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

23、sponsibility, 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 followed during the project. Example: The standard requires the developer to establish leve

24、ls 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 d

25、evelopment filesProject control:Source code files, data files, installation softwareInformation in documents agreed upon by the project to be correctReuse librariesEvaluation recordsOrganizational control:General purpose software - operating systems, database management systems, e-mail, word process

26、ors, spreadsheetsEngineering and development tools - CASE tools, editors, compilers, debuggers, SCM tools, test softwareComputer system administrative tools and products - diagnostic software, network managers, archives, backupsEvaluation recordsAcquirer control:SpecificationsSome key goals of SCM r

27、equirements 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 requir

28、ements.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 speci

29、fications 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 represe

30、ntatives. 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 r

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

32、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: compute

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

34、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 approach to be followed for software p