Software Engineering Body of Knowledge (v3) (2014) (811503), страница 83
Текст из файла (страница 83)
Those factors are broken down into subfactors and sub-subfactors until root causes canbe identified.A very simple approach that is useful in qualitycontrol is the use of a checklist. Checklists area list of key points in a process with tasks thatmust be completed. As each task is completed,it is checked off the list.
If a problem occurs,then sometimes the checklist can quickly identifytasks that may have been skipped or only partially completed.Finally, relations diagrams are a means for displaying complex relationships. They give visualsupport to cause-and-effect thinking. The diagram relates the specific to the general, revealingkey causes and key effects.Root cause analysis aims at preventing therecurrence of undesirable events. Reduction ofvariation due to common causes requires utilization of a number of techniques.
An importantpoint to note is that these techniques should beused offline and not necessarily in direct responseto the occurrence of some undesirable event.Some of the techniques that may be used toreduce variation due to common causes are givenbelow.1.Cause-and-effect diagrams may be used toidentify the sub and sub-sub causes.2.Fault tree analysis is a technique that may beused to understand the sources of failures.3.Designed experiments may be used to understand the impact of various causes on theoccurrence of undesirable events (see Empirical Methods and Experimental Techniquesin this KA).4.Various kinds of correlation analyses may beused to understand the relationship betweenvarious causes and their impact. These techniques may be used in cases when conducting controlled experiments is difficult butdata may be gathered (see Statistical Analysis in this KA).15-14 SWEBOK® Guide V3.0c9s1,c2s1c3s6,c3s9,c4s6,c6s2,c7s1,c7s3,c8s1,c9s12.2. Concepts ofc11s2,Correlation andc11s8Regression3. Measurement3.1. Levels(Scales) ofMeasurement3.2. Directand DerivedMeasuresc3s2c7s5p442–447Moore 2006[13*]Sommerville 2011[12*]c7s5c10s3Cheney and Kincaid 2007[11*]c4s4c1McConnell 2004[10*]Fairley 2009[6*]c3s1,c3s2Tockey 2004[7*]Voland 2003[5*]2.1. Concept ofUnit of Analysis(SamplingUnits), Sample,and PopulationKan 2002[4*]1. EmpiricalMethods andExperimentalTechniques1.1. DesignedExperiment1.2. ObservationalStudy1.3. RetrospectiveStudy2. StatisticalAnalysisNull and Lobur 2006[3*]Montgomery and Runger 2007[2*]MATRIX OF TOPICS VS.
REFERENCE MATERIALMoore 2006[13*]Sommerville 2011[12*]McConnell 2004[10*]Tockey 2004[7*]Fairley 2009[6*]Voland 2003[5*]Kan 2002[4*]c2s3.1c3s5c1s2,c1s3,c1s44.1. Design inEngineeringEducation4.2. Designas a ProblemSolving Activity4.3. StepsInvolved inEngineeringDesign5. Modeling,Prototyping, andSimulation5.1. Modeling5.2. Simulation5.3. Prototypingc1s4,c2s1,c3s3c5s1c4c6c5,c3s7,c9s8c9s3.2c9s3,c9s4,c9s5c5c36. Standards7.1. Techniquesfor ConductingRoot CauseAnalysisc13s3c3s4,c3s54. EngineeringDesign7. Root CauseAnalysisCheney and Kincaid 2007[11*]3.3. Reliabilityand Validity3.4. AssessingReliabilityNull and Lobur 2006[3*]Montgomery and Runger 2007[2*]Engineering Foundations 15-15c1s2c13s3.4.515-16 SWEBOK® Guide V3.0FURTHER READINGSA.
Abran, Software Metrics and SoftwareMetrology. [14]W.G. Vincenti, What Engineers Know and HowThey Know It. [15]This book provides very good information on theproper use of the terms measure, measurementmethod and measurement outcome. It providesstrong support material for the entire section onMeasurement.This book provides an interesting introduction to engineering foundations through a seriesof case studies that show many of the foundational concepts as used in real world engineeringapplications.Engineering Foundations 15-17REFERENCES[1] ISO/IEC/IEEE 24765:2010 Systems andSoftware Engineering—Vocabulary, ISO/IEC/IEEE, 2010.[2*] D.C. Montgomery and G.C.
Runger,Applied Statistics and Probability forEngineers, 4th ed., Wiley, 2007.[3*] L. Null and J. Lobur, The Essentials ofComputer Organization and Architecture,2nd ed., Jones and Bartlett Publishers,2006.[4*] S.H. Kan, Metrics and Models in SoftwareQuality Engineering, 2nd ed., AddisonWesley, 2002.[5*] G. Voland, Engineering by Design, 2nd ed.,Prentice Hall, 2003.[6*] R.E. Fairley, Managing and LeadingSoftware Projects, Wiley-IEEE ComputerSociety Press, 2009.[7*] S.
Tockey, Return on Software: Maximizingthe Return on Your Software Investment,Addison-Wesley, 2004.[8] Canadian Engineering Accreditation Board,Engineers Canada, “Accreditation Criteriaand Procedures,” Canadian Council ofProfessional Engineers, 2011; www.engineerscanada.ca/files/w_Accreditation_Criteria_Procedures_2011.pdf.[9] ABET Engineering AccreditationCommission, “Criteria for AccreditingEngineering Programs, 2012-2013,”ABET, 2011; www.abet.org/uploadedFiles/Accreditation/Accreditation_Process/Accreditation_Documents/Current/eaccriteria-2012-2013.pdf.[10*] S. McConnell, Code Complete, 2nd ed.,Microsoft Press, 2004.[11*] E.W. Cheney and D.R.
Kincaid, NumericalMathematics and Computing, 6th ed.,Brooks/Cole, 2007.[12*] I. Sommerville, Software Engineering, 9thed., Addison-Wesley, 2011.[13*] J.W. Moore, The Road Map to SoftwareEngineering: A Standards-Based Guide,Wiley-IEEE Computer Society Press, 2006.[14] A. Abran, Software Metrics and SoftwareMetrology, Wiley-IEEE Computer SocietyPress, 2010.[15] W.G.
Vincenti, What Engineers Knowand How They Know It, John HopkinsUniversity Press, 1990.APPENDIX AKNOWLEDGE AREA DESCRIPTIONSPECIFICATIONSINTRODUCTIONThis document presents the specifications provided to the Knowledge Area Editors (KA Editors) regarding the Knowledge Area Descriptions(KA Descriptions) of the Version 3 (V3) editionof the Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide).
This documentwill also enable readers, reviewers, and users toclearly understand what specifications were usedwhen developing this version of the SWEBOKGuide.This document begins by situating the SWEBOK Guide as a foundational document for theIEEE Computer Society suite of software engineering products and more widely within thesoftware engineering community at large. Therole of the baseline and the Change ControlBoard is then described.
Criteria and requirements are defined for the breakdowns of topics,for the rationale underlying these breakdownsand the succinct description of topics, and for reference materials. Important input documents arealso identified, and their role within the project isexplained. Noncontent issues such as submissionformat and style guidelines are also discussed.THE SWEBOK GUIDE IS AFOUNDATIONAL DOCUMENT FOR THEIEEE COMPUTER SOCIETY SUITE OFSOFTWARE ENGINEERING PRODUCTSThe SWEBOK Guide is an IEEE Computer Society flagship and structural document for the IEEEComputer Society suite of software engineering products.
The SWEBOK Guide is also morewidely recognized as a foundational documentwithin the software engineering community atlarge notably through the official recognition ofthe 2004 Version as ISO/IEC Technical Report19759:2005. The list of knowledge areas (KAs)and the breakdown of topics within each KA isdescribed and detailed in the introduction of thisSWEBOK Guide.Consequently, the SWEBOK Guide is foundational to other initiatives within the IEEE Computer Society:a)The list of KAs and the breakdown of topicswithin each KA are also adopted by the software engineering certification and associatedprofessional development products offeredby the IEEE Computer Society (see www.computer.org/certification).b)The list of KAs and the breakdown of topics are also foundational to the softwareengineering curricula guidelines developedor endorsed by the IEEE Computer Society(www.computer.org/portal/web/education/Curricula).c)The Consolidated Reference List (see Appendix C), meaning the list of recommendedreference materials (to the level of sectionnumber) that accompanies the breakdown oftopics within each KA is also adopted by thesoftware engineering certification and associated professional development productsoffered by the IEEE Computer Society.BASELINE AND CHANGE CONTROLBOARDDue to the structural nature of the SWEBOKGuide and its adoption by other products, a baseline was developed at the outset of the projectcomprised of the list of KAs, the breakdown ofA-1A-2 SWEBOK® Guide V3.0topics within each KA, and the Consolidated Reference List.A Change Control Board (CCB) has been inplace for the development of this version to handle all change requests to this baseline comingfrom the KA Editors, arising during the reviewprocess, or otherwise.
Change requests must beapproved both by the SWEBOK Guide Editorsand by the CCB before being implemented. ThisCCB is comprised of members of the initiativeslisted above and acting under the authority of theSoftware and Systems Engineering Committee ofthe IEEE Computer Society Professional Activities Board.CRITERIA AND REQUIREMENTS FORTHE BREAKDOWN OF TOPICS WITHINA KNOWLEDGE AREAa)KA Editors are instructed to adopt the baseline breakdown of topics.b)The breakdown of topics is expected to be“reasonable,” not “perfect.”c)The breakdown of topics within a KA mustdecompose the subset of the Software Engineering Body of Knowledge that is “generally recognized.” See below for a moredetailed discussion of this point.d)The breakdown of topics within a KA mustnot presume specific application domains,business needs, sizes of organizations, organizational structures, management philosophies,software life cycle models, software technologies, or software development methods.e)The breakdown of topics must, as muchas possible, be compatible with the various schools of thought within softwareengineering.f)The breakdown of topics within a KA mustbe compatible with the breakdown of software engineering generally found in industry and in the software engineering literatureand standards.g)The breakdown of topics is expected to be asinclusive as possible.h)The SWEBOK Guide adopts the positionthat even though the following “themes” arecommon across all Knowledge Areas, theyare also an integral part of all KnowledgeAreas and therefore must be incorporatedinto the proposed breakdown of topics ofeach Knowledge Area.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
