Software Engineering Body of Knowledge (v3) (2014) (811503), страница 5
Текст из файла (страница 5)
The goal in developing this update toSWEBOK is to improve the currency, readability,consistency, and usability of the Guide.All knowledge areas (KAs) have been updatedto reflect changes in software engineering sincepublication of SWEBOK 2004. Four new foundation KAs and a Software Engineering Professional Practices KA have been added. The Software Engineering Tools and Methods KA hasbeen revised as Software Engineering Modelsand Methods. Software engineering tools is nowa topic in each of the KAs. Three appendices provide the specifications for the KA description, anannotated set of relevant standards for each KA,and a listing of the references cited in the Guide.This Guide, written under the auspices of theProfessional Activities Board of the IEEE Computer Society, represents a next step in the evolution of the software engineering profession.WHAT IS SOFTWARE ENGINEERING?ISO/IEC/IEEE Systems and Software EngineeringVocabulary (SEVOCAB) defines software engineering as “the application of a systematic, disciplined, quantifiable approach to the development,operation, and maintenance of software; that is, theapplication of engineering to software).”1WHAT ARE THE OBJECTIVES OF THESWEBOK GUIDE?The Guide should not be confused with the Bodyof Knowledge itself, which exists in the publishedliterature.
The purpose of the Guide is to describethe portion of the Body of Knowledge that is generally accepted, to organize that portion, and toprovide topical access to it.The Guide to the Software Engineering Bodyof Knowledge (SWEBOK Guide) was establishedwith the following five objectives:1.To promote a consistent view of softwareengineering worldwide2.To specify the scope of, and clarify the placeof software engineering with respect to otherdisciplines such as computer science, project management, computer engineering, andmathematics3.To characterize the contents of the softwareengineering discipline4.To provide a topical access to the SoftwareEngineering Body of Knowledge5.To provide a foundation for curriculumdevelopment and for individual certificationand licensing materialThe first of these objectives, a consistent worldwide view of software engineering, was supportedby a development process which engaged approximately 150 reviewers from 33 countries.
Moreinformation regarding the development process canbe found on the website (www.swebok.org). Professional and learned societies and public agenciesinvolved in software engineering were contacted,made aware of this project to update SWEBOK, andinvited to participate in the review process. KA editors were recruited from North America, the PacificRim, and Europe.
Presentations on the project weremade at various international venues.The second of the objectives, the desire tospecify the scope of software engineering, motivates the fundamental organization of the Guide.The material that is recognized as being withinthis discipline is organized into the fifteen KAslisted in Table I.1. Each of these KAs is treated ina chapter in this Guide.1 See www.computer.org/sevocab.xxxixxxii SWEBOK® Guide V3.0Table I.1. The 15 SWEBOK KAsSoftware RequirementsSoftware DesignSoftware ConstructionSoftware TestingSoftware MaintenanceSoftware Configuration ManagementSoftware Engineering ManagementSoftware Engineering ProcessSoftware Engineering Models and MethodsSoftware QualitySoftware Engineering Professional PracticeSoftware Engineering EconomicsComputing FoundationsMathematical FoundationsEngineering FoundationsIn specifying scope, it is also important to identify the disciplines that intersect with softwareengineering.
To this end, SWEBOK V3 also recognizes seven related disciplines, listed in TableI.2. Software engineers should, of course, haveknowledge of material from these disciplines(and the KA descriptions in this Guide may makereference to them). It is not, however, an objective of the SWEBOK Guide to characterize theknowledge of the related disciplines.Table I.2. Related DisciplinesComputer EngineeringComputer ScienceGeneral ManagementMathematicsProject ManagementQuality ManagementSystems EngineeringThe relevant elements of computer scienceand mathematics are presented in the ComputingFoundations and Mathematical Foundations KAsof the Guide (Chapters 13 and 14).HIERARCHICAL ORGANIZATIONThe organization of the KA chapters supports thethird of the project’s objectives—a characterization of the contents of software engineering. Thedetailed specifications provided by the project’seditorial team to the associate editors regardingthe contents of the KA descriptions can be foundin Appendix A.The Guide uses a hierarchical organization todecompose each KA into a set of topics with recognizable labels.
A two (sometime three) levelbreakdown provides a reasonable way to findtopics of interest. The Guide treats the selectedtopics in a manner compatible with major schoolsof thought and with breakdowns generally foundin industry and in software engineering literatureand standards.
The breakdowns of topics do notpresume particular application domains, businessuses, management philosophies, developmentmethods, and so forth. The extent of each topic’sdescription is only that needed to understand thegenerally accepted nature of the topics and forthe reader to successfully find reference material;the Body of Knowledge is found in the referencematerials themselves, not in the Guide.REFERENCE MATERIAL AND MATRIXTo provide topical access to the knowledge—thefourth of the project’s objectives—the Guideidentifies authoritative reference material foreach KA. Appendix C provides a ConsolidatedReference List for the Guide.
Each KA includesrelevant references from the Consolidated Reference List and also includes a matrix relating thereference material to the included topics.It should be noted that the Guide does notattempt to be comprehensive in its citations.Much material that is both suitable and excellentis not referenced. Material included in the Consolidated Reference List provides coverage of thetopics described.DEPTH OF TREATMENTTo achieve the SWEBOK fifth objective—providing a foundation for curriculum development,Introduction xxxiiicertification, and licensing, the criterion of generally accepted knowledge has been applied, tobe distinguished from advanced and researchknowledge (on the grounds of maturity) and fromspecialized knowledge (on the grounds of generality of application).The equivalent term generally recognizedcomes from the Project Management Institute:“Generally recognized means the knowledgeand practices described are applicable to mostprojects most of the time, and there is consensusabout their value and usefulness.”2However, the terms “generally accepted” or“generally recognized” do not imply that the designated knowledge should be uniformly appliedto all software engineering endeavors—each project’s needs determine that—but it does imply thatcompetent, capable software engineers shouldbe equipped with this knowledge for potentialapplication.
More precisely, generally acceptedknowledge should be included in the study material for the software engineering licensing examination that graduates would take after gainingfour years of work experience. Although this criterion is specific to the US style of education anddoes not necessarily apply to other countries, wedeem it useful.STRUCTURE OF THE KA DESCRIPTIONSThe KA descriptions are structured as follows.In the introduction, a brief definition of the KAand an overview of its scope and of its relationship with other KAs are presented.2 A Guide to the Project Management Body ofKnowledge, 5th ed., Project Management Institute,2013; www.pmi.org.The breakdown of topics in each KA constitutes the core the KA description, describingthe decomposition of the KA into subareas, topics, and sub-topics. For each topic or subtopic, ashort description is given, along with one or morereferences.The reference material was chosen because it isconsidered to constitute the best presentation ofthe knowledge relative to the topic.
A matrix linksthe topics to the reference material.The last part of each KA description is the listof recommended references and (optionally) further readings. Relevant standards for each KA arepresented in Appendix B of the Guide.APPENDIX A. KA DESCRIPTIONSPECIFICATIONSAppendix A describes the specifications providedby the editorial team to the associate editors forthe content, recommended references, format,and style of the KA descriptions.APPENDIX B.
ALLOCATION OF STANDARDS TO KASAppendix B is an annotated list of the relevantstandards, mostly from the IEEE and the ISO, foreach of the KAs of the SWEBOK Guide.APPENDIX C. CONSOLIDATEDREFERENCE LISTAppendix C contains the consolidated list of recommended references cited in the KAs (thesereferences are marked with an asterisk (*) in thetext).CHAPTER 1SOFTWARE REQUIREMENTSACRONYMSdoes not imply, however, that a software engineercould not perform the function.A risk inherent in the proposed breakdown isthat a waterfall-like process may be inferred. Toguard against this, topic 2, Requirements Process,is designed to provide a high-level overview of therequirements process by setting out the resourcesand constraints under which the process operatesand which act to configure it.An alternate decomposition could use a product-based structure (system requirements, software requirements, prototypes, use cases, andso on).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
