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 DepartmentMonmouth UniversityWest Long Branch, NJ 07764-1898Table of Contents1. SCOPE 31.1.I DENTIFICATION 3 1.2.S YSTEM O VERVIEW 3 1.3.D OCUMENT O VERVIEW 32. REFERENCED DOCUMENTS 33. REQUIREMENTS SUMMARY 33.1.B ACKGROUND,O BJECTIVES, AND S COPE 4 3.2.O PERATIONAL P OLICIES AND C ONSTRAINTS 4 3.3.D ESCRIPTION OF C URRENT S YSTEM OR S ITUATION 5 3.4.U SERS OR I NVOLVED P ERSONNEL 5 3.4.1C ONFIGURATION R EQUIREMENTS 6 3.5.S OFTWARE C ONFIGURATION M ANAGEMENT C RITERIA 64. JUSTIFICATION 94.1A SSUMPTIONS AND C ONSTRAINTS9 4.2A DDITIONAL I TEMS FOR CONSIDERATION: 95. NOTES 91 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 delivery3.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, work-in-progress (i.e., data specified in documents associated with particular development activities)•Software development filesProject control:•Source code files, data files, installation software•Information in documents agreed upon by the project to be correct•Reuse libraries•Evaluation recordsOrganizational 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 recordsAcquirer control:•Specifications。