commit 2833de9b2b848bb6255808365f5ee371b5569598 from: Sergey Bronnikov date: Mon Feb 07 11:10:40 2022 UTC Fix formatting issues Follows up #11 Follows up #10 Follows up #9 Follows up #8 Follows up #7 Follows up #6 Follows up #5 Follows up #4 Follows up #3 Follows up #2 Follows up #1 commit - 2f3edb9c9b1305277610ba22041c2ca0ed3b3160 commit + 2833de9b2b848bb6255808365f5ee371b5569598 blob - 0dfc02c35601030a1d710437236318c5a179c713 blob + 781b30d3e787aa7cf6044f5729c30e1dc0f2901e --- 0_introduction.md +++ 0_introduction.md @@ -37,22 +37,24 @@ special damages, even if IEEE has been advised of the damages. Copyright © 2014 IEEE. All rights reserved. + Paperback ISBN-10: 0-7695-5166- + Paperback ISBN-13: 978-0-7695-5166- Digital copies of _SWEBOK Guide_ V3.0 may be downloaded free of charge for -personal and academic use via [http://www.swebok.org.](http://www.swebok.org). +personal and academic use via [http://www.swebok.org/](http://www.swebok.org). _IEEE Computer Society Staff for This Publication_ -Angela Burgess, Executive Director -Anne Marie Kelly, Associate Executive Director, Director of Governance -Evan M. Butterfield, Director of Products and Services -John Keppler, Senior Manager, Professional Education -Kate Guillemette, Product Development Editor -Dorian McClenahan, Education Program Product Developer -Michelle Phon, Professional Education & Certification Program Coordinator -Jennie Zhu-Mai, Editorial Designer +- Angela Burgess, Executive Director +- Anne Marie Kelly, Associate Executive Director, Director of Governance +- Evan M. Butterfield, Director of Products and Services +- John Keppler, Senior Manager, Professional Education +- Kate Guillemette, Product Development Editor +- Dorian McClenahan, Education Program Product Developer +- Michelle Phon, Professional Education & Certification Program Coordinator +- Jennie Zhu-Mai, Editorial Designer _IEEE Computer Society Products and Services._ @@ -243,14 +245,17 @@ USA, dickfairley@gmail.com Alain Abran, Department of Software and IT Engineering, École de technologie supérieure (ÉTS), Canada, alain.abran@etsmtl.ca + Juan Garbajosa, Universidad Politecnica de Madrid (Technical University of Madrid, UPM), Spain, juan.garbajosa@upm.es + Gargi Keeni, Tata Consultancy Services, India, gargi@ieee.org Beijun Shen, School of Software, Shanghai Jiao Tong University, China, bjshen@sjtu.edu.cn ### Contributing Editors The following persons contributed to editing the SWEBOK Guide V3: + - Don Shafer - Linda Shafer - Mary Jane Willshire @@ -259,6 +264,7 @@ The following persons contributed to editing the SWEBO ### Change Control Board The following persons served on the SWEBOK Guide V3 Change Control Board: + - Pierre Bourque - Richard E. (Dick) Fairley, Chair - Dennis Frailey @@ -620,36 +626,37 @@ The results of this ballot were 259 Yes votes and 5 No **The following motion was unanimously adopted by the Professional Activities Board of the IEEE Computer Society in December 2013:** -The Professional Activities Board of the IEEE Computer Society finds that the -Guide to the Software Engineering Body of Knowledge Version 3.0 has been -successfully completed; and endorses the Guide to the Software Engineering Body -of Knowledge Version 3.0 and commends it to the IEEE Computer Society Board of -Governors for their approval. +_The Professional Activities Board of the IEEE Computer Society finds_ that the +Guide to the Software Engineering Body of Knowledge Version 3.0 _has been +successfully completed; and endorses the_ Guide to the Software Engineering Body +of Knowledge Version 3.0 _and commends it to the IEEE Computer Society Board of +Governors for their approval_. **The following motion was adopted by the IEEE Computer Society Board of Governors in December 2013:** -MOVED, that the Board of Governors of the IEEE Computer Society approves Version 3.0 of the -Guide to the Software Engineering Body of Knowledge and authorizes the Chair of the Profes- -sional Activities Board to proceed with printing. +_MOVED, that the Board of Governors of the IEEE Computer Society approves +Version 3.0 of the_ Guide to the Software Engineering Body of Knowledge _and +authorizes the Chair of the Professional Activities Board to proceed with +printing_. ### Motions Regarding The Approval Of SWEBOK Guide 2004 Version **The following motion was unanimously adopted by the Industrial Advisory Board of the _SWEBOK Guide_ project in February 2004:** -The Industrial Advisory Board finds that the Software Engineering Body of +_The Industrial Advisory Board finds that the Software Engineering Body of Knowledge project initiated in 1998 has been successfully completed; and endorses the 2004 Version of the Guide to the SWEBOK and commends it to the -IEEE Computer Society Board of Governors for their approval. +IEEE Computer Society Board of Governors for their approval_. **The following motion was adopted by the IEEE Computer Society Board of Governors in February 2004:** -MOVED, that the Board of Governors of the IEEE Computer Society approves the -2004 Edition of the Guide to the Software Engineering Body of Knowledge and +_MOVED, that the Board of Governors of the IEEE Computer Society approves the +2004 Edition of the_ Guide to the Software Engineering Body of Knowledge _and authorizes the Chair of the Professional Practices Committee to proceed with -printing. +printing_. Please also note that the 2004 edition of the _Guide to the Software Engineering Body of Knowledge_ was submitted by the IEEE Computer Society to @@ -658,12 +665,9 @@ ISO/IEC without any change and was recognized as Techn ## Introduction To The Guide -KA Knowledge Area +- KA Knowledge Area +- SWEBOK Software Engineering Body of Knowledge -SWEBOK -Software Engineering Body of -Knowledge - Publication of the 2004 version of this _Guide to the Software Engineering Body of Knowledge_ (SWEBOK 2004) was a major milestone in establishing software engineering as a recognized engineering discipline. The goal in developing this @@ -683,18 +687,19 @@ This _Guide_, written under the auspices of the Profes of the IEEE Computer Society, represents a next step in the evolution of the software engineering profession. -**WHAT IS SOFTWARE ENGINEERING?** +**What Is Software Engineering?** ISO/IEC/IEEE Systems and Software Engineering Vocabulary (SEVOCAB) defines software engineering as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software).”^1 -**WHAT ARE THE OBJECTIVES OF THE SWEBOK GUIDE?** +**What Are The Objectives Of The SWEBOK Guide?** The _Guide_ should not be confused with the Body of Knowledge itself, which exists in the published + 1 See [http://www.computer.org/sevocab](http://www.computer.org/sevocab). literature. The purpose of the Guide is to describe the portion of the Body of @@ -716,18 +721,18 @@ certification and licensing material The first of these objectives, a consistent worldwide view of software engineering, was supported by a development process which engaged approximately 150 reviewers from 33 countries. More information regarding the development -process can be found on the website (www.swebok.org). Professional and learned -societies and public agencies involved in software engineering were contacted, -made aware of this project to update SWEBOK, and invited to participate in the -review process. KA editors were recruited from North America, the Pacific Rim, -and Europe. Presentations on the project were made at various international -venues. The second of the objectives, the desire to specify the scope of -software engineering, motivates the fundamental organization of the Guide. The -material that is recognized as being within this discipline is organized into -the fifteen KAs listed in Table I.1. Each of these KAs is treated in a chapter -in this Guide. +process can be found on the website ([www.swebok.org](http://www.swebok.org)). +Professional and learned societies and public agencies involved in software +engineering were contacted, made aware of this project to update SWEBOK, and +invited to participate in the review process. KA editors were recruited from +North America, the Pacific Rim, and Europe. Presentations on the project were +made at various international venues. The second of the objectives, the desire +to specify the scope of software engineering, motivates the fundamental +organization of the Guide. The material that is recognized as being within this +discipline is organized into the fifteen KAs listed in Table I.1. Each of these +KAs is treated in a chapter in this Guide. -Table I.1. The 15 SWEBOK KAs +Table I.1. The 15 SWEBOK KAs Software Requirements Software Design @@ -753,7 +758,7 @@ descriptions in this _Guide_ may make reference to the an objective of the _SWEBOK Guide_ to characterize the knowledge of the related disciplines. -Table I.2. Related Disciplines +Table I.2. Related Disciplines Computer Engineering Computer Science @@ -767,7 +772,7 @@ The relevant elements of computer science and mathemat Computing Foundations and Mathematical Foundations KAs of the _Guide_ (Chapters 13 and 14). -##### HIERARCHICAL ORGANIZATION +**Hierarchical Organization** The organization of the KA chapters supports the third of the project’s objectives - a characterization of the contents of software engineering. The @@ -787,7 +792,7 @@ the generally accepted nature of the topics and for th find reference material; the Body of Knowledge is found in the reference materials themselves, not in the Guide. -REFERENCE MATERIAL AND MATRIX +**Reference Material And Matrix** To provide topical access to the knowledge-the fourth of the project’s objectives-the Guide identifies authoritative reference material for each KA. @@ -799,18 +804,14 @@ citations. Much material that is both suitable and exc referenced. Material included in the Consolidated Reference List provides coverage of the topics described. -DEPTH OF TREATMENT +**Depth Of Treatment** To achieve the SWEBOK fifth objective-providing a foundation for curriculum -development, +development, certification, and licensing, the criterion of _generally +accepted_ knowledge has been applied, to be distinguished from advanced and +research knowledge (on the grounds of maturity) and from specialized knowledge +(on the grounds of generality of application). -Introduction - -certification, and licensing, the criterion of _generally accepted_ knowledge -has been applied, to be distinguished from advanced and research knowledge (on -the grounds of maturity) and from specialized knowledge (on the grounds of -generality of application). - The equivalent term _generally recognized_ comes from the Project Management Institute: “Generally recognized means the knowledge and practices described are applicable to most projects most of the time, and there is consensus about @@ -825,14 +826,14 @@ would take after gaining four years of work experience is specific to the US style of education and does not necessarily apply to other countries, we deem it useful. -**STRUCTURE OF THE KA DESCRIPTIONS** +**Structure Of The KA Descriptions** The KA descriptions are structured as follows. In the introduction, a brief definition of the KA and an overview of its scope and of its relationship with other KAs are presented. _A Guide to the Project Management Body of Knowledge_, 5th ed., Project -Management Institute, 2013; [http://www.pmi.org.](http://www.pmi.org.) +Management Institute, 2013; [http://www.pmi.org/](http://www.pmi.org/). The breakdown of topics in each KA constitutes the core the KA description, describing the decomposition of the KA into subareas, topics, and sub-topics. @@ -845,18 +846,18 @@ topics to the reference material. The last part of eac list of recommended references and (optionally) further readings. Relevant standards for each KA are presented in Appendix B of the Guide. -APPENDIX A. KA DESCRIPTION SPECIFICATIONS +**APPENDIX A. KA Description Specifications** Appendix A describes the specifications provided by the editorial team to the associate editors for the content, recommended references, format, and style of the KA descriptions. -APPENDIX B. ALLOCATION OF STANDARDS TO KAS +**APPENDIX B. Allocation Of Standards To KAS** Appendix B is an annotated list of the relevant standards, mostly from the IEEE and the ISO, for each of the KAs of the SWEBOK Guide. -APPENDIX C. CONSOLIDATED REFERENCE LIST +**APPENDIX C. Consolidated Reference List** Appendix C contains the consolidated list of recommended references cited in the KAs (these references are marked with an asterisk (*) in the text). blob - 053f2b5a28abc127aa2bbb80b32149a824542f9d blob + 3f7d518373fd17e24288522bb878a373f2687796 --- 10_software_quality.md +++ 10_software_quality.md @@ -1014,7 +1014,7 @@ Software Quality 10-17 [1] P.B. Crosby, _Quality Is Free_, McGraw-Hill, 1979. [2] W. Humphrey, _Managing the Software Process_, Addison-Wesley, 1989. [3] S.H. Kan, _Metrics and Models in Software Quality Engineering_, 2nd ed., -Addison- Wesley, 2002. +Addison-Wesley, 2002. [4] _ISO/IEC 25010:2011 Systems and Software Engineering—Systems and Software Quality Requirements and Evaluation (SQuaRE)—Systems and Software Quality Models_, ISO/IEC, 2011. blob - 46a1c05f92f87416ca290cb2fd99a49946a206d7 blob + 10d880bce5746368ce295c07783ce5b52d3346f6 --- 1_software_requirements.md +++ 1_software_requirements.md @@ -51,11 +51,10 @@ Software Testing, Software Maintenance, Software Confi Software Engineering Management, Software Engineering Process, Software Engineering Models and Methods, and Software Quality KAs. -**BREAKDOWN OF TOPICS FOR SOFTWARE REQUIREMENTS** +**Breakdown Of Topics For Software Requirements** -The breakdown of topics for the Software - -Requirements KA is shown in Figure 1.1. +The breakdown of topics for the Software Requirements KA is shown in Figure +1.1. ### 1. Software Requirements Fundamentals @@ -962,7 +961,7 @@ alternative solutions. Its coverage is exemplary and s reference for key techniques such as use case modeling and requirements prioritization. -C. Potts, K. Takahashi, and A. Antón, “Inquiry- Based Requirements Analysis” [6]. +C. Potts, K. Takahashi, and A. Antón, “Inquiry-Based Requirements Analysis” [6]. This paper is an easily digested account of work that has proven to be very influential in the development of requirements handling. It describes how and blob - fdf1989d18a0b16bcd738a15363d586f5c18584a blob + 631b665c3966775525c2a7eb0c44f550a354150d --- 2_software_design.md +++ 2_software_design.md @@ -62,7 +62,7 @@ This Software Design KA is related specifically to the Software Construction, Software Engineering Management, Software Engineering Models and Methods, Software Quality, and Computing Foundations KAs. -**BREAKDOWN OF TOPICS FOR SOFTWARE DESIGN** +**Breakdown Of Topics For Software Design** The breakdown of topics for the Software Design KA is shown in Figure 2.1. @@ -100,8 +100,6 @@ Software design is generally considered a two-step pro ![Figure 2.1 Breakdown of Topics for the Software Design KA](images/Figure-2.1.png) -Software Design 2-3 - - Architectural design (also referred to as high-level design and top-level design) describes how software is organized into components. - Detailed design describes the desired behavior of these components. @@ -248,8 +246,6 @@ design (for example, design patterns). These design co to design families of programs (also known as product lines). Interestingly, most of these concepts can be seen as attempts to describe, and thus reuse, design knowledge. - -Software Design 2-5 #### 3.1. Architectural Structures and Viewpoints @@ -403,8 +399,6 @@ Information presentation may be textual or graphical i keeps the information presentation separate from the information itself. The MVC (Model-View-Controller) approach is an effective way to keep information presentation separating from the information being presented. - -Software Design 2-7 Software engineers also consider software response time and feedback in the design of information presentation. Response time is generally measured from @@ -551,8 +545,6 @@ structural (static) view vs. the behavioral (dynamic) [4*, c7] [5*, c6, c7] [6*, c4, c5, c6, c7] [12*, c7] [14*, c7] --> - -Software Design 2-9 The following notations, mostly but not always graphical, describe and represent the structural aspects of a software design - that is, they are used blob - 0d080ccd89c585d1e534f19fcc339557caa39c15 blob + 2be8fd5eb55c4208fa244a3f944bd070c140280c --- 3_software_construction.md +++ 3_software_construction.md @@ -2,14 +2,14 @@ **Acronyms** -API Application Programming Interface -COTS Commercial Off-the-Shelf -GUI Graphical User Interface -IDE Integrated Development Environment -OMG Object Management Group -POSIX Portable Operating System Interface -TDD Test-Driven Development -UML Unified Modeling Language +- API Application Programming Interface +- COTS Commercial Off-the-Shelf +- GUI Graphical User Interface +- IDE Integrated Development Environment +- OMG Object Management Group +- POSIX Portable Operating System Interface +- TDD Test-Driven Development +- UML Unified Modeling Language **Introduction** @@ -42,7 +42,7 @@ support the design and construction of software produc project management, insofar as the management of construction can present considerable challenges. -**BREAKDOWN OF TOPICS FOR SOFTWARE CONSTRUCTION** +**Breakdown Of Topics For Software Construction** Figure 3.1 gives a graphical representation of the top-level decomposition of the breakdown for the Software Construction KA. @@ -62,8 +62,6 @@ following sections define these concepts and describe construction. ![Figure 3.1. Breakdown of Topics for the Software Construction KA](images/Figure-3.1.png) - -Software Construction 3-3 #### 1.1. Minimizing Complexity @@ -221,8 +219,6 @@ ensuring quality during construction, and improving th among other uses (see the Software Engineering Process KA for more on measurement). -Software Construction 3-5 - ### 3. Practical Considerations Construction is an activity in which the software engineer has to deal with @@ -381,8 +377,6 @@ encapsulate reusable code fragments into well-structur components. The tasks related to software construction for reuse during coding and testing are as follows: -Software Construction 3-7 - - Variability implementation with mechanisms such as parameterization, conditional compilation, design patterns, and so forth. - Variability encapsulation to make the software assets easy to configure and @@ -542,8 +536,6 @@ code is modified, and so on. Assertions are normally c development time and are later compiled out of the code so that they don’t degrade the performance. -Software Construction 3-9 - Design by contract is a development approach in which preconditions and postconditions are included for each routine. When preconditions and postconditions are used, each routine or class is said to form a contract with @@ -690,8 +682,6 @@ Modern message-oriented middleware usually provides an (ESB), which supports service-oriented interaction and communication between multiple software applications. -Software Construction 3-11 - #### 4.12. Construction Methods for Distributed Software @@ -755,7 +745,6 @@ implementations must implement. Typical examples of pl systems (Portable Operating System Interface), which represents a set of standards implemented primarily for UNIX-based operating systems. - #### 4.16. Test-First Programming @@ -835,8 +824,6 @@ can be used for locating the source of errors, program optimization analysis. Program slicing tools compute program slices for various programming languages using static or dynamic analysis methods. -Software Construction 3-13 - ### Matrix Of Topics vs. Reference Material McConnell 2004 blob - 7cdb206b01f1c6fe440eb4d716f01d89a969056b blob + ab23b48be46fa62c21903a8a2c07800f62908670 --- 4_software_testing.md +++ 4_software_testing.md @@ -2,10 +2,10 @@ **Acronyms** -API Application Program Interface -TDD Test-Driven Development -TTCN3 Testing and Test Control Notation Version 3 -XP Extreme Programming +- API Application Program Interface +- TDD Test-Driven Development +- TTCN3 Testing and Test Control Notation Version 3 +- XP Extreme Programming **Introduction** @@ -79,7 +79,7 @@ Software testing is also related to software construct Testing in the Software Construction KA). In particular, unit and integration testing are intimately related to software construction, if not part of it. -**BREAKDOWN OF TOPICS FOR SOFTWARE TESTING** +**Breakdown Of Topics For Software Testing** The breakdown of topics for the Software Testing KA is shown in Figure 4.1. A more detailed breakdown is provided in the Matrix of Topics vs. Reference @@ -1343,7 +1343,7 @@ ISO/ IEC/IEEE, 2010. Prioritization: A Survey,” Software Testing Verification and Reliability, vol. 22, no. 2, Mar. 2012, pp. 67–120. [9] S.H. Kan, Metrics and Models in Software Quality Engineering, 2nd ed., -Addison- Wesley, 2002. +Addison-Wesley, 2002. [10] J. Nielsen, Usability Engineering, Morgan Kaufmann, 1993. [11] T.Y. Chen et al., “Adaptive Random Testing: The ART of Test Case Diversity,” Journal of Systems and Software, vol. 83, no. 1, Jan. 2010, pp. blob - 97ff1b2b2b873aae0565cf584ead17f75e139c1c blob + ccfae111b717a295a985f28412d45bc268c24369 --- 5_software_maintenance.md +++ 5_software_maintenance.md @@ -2,12 +2,12 @@ **Acronyms** -MR Modification Request -PR Problem Report -SCM Software Configuration Management -SLA Service-Level Agreement -SQA Software Quality Assurance -V&V Verification and Validation +- MR Modification Request +- PR Problem Report +- SCM Software Configuration Management +- SLA Service-Level Agreement +- SQA Software Quality Assurance +- V&V Verification and Validation **Introduction** @@ -38,7 +38,7 @@ area (KA) is related to all other aspects of software this KA description is linked to all other software engineering KAs of the Guide. -BREAKDOWN OF TOPICS FOR SOFTWARE MAINTENANCE +**Breakdown Of Topics For Software Maintenance** The breakdown of topics for the Software Maintenance KA is shown in Figure 5.1. @@ -60,6 +60,7 @@ for software maintenance: ISO/IEC/IEEE 14764 [1].^1 In engineering, software maintenance is essentially one of the many technical processes. + 1 For the purpose of conciseness and ease of reading, this standard is referred to simply as IEEE 14764 in the subsequent text of this KA. @@ -96,8 +97,6 @@ evolve/maintain them over a software life cycle. ![Figure 5.1. Breakdown of Topics for the Software Maintenance KA](images/Figure-5.1.png) -Software Maintenance 5-3 - #### 1.3. Need for Maintenance @@ -248,8 +247,6 @@ it may be difficult to bring it offline to test. Tests the most meaningful place - the production system. The Software Testing KA provides additional information and references on this matter in its subtopic on regression testing. - -Software Maintenance 5-5 ##### 2.1.3. Impact Analysis @@ -403,8 +400,6 @@ factors. IEEE 14764 states that “the two most popula resources for software maintenance are the use of parametric models and the use of experience” [1*, c7s4.1]. A combination of these two can also be used. -Software Maintenance 5-7 - ##### 2.3.2. Parametric Models @@ -554,8 +549,6 @@ software configuration management, verification and va resolution, software quality assurance, reviews, and audits. Another important support activity consists of training the maintainers and users. -Software Maintenance 5-9 - ##### 3.2.3. Maintenance Planning Activities @@ -698,9 +691,6 @@ a number of additional activities such as user experiences a smooth transition to the new environment; - notification of completion: when the scheduled migration is completed, a notification is sent to all concerned; - -Software Maintenance 5-11 - - postoperation review: an assessment of parallel operation and the impact of changing to the new environment; - data archival: storing the old software data. @@ -776,8 +766,6 @@ Sneed 2008 2.3. Maintenance Cost Estimation 2.3.1. Cost Estimation c7s4.1 c7s2.4 -Software Maintenance 5-13 - IEEE/ISO/IEC 14764 2006 [1] @@ -809,7 +797,7 @@ Sneed 2008 4.5. Retirement c5s6 **5. Software Maintenance Tools** c6s4 c14 -**Further Readings +**Further Readings** A. April and A. Abran, _Software Maintenance Management: Evaluation and Continuous Improvement_ [6]. blob - e5c670941aabddbf9aac6965a307a455ab95baec blob + 9c7de09802d4d09dfeee051450c0beff73e97c0a --- 6_software_configuration_management.md +++ 6_software_configuration_management.md @@ -59,7 +59,7 @@ The Software Configuration Management KA is related to the object of configuration management is the artifact produced and used throughout the software engineering process. -**BREAKDOWN OF TOPICS FOR SOFTWARE CONFIGURATION MANAGEMENT** +**Breakdown Of Topics For Software Configuration Management** The breakdown of topics for the Software Configuration Management KA is shown in Figure 6.1. @@ -111,7 +111,7 @@ maintenance organizations. It is within this context t software configuration control tasks are conducted. Frequently, the same tools support development, maintenance, and SCM purposes. -#### 1.2. Constraints and Guidance for the SCM Process_ +#### 1.2. Constraints and Guidance for the SCM Process @@ -259,7 +259,7 @@ reference for the SCM process. It is maintained (that as necessary during the software life cycle. In implementing the SCMP, it is typically necessary to develop a number of more detailed, subordinate procedures defining how specific requirements will be carried out during -day-to-day activities— for example, which branching strategies will be used and +day-to-day activities - for example, which branching strategies will be used and how frequently builds occur and automated tests of all kinds are run. Guidance on the creation and maintenance of an SCMP, based on the information @@ -892,8 +892,8 @@ Addison-Wesley, 2003. [4] I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011. -[5] J.W. Moore, The Road Map to Software Engineering: A Standards-Based Guide -, Wiley-IEEE Computer Society Press, 2006. +[5] J.W. Moore, The Road Map to Software Engineering: A Standards-Based Guide, +Wiley-IEEE Computer Society Press, 2006. [6] S.P. Berczuk and B. Appleton, Software Configuration Management Patterns: Effective Teamwork, Practical Integration, Addison-Wesley Professional, 2003. blob - a242f382395777d4a9969f5e23e10b75acd95fef blob + 0da061c75ed03d074c08eeefed6186bd9ffe474f --- 7_software_engineering_management.md +++ 7_software_engineering_management.md @@ -2,7 +2,7 @@ **Acronyms** -- PMBOK ® Guide Guide to the Project Management Body of Knowledge +- PMBOK® Guide Guide to the Project Management Body of Knowledge - SDLC Software Development Life Cycle - SEM Software Engineering Management - SQA Software Quality Assurance @@ -25,6 +25,7 @@ the same way other complex endeavors are managed. Howe specific to software projects and software life cycle processes that complicate effective management, including these: + 1 The terms Initiating, Planning, Executing, Monitoring and Controlling, and Closing are used to describe process groups in the _PMBOK_ ® _Guide_ and _SWX_. @@ -156,7 +157,7 @@ conjunction with this one will be particularly helpful - The Software Engineering Economics KA discusses how to make software-related decisions in a business context. -**BREAKDOWN OF TOPICS FOR SOFTWARE ENGINEERING MANAGEMENT** +**Breakdown Of Topics For Software Engineering Management** Because most software development life cycle models require similar activities that may be executed in different ways, the breakdown of topics is @@ -610,8 +611,9 @@ process. The standard also includes a measurement info analyst and librarian). Adequate funding, training, tools, and support to conduct the process should also be allocated. + 2 Please note that these two chapters can be downloaded free of charge from -http://www.psmsc.com/ PSMBook.asp. +http://www.psmsc.com/PSMBook.asp. #### 6.2. Plan the Measurement Process blob - 551dd676d2ae5b454a0e9bd6c4afc9e9cd70836d blob + 8f33eea18dc2512073d7a55c517a55fc8fe845a3 --- 8_software_engineering_process.md +++ 8_software_engineering_process.md @@ -50,7 +50,7 @@ processes for project and product quality. Measurement in the Engineering Foundations KA are essential for evaluating and control- ling software processes. -**BREAKDOWN OF TOPICS FOR SOFTWARE ENGINEERING PROCESS** +**Breakdown Of Topics For Software Engineering Process** As illustrated in Figure 8.1, this KA is concerned with software process definition, software life cycles, software process assessment and improve- @@ -90,8 +90,6 @@ other subprocesses of the software requirements proces and iterated in various ways; ![Figure 8.1. Breakdown of Topics for the Software Engineering Process KA](images/Figure-8.1.png) - -Software Engineering Process 8-3 the software requirements process and its subprocesses may be entered and exited multiple times during software development or modification. @@ -452,19 +450,14 @@ prevention. -Software process capability and software process -maturity are typically rated using five or six levels -to characterize the capability or maturity of the -software processes used within an organization. -A _continuous_ rating system involves assign- -ing a rating to each software process of interest; -a _staged_ rating system is established by assign- -ing the same maturity rating to all of the software -processes within a specified process level. A rep- -resentation of continuous and staged process lev- -els is provided in Table 8.1. Continuous models -typically use a level 0 rating; staged models typi- -cally do not. +Software process capability and software process maturity are typically rated +using five or six levels to characterize the capability or maturity of the +software 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 software processes within a specified process level. A representation of +continuous and staged process levels is provided in Table 8.1. Continuous +models typically use a level 0 rating; staged models typically do not. | Level | Continuous Representation of Capability Levels | Staged Representation of Maturity Levels | |-------:|:-----------------------------------------------|------------------------------------------| @@ -560,8 +553,8 @@ and the quality of requirements, design documentation, products. Also note that efficiency and effectiveness are independent concepts. An -effective software process can be inefficient in achieving a desired soft- -ware process result; for example, the amount of effort expended to find and fix +effective software process can be inefficient in achieving a desired software +process result; for example, the amount of effort expended to find and fix software defects could be very high and result in low efficiency, as compared to expectations. @@ -730,8 +723,8 @@ diagrams, run charts, control charts, and cause-and-ef Cause Analysis in the Engineering Foundations KA). In addition, various statistical techniques can be used that range from calculation of medians and means to multivariate analysis methods (see Statistical Analysis in the -Engineering Foundations KA). Data collected using quantitative process mea- -surement techniques can also be used as inputs to simulation models (see +Engineering Foundations KA). Data collected using quantitative process +measurement techniques can also be used as inputs to simulation models (see Modeling, Prototyping, and Simulation in the Engineering Foundations KA); these models can be used to assess the impact of various approaches to software process improvement. blob - 0efd7bba05364b0a969381043780e779095acdb1 blob + 78a825b2b3e272ed669d3a3dbd71f715cb9f3fbd --- 9_software_engineering_models.md +++ 9_software_engineering_models.md @@ -26,7 +26,7 @@ software engineering models and methods that encompass cycle phases, since methods specific for single life cycle phases are covered by other KAs. -BREAKDOWN OF TOPICS FOR SOFTWARE ENGINEERING MODELS AND METHODS +**Breakdown Of Topics For Software Engineering Models And Methods** This chapter on software engineering models and methods is divided into four main topic areas: