Software Engineering Body of Knowledge (v3) (2014) (811503), страница 31
Текст из файла (страница 31)
There are likely to be specific SQA requirements for ensuring compliancewith specified SCM processes and procedures.The person responsible for SCM ensures thatthose with the assigned responsibility performthe defined SCM tasks correctly. The softwarequality assurance authority, as part of a compliance auditing activity, might also perform thissurveillance.The use of integrated SCM tools with processcontrol capability can make the surveillancetask easier. Some tools facilitate process compliance while providing flexibility for the software engineer to adapt procedures.
Other toolsenforce process, leaving the software engineerwith less flexibility. Surveillance requirementsand the level of flexibility to be provided to thesoftware engineer are important considerationsin tool selection.1.5.1. SCM Measures and Measurement[3*, c9s2, c25s2–s3]SCM measures can be designed to provide specific information on the evolving product or toprovide insight into the functioning of the SCMprocess. A related goal of monitoring the SCMprocess is to discover opportunities for processimprovement. Measurements of SCM processesprovide a good means for monitoring the effectiveness of SCM activities on an ongoing basis.These measurements are useful in characterizing the current state of the process as well as inproviding a basis for making comparisons overtime.
Analysis of the measurements may produce6-6 SWEBOK® Guide V3.0insights leading to process changes and corresponding updates to the SCMP.Software libraries and the various SCM toolcapabilities provide sources for extracting information about the characteristics of the SCMprocess (as well as providing project and management information).
For example, informationabout the time required to accomplish varioustypes of changes would be useful in an evaluation of the criteria for determining what levels ofauthority are optimal for authorizing certain typesof changes and for estimating future changes.Care must be taken to keep the focus of thesurveillance on the insights that can be gainedfrom the measurements, not on the measurementsthemselves. Discussion of software process andproduct measurement is presented in the Software Engineering Process KA.
Software measurement programs are described in the SoftwareEngineering Management KA.1.5.2. In-Process Audits of SCM[3*, c1s1]Audits can be carried out during the softwareengineering process to investigate the current status of specific elements of the configuration or toassess the implementation of the SCM process.In-process auditing of SCM provides a more formal mechanism for monitoring selected aspectsof the process and may be coordinated with theSQA function (see topic 5, Software Configuration Auditing).2. Software Configuration Identification[2*, c8] [4*, c29s1.1]Software configuration identification identifiesitems to be controlled, establishes identificationschemes for the items and their versions, andestablishes the tools and techniques to be used inacquiring and managing controlled items.
Theseactivities provide the basis for the other SCMactivities.2.1. Identifying Items to Be Controlled[2*, c8s2.2] [4*, c29s1.1]One of the first steps in controlling change isidentifying the software items to be controlled.This involves understanding the software configuration within the context of the system configuration, selecting software configuration items,developing a strategy for labeling software itemsand describing their relationships, and identifyingboth the baselines to be used and the procedurefor a baseline’s acquisition of the items.2.1.1. Software Configuration[1, c3]Software configuration is the functional and physical characteristics of hardware or software as setforth in technical documentation or achieved ina product.
It can be viewed as part of an overallsystem configuration.2.1.2. Software Configuration Item[4*, c29s1.1]A configuration item (CI) is an item or aggregation of hardware or software or both that isdesigned to be managed as a single entity. A software configuration item (SCI) is a software entitythat has been established as a configuration item[1]. The SCM typically controls a variety of itemsin addition to the code itself. Software items withpotential to become SCIs include plans, specifications and design documentation, testing materials, software tools, source and executable code,code libraries, data and data dictionaries, anddocumentation for installation, maintenance,operations, and software use.Selecting SCIs is an important process inwhich a balance must be achieved between providing adequate visibility for project control purposes and providing a manageable number ofcontrolled items.2.1.3. Software Configuration ItemRelationships[3*, c7s4]Structural relationships among the selectedSCIs, and their constituent parts, affect otherSCM activities or tasks, such as softwarebuilding or analyzing the impact of proposedchanges.
Proper tracking of these relationshipsis also important for supporting traceability.The design of the identification scheme for SCIsSoftware Configuration Management 6-7Figure 6.2. Acquisition of Itemsshould consider the need to map identified itemsto the software structure, as well as the need tosupport the evolution of the software items andtheir relationships.2.1.4. Software Version[1, c3] [4*, c29s3]Software items evolve as a software project proceeds. A version of a software item is an identified instance of an item. It can be thought of as astate of an evolving item.
A variant is a version ofa program resulting from the application of software diversity.2.1.5. Baseline[1, c3]A software baseline is a formally approved version of a configuration item (regardless of media)that is formally designated and fixed at a specifictime during the configuration item’s life cycle.The term is also used to refer to a particular version of a software configuration item that hasbeen agreed on. In either case, the baseline canonly be changed through formal change control procedures. A baseline, together with allapproved changes to the baseline, represents thecurrent approved configuration.Commonly used baselines include functional, allocated, developmental, and productbaselines.
The functional baseline correspondsto the reviewed system requirements. The allocated baseline corresponds to the reviewedsoftware requirements specification and software interface requirements specification. Thedevelopmental baseline represents the evolvingsoftware configuration at selected times duringthe software life cycle. Change authority forthis baseline typically rests primarily with thedevelopment organization but may be sharedwith other organizations (for example, SCM orTest). The product baseline corresponds to thecompleted software product delivered for system integration.
The baselines to be used for agiven project, along with the associated levels ofauthority needed for change approval, are typically identified in the SCMP.2.1.6. Acquiring Software Configuration Items[3*, c18]Software configuration items are placed underSCM control at different times; that is, they areincorporated into a particular baseline at a particular point in the software life cycle. The triggeringevent is the completion of some form of formalacceptance task, such as a formal review.
Figure6.2 characterizes the growth of baselined items asthe life cycle proceeds. This figure is based on thewaterfall model for purposes of illustration only;the subscripts used in the figure indicate versions6-8 SWEBOK® Guide V3.0of the evolving items. The software change request(SCR) is described in section 3.1.In acquiring an SCI, its origin and initial integrity must be established. Following the acquisition of an SCI, changes to the item must be formally approved as appropriate for the SCI andthe baseline involved, as defined in the SCMP.Following approval, the item is incorporated intothe software baseline according to the appropriateprocedure.2.2. Software Library[3*, c1s3] [4*, c29s1.2]A software library is a controlled collection ofsoftware and related documentation designed toaid in software development, use, or maintenance[1].
It is also instrumental in software release management and delivery activities. Several types oflibraries might be used, each corresponding to thesoftware item’s particular level of maturity. Forexample, a working library could support codingand a project support library could support testing, while a master library could be used for finished products. An appropriate level of SCM control (associated baseline and level of authority forchange) is associated with each library. Security,in terms of access control and the backup facilities, is a key aspect of library management.The tool(s) used for each library must supportthe SCM control needs for that library—both interms of controlling SCIs and controlling accessto the library.
At the working library level, this isa code management capability serving developers, maintainers, and SCM. It is focused on managing the versions of software items while supporting the activities of multiple developers. Athigher levels of control, access is more restrictedand SCM is the primary user.These libraries are also an important sourceof information for measurements of work andprogress.3. Software Configuration Control[2*, c9] [4*, c29s2]Software configuration control is concernedwith managing changes during the softwarelife cycle. It covers the process for determiningwhat changes to make, the authority for approving certain changes, support for the implementation of those changes, and the concept of formaldeviations from project requirements as well aswaivers of them. Information derived from theseactivities is useful in measuring change trafficand breakage as well as aspects of rework.3.1. Requesting, Evaluating, and ApprovingSoftware Changes[2*, c9s2.4] [4*, c29s2]The first step in managing changes to controlleditems is determining what changes to make.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
