Software Engineering Body of Knowledge (v3) (2014) (811503), страница 30
Текст из файла (страница 30)
Breakdown of Topics for the Software Configuration Management KAThe SCM activities are management and planning of the SCM process, software configurationidentification, software configuration control,software configuration status accounting, software configuration auditing, and software releasemanagement and delivery.The Software Configuration Management KAis related to all the other KAs, since the objectof configuration management is the artifact produced and used throughout the software engineering process.BREAKDOWN OF TOPICS FORSOFTWARE CONFIGURATIONMANAGEMENTThe breakdown of topics for the Software Configuration Management KA is shown in Figure 6.1.1. Management of the SCM ProcessSCM controls the evolution and integrity of aproduct by identifying its elements; managing andcontrolling change; and verifying, recording, andreporting on configuration information. From thesoftware engineer’s perspective, SCM facilitatesdevelopment and change implementation activities.
A successful SCM implementation requirescareful planning and management. This, in turn,requires an understanding of the organizationalcontext for, and the constraints placed on, thedesign and implementation of the SCM process.1.1. Organizational Context for SCM[2*, c6, ann. D] [3*, introduction] [4*, c29]To plan an SCM process for a project, it is necessary to understand the organizational context andthe relationships among organizational elements.SCM interacts with several other activities ororganizational elements.The organizational elements responsible for thesoftware engineering supporting processes may bestructured in various ways. Although the responsibility for performing certain SCM tasks might beassigned to other parts of the organization (such asthe development organization), the overall responsibility for SCM often rests with a distinct organizational element or designated individual.Software is frequently developed as part of alarger system containing hardware and firmwareelements.
In this case, SCM activities take placeSoftware Configuration Management 6-3in parallel with hardware and firmware CM activities and must be consistent with system-levelCM. Note that firmware contains hardware andsoftware; therefore, both hardware and softwareCM concepts are applicable.SCM might interface with an organization’squality assurance activity on issues such asrecords management and nonconforming items.Regarding the former, some items under SCMcontrol might also be project records subject toprovisions of the organization’s quality assuranceprogram.
Managing nonconforming items is usually the responsibility of the quality assuranceactivity; however, SCM might assist with tracking and reporting on software configuration itemsfalling into this category.Perhaps the closest relationship is with thesoftware development and maintenance organizations.
It is within this context that many ofthe software configuration control tasks are conducted. Frequently, the same tools support development, maintenance, and SCM purposes.1.2. Constraints and Guidance for the SCMProcess[2*, c6, ann. D, ann.
E] [3*, c2, c5][5*, c19s2.2]Constraints affecting, and guidance for, the SCMprocess come from a number of sources. Policies and procedures set forth at corporate or otherorganizational levels might influence or prescribethe design and implementation of the SCM process for a given project. In addition, the contractbetween the acquirer and the supplier might contain provisions affecting the SCM process. Forexample, certain configuration audits might berequired, or it might be specified that certain itemsbe placed under CM. When software products tobe developed have the potential to affect publicsafety, external regulatory bodies may imposeconstraints.
Finally, the particular software lifecycle process chosen for a software project andthe level of formalism selected to implement thesoftware affect the design and implementation ofthe SCM process.Guidance for designing and implementing anSCM process can also be obtained from “bestpractice,” as reflected in the standards on softwareengineering issued by the various standards organizations (see Appendix B on standards).1.3. Planning for SCM[2*, c6, ann. D, ann. E] [3*, c23] [4*, c29]The planning of an SCM process for a givenproject should be consistent with the organizational context, applicable constraints, commonly accepted guidance, and the nature of theproject (for example, size, safety criticality, andsecurity).
The major activities covered are software configuration identification, software configuration control, software configuration statusaccounting, software configuration auditing, andsoftware release management and delivery. Inaddition, issues such as organization and responsibilities, resources and schedules, tool selectionand implementation, vendor and subcontractorcontrol, and interface control are typically considered. The results of the planning activity arerecorded in an SCM Plan (SCMP), which is typically subject to SQA review and audit.Branching and merging strategies should becarefully planned and communicated, since theyimpact many SCM activities.
From an SCM standpoint, a branch is defined as a set of evolving sourcefile versions [1]. Merging consists in combiningdifferent changes to the same file [1]. This typically occurs when more than one person changes aconfiguration item. There are many branching andmerging strategies in common use (see the FurtherReadings section for additional discussion).The software development life cycle model(see Software Life Cycle Models in the SoftwareEngineering Process KA) also impacts SCMactivities, and SCM planning should take thisinto account.
For instance, continuous integrationis a common practice in many software development approaches. It is typically characterized byfrequent build-test-deploy cycles. SCM activitiesmust be planned accordingly.1.3.1. SCM Organization and Responsibilities[2*, ann. Ds5, ann. Ds6] [3*, c10-11][4*, introduction, c29]To prevent confusion about who will performgiven SCM activities or tasks, organizational6-4 SWEBOK® Guide V3.0roles to be involved in the SCM process needto be clearly identified. Specific responsibilitiesfor given SCM activities or tasks also need to beassigned to organizational entities, either by titleor by organizational element. The overall authority and reporting channels for SCM should also beidentified, although this might be accomplishedat the project management or quality assuranceplanning stage.1.3.2. SCM Resources and Schedules[2*, ann.
Ds8] [3*, c23]Planning for SCM identifies the staff and toolsinvolved in carrying out SCM activities and tasks.It addresses scheduling questions by establishingnecessary sequences of SCM tasks and identifying their relationships to the project schedulesand milestones established at the project management planning stage.
Any training requirementsnecessary for implementing the plans and training new staff members are also specified.1.3.3. Tool Selection and Implementation[3*, c26s2, c26s6] [4*, c29s5]As for any area of software engineering, theselection and implementation of SCM toolsshould be carefully planned.
The following questions should be considered:• Organization: what motivates tool acquisition from an organizational perspective?• Tools: can we use commercial tools ordevelop them ourselves?• Environment: what are the constraintsimposed by the organization and its technical context?• Legacy: how will projects use (or not) thenew tools?• Financing: who will pay for the tools’acquisition, maintenance, training, andcustomization?• Scope: how will the new tools be deployed—for instance, through the entire organizationor only on specific projects?• Ownership: who is responsible for the introduction of new tools?• Future: what is the plan for the tools’ use inthe future?• Change: how adaptable are the tools?• Branching and merging: are the tools’ capabilities compatible with the planned branching and merging strategies?• Integration: do the various SCM tools integrate among themselves? With other tools inuse in the organization?• Migration: can the repository maintained bythe version control tool be ported to anotherversion control tool while maintaining complete history of the configuration items itcontains?SCM typically requires a set of tools, asopposed to a single tool.
Such tool sets are sometimes referred to as workbenches. In such a context, another important consideration in planning for tool selection is determining if the SCMworkbench will be open (in other words, toolsfrom different suppliers will be used in different activities of the SCM process) or integrated(where elements of the workbench are designedto work together).The size of the organization and the type ofprojects involved may also impact tool selection(see topic 7, Software Configuration Management Tools).1.3.4. Vendor/Subcontractor Control[2*, c13] [3*, c13s9, c14s2]A software project might acquire or make use ofpurchased software products, such as compilersor other tools.
SCM planning considers if andhow these items will be taken under configuration control (for example, integrated into the project libraries) and how changes or updates will beevaluated and managed.Similar considerations apply to subcontractedsoftware. When using subcontracted software,both the SCM requirements to be imposed onthe subcontractor’s SCM process as part of thesubcontract and the means for monitoring compliance need to be established.
The latter includesconsideration of what SCM information must beavailable for effective compliance monitoring.Software Configuration Management 6-51.3.5. Interface Control[2*, c12] [3*, c24s4]When a software item will interface withanother software or hardware item, a changeto either item can affect the other. Planning forthe SCM process considers how the interfacingitems will be identified and how changes to theitems will be managed and communicated. TheSCM role may be part of a larger, system-levelprocess for interface specification and control;it may involve interface specifications, interfacecontrol plans, and interface control documents.In this case, SCM planning for interface controltakes place within the context of the systemlevel process.1.4. SCM Plan[2*, ann. D] [3*, c23] [4*, c29s1]The results of SCM planning for a given projectare recorded in a software configuration management plan (SCMP), a “living document” whichserves as a reference for the SCM process.
It ismaintained (that is, updated and approved) asnecessary during the software life cycle. In implementing the SCMP, it is typically necessary todevelop a number of more detailed, subordinateprocedures defining how specific requirementswill be carried out during day-to-day activities—for example, which branching strategies will beused and how frequently builds occur and automated tests of all kinds are run.Guidance on the creation and maintenance ofan SCMP, based on the information produced bythe planning activity, is available from a numberof sources, such as [2*]. This reference providesrequirements for the information to be containedin an SCMP; it also defines and describes six categories of SCM information to be included in anSCMP:• Introduction (purpose, scope, terms used)• SCM Management (organization, responsibilities, authorities, applicable policies,directives, and procedures)• SCM Activities (configuration identification,configuration control, and so on)• SCM Schedules (coordination with otherproject activities)• SCM Resources (tools, physical resources,and human resources)• SCMP Maintenance.1.5. Surveillance of Software ConfigurationManagement[3*, c11s3]After the SCM process has been implemented,some degree of surveillance may be necessaryto ensure that the provisions of the SCMP areproperly carried out.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
