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

1、S So of ft tw wa ar re e C Co on nf fi ig gu ur ra at ti io on n M Ma an na ag ge em me en nt t ( (S SC CM M) )Document Number: nnDate: Day, Month Day, Year P Pr ro oj je ec ct t N Na am me e Author 1Author 2 - if none, leave blank lineAuthor 3 - if none, leave blank lineAuthor 4 - if none, leave bl

2、ank lineProfessor NameSoftware Engineering Department MonmouthUniversity 2 / 11West Long Branch, NJ07764-1898T Ta ab bl le e o of f C Co on nt te en nt ts s1 1. . S SC CO OP PE E3 31 1. .1 1. . I ID DE EN NT TI IF FI IC CA AT TI IO ON N3 31 1. .2 2. . S SY YS ST TE EM M O OV VE ER RV VI IE EW W3 31

3、1. .3 3. . D DO OC CU UM ME EN NT T O OV VE ER RV VI IE EW W3 32 2. . R RE EF FE ER RE EN NC CE ED D D DO OC CU UM ME EN NT TS S3 33 3. . R RE EQ QU UI IR RE EM ME EN NT TS S S SU UM MM MA AR RY Y3 33 3. .1 1. . B BA AC CK KG GR RO OU UN ND D, , O OB BJ JE EC CT TI IV VE ES S, , A AN ND D S SC CO OP

4、 PE E4 43 3. .2 2. . O OP PE ER RA AT TI IO ON NA AL L P PO OL LI IC CI IE ES S A AN ND D C CO ON NS ST TR RA AI IN NT TS S4 43 3. .3 3. . D DE ES SC CR RI IP PT TI IO ON N O OF F C CU UR RR RE EN NT T S SY YS ST TE EM M O OR R S SI IT TU UA AT TI IO ON N5 53 3. .4 4. . U US SE ER RS S O OR R I IN N

5、V VO OL LV VE ED D P PE ER RS SO ON NN NE EL L5 53.4.1 CONFIGURATION REQUIREMENTS63 3. .5 5. . S SO OF FT TW WA AR RE E C CO ON NF FI IG GU UR RA AT TI IO ON N M MA AN NA AG GE EM ME EN NT T C CR RI IT TE ER RI IA A6 64 4. . J JU US ST TI IF FI IC CA AT TI IO ON N9 94 4. .1 1 A AS SS SU UM MP PT TI

6、IO ON NS S A AN ND D C CO ON NS ST TR RA AI IN NT TS S9 94 4. .2 2 A AD DD DI IT TI IO ON NA AL L I IT TE EM MS S F FO OR R C CO ON NS SI ID DE ER RA AT TI IO ON N: :9 95 5. . N NO OT TE ES S1 10 0 3 / 111 1 S Sc co op pe eThis section shall be divided into the following paragraphs.1 1. .1 1 I Id de

7、 en nt ti if fi ic ca at ti io on nThis 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 1. .2 2 S Sy ys st te em m O

8、Ov ve er rv vi ie ew wThis 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,

9、acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.1 1. .3 3 D Do oc cu um me en nt t O Ov ve er rv vi ie ew wThis paragraph shall summarize the purpose and contents of this document and shall describe any security or priv

10、acy considerations associated with its use.2 2 R Re ef fe er re en nc ce ed d D Do oc cu um me en nt ts sThis 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. 4 / 113 3 R Re eq q

11、u ui ir re em me en nt ts s S Su um mm ma ar ry yThis section shall be divided into the following paragraphs to describe the risk management requirements as it currently exists.3 3. .1 1 B Ba ac ck kg gr ro ou un nd d, , O Ob bj je ec ct ti iv ve es s, , a an nd d S Sc co op pe eThis paragraph shall

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

13、ch, described in the projects SDP, is to address all applicable contract clauses for SCM including:Configuration identificationConfiguration controlConfiguration status accountingConfiguration auditsPackaging, storage, handling, and delivery3 3. .2 2 O Op pe er ra at ti io on na al l P Po ol li ic c

14、i ie es s a an nd d C Co on ns st tr ra ai in nt ts sThis paragraph shall describe any operational policies and constraints that apply to the current system or situation. 5 / 11Example: SCM activities apply to all software products prepared, modified, and/or used to develop software products as well

15、 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. .3 3 D De es sc

16、 cr ri ip pt ti io on n o of f C Cu ur rr re en nt t S Sy ys st te em m o or r S Si it tu ua at ti io on nThis 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,

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

18、tes or modes, this paragraph shall so state, without the need to create artificial distinctions. 3 3. .4 4 U Us se er rs s o or r I In nv vo ol lv ve ed d P Pe er rs so on nn ne el lThis paragraph shall describe the types of users of the system, or personnel involved in the current situation, includ

19、ing, as applicable, organizational structures, training/skills, responsibilities, activities, and interactions with one another.Example: Developers key activities related to Software configuration management: 6 / 11Describe the approach to be followed for software configuration management, identifyi

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

21、 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/rele

22、ase 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 request

23、s, 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 be

24、en 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

25、 reports.Support acquirer-conducted configuration audits as specified in the contract. 7 / 11Establish 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.Prep

26、are a version description for the system.Meet general requirements and perform integral processes of the standard.3 3. .4 4. .1 1 C Co on nf fi ig gu ur ra at ti io on n R Re eq qu ui ir re em me en nt ts sThis paragraph describes the configuration management requirements for the project.Example: SC

27、M 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 arrang

28、ement suitable for the project.3 3. .5 5 S So of ft tw wa ar re e C Co on nf fi ig gu ur ra at ti io on n M Ma an na ag ge em me en nt t C Cr ri it te er ri ia aThis paragraph describes the software configuration management criteria to be followed during the project. Example: The standard requires t

29、he 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: 8 / 11Engineering data - notes, records, work-in-progress (i.e., data specified in documents associated with parti

30、cular 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 purpose software - operating systems, database m

31、anagement systems, , word processors, spreadsheetsEngineering and development tools - CASE tools, editors, compilers, debuggers, SCM tools, test softwareComputer system administrative tools and products - diagnostic software, network managers, archives, backupsEvaluation records 9 / 11Acquirer contr

32、ol: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 associated products match a specific set of

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

34、rough 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 a

35、uthorized 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

36、. 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. 10 / 11All

37、 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

38、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

39、 of information that will be contained in each record and who is responsible for performing these activities.4 4 J Ju us st ti if fi ic ca at ti io on nThis section shall be divided into the following paragraphs.4 4. .1 1 A As ss su um mp pt ti io on ns s a an nd d C Co on ns st tr ra ai in nt ts sThis paragraph shall identify any assumptions and constraints applicable to the changes identified in this section.4 4. .2 2 A Ad dd di it ti io on na al l I It te em ms s f fo or r c co on ns si id de er ra at ti io on n: :This paragraph shall identify additional items that sho