commit - 2f3edb9c9b1305277610ba22041c2ca0ed3b3160
commit + 2833de9b2b848bb6255808365f5ee371b5569598
blob - 0dfc02c35601030a1d710437236318c5a179c713
blob + 781b30d3e787aa7cf6044f5729c30e1dc0f2901e
--- 0_introduction.md
+++ 0_introduction.md
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._
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
### Change Control Board
The following persons served on the SWEBOK Guide V3 Change Control Board:
+
- Pierre Bourque
- Richard E. (Dick) Fairley, Chair
- Dennis Frailey
**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
## 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
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
+<!-- FIXME -->
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
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 <!-- FIXME -->
Software Requirements
Software Design
an objective of the _SWEBOK Guide_ to characterize the knowledge of the related
disciplines.
-Table I.2. Related Disciplines
+Table I.2. Related Disciplines <!-- FIXME -->
Computer Engineering
Computer Science
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
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.
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
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.
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
[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
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
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
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.
-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.
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
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
[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
**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**
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.
construction.
-
-Software Construction 3-3
#### 1.1. Minimizing Complexity
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
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
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
(ESB), which supports service-oriented interaction and communication between
multiple software applications.
-Software Construction 3-11
-
#### 4.12. Construction Methods for Distributed Software
<!-- [7] -->
systems (Portable Operating System Interface), which represents a set of
standards implemented primarily for UNIX-based operating systems.
-
#### 4.16. Test-First Programming
<!-- [1] -->
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
**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**
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
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
**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**
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.
engineering, software maintenance is essentially one of the many technical
processes.
+<!-- FIXME: footnote -->
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.
-Software Maintenance 5-3
-
#### 1.3. Need for Maintenance
<!-- [2*, c1s5] -->
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
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
<!-- [2*, c12s5.6] -->
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
<!-- [1*, c7s3] -->
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.
2.3. Maintenance Cost Estimation
2.3.1. Cost Estimation c7s4.1 c7s2.4
-Software Maintenance 5-13
-
IEEE/ISO/IEC 14764 2006
[1]
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
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.
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
<!-- [2, c6, ann. D, ann. E] [3, c2, c5] [5, c19s2.2] -->
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
[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
**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
specific to software projects and software life cycle processes that complicate
effective management, including these:
+<!-- FIXME: footnote -->
1 The terms Initiating, Planning, Executing, Monitoring and Controlling, and
Closing are used to describe process groups in the _PMBOK_ ® _Guide_ and _SWX_.
- 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
analyst and librarian). Adequate funding, training, tools, and support to
conduct the process should also be allocated.
+<!-- FIXME: footnote -->
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
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-
and iterated in various ways;
-
-Software Engineering Process 8-3
the software requirements process and its subprocesses may be entered and
exited multiple times during software development or modification.
<!-- [1*, p28–34] [3*, s26.5] [4*, p39–45] -->
-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 |
|-------:|:-----------------------------------------------|------------------------------------------|
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.
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
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:
