某公司SCM供应链管理

1、Software Con figuratio n Man ageme nt(SCM)Docume nt Number: nnDate: Day, Month Day, Y earProject NameAuthor 1Author 2 - if non e, leave bla nk lineAuthor 3 - if non e, leave bla nk line Author 4 - if non e, leave bla nk lineProfessor NameSoftware Engin eeri ng Departme ntMonm outh Uni versityWest Lo

2、ng Bran ch, NJ 07764-1898Table of Contents1. scope41.1. Identification41.2. System Overview41.3. Document Overview42. REFERENCED DOCUMENTS53. requirements summary53.1. Background , Objectives , and Scope53.2. Operational Policies and Constraints63.3. Description of Current System or Situation63.4. U

3、sers or Involved Personnel73.4.1 Configuration Requirements8 3.5. Software Configuration Management Criteria4. JUSTIFICATION124.1 Assumptions andConstraints124.2 Additional Items for consideration :125. NOTES131 ScopeThis section shall be divided into the following paragraphs.1.1 Identification This

4、 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 OverviewThis paragraph shall briefly state the purpose of t

5、he 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 pla

6、nned operating sites; and list other relevant documents.1.3 Document OverviewThis paragraph shall summarizethe purposeand contents of thisdocumentand shall describe any securityor privacy considerationsassociated with its use.2 Refere need Docume ntsThis sectionshall list the number, title, revision

7、, and date of alldocume nts refere need in this specificati on. This sect ion shall also ide ntify the source for all docume nts.3 Requireme nts SummaryThis sect ion shall be divided into the follow ing paragraphs to describe therisk man ageme nt requireme nts as it curre ntly exists.3.1 Backgro und

8、, Objectives, and ScopeThis paragraph shall describe the backgro und, missi on or objectives, andscope of the product or situati on.Example: Requireme nts regard ing software con figurati on man ageme nt (SCM) cover a broad arena. SCM is consideredone of the integralprocesses that support the other

9、activities in the sta ndard. The developers approach, described in the projects SDP, is to address all applicable con tract clauses for SCM in cludi ng:Con figuratio n ide ntificati onCon figuratio n con trolCon figuratio n status acco un ti ngCon figurati on auditsPackag ing, storage, han dli ng, a

10、nd delivery3.2 Operati onal Policies and Con strai ntsThis paragraph shall describe any operationalpolicies and constraintsthat apply to the curre nt system or situati on.Example: SCM activities apply to all software products prepared, modified, an d/or used to develop software products as well as t

11、o the products un der developme nt,modificati on,ree ngin eeri ng,or reuse.If asystem/subsystem or SWI is developed in multiple builds, SCM in each build is to be un derstoodto take place in the con text of the softwareproducts and con trols in place at the start of the build.3.3 Descripti on of Cur

12、re nt System or Situati onThis paragraph shall provide a description of the current system or situati on, ide ntify ing differe nces associated with differe nt states or modesof operation (for example, regular,maintenance,training, degraded,emerge ncy, alternative-site, wartime, peacetime). The dist

13、i nctio n betwee n states and modes is arbitrary. A system may be described in terms of states only, modes only, states withi n modes, modes with in states, or any other scheme that is useful. If the system operates without states or modes, this paragraph shall so state, without the n eed to create

14、artificial dist in cti on s.3.4 Users or Involved PersonnelThis paragraphshall describethe types of usersof the system,orpersonnel involved in the current situation, including, as applicable, organizational structures, training/skills, responsibilities, activities, and interactions with one another.

15、 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.

16、Participate in selecting CSCIs during system (architectural) design. Identify entities to be placed under configuration control. Assign a projectunique identifier to each SWI and each additional entity to be placed under configuration control, including software products to be developed or used and

17、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 gr

18、oups 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

19、 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. Incl

20、ude, 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,

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

22、entsThis paragraph describes the configuration management requirements for the project.Example:SCM requireme nts task the developer to keep track ofeveryth ing duri ng the course of the developme nt. SCM is an activity, not an orga ni zati on. SCM may be performed by members of the developme nt team

23、,individualswithin a project tasked with that responsibility,aseparate orga ni zatio n, or other arran geme nt suitable for the project.3.5 Software Con figurati on Man ageme nt CriteriaThis paragraph describes the software con figurati on man ageme nt criteria to be followed duri ng the project.Exa

24、mple: The sta ndard requires the developer to establish levels of con trol for allwork products. Some examples of possible levels of control and of things the developer might ide ntify and con trol are:Author con trol:Engineeringdata - notes, records, work-in-progress(i.e., dataspecified in document

25、sassociated with particular developmentactivities)Software developme nt filesProject con trol:Informationin documentsagreed upon by the project to becorrectReuse librariesEvaluati on recordsOrga ni zati onal con trol:Gen eralpurpose software - operat ingsystems, databaseman ageme nt systems, e-mail,

26、 word processors, spreadsheetsEngin eeri ngand developme nt tools - CASE tools, editors,compilers, debuggers, SCM tools, test softwareComputer system adm ini strative tools and products - diag no stic software, n etwork man agers, archives, backupsEvaluati on recordsAcquirer con trol:Specificati ons

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

28、anges 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 modi

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

30、and developer representatives. The standarddoesnot 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 standa

31、rd 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 configurationaudits, these activities may notapply to all projects.All work products (including compu

32、terized 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 fil

33、es, 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 co

34、ntained in each record and who is responsible for performing these activities.4 JustificationThis section shall be divided into the following paragraphs.4.1 Assumptions and ConstraintsThis paragraph shall identify any assumptions and constraints applicableto 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 softw