某公司SCM供应链管理

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 DepartmentMonmouth UniversityWest Long Branch, NJ 0776

2、4-1898Table of Contents1. SCOPE41.1.IDENTIFICATION41.2.SYSTEM OVERVIEW41.3.D OCUMENT OVERVIEW42. REFERENCED DOCUMENTS53. REQUIREMENTS SUMMARY53.1.B ACKGROUND, OBJECTIVES, AND SCOPE53.2.OPERATIONALPOLICIES ANDC ONSTRAINTS63.3.D ESCRIPTION OFCURRENTSYSTEM OR SITUATION63.4.U SERS OR INVOLVED PERSONNEL7

3、3.4.1CONFIGURATIONREQUIREMENTS83.5.SOFTWARE C ONFIGURATIONM ANAGEMENT CRITERIA94. JUSTIFICATION124.1ASSUMPTIONS AND CONSTRAINTS124.2ADDITIONAL I TEMS FOR CONSIDERATION:125. NOTES131 ScopeThis section shall be divided into the following paragraphs.1.1 IdentificationThis paragraph shall contain a full

4、 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 software to w

5、hich 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

6、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 document

7、s 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 paragraph

8、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 integralprocesses that support the other activities in the standard. The developer'

9、;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 ConstraintsThisp

10、aragraphshalldescribeanyoperationalpoliciesandconstraintsthat 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 underdevelopment,modification,reengineering,orreuse.Ifa

11、system/subsystemorSWIis developed inmultiplebuilds,SCMin eachbuildis tobe understoodtotake place in the contextofthesoftwareproducts and controls in place at the start of the build.3.3 Description of Current System or SituationThisparagraphshallprovideadescriptionof thecurrentsystemorsituation, iden

12、tifying differences associated with different states or modesof operation(for example,regular,maintenance,training,degraded,emergency, alternative-site, wartime, peacetime). The distinction betweenstates and modes is arbitrary.A systemmaybedescribedintermsofstates only, modes only, states within mod

13、es, modes within states, or anyother scheme that is useful.Ifthesystem operateswithoutstatesormodes, this paragraph shall so state, without the need to create artificialdistinctions. 3.4 Users or Involved PersonnelThis paragraph shall describe the types of users of the system, or personnel involved

14、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:Describetheapproachtobefollowedforsoftwareconfigurationm

15、anagement, identifying risks/uncertainties and plans for dealing with them. Cover all contractual clauses pertaining to software configuration management.ParticipateinselectingCSCIsduringsystem(architectural)design.Identify entities to be placed under configuration control. Assign a project-unique i

16、dentifierto eachSWIandeachadditionalentitytobe placedunder configuration control,includingsoftware products tobedevelopedor used and the elements of the software development environment. Usean identification scheme that identifies entities at the level of control andinclude version/revision/release

17、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 tobe followed to request authorization for changes, process change requests,tra

18、ck changes, distribute changes, and maintain past versions. Propose totheacquirer,inaccordancewithcontractuallyestablishedformsandprocedures, changes that affect an entity already under acquirer control.Prepare andmaintainrecordsofconfigurationstatus of allentitiesthathavebeenplaced under project-le

19、velor higherconfigurationcontrol.Maintain configuration status records for the life of the contract. Include,as applicable, version/revision/release, changes since being placed underproject-levelorhigherconfigurationcontrol,andstatusofassociatedproblem/change reports.Supportacquirer-conductedconfigu

20、rationauditsasspecifiedinthecontract.Establish and implement procedures for packaging, storage, handling, anddelivery 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 req

21、uirements and perform integral processes of the standard.3.4.1 Configuration RequirementsThis paragraph describes the configuration management requirements for the project.Example:SCMrequirementstaskthedeveloperto"keeptrackof"everything during the course of the development. SCM is an activ

22、ity, notan organization. SCM may be performed by members of the developmentteam,individualswithinaprojecttaskedwiththatresponsibility,aseparate organization, or other arrangement suitable for the project.3.5 Software Configuration Management CriteriaThis paragraph describes the software configuratio

23、n management criteria to be followed during the project.Example: The standard requires the developer to establish levels of control for allwork products. Some examples of possible levels of control and of things the developer might identify and control are:Author control:Engineeringdata-notes,record

24、s,work-in-progress(i.e.,dataspecifiedindocumentsassociatedwithparticulardevelopmentactivities)Software development filesProject control:Source code files, data files, installation softwareInformationindocumentsagreeduponbytheprojecttobecorrectReuse librariesEvaluation recordsOrganizational control:G

25、eneral purpose 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 manag

26、ers, archives, backupsEvaluation recordsAcquirer control:SpecificationsSome keygoalsof SCMrequirementsare to ensurethatthedeveloper:keeps trackof all softwareandsoftwareproductdescriptionsassociatedwith the project; implements only authorized changes to requirements; and knows what software and asso

27、ciated products match a specific set of requirements or changes to those requirements.To implement changes to requirements, the acquirer and developer mustagree uponwhatthose changesare.Whenrequirementshavebeendefined and recorded as specifications and those specifications have beenplacedoncontract,

28、changesareimplementedthroughcontractmodifications.Whenspecificationshavenotbeenmadea partofthecontract,the acquireranddeveloperwillneedtoprovideameansforcontrolling and making changes to requirements. These means can be asinformal as a phone call or hand-shake, or as formal as documents signedby aut

29、horized acquirer and developer representatives. The standarddoesnotprovidecontractualformsornoticesconcerningchangesinrequirements, such as Engineering Change Proposals (ECPs), EngineeringChange Notices (ECNs), or notification to users of changes in a particularversion of the software. Although the

30、standard does provide a reminder intheformoftwo"shell"requirementstosupportacquirerconfigurationmanagementactivitiesfor(1) proposingchangestoacquirercontrolledentities, and (2) supporting configurationaudits,theseactivitiesmaynotapply to all projects.All work products (including computeriz

31、ed files, the software products thatconstitutethedevelopmentenvironment,andhardware),notjustdeliverables,aretobeidentified andcontrolledduringthedevelopmentand under developer software configuration management activity. The physically controlled items can include: computer files, magnetic media (tap

32、es, 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 contained in each record

33、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 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 product evaluati