Software Engineering Body of Knowledge (v3) (2014) (811503), страница 37
Текст из файла (страница 37)
The various methods, tools,and techniques employed should be evaluated fortheir effectiveness and appropriateness, and theprocess being used by the project should also besystematically and periodically assessed for relevance, utility, and efficacy in the project context.Where appropriate, changes should be made andmanaged.5. ClosureAn entire project, a major phase of a project,or an iterative development cycle reaches closure when all the plans and processes have beenenacted and completed. The criteria for project,phase, or iteration success should be evaluated.Once closure is established, archival, retrospective, and process improvement activities can beperformed.5.1. Determining Closure[1, s3.7, s4.6]Closure occurs when the specified tasks for aproject, a phase, or an iteration have been completed and satisfactory achievement of the completion criteria has been confirmed.
Softwarerequirements can be confirmed as satisfied or not,and the degree of achieving the objectives canbe determined. Closure processes should involverelevant stakeholders and result in documentationof relevant stakeholders’ acceptance; any knownproblems should be documented.5.2. Closure Activities[2, s3.7, s4.8]After closure has been confirmed, archiving ofproject materials should be accomplished inaccordance with stakeholder agreed-upon methods, location, and duration—possibly includingdestruction of sensitive information, software,and the medium on which copies are resident.The organization’s measurement database shouldbe updated with relevant project data.
A project,phase, or iteration retrospective analysis shouldbe undertaken so that issues, problems, risks,and opportunities encountered can be analyzed(see topic 4, Review and Evaluation). Lessonslearned should be drawn from the project and fedinto organizational learning and improvementendeavors.6. Software Engineering MeasurementThe importance of measurement and its role inbetter management and engineering practices iswidely acknowledged (see Measurement in theEngineering Foundations KA).
Effective measurement has become one of the cornerstonesof organizational maturity. Measurement can beapplied to organizations, projects, processes, andwork products. In this section the focus is on theapplication of measurement at the levels of projects, processes, and work products.This section follows the IEEE 15939:2008standard [6], which describes a process to definethe activities and tasks necessary to implement asoftware measurement process. The standard alsoincludes a measurement information model.6.1. Establish and Sustain MeasurementCommitment[7*, c1, c2]2• Requirements for measurement. Each measurement endeavor should be guided byorganizational objectives and driven by a setof measurement requirements established by2 Please note that these two chapters can bedownloaded free of charge from www.psmsc.com/PSMBook.asp.7-10 SWEBOK® Guide V3.0the organization and the project (for example, an organizational objective might be“first-to-market with new products”).• Scope of measurement.
The organizationalunit to which each measurement requirementis to be applied should be established. Thismay consist of a functional area, a singleproject, a single site, or an entire enterprise.The temporal scope of the measurementeffort should also be considered becausetime series of some measurements may berequired; for example, to calibrate estimation models (see section 2.3, Effort, Schedule, and Cost Estimation).• Team commitment to measurement.
Thecommitment should be formally established,communicated, and supported by resources(see next item).• Resources for measurement. An organization’s commitment to measurement is anessential factor for success, as evidenced bythe assignment of resources for implementing the measurement process. Assigningresources includes allocation of responsibility for the various tasks of the measurementprocess (such as analyst and librarian). Adequate funding, training, tools, and support toconduct the process should also be allocated.6.2. Plan the Measurement Process[7*, c1, c2]• Characterize the organizational unit. Theorganizational unit provides the context formeasurement, so the organizational contextshould be made explicit, including the constraints that the organization imposes onthe measurement process.
The characterization can be stated in terms of organizationalprocesses, application domains, technology,organizational interfaces, and organizationalstructure.• Identify information needs. Informationneeds are based on the goals, constraints,risks, and problems of the organizationalunit. They may be derived from business,organizational, regulatory, and/or productobjectives. They should be identified andprioritized. Then a subset of objectives to beaddressed can be selected, documented, communicated, and reviewed by stakeholders.• Select measures. Candidate measures shouldbe selected, with clear links to the information needs. Measures should be selectedbased on the priorities of the informationneeds and other criteria such as cost of collection, degree of process disruption duringcollection, ease of obtaining accurate, consistent data, and ease of analysis and reporting.
Because internal quality characteristics(see Models and Quality Characteristics inthe Software Quality KA) are often not contained in the contractually binding softwarerequirements, it is important to consider measuring the internal quality of the software toprovide an early indicator of potential issuesthat may impact external stakeholders.• Define data collection, analysis, and reporting procedures. This encompasses collectionprocedures and schedules, storage, verification, analysis, reporting, and configurationmanagement of data.• Select criteria for evaluating the informationproducts.
Criteria for evaluation are influenced by the technical and business objectives of the organizational unit. Informationproducts include those associated with theproduct being produced, as well as thoseassociated with the processes being used tomanage and measure the project.• Provide resources for measurement tasks.
Themeasurement plan should be reviewed andapproved by the appropriate stakeholders toinclude all data collection procedures; storage,analysis, and reporting procedures; evaluationcriteria; schedules; and responsibilities. Criteria for reviewing these artifacts should havebeen established at the organizational-unitlevel or higher and should be used as the basisfor these reviews.
Such criteria should takeinto consideration previous experience, availability of resources, and potential disruptionsto projects when changes from current practices are proposed. Approval demonstratescommitment to the measurement process.• Identify resources to be made available forimplementing the planned and approvedSoftware Engineering Management 7-11measurement tasks. Resource availabilitymay be staged in cases where changes areto be piloted before widespread deployment.Consideration should be paid to the resourcesnecessary for successful deployment of newprocedures or measures.• Acquire and deploy supporting technologies.This includes evaluation of available supportingtechnologies, selection of the most appropriatetechnologies, acquisition of those technologies,and deployment of those technologies.6.3. Perform the Measurement Process[7*, c1, c2]• Integrate measurement procedures with relevant software processes.
The measurementprocedures, such as data collection, shouldbe integrated into the software processesthey are measuring. This may involve changing current software processes to accommodate data collection or generation activities.It may also involve analysis of current software processes to minimize additional effortand evaluation of the effect on employees toensure that the measurement procedures willbe accepted. Morale issues and other humanfactors should be considered. In addition, themeasurement procedures should be communicated to those providing the data. Trainingand support may also need to be provided.Data analysis and reporting procedures aretypically integrated into organizational and/or project processes in a similar manner.• Collect data. Data should be collected, verified, and stored. Collection can sometimesbe automated by using software engineering management tools (see topic 7, Software Engineering Management Tools) toanalyze data and develop reports.
Data maybe aggregated, transformed, or recoded aspart of the analysis process, using a degreeof rigor appropriate to the nature of the dataand the information needs. The results ofthis analysis are typically indicators such asgraphs, numbers, or other indications thatwill be interpreted, resulting in conclusionsand recommendations to be presented tostakeholders (see Statistical Analysis in theEngineering Foundations KA). The resultsand conclusions are usually reviewed, usinga process defined by the organization (whichmay be formal or informal).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
