Software Engineering Body of Knowledge (v3) (2014) (811503), страница 32
Текст из файла (страница 32)
Thesoftware change request process (see a typicalflow of a change request process in Figure 6.3)provides formal procedures for submitting andrecording change requests, evaluating the potential cost and impact of a proposed change, andaccepting, modifying, deferring, or rejectingthe proposed change.
A change request (CR) isa request to expand or reduce the project scope;modify policies, processes, plans, or procedures;modify costs or budgets; or revise schedules[1]. Requests for changes to software configuration items may be originated by anyone at anypoint in the software life cycle and may includea suggested solution and requested priority. Onesource of a CR is the initiation of correctiveaction in response to problem reports.
Regardlessof the source, the type of change (for example,defect or enhancement) is usually recorded on theSoftware CR (SCR).This provides an opportunity for trackingdefects and collecting change activity measurements by change type. Once an SCR is received,a technical evaluation (also known as an impactanalysis) is performed to determine the extent ofthe modifications that would be necessary shouldthe change request be accepted. A good understanding of the relationships among software(and, possibly, hardware) items is important forthis task. Finally, an established authority—commensurate with the affected baseline, the SCIinvolved, and the nature of the change—willevaluate the technical and managerial aspectsof the change request and either accept, modify,reject, or defer the proposed change.Software Configuration Management 6-9Figure 6.3. Flow of a Change Control Process3.1.1. Software Configuration Control Board[2*, c9s2.2] [3*, c11s1] [4*, c29s2]The authority for accepting or rejecting proposedchanges rests with an entity typically known as aConfiguration Control Board (CCB).
In smallerprojects, this authority may actually reside withthe leader or an assigned individual rather than amultiperson board. There can be multiple levelsof change authority depending on a variety of criteria—such as the criticality of the item involved,the nature of the change (for example, impact onbudget and schedule), or the project’s currentpoint in the life cycle. The composition of theCCBs used for a given system varies dependingon these criteria (an SCM representative wouldalways be present). All stakeholders, appropriateto the level of the CCB, are represented. Whenthe scope of authority of a CCB is strictly software, it is known as a Software ConfigurationControl Board (SCCB). The activities of the CCBare typically subject to software quality audit orreview.3.1.2. Software Change Request Process[3*, c1s4, c8s4]An effective software change request (SCR) process requires the use of supporting tools and procedures for originating change requests, enforcing the flow of the change process, capturingCCB decisions, and reporting change processinformation.
A link between this tool capabilityand the problem-reporting system can facilitatethe tracking of solutions for reported problems.3.2. Implementing Software Changes[4*, c29]Approved SCRs are implemented using thedefined software procedures in accordance withthe applicable schedule requirements. Since anumber of approved SCRs might be implementedsimultaneously, it is necessary to provide a meansfor tracking which SCRs are incorporated intoparticular software versions and baselines. Aspart of the closure of the change process, completed changes may undergo configuration auditsand software quality verification—this includesensuring that only approved changes have beenmade.
The software change request processdescribed above will typically document theSCM (and other) approval information for thechange.Changes may be supported by source code version control tools. These tools allow a team ofsoftware engineers, or a single software engineer,to track and document changes to the source code.These tools provide a single repository for storingthe source code, can prevent more than one software engineer from editing the same module atthe same time, and record all changes made to the6-10 SWEBOK® Guide V3.0source code.
Software engineers check modulesout of the repository, make changes, documentthe changes, and then save the edited modulesin the repository. If needed, changes can also bediscarded, restoring a previous baseline. Morepowerful tools can support parallel developmentand geographically distributed environments.These tools may be manifested as separate,specialized applications under the control of anindependent SCM group. They may also appearas an integrated part of the software engineeringenvironment. Finally, they may be as elementaryas a rudimentary change control system providedwith an operating system.3.3. Deviations and Waivers[1, c3]The constraints imposed on a software engineering effort or the specifications produced during thedevelopment activities might contain provisionsthat cannot be satisfied at the designated pointin the life cycle.
A deviation is a written authorization, granted prior to the manufacture of anitem, to depart from a particular performance ordesign requirement for a specific number of unitsor a specific period of time. A waiver is a written authorization to accept a configuration item orother designated item that is found, during production or after having been submitted for inspection,to depart from specified requirements but is nevertheless considered suitable for use as-is or afterrework by an approved method. In these cases, aformal process is used for gaining approval fordeviations from, or waivers of, the provisions.4. Software Configuration Status Accounting[2*, c10]Software configuration status accounting (SCSA)is an element of configuration management consisting of the recording and reporting of information needed to manage a configuration effectively.4.1. Software Configuration Status Information[2*, c10s2.1]The SCSA activity designs and operates a system for the capture and reporting of necessaryinformation as the life cycle proceeds.
As in anyinformation system, the configuration status information to be managed for the evolving configurations must be identified, collected, and maintained.Various information and measurements are neededto support the SCM process and to meet the configuration status reporting needs of management,software engineering, and other related activities.The types of information available include theapproved configuration identification as well asthe identification and current implementation status of changes, deviations, and waivers.Some form of automated tool support is necessary to accomplish the SCSA data collection andreporting tasks; this could be a database capability, a stand-alone tool, or a capability of a larger,integrated tool environment.4.2. Software Configuration Status Reporting[2*, c10s2.4] [3*, c1s5, c9s1, c17]Reported information can be used by variousorganizational and project elements—includingthe development team, the maintenance team,project management, and software quality activities.
Reporting can take the form of ad hoc queries to answer specific questions or the periodicproduction of predesigned reports. Some information produced by the status accounting activityduring the course of the life cycle might becomequality assurance records.In addition to reporting the current status of theconfiguration, the information obtained by theSCSA can serve as a basis of various measurements. Examples include the number of changerequests per SCI and the average time needed toimplement a change request.5. Software Configuration Auditing[2*, c11]A software audit is an independent examination of a work product or set of work products toassess compliance with specifications, standards,contractual agreements, or other criteria [1].Audits are conducted according to a well-definedprocess consisting of various auditor roles andresponsibilities.
Consequently, each audit mustbe carefully planned. An audit can require a number of individuals to perform a variety of tasksover a fairly short period of time. Tools to supportSoftware Configuration Management 6-11the planning and conduct of an audit can greatlyfacilitate the process.Software configuration auditing determinesthe extent to which an item satisfies the requiredfunctional and physical characteristics. Informalaudits of this type can be conducted at key pointsin the life cycle. Two types of formal audits mightbe required by the governing contract (for example, in contracts covering critical software): theFunctional Configuration Audit (FCA) and thePhysical Configuration Audit (PCA).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
