Software Engineering Body of Knowledge (v3) (2014) (811503), страница 41
Текст из файла (страница 41)
Themodel can provide a norm for a benchmarkingSoftware Engineering Process 8-7comparison among projects within an organization and among organizations.A process audit differs from a process assessment. Assessments are performed to determinelevels of capability or maturity and to identifysoftware processes to be improved. Audits aretypically conducted to ascertain compliance withpolicies and standards.
Audits provide management visibility into the actual operations beingperformed in the organization so that accurateand meaningful decisions can be made concerning issues that are impacting a development project, a maintenance activity, or a software-relatedtopic.Success factors for software process assessment and improvement within software engineering organizations include management sponsorship, planning, training, experienced and capableleaders, team commitment, expectation management, the use of change agents, plus pilot projectsand experimentation with tools. Additional factors include independence of the assessor and thetimeliness of the assessment.3.1. Software Process Assessment Models[2*, s4.5, s4.6] [3*, s26.5] [4*, p44–48]Software process assessment models typicallyinclude assessment criteria for software processesthat are regarded as constituting good practices.These practices may address software development processes only, or they may also includetopics such as software maintenance, softwareproject management, systems engineering, orhuman resources management.3.2. Software Process Assessment Methods[1*, p322–331] [3*, s26.3][4*, p44–48, s16.4] [6]A software process assessment method can bequalitative or quantitative.
Qualitative assessments rely on the judgment of experts; quantitative assessments assign numerical scores tosoftware processes based on analysis of objectiveevidence that indicates attainment of the goalsand outcomes of a defined software process. Forexample, a quantitative assessment of the software inspection process might be performed byexamining the procedural steps followed andresults obtained plus data concerning defectsfound and time required to find and fix the defectsas compared to software testing.A typical method of software process assessment includes planning, fact-finding (by collecting evidence through questionnaires, interviews,and observation of work practices), collectionand validation of process data, and analysis andreporting. Process assessments may rely on thesubjective, qualitative judgment of the assessor,or on the objective presence or absence of definedartifacts, records, and other evidence.The activities performed during a software process assessment and the distribution of effort forassessment activities are different depending onthe purpose of the software process assessment.Software process assessments may be undertakento develop capability ratings used to make recommendations for process improvements or may beundertaken to obtain a process maturity rating inorder to qualify for a contract or award.The quality of assessment results depends onthe software process assessment method, theintegrity and quality of the obtained data, theassessment team’s capability and objectivity, andthe evidence examined during the assessment.The goal of a software process assessment is togain insight that will establish the current statusof a process or processes and provide a basis forprocess improvement; performing a softwareprocess assessment by following a checklist forconformance without gaining insight adds littlevalue.3.3. Software Process Improvement Models[2*, p187–188] [3*, s26.5] [4*, s2.7]Software process improvement models emphasize iterative cycles of continuous improvement.A software process improvement cycle typicallyinvolves the subprocesses of measuring, analyzing, and changing.
The Plan-Do-Check-Actmodel is a well-known iterative approach tosoftware process improvement. Improvementactivities include identifying and prioritizingdesired improvements (planning); introducingan improvement, including change managementand training (doing); evaluating the improvement8-8 SWEBOK® Guide V3.0as compared to previous or exemplary processresults and costs (checking); and making furthermodifications (acting). The Plan-Do-Check-Actprocess improvement model can be applied, forexample, to improve software processes thatenhance defect prevention.3.4. Continuous and Staged Software ProcessRatings[1*, p28–34] [3*, s26.5] [4*, p39–45]Software process capability and software processmaturity are typically rated using five or six levelsto characterize the capability or maturity of thesoftware processes used within an organization.A continuous rating system involves assigning a rating to each software process of interest;a staged rating system is established by assigning the same maturity rating to all of the softwareprocesses within a specified process level.
A representation of continuous and staged process levels is provided in Table 8.1. Continuous modelstypically use a level 0 rating; staged models typically do not.Table 8.1. Software Process Rating LevelsContinuousStagedRepresentationRepresentationLevelof Capabilityof MaturityLevelsLevels0Incomplete1PerformedInitial2ManagedManaged3DefinedDefinedQuantitatively4Managed5OptimizingIn Table 8.1, level 0 indicates that a softwareprocess is incompletely performed or may not beperformed. At level 1, a software process is beingperformed (capability rating), or the softwareprocesses in a maturity level 1 group are beingperformed but on an ad hoc, informal basis.
Atlevel 2, a software process (capability rating) orthe processes in maturity level 2 are being performed in a manner that provides managementvisibility into intermediate work products andcan exert some control over transitions betweenprocesses. At level 3, a single software process orthe processes in a maturity level 3 group plus theprocess or processes in maturity level 2 are welldefined (perhaps in organizational policies andprocedures) and are being repeated across different projects.
Level 3 of process capability ormaturity provides the basis for process improvement across an organization because the processis (or processes are) conducted in a similar manner. This allows collection of performance datain a uniform manner across multiple projects. Atmaturity level 4, quantitative measures can beapplied and used for process assessment; statistical analysis may be used.
At maturity level 5,the mechanisms for continuous process improvements are applied.Continuous and staged representations can beused to determine the order in which softwareprocesses are to be improved. In the continuousrepresentation, the different capability levels fordifferent software processes provide a guidelinefor determining the order in which software processes will be improved. In the staged representation, satisfying the goals of a set of software processes within a maturity level is accomplished forthat maturity level, which provides a foundationfor improving all of the software processes at thenext higher level.4. Software Measurement[3*, s26.2] [4*, s18.1.1]This topic addresses software process and product measurement, quality of measurement results,software information models, and software process measurement techniques (see Measurementin the Engineering Foundations KA).Before a new process is implemented or a current process is modified, measurement results forthe current situation should be obtained to provide a baseline for comparison between the current situation and the new situation.
For example, before introducing the software inspectionprocess, effort required to fix defects discoveredby testing should be measured. Following an initial start-up period after the inspection processis introduced, the combined effort of inspectionSoftware Engineering Process 8-9plus testing can be compared to the previousamount of effort required for testing alone. Similar considerations apply if a process is changed.4.1. Software Process and Product Measurement[1*, s6.3, p273] [3*, s26.2, p638]Software process and product measurement areconcerned with determining the efficiency andeffectiveness of a software process, activity, ortask. The efficiency of a software process, activity,or task is the ratio of resources actually consumedto resources expected or desired to be consumedin accomplishing a software process, activity, ortask (see Efficiency in the Software EngineeringEconomics KA).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
