Software Engineering Body of Knowledge (v3) (2014) (811503), страница 43
Текст из файла (страница 43)
Process measurement techniques can be used to collect bothquantitative and qualitative data.4.4.1. Quantitative Process MeasurementTechniques[4*, s5.1, s5.7, s9.8]The purpose of quantitative process measurementtechniques is to collect, transform, and analyzequantitative process and work product data thatcan be used to indicate where process improvements are needed and to assess the results ofprocess improvement initiatives. Quantitativeprocess measurement techniques are used to collect and analyze data in numerical form to whichmathematical and statistical techniques can beapplied.Quantitative process data can be collected asa byproduct of software processes. For example,the number of defects discovered during softwaretesting and the staff-hours expended can be collected by direct measurement, and the productivity of defect discovery can be derived by calculating defects discovered per staff-hour.Basic tools for quality control can be used toanalyze quantitative process measurement data(e.g., check sheets, Pareto diagrams, histograms,scatter diagrams, run charts, control charts, andcause-and-effect diagrams) (see Root CauseAnalysis in the Engineering Foundations KA).
Inaddition, various statistical techniques can be usedthat range from calculation of medians and meansto multivariate analysis methods (see StatisticalAnalysis in the Engineering Foundations KA).Data collected using quantitative process measurement techniques can also be used as inputsto simulation models (see Modeling, Prototyping, and Simulation in the Engineering Foundations KA); these models can be used to assess theimpact of various approaches to software processimprovement.Orthogonal Defect Classification (ODC) canbe used to analyze quantitative process measurement data. ODC can be used to group detecteddefects into categories and link the defects in8-12 SWEBOK® Guide V3.0each category to the software process or software processes where a group of defects originated (see Defect Characterization in the Software Quality KA).
Software interface defects,for example, may have originated during an inadequate software design process; improving thesoftware design process will reduce the numberof software interface defects. ODC can providequantitative data for applying root cause analysis.Statistical Process Control can be used to trackprocess stability, or the lack of process stability,using control charts.4.4.2. Qualitative Process MeasurementTechniques[1*, s6.4]Qualitative process measurement techniques—including interviews, questionnaires, and expertjudgment—can be used to augment quantitativeprocess measurement techniques.
Group consensus techniques, including the Delphi technique,can be used to obtain consensus among groups ofstakeholders.5. Software Engineering Process Tools[1*, s8.7]Software process tools support many of the notations used to define, implement, and manageindividual software processes and software lifecycle models. They include editors for notationssuch as data-flow diagrams, state charts, BPMN,IDEF0 diagrams, Petri nets, and UML activitydiagrams. In some cases, software process toolsallow different types of analyses and simulations (for example, discrete event simulation).
Inaddition, general purpose business tools, such asa spreadsheet, may be useful.Computer-Assisted Software Engineering(CASE) tools can reinforce the use of integratedprocesses, support the execution of process definitions, and provide guidance to humans in performing well-defined processes. Simple toolssuch as word processors and spreadsheets canbe used to prepare textual descriptions of processes, activities, and tasks; these tools also support traceability among the inputs and outputs ofmultiple software processes (such as stakeholderneeds analysis, software requirements specification, software architecture, and software detaileddesign) as well as the results of software processes such as documentation, software components, test cases, and problem reports.Most of the knowledge areas in this Guidedescribe specialized tools that can be used tomanage the processes within that KA. In particular, see the Software Configuration ManagementKA for a discussion of software configurationmanagement tools that can be used to manage theconstruction, integration, and release processesfor software products.
Other tools, such as thosefor requirements management and testing, aredescribed in the appropriate KAs.Software process tools can support projectsthat involve geographically dispersed (virtual)teams. Increasingly, software process tools areavailable through cloud computing facilities aswell as through dedicated infrastructures.A project control panel or dashboard can display selected process and product attributes forsoftware projects and indicate measurements thatare within control limits and those needing corrective action.Software Engineering Process 8-13p2951.1. Software Process Managementp183, p1861.2. Software Process Infrastructure2. Software Life Cycles2.1. Categories of Software Processes2.2. Software Life Cycle Models2.3. Software Process Adaptationc2p190prefacep294–295c2s2.7s3.2p512.4. Practical Considerations3.1. Software Process Assessment Modelsp437–438c22, c23,c24s2.1p188, p194c26p397, c15s4.5,s4.6s26.5p44–48s26.3p44–48,s16.4s26.5s2.7s26.5p39–45s26.2s18.1.1p322–331p187–188p28–344. Software Measurement4.1. Software Process and ProductMeasurements6.3,p273s26.2,p6384.2. Quality of Measurement Results4.3. Software Information Modelsp453–454p188–1903. Software Process Assessment andImprovement3.2. Software Process AssessmentMethods3.3. Software Process ImprovementModels3.4. Continuous and Staged Ratingsp28–29,p36,c5s26.1Kan 2003[4*]p177Sommerville 2011[3*]Moore 2009[2*]1. Software Process DefinitionFairley 2009[1*]MATRIX OF TOPICS VS.
REFERENCE MATERIALp310–3114.4. Software Process MeasurementTechniquess6.4,c85. Software Engineering Process Toolss8.7p. 712–713s3.4,s3.5,s3.6,s3.7s19.2s5.1,s5.7,s9.88-14 SWEBOK® Guide V3.0FURTHER READINGSREFERENCESSoftware Extension to the Guide to the ProjectManagement Body of Knowledge® (SWX)[5].[1*] R.E.
Fairley, Managing and LeadingSoftware Projects, Wiley-IEEE ComputerSociety Press, 2009.SWX provides adaptations and extensions to thegeneric practices of project management documented in the PMBOK® Guide for managingsoftware projects. The primary contribution ofthis extension to the PMBOK® Guide is description of processes that are applicable for managingadaptive life cycle software projects.[2*] J.W. Moore, The Road Map to SoftwareEngineering: A Standards-Based Guide,Wiley-IEEE Computer Society Press, 2006.D. Gibson, D.
Goldenson, and K. Kost,“Performance Results of CMMI-BasedProcess Improvement” [6].This technical report summarizes publicly available empirical evidence about the performanceresults that can occur as a consequence of CMMIbased process improvement. The report containsa series of brief case descriptions that were created with collaboration from representativesfrom 10 organizations that have achieved notablequantitative performance results through theirCMMI-based improvement efforts.CMMI® for Development, Version 1.3 [7].CMMI® for Development, Version 1.3 provides anintegrated set of process guidelines for developing and improving products and services. Theseguidelines include best practices for developingand improving products and services to meet theneeds of customers and end users.ISO/IEC 15504-1:2004 Information technology—Process assessment—Part 1:Concepts and vocabulary [8].This standard, commonly known as SPICE(Software Process Improvement and CapabilityDetermination), includes multiple parts.
Part 1provides concepts and vocabulary for softwaredevelopment processes and related businessmanagement functions. Other parts of 15504define the requirements and procedures for performing process assessments.[3*] I. Sommerville, Software Engineering, 9thed., Addison-Wesley, 2011.[4*] S.H. Kan, Metrics and Models in SoftwareQuality Engineering, 2nd ed., AddisonWesley, 2002.[5] Project Management Institute and IEEEComputer Society, Software Extensionto the PMBOK® Guide Fifth Edition, ed:Project Management Institute, 2013.[6] D.
Gibson, D. Goldenson, and K. Kost,“Performance Results of CMMI-BasedProcess Improvement,” SoftwareEngineering Institute, 2006; http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=8065.[7] CMMI Product Team, “CMMI forDevelopment, Version 1.3,” SoftwareEngineering Institute, 2010; http://resources.sei.cmu.edu/library/asset-view.cfm?assetID=9661.[8] ISO/IEC 15504-1:2004, InformationTechnology—Process Assessment—Part 1:Concepts and Vocabulary, ISO/IEC, 2004.CHAPTER 9SOFTWARE ENGINEERING MODELSAND METHODSACRONYMS3GLBNFFDDIDEPBIRADUMLXPBREAKDOWN OF TOPICS FORSOFTWARE ENGINEERING MODELSAND METHODS3rd Generation LanguageBackus-Naur FormFeature-Driven DevelopmentIntegrated DevelopmentEnvironmentProduct Backlog ItemRapid Application DevelopmentUnified Modeling LanguageeXtreme ProgrammingThis chapter on software engineering models andmethods is divided into four main topic areas:• Modeling: discusses the general practiceof modeling and presents topics in modeling principles; properties and expression ofmodels; modeling syntax, semantics, andpragmatics; and preconditions, postconditions, and invariants.• Types of Models: briefly discusses modelsand aggregation of submodels and providessome general characteristics of model typescommonly found in the software engineeringpractice.• Analysis of Models: presents some of thecommon analysis techniques used in modeling to verify completeness, consistency, correctness, traceability, and interaction.• Software Engineering Methods: presents abrief summary of commonly used softwareengineering methods.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
