commit a96d3aa5e261a1b854391ddeb9c33fc4873bd36e from: Sergey Bronnikov date: Mon Jan 17 09:14:58 2022 UTC Fix formatting in Software Engineering Process Closes #9 commit - d80ae7612232a4c79cdf86300259959bc179a0e6 commit + a96d3aa5e261a1b854391ddeb9c33fc4873bd36e blob - 47f8ff28e24483f2458cb3bb3edafcbcff8b91dc blob + 59436ab30f0e31ac539ce9ad926bb180826ff77d --- 8_software_engineering_process.md +++ 8_software_engineering_process.md @@ -1,642 +1,457 @@ -**CHAPTER 8** +## Chapter 8: Software Engineering Process -**SOFTWARE ENGINEERING PROCESS** +**Acronyms** -##### ACRONYMS +- BPMN Business Process Modeling Notation +- CASE Computer-Assisted Software Engineering +- CM Configuration Management +- CMMI Capability Maturity Model Integration +- GQM Goal-Question-Metric +- IDEF0 Integration Definition +- LOE Level of Effort +- ODC Orthogonal Defect Classification +- SDLC Software Development Life Cycle +- SPLC Software Product Life Cycle +- UML Unified Modeling Language -BPMN Business Process Modeling Notation -CASE Computer-Assisted Software Engineering -CM Configuration Management -CMMI Capability Maturity Model Integration -GQM Goal-Question-Metric -IDEF0 Integration Definition -LOE Level of Effort -ODC Orthogonal Defect Classification -SDLC Software Development Life Cycle -SPLC Software Product Life Cycle -UML Unified Modeling Language +**Introduction** -##### INTRODUCTION +An engineering process consists of a set of interrelated activities that +transform one or more inputs into outputs while consuming resources to +accomplish the transformation. Many of the processes of traditional engineering +disciplines (e.g., electrical, mechanical, civil, chemical) are concerned with +transforming energy and physical entities from one form into another, as in a +hydroelectric dam that transforms potential energy into electrical energy or a +petroleum refinery that uses chemical processes to transform crude oil into +gasoline. In this knowledge area (KA), software engineering processes are +concerned with work activities accomplished by software engineers to develop, +maintain, and operate software, such as requirements, design, construction, +testing, configuration management, and other software engineering processes. +For readability, “software engineering process” will be referred to as +“software process” in this KA. In addition, please note that “software process” +denotes work activities - not the execution process for implemented software. +Software processes are specified for a number of reasons: to facilitate human +understanding, communication, and coordination; to aid management of software +projects; to measure and improve the quality of software products in an +efficient manner; to support process improvement; and to provide a basis for +automated support of process execution. -An engineering process consists of a set of inter- -related activities that transform one or more inputs -into outputs while consuming resources to accom- -plish the transformation. Many of the processes of -traditional engineering disciplines (e.g., electrical, -mechanical, civil, chemical) are concerned with -transforming energy and physical entities from -one form into another, as in a hydroelectric dam -that transforms potential energy into electrical -energy or a petroleum refinery that uses chemical -processes to transform crude oil into gasoline. -In this knowledge area (KA), software engineer- -ing processes are concerned with work activities -accomplished by software engineers to develop, -maintain, and operate software, such as require- -ments, design, construction, testing, configura- -tion management, and other software engineering -processes. For readability, “software engineering +SWEBOK KAs closely related to this Software Engineering Process KA include +Software Engineering Management, Software Engineering Models and Methods, and +Software Quality; the Measurement and Root Cause Analysis topic found in the +Engineering Foundations KA is also closely related. Software Engineering +Management is concerned with tailoring, adapting, and implementing software +processes for a specific software project (see Process Planning in the Software +Engineering Management KA). Models and methods support a systematic approach +to software development and modification. - -process” will be referred to as “software process” -in this KA. In addition, please note that “software -process” denotes work activities—not the execu- -tion process for implemented software. -Software processes are specified for a number -of reasons: to facilitate human understanding, -communication, and coordination; to aid man- -agement of software projects; to measure and -improve the quality of software products in an -efficient manner; to support process improve- -ment; and to provide a basis for automated sup- -port of process execution. -SWEBOK KAs closely related to this Soft- -ware Engineering Process KA include Software -Engineering Management, Software Engineer- -ing Models and Methods, and Software Quality; -the Measurement and Root Cause Analysis topic -found in the Engineering Foundations KA is also -closely related. Software Engineering Manage- -ment is concerned with tailoring, adapting, and -implementing software processes for a specific -software project (see Process Planning in the -Software Engineering Management KA). Mod- -els and methods support a systematic approach to -software development and modification. -The Software Quality KA is concerned with -the planning, assurance, and control processes -for project and product quality. Measurement and -measurement results in the Engineering Founda- -tions KA are essential for evaluating and control- +The Software Quality KA is concerned with the planning, assurance, and control +processes for project and product quality. Measurement and measurement results +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- +ment, software measurement, and software engineering process tools. +### 1. Software Process Definition -As illustrated in Figure 8.1, this KA is concerned -with software process definition, software life -cycles, software process assessment and improve- -ment, software measurement, and software engi- -neering process tools. + +This topic is concerned with a definition of software process, software +process management, and software process infrastructure. -**1. Software Process Definition** - [1*, p177] [2*, p295] [3*, p28–29, p36, c5] - -This topic is concerned with a definition of soft- -ware process, software process management, and -software process infrastructure. -As stated above, a software process is a set of -interrelated activities and tasks that transform -input work products into output work products. -At minimum, the description of a software pro- -cess includes required inputs, transforming work -activities, and outputs generated. As illustrated in -Figure 8.2, a software process may also include -its entry and exit criteria and decomposition -of the work activities into tasks, which are the -smallest units of work subject to management -accountability. A process input may be a trigger- -ing event or the output of another process. Entry -criteria should be satisfied before a process can -commence. All specified conditions should be -satisfied before a process can be successfully - - -concluded, including the acceptance criteria for +As stated above, a software process is a set of interrelated activities and +tasks that transform input work products into output work products. At minimum, +the description of a software process includes required inputs, transforming +work activities, and outputs generated. As illustrated in Figure 8.2, a +software process may also include its entry and exit criteria and decomposition +of the work activities into tasks, which are the smallest units of work subject +to management accountability. A process input may be a triggering event or +the output of another process. Entry criteria should be satisfied before a +process can commence. All specified conditions should be satisfied before a +process can be successfully concluded, including the acceptance criteria for the output work product or work products. -A software process may include subprocesses. -For example, software requirements validation is -a process used to determine whether the require- -ments will provide an adequate basis for software -development; it is a subprocess of the software -requirements process. Inputs for requirements val- -idation are typically a software requirements spec- -ification and the resources needed to perform vali- -dation (personnel, validation tools, sufficient time). -The tasks of the requirements validation activity -might include requirements reviews, prototyping, -and model validation. These tasks involve work -assignments for individuals and teams. The output -of requirements validation is typically a validated -software requirements specification that provides -inputs to the software design and software test- -ing processes. Requirements validation and other -subprocesses of the software requirements process -are often interleaved and iterated in various ways; +A software process may include subprocesses. For example, software requirements +validation is a process used to determine whether the requirements will +provide an adequate basis for software development; it is a subprocess of the +software requirements process. Inputs for requirements validation are +typically a software requirements specification and the resources needed to +perform validation (personnel, validation tools, sufficient time). The tasks +of the requirements validation activity might include requirements reviews, +prototyping, and model validation. These tasks involve work assignments for +individuals and teams. The output of requirements validation is typically a +validated software requirements specification that provides inputs to the +software design and software testing processes. Requirements validation and +other subprocesses of the software requirements process are often interleaved +and iterated in various ways; -Figure 8.1. Breakdown of Topics for the Software Engineering Process KA +![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. -Software Engineering Process 8-3 +Complete definition of a software process may also include the roles and +competencies, IT support, software engineering techniques and tools, and work +environment needed to perform the process, as well as the approaches and +measures (Key Performance Indicators) used to determine the efficiency and +effectiveness of performing the process. -the software requirements process and its subpro- -cesses may be entered and exited multiple times -during software development or modification. -Complete definition of a software process may -also include the roles and competencies, IT sup- -port, software engineering techniques and tools, -and work environment needed to perform the -process, as well as the approaches and measures -(Key Performance Indicators) used to determine -the efficiency and effectiveness of performing the -process. -In addition, a software process may include -interleaved technical, collaborative, and adminis- -trative activities. -Notations for defining software processes -include textual lists of constituent activities and -tasks described in natural language; data-flow -diagrams; state charts; BPMN; IDEF0; Petri nets; -and UML activity diagrams. The transforming -tasks within a process may be defined as proce- -dures; a procedure may be specified as an ordered -set of steps or, alternatively, as a checklist of the +In addition, a software process may include interleaved technical, +collaborative, and administrative activities. + +Notations for defining software processes include textual lists of constituent +activities and tasks described in natural language; data-flow diagrams; state +charts; BPMN; IDEF0; Petri nets; and UML activity diagrams. The transforming +tasks within a process may be defined as procedures; a procedure may be +specified as an ordered set of steps or, alternatively, as a checklist of the work to be accomplished in performing a task. -It must be emphasized that there is no best soft- -ware process or set of software processes. Soft- -ware processes must be selected, adapted, and -applied as appropriate for each project and each -organizational context. No ideal process, or set of -processes, exists. -_1.1. Software Process Management_ -[3*, s26.1] [4*, p453–454] +It must be emphasized that there is no best software process or set of +software processes. Software processes must be selected, adapted, and applied +as appropriate for each project and each organizational context. No ideal +process, or set of processes, exists. -Two objectives of software process management -are to realize the efficiency and effectiveness that +#### 1.1. Software Process Management + -result from a systematic approach to accomplish- -ing software processes and producing work prod- -ucts—be it at the individual, project, or organiza- -tional level—and to introduce new or improved -processes. -Processes are changed with the expectation that -a new or modified process will improve the effi- -ciency and/or effectiveness of the process and the -quality of the resulting work products. Changing -to a new process, improving an existing process, -organizational change, and infrastructure change -(technology insertion or changes in tools) are -closely related, as all are usually initiated with the -goal of improving the cost, development sched- -ule, or quality of the software products. Process -change has impacts not only for the software -product; they often lead to organizational change. -Changing a process or introducing a new process -can have ripple effects throughout an organiza- -tion. For example, changes in IT infrastruc- -ture tools and technology often require process +Two objectives of software process management are to realize the efficiency and +effectiveness that result from a systematic approach to accomplishing +software processes and producing work products - be it at the individual, +project, or organizational level - and to introduce new or improved processes. + +Processes are changed with the expectation that a new or modified process will +improve the efficiency and/or effectiveness of the process and the quality of +the resulting work products. Changing to a new process, improving an existing +process, organizational change, and infrastructure change (technology insertion +or changes in tools) are closely related, as all are usually initiated with the +goal of improving the cost, development schedule, or quality of the software +products. Process change has impacts not only for the software product; they +often lead to organizational change. Changing a process or introducing a new +process can have ripple effects throughout an organization. For example, +changes in IT infrastructure tools and technology often require process changes. -Existing processes may be modified when -other new processes are deployed for the first -time (for example, introducing an inspection -activity within a software development project -will likely impact the software testing process— -see Reviews and Audits in the Software Quality -KA and in the Software Testing KA). These situ- -ations can also be termed “process evolution.” -If the modifications are extensive, then changes -in the organizational culture and business model -will likely be necessary to accommodate the pro- -cess changes. +Existing processes may be modified when other new processes are deployed for +the first time (for example, introducing an inspection activity within a +software development project will likely impact the software testing process - +see Reviews and Audits in the Software Quality KA and in the Software Testing +KA). These situations can also be termed “process evolution.” If the +modifications are extensive, then changes in the organizational culture and +business model will likely be necessary to accommodate the process changes. -Figure 8.2. Elements of a Software Process +![Figure 8.2. Elements of a Software Process](images/Figure-8.2.png) +#### 1.2. Software Process Infrastructure -_1.2. Software Process Infrastructure_ -[2*, p183, p186] [4*, p437–438] + -Establishing, implementing, and managing soft- -ware processes and software life cycle models -often occurs at the level of individual software -projects. However, systematic application of -software processes and software life cycle mod- -els across an organization can provide benefits -to all software work within the organization, -although it requires commitment at the organi- -zational level. A software process infrastructure -can provide process definitions, policies for inter- -preting and applying the processes, and descrip- -tions of the procedures to be used to implement -the processes. Additionally, a software process -infrastructure may provide funding, tools, train- -ing, and staff members who have been assigned -responsibilities for establishing and maintaining -the software process infrastructure. -Software process infrastructure varies, depend- -ing on the size and complexity of the organization -and the projects undertaken within the organiza- -tion. Small, simple organizations and projects -have small, simple infrastructure needs. Large, -complex organizations and projects, by neces- -sity, have larger and more complex software -process infrastructures. In the latter case, various -organizational units may be established (such as -a software engineering process group or a steer- -ing committee) to oversee implementation and -improvement of the software processes. -A common misperception is that establishing a -software process infrastructure and implementing -repeatable software processes will add time and -cost to software development and maintenance. -There is a cost associated with introducing or -improving a software process; however, experi- -ence has shown that implementing systematic -improvement of software processes tends to result -in lower cost through improved efficiency, avoid- -ance of rework, and more reliable and affordable -software. Process performance thus influences -software product quality. +Establishing, implementing, and managing software processes and software life +cycle models often occurs at the level of individual software projects. +However, systematic application of software processes and software life cycle +models across an organization can provide benefits to all software work +within the organization, although it requires commitment at the organi- +zational level. A software process infrastructure can provide process +definitions, policies for interpreting and applying the processes, and +descriptions of the procedures to be used to implement the processes. +Additionally, a software process infrastructure may provide funding, tools, +training, and staff members who have been assigned responsibilities for +establishing and maintaining the software process infrastructure. -**2. Software Life Cycles** - [1*, c2] [2*, p190] +Software process infrastructure varies, depending on the size and complexity +of the organization and the projects undertaken within the organization. +Small, simple organizations and projects have small, simple infrastructure +needs. Large, complex organizations and projects, by necessity, have larger +and more complex software process infrastructures. In the latter case, various +organizational units may be established (such as a software engineering process +group or a steering committee) to oversee implementation and improvement of +the software processes. -This topic addresses categories of software pro- -cesses, software life cycle models, software +A common misperception is that establishing a software process infrastructure +and implementing repeatable software processes will add time and cost to +software development and maintenance. There is a cost associated with +introducing or improving a software process; however, experience has shown +that implementing systematic improvement of software processes tends to result +in lower cost through improved efficiency, avoidance of rework, and more +reliable and affordable software. Process performance thus influences software +product quality. +### 2. Software Life Cycles -process adaptation, and practical considerations. -A software development life cycle (SDLC) -includes the software processes used to specify -and transform software requirements into a deliv- -erable software product. A software product life -cycle (SPLC) includes a software development -life cycle plus additional software processes that -provide for deployment, maintenance, support, -evolution, retirement, and all other inception- -to-retirement processes for a software product, -including the software configuration management -and software quality assurance processes that are -applied throughout a software product life cycle. -A software product life cycle may include multi- -ple software development life cycles for evolving -and enhancing the software. -Individual software processes have no tempo- -ral ordering among them. The temporal relation- -ships among software processes are provided by -a software life cycle model: either an SDLC or -SPLC. Life cycle models typically emphasize -the key software processes within the model -and their temporal and logical interdependen- -cies and relationships. Detailed definitions of -the software processes in a life cycle model may -be provided directly or by reference to other -documents. -In addition to conveying the temporal and -logical relationships among software processes, -the software development life cycle model (or -models used within an organization) includes the -control mechanisms for applying entry and exit -criteria (e.g., project reviews, customer approv- -als, software testing, quality thresholds, dem- -onstrations, team consensus). The output of one -software process often provides the input for oth- -ers (e.g., software requirements provide input for -a software architectural design process and the -software construction and software testing pro- -cesses). Concurrent execution of several software -process activities may produce a shared output -(e.g., the interface specifications for interfaces -among multiple software components developed -by different teams). Some software processes -may be regarded as less effective unless other -software processes are being performed at the -same time (e.g., software test planning during -software requirements analysis can improve the -software requirements). + +This topic addresses categories of software processes, software life cycle +models, software process adaptation, and practical considerations. A software +development life cycle (SDLC) includes the software processes used to specify +and transform software requirements into a deliverable software product. A +software product life cycle (SPLC) includes a software development life cycle +plus additional software processes that provide for deployment, maintenance, +support, evolution, retirement, and all other inception-to-retirement +processes for a software product, including the software configuration +management and software quality assurance processes that are applied throughout +a software product life cycle. A software product life cycle may include multi- +ple software development life cycles for evolving and enhancing the software. +Individual software processes have no temporal ordering among them. The +temporal relationships among software processes are provided by a software +life cycle model: either an SDLC or SPLC. Life cycle models typically emphasize +the key software processes within the model and their temporal and logical +interdependencies and relationships. Detailed definitions of the software +processes in a life cycle model may be provided directly or by reference to +other documents. -Software Engineering Process 8-5 +In addition to conveying the temporal and logical relationships among software +processes, the software development life cycle model (or models used within an +organization) includes the control mechanisms for applying entry and exit +criteria (e.g., project reviews, customer approvals, software testing, +quality thresholds, demonstrations, team consensus). The output of one +software process often provides the input for others (e.g., software +requirements provide input for a software architectural design process and the +software construction and software testing processes). Concurrent execution +of several software process activities may produce a shared output (e.g., the +interface specifications for interfaces among multiple software components +developed by different teams). Some software processes may be regarded as less +effective unless other software processes are being performed at the same time +(e.g., software test planning during software requirements analysis can improve +the software requirements). -_2.1. Categories of Software Processes_ -[1*, Preface] [2* , p294–295] [3*, c22–c24] +#### 2.1. Categories of Software Processes -Many distinct software processes have been -defined for use in the various parts of the soft- -ware development and software maintenance life -cycles. These processes can be categorized as -follows: + -1. _Primary processes_ include software pro- - cesses for development, operation, and - maintenance of software. -2. _Supporting processes_ are applied intermit- - tently or continuously throughout a software - product life cycle to support primary pro- - cesses; they include software processes such - as configuration management, quality assur- - ance, and verification and validation. -3. _Organizational processes_ provide sup- - port for software engineering; they include - training, process measurement analysis, - infrastructure management, portfolio and - reuse management, organizational process - improvement, and management of software - life cycle models. -4. _Cross-project processes,_ such as reuse, soft- - ware product line, and domain engineering; - they involve more than a single software - project in an organization. +Many distinct software processes have been defined for use in the various parts +of the software development and software maintenance life cycles. These +processes can be categorized as follows: -Software processes in addition to those listed -above include the following. -Project management processes include pro- -cesses for planning and estimating, resource -management, measuring and controlling, leading, -managing risk, managing stakeholders, and coor- -dinating the primary, supporting, organizational, -and cross-project processes of software develop- -ment and maintenance projects. -Software processes are also developed for -particular needs, such as process activities that -address software quality characteristics (see -the Software Quality KA). For example, secu- -rity concerns during software development may -necessitate one or more software processes to -protect the security of the development environ- -ment and reduce the risk of malicious acts. Soft- -ware processes may also be developed to provide -adequate grounds for establishing confidence in -the integrity of the software. +1. _Primary processes_ include software processes for development, operation, + and maintenance of software. +2. _Supporting processes_ are applied intermittently or continuously + throughout a software product life cycle to support primary processes; + they include software processes such as configuration management, quality + assurance, and verification and validation. +3. _Organizational processes_ provide support for software engineering; they + include training, process measurement analysis, infrastructure management, + portfolio and reuse management, organizational process improvement, and + management of software life cycle models. +4. _Cross-project processes,_ such as reuse, software product line, and + domain engineering; they involve more than a single software project in an + organization. +Software processes in addition to those listed above include the following. -2.2. Software Life Cycle Models -[1*, c2] [2*, s3.2] [3*, s2.1] [5] +Project management processes include processes for planning and estimating, +resource management, measuring and controlling, leading, managing risk, +managing stakeholders, and coordinating the primary, supporting, +organizational, and cross-project processes of software development and +maintenance projects. +Software processes are also developed for particular needs, such as process +activities that address software quality characteristics (see the Software +Quality KA). For example, security concerns during software development may +necessitate one or more software processes to protect the security of the +development environment and reduce the risk of malicious acts. Software +processes may also be developed to provide adequate grounds for establishing +confidence in the integrity of the software. -The intangible and malleable nature of software -permits a wide variety of software development -life cycle models, ranging from linear models in -which the phases of software development are -accomplished sequentially with feedback and -iteration as needed followed by integration, test- -ing, and delivery of a single product; to iterative -models in which software is developed in incre- -ments of increasing functionality on iterative -cycles; to agile models that typically involve -frequent demonstrations of working software to -a customer or user representative who directs -development of the software in short iterative -cycles that produce small increments of working, -deliverable software. Incremental, iterative, and -agile models can deliver early subsets of working +#### 2.2. Software Life Cycle Models + + + +The intangible and malleable nature of software permits a wide variety of +software development life cycle models, ranging from linear models in which the +phases of software development are accomplished sequentially with feedback and +iteration as needed followed by integration, testing, and delivery of a +single product; to iterative models in which software is developed in incre- +ments of increasing functionality on iterative cycles; to agile models that +typically involve frequent demonstrations of working software to a customer or +user representative who directs development of the software in short iterative +cycles that produce small increments of working, deliverable software. +Incremental, iterative, and agile models can deliver early subsets of working software into the user environment, if desired. -Linear SDLC models are sometimes referred -to as predictive software development life cycle -models, while iterative and agile SDLCs are -referred to as adaptive software development -life cycle models. It should be noted that vari- -ous maintenance activities during an SPLC can -be conducted using different SDLC models, as -appropriate to the maintenance activities. -A distinguishing feature of the various soft- -ware development life cycle models is the way in -which software requirements are managed. Lin- -ear development models typically develop a com- -plete set of software requirements, to the extent -possible, during project initiation and planning. -The software requirements are then rigorously -controlled. Changes to the software requirements -are based on change requests that are processed -by a change control board (see Requesting, -Evaluating and Approving Software Changes in -the Change Control Board in the Software Con- -figuration Management KA). An incremental -model produces successive increments of work- -ing, deliverable software based on partitioning -of the software requirements to be implemented -in each of the increments. The software require- -ments may be rigorously controlled, as in a linear -model, or there may be some flexibility in revising -the software requirements as the software product -evolves. Agile models may define product scope -and high-level features initially; however, agile -models are designed to facilitate evolution of the -software requirements during the project. -It must be emphasized that the continuum of -SDLCs from linear to agile is not a thin, straight -line. Elements of different approaches may be -incorporated into a specific model; for exam- -ple, an incremental software development life -cycle model may incorporate sequential soft- -ware requirements and design phases but permit -considerable flexibility in revising the software -requirements and architecture during software -construction. -_2.3. Software Process Adaptation_ -[1*, s2.7] [2*, p51] +Linear SDLC models are sometimes referred to as predictive software development +life cycle models, while iterative and agile SDLCs are referred to as adaptive +software development life cycle models. It should be noted that various +maintenance activities during an SPLC can be conducted using different SDLC +models, as appropriate to the maintenance activities. -Predefined SDLCs, SPLCs, and individual soft- -ware processes often need to be adapted (or -“tailored”) to better serve local needs. Organiza- -tional context, innovations in technology, project -size, product criticality, regulatory requirements, -industry practices, and corporate culture may -determine needed adaptations. Adaptation of -individual software processes and software life -cycle models (development and product) may -consist of adding more details to software pro- -cesses, activities, tasks, and procedures to address -critical concerns. It may consist of using an alter- -nate set of activities that achieves the purpose and -outcomes of the software process. Adaptation -may also include omitting software processes -or activities from a development or product life -cycle model that are clearly inapplicable to the -scope of work to be accomplished. +A distinguishing feature of the various software development life cycle +models is the way in which software requirements are managed. Linear +development models typically develop a complete set of software requirements, +to the extent possible, during project initiation and planning. The software +requirements are then rigorously controlled. Changes to the software +requirements are based on change requests that are processed by a change +control board (see Requesting, Evaluating and Approving Software Changes in the +Change Control Board in the Software Configuration Management KA). An +incremental model produces successive increments of working, deliverable +software based on partitioning of the software requirements to be implemented +in each of the increments. The software requirements may be rigorously +controlled, as in a linear model, or there may be some flexibility in revising +the software requirements as the software product evolves. Agile models may +define product scope and high-level features initially; however, agile models +are designed to facilitate evolution of the software requirements during the +project. -_2.4. Practical Considerations_ -[2*, p188–190] +It must be emphasized that the continuum of SDLCs from linear to agile is not a +thin, straight line. Elements of different approaches may be incorporated into +a specific model; for example, an incremental software development life cycle +model may incorporate sequential software requirements and design phases but +permit considerable flexibility in revising the software requirements and +architecture during software construction. -In practice, software processes and activities are -often interleaved, overlapped, and applied concur- -rently. Software life cycle models that specify dis- -crete software processes, with rigorously specified -entry and exit criteria and prescribed boundaries -and interfaces, should be recognized as idealiza- -tions that must be adapted to reflect the realities of -software development and maintenance within the -organizational context and business environment. -Another practical consideration: software -processes (such as configuration management, +#### 2.3. Software Process Adaptation + -construction, and testing) can be adapted to facili- -tate operation, support, maintenance, migration, -and retirement of the software. -Additional factors to be considered when -defining and tailoring a software life cycle model -include required conformance to standards, direc- -tives, and policies; customer demands; criticality -of the software product; and organizational matu- -rity and competencies. Other factors include the -nature of the work (e.g., modification of exist- -ing software versus new development) and the -application domain (e.g., aerospace versus hotel -management). +Predefined SDLCs, SPLCs, and individual software processes often need to be +adapted (or “tailored”) to better serve local needs. Organizational context, +innovations in technology, project size, product criticality, regulatory +requirements, industry practices, and corporate culture may determine needed +adaptations. Adaptation of individual software processes and software life +cycle models (development and product) may consist of adding more details to +software processes, activities, tasks, and procedures to address critical +concerns. It may consist of using an alternate set of activities that +achieves the purpose and outcomes of the software process. Adaptation may also +include omitting software processes or activities from a development or product +life cycle model that are clearly inapplicable to the scope of work to be +accomplished. -**3. Software Process Assessment and -Improvement** - [2*, p188, p194] [3*, c26] [4*, p397, c15] +#### 2.4. Practical Considerations + -This topic addresses software process assess- -ment models, software process assessment meth- -ods, software process improvement models, and -continuous and staged process ratings. Software -process assessments are used to evaluate the form -and content of a software process, which may -be specified by a standardized set of criteria. In -some instances, the terms “process appraisal” -and “capability evaluation” are used instead of -process assessment. Capability evaluations are -typically performed by an acquirer (or potential -acquirer) or by an external agent on behalf of -an acquirer (or potential acquirer). The results -are used as an indicator of whether the software -processes used by a supplier (or potential sup- -plier) are acceptable to the acquirer. Performance -appraisals are typically performed within an orga- -nization to identify software processes in need of -improvement or to determine whether a process -(or processes) satisfies the criteria at a given level -of process capability or maturity. -Process assessments are performed at the lev- -els of entire organizations, organizational units -within organizations, and individual projects. -Assessment may involve issues such as assess- -ing whether software process entry and exit cri- -teria are being met, to review risk factors and -risk management, or to identify lessons learned. -Process assessment is carried out using both an -assessment model and an assessment method. The -model can provide a norm for a benchmarking +In practice, software processes and activities are often interleaved, +overlapped, and applied concurrently. Software life cycle models that specify +discrete software processes, with rigorously specified entry and exit +criteria and prescribed boundaries and interfaces, should be recognized as +idealizations that must be adapted to reflect the realities of software +development and maintenance within the organizational context and business +environment. Another practical consideration: software processes (such as +configuration management, construction, and testing) can be adapted to facili- +tate operation, support, maintenance, migration, and retirement of the +software. +Additional factors to be considered when defining and tailoring a software life +cycle model include required conformance to standards, directives, and +policies; customer demands; criticality of the software product; and +organizational maturity and competencies. Other factors include the nature of +the work (e.g., modification of existing software versus new development) and +the application domain (e.g., aerospace versus hotel management). +### 3. Software Process Assessment and Improvement -Software Engineering Process 8-7 + -comparison among projects within an organiza- -tion and among organizations. -A process audit differs from a process assess- -ment. Assessments are performed to determine -levels of capability or maturity and to identify -software processes to be improved. Audits are -typically conducted to ascertain compliance with -policies and standards. Audits provide manage- -ment visibility into the actual operations being -performed in the organization so that accurate -and meaningful decisions can be made concern- -ing issues that are impacting a development proj- -ect, a maintenance activity, or a software-related -topic. -Success factors for software process assess- -ment and improvement within software engineer- -ing organizations include management sponsor- -ship, planning, training, experienced and capable -leaders, team commitment, expectation manage- -ment, the use of change agents, plus pilot projects -and experimentation with tools. Additional fac- -tors include independence of the assessor and the -timeliness of the assessment. +This topic addresses software process assessment models, software process +assessment methods, software process improvement models, and continuous and +staged process ratings. Software process assessments are used to evaluate the +form and content of a software process, which may be specified by a +standardized set of criteria. In some instances, the terms “process appraisal” +and “capability evaluation” are used instead of process assessment. Capability +evaluations are typically performed by an acquirer (or potential acquirer) or +by an external agent on behalf of an acquirer (or potential acquirer). The +results are used as an indicator of whether the software processes used by a +supplier (or potential supplier) are acceptable to the acquirer. Performance +appraisals are typically performed within an organization to identify +software processes in need of improvement or to determine whether a process (or +processes) satisfies the criteria at a given level of process capability or +maturity. -_3.1. Software Process Assessment Models_ -[2*, s4.5, s4.6] [3*, s26.5] [4*, p44–48] +Process assessments are performed at the levels of entire organizations, +organizational units within organizations, and individual projects. Assessment +may involve issues such as assessing whether software process entry and exit +criteria are being met, to review risk factors and risk management, or to +identify lessons learned. Process assessment is carried out using both an +assessment model and an assessment method. The model can provide a norm for a +benchmarking comparison among projects within an organization and among +organizations. -Software process assessment models typically -include assessment criteria for software processes -that are regarded as constituting good practices. -These practices may address software develop- -ment processes only, or they may also include -topics such as software maintenance, software -project management, systems engineering, or -human resources management. +A process audit differs from a process assessment. Assessments are performed +to determine levels of capability or maturity and to identify software +processes to be improved. Audits are typically conducted to ascertain +compliance with policies and standards. Audits provide management visibility +into the actual operations being performed in the organization so that accurate +and meaningful decisions can be made concerning issues that are impacting a +development project, a maintenance activity, or a software-related topic. -_3.2. Software Process Assessment Methods_ -[1*, p322–331] [3*, s26.3] -[4*, p44–48, s16.4] [6] +Success factors for software process assessment and improvement within +software engineering organizations include management sponsorship, +planning, training, experienced and capable leaders, team commitment, +expectation management, the use of change agents, plus pilot projects and +experimentation with tools. Additional factors include independence of the +assessor and the timeliness of the assessment. -A software process assessment method can be -qualitative or quantitative. Qualitative assess- -ments rely on the judgment of experts; quanti- -tative assessments assign numerical scores to -software processes based on analysis of objective -evidence that indicates attainment of the goals -and outcomes of a defined software process. For -example, a quantitative assessment of the soft- -ware inspection process might be performed by +#### 3.1. Software Process Assessment Models + -examining the procedural steps followed and -results obtained plus data concerning defects -found and time required to find and fix the defects -as compared to software testing. -A typical method of software process assess- -ment includes planning, fact-finding (by collect- -ing evidence through questionnaires, interviews, -and observation of work practices), collection -and validation of process data, and analysis and -reporting. Process assessments may rely on the -subjective, qualitative judgment of the assessor, -or on the objective presence or absence of defined -artifacts, records, and other evidence. -The activities performed during a software pro- -cess assessment and the distribution of effort for -assessment activities are different depending on -the purpose of the software process assessment. -Software process assessments may be undertaken -to develop capability ratings used to make recom- -mendations for process improvements or may be -undertaken to obtain a process maturity rating in -order to qualify for a contract or award. -The quality of assessment results depends on -the software process assessment method, the -integrity and quality of the obtained data, the -assessment team’s capability and objectivity, and -the evidence examined during the assessment. -The goal of a software process assessment is to -gain insight that will establish the current status -of a process or processes and provide a basis for -process improvement; performing a software -process assessment by following a checklist for -conformance without gaining insight adds little -value. +Software process assessment models typically include assessment criteria for +software processes that are regarded as constituting good practices. These +practices may address software development processes only, or they may also +include topics such as software maintenance, software project management, +systems engineering, or human resources management. +#### 3.2. Software Process Assessment Methods -3.3. Software Process Improvement Models -[2*, p187–188] [3*, s26.5] [4*, s2.7] + +A software process assessment method can be qualitative or quantitative. +Qualitative assessments rely on the judgment of experts; quantitative +assessments assign numerical scores to software processes based on analysis of +objective evidence that indicates attainment of the goals and outcomes of a +defined software process. For example, a quantitative assessment of the soft- +ware inspection process might be performed by examining the procedural steps +followed and results obtained plus data concerning defects found and time +required to find and fix the defects as compared to software testing. -Software process improvement models empha- -size iterative cycles of continuous improvement. -A software process improvement cycle typically -involves the subprocesses of measuring, ana- -lyzing, and changing. The Plan-Do-Check-Act -model is a well-known iterative approach to -software process improvement. Improvement -activities include identifying and prioritizing -desired improvements (planning); introducing -an improvement, including change management -and training (doing); evaluating the improvement as compared to previous or exemplary process -results and costs (checking); and making further -modifications (acting). The Plan-Do-Check-Act -process improvement model can be applied, for -example, to improve software processes that -enhance defect prevention. +A typical method of software process assessment includes planning, +fact-finding (by collecting evidence through questionnaires, interviews, and +observation of work practices), collection and validation of process data, and +analysis and reporting. Process assessments may rely on the subjective, +qualitative judgment of the assessor, or on the objective presence or absence +of defined artifacts, records, and other evidence. -_3.4. Continuous and Staged Software Process -Ratings_ -[1*, p28–34] [3*, s26.5] [4*, p39–45] +The activities performed during a software process assessment and the +distribution of effort for assessment activities are different depending on the +purpose of the software process assessment. Software process assessments may be +undertaken to develop capability ratings used to make recommendations for +process improvements or may be undertaken to obtain a process maturity rating +in order to qualify for a contract or award. +The quality of assessment results depends on the software process assessment +method, the integrity and quality of the obtained data, the assessment team’s +capability and objectivity, and the evidence examined during the assessment. +The goal of a software process assessment is to gain insight that will +establish the current status of a process or processes and provide a basis for +process improvement; performing a software process assessment by following a +checklist for conformance without gaining insight adds little value. + +#### 3.3. Software Process Improvement Models + + + +Software process improvement models emphasize iterative cycles of continuous +improvement. A software process improvement cycle typically involves the +subprocesses of measuring, analyzing, and changing. The Plan-Do-Check-Act +model is a well-known iterative approach to software process improvement. +Improvement activities include identifying and prioritizing desired +improvements (planning); introducing an improvement, including change +management and training (doing); evaluating the improvement as compared to +previous or exemplary process results and costs (checking); and making further +modifications (acting). The Plan-Do-Check-Act process improvement model can be +applied, for example, to improve software processes that enhance defect +prevention. + +#### 3.4. Continuous and Staged Software Process Ratings + + + Software process capability and software process maturity are typically rated using five or six levels to characterize the capability or maturity of the @@ -651,657 +466,418 @@ els is provided in Table 8.1. Continuous models typically use a level 0 rating; staged models typi- cally do not. +| Level | Continuous Representation of Capability Levels | Staged Representation of Maturity Levels | +|-------:|:-----------------------------------------------|------------------------------------------| +| 0 | Incomplete | | +| 1 | Performed | Initial | +| 2 | Managed | Managed | +| 3 | Defined | Defined | +| 4 | | Quantitatively Managed | +| 5 | | Optimizing | Table 8.1. Software Process Rating Levels +In Table 8.1, level 0 indicates that a software process is incompletely +performed or may not be performed. At level 1, a software process is being +performed (capability rating), or the software processes in a maturity level 1 +group are being performed but on an ad hoc, informal basis. At level 2, a +software process (capability rating) or the processes in maturity level 2 are +being performed in a manner that provides management visibility into +intermediate work products and can exert some control over transitions between +processes. At level 3, a single software process or the processes in a maturity +level 3 group plus the process or processes in maturity level 2 are well +defined (perhaps in organizational policies and procedures) and are being +repeated across different projects. Level 3 of process capability or maturity +provides the basis for process improvement across an organization because the +process is (or processes are) conducted in a similar manner. This allows +collection of performance data in a uniform manner across multiple projects. At +maturity level 4, quantitative measures can be applied and used for process +assessment; statistical analysis may be used. At maturity level 5, the +mechanisms for continuous process improvements are applied. -Level +Continuous and staged representations can be used to determine the order in +which software processes are to be improved. In the continuous representation, +the different capability levels for different software processes provide a +guideline for determining the order in which software processes will be +improved. In the staged representation, satisfying the goals of a set of +software processes within a maturity level is accomplished for that maturity +level, which provides a foundation for improving all of the software processes +at the next higher level. +### 4. Software Measurement -Continuous -Representation -of Capability -Levels + +This topic addresses software process and product measurement, quality of +measurement results, software information models, and software process +measurement techniques (see Measurement in the Engineering Foundations KA). -Staged -Representation -of Maturity -Levels -0 Incomplete -1 Performed Initial -2 Managed Managed -3 Defined Defined +Before a new process is implemented or a current process is modified, +measurement results for the current situation should be obtained to provide a +baseline for comparison between the current situation and the new situation. +For example, before introducing the software inspection process, effort +required to fix defects discovered by testing should be measured. Following an +initial start-up period after the inspection process is introduced, the +combined effort of inspection plus testing can be compared to the previous +amount of effort required for testing alone. Similar considerations apply if +a process is changed. +#### 4.1. Software Process and Product Measurement -4 -Quantitatively -Managed -5 Optimizing + -In Table 8.1, level 0 indicates that a software -process is incompletely performed or may not be -performed. At level 1, a software process is being -performed (capability rating), or the software -processes in a maturity level 1 group are being -performed but on an ad hoc, informal basis. At -level 2, a software process (capability rating) or -the processes in maturity level 2 are being per- -formed in a manner that provides management +Software process and product measurement are concerned with determining the +efficiency and effectiveness of a software process, activity, or task. The +_efficiency_ of a software process, activity, or task is the ratio of resources +actually consumed to resources expected or desired to be consumed in +accomplishing a software process, activity, or task (see Efficiency in the +Software Engineering Economics KA). Effort (or equivalent cost) is the primary +measure of resources for most software processes, activities, and tasks; it is +measured in units such as person-hours, person-days, staff-weeks, or +staff-months of effort or in equivalent monetary units - such as euros or +dollars. +_Effectiveness_ is the ratio of actual output to expected output produced by a +software process, activity, or task; for example, actual number of defects +detected and corrected during software testing to expected number of defects to +be detected and corrected - perhaps based on historical data for similar +projects (see Effectiveness in the Software Engineering Economics KA). Note +that measurement of software process effectiveness requires measurement of +the relevant product attributes; for example, measurement of software defects +discovered and corrected during software testing. -visibility into intermediate work products and -can exert some control over transitions between -processes. At level 3, a single software process or -the processes in a maturity level 3 group plus the -process or processes in maturity level 2 are well -defined (perhaps in organizational policies and -procedures) and are being repeated across dif- -ferent projects. Level 3 of process capability or -maturity provides the basis for process improve- -ment across an organization because the process -is (or processes are) conducted in a similar man- -ner. This allows collection of performance data -in a uniform manner across multiple projects. At -maturity level 4, quantitative measures can be -applied and used for process assessment; statis- -tical analysis may be used. At maturity level 5, -the mechanisms for continuous process improve- -ments are applied. -Continuous and staged representations can be -used to determine the order in which software -processes are to be improved. In the continuous -representation, the different capability levels for -different software processes provide a guideline -for determining the order in which software pro- -cesses will be improved. In the staged representa- -tion, satisfying the goals of a set of software pro- -cesses within a maturity level is accomplished for -that maturity level, which provides a foundation -for improving all of the software processes at the -next higher level. +One must take care when measuring product attributes for the purpose of +determining process effectiveness. For example, the number of defects detected +and corrected by testing may not achieve the expected number of defects and +thus provide a misleadingly low effectiveness measure, either because the +software being tested is of better-than-usual quality or perhaps because +introduction of a newly introduced upstream inspection process has reduced +the remaining number of defects in the software. -**4. Software Measurement** - [3*, s26.2] [4*, s18.1.1] +Product measures that may be important in determining the effectiveness of +software processes include product complexity, total defects, defect density, +and the quality of requirements, design documentation, and other related work +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 +software defects could be very high and result in low efficiency, as compared +to expectations. -This topic addresses software process and prod- -uct measurement, quality of measurement results, -software information models, and software pro- -cess measurement techniques (see Measurement -in the Engineering Foundations KA). -Before a new process is implemented or a cur- -rent process is modified, measurement results for -the current situation should be obtained to pro- -vide a baseline for comparison between the cur- -rent situation and the new situation. For exam- -ple, before introducing the software inspection -process, effort required to fix defects discovered -by testing should be measured. Following an ini- -tial start-up period after the inspection process -is introduced, the combined effort of inspection +An efficient process can be ineffective in accomplishing the desired +transformation of input work products into output work products; for example, +failure to find and correct a sufficient number of software defects during the +testing process. +Causes of low efficiency and/or low effectiveness in the way a software +process, activity, or task is executed might include one or more of the +following problems: deficient input work products, inexperienced personnel, +lack of adequate tools and infrastructure, learning a new process, a complex +product, or an unfamiliar product domain. The efficiency and effectiveness of +software process execution are also affected (either positively or +negatively) by factors such as turnover in software personnel, schedule +changes, a new customer representative, or a new organizational policy. +In software engineering, productivity in performing a process, activity, or +task is the ratio of output produced divided by resources consumed; for +example, the number of software defects discovered and corrected divided by +person-hours of effort (see Productivity in the Software Engineering +Economics KA). Accurate measurement of productivity must include total effort +used to satisfy the exit criteria of a software process, activity, or task; +for example, the effort required to correct defects discovered during software +testing must be included in software development productivity. -Software Engineering Process 8-9 +Calculation of productivity must account for the context in which the work is +accomplished. For example, the effort to correct discovered defects will be +included in the productivity calculation of a software team if team members +correct the defects they find—as in unit testing by software developers or in a +cross-functional agile team. Or the productivity calculation may include either +the effort of the software developers or the effort of an independent testing +team, depending on who fixes the defects found by the independent testers. Note +that this example refers to the effort of teams of developers or teams of +testers and not to individuals. Software productivity calculated at the level +of individuals can be misleading because of the many factors that can affect +the individual productivity of software engineers. -plus testing can be compared to the previous -amount of effort required for testing alone. Simi- -lar considerations apply if a process is changed. +Standardized definitions and counting rules for measurement of software +processes and work products are necessary to provide standardized measurement +results across projects within an organization, to populate a repository of +historical data that can be analyzed to identify software processes that need +to be improved, and to build predictive models based on accumulated data. In +the example above, definitions of software defects and staff-hours of testing +effort plus counting rules for defects and effort would be necessary to obtain +satisfactory measurement results. -_4.1. Software Process and Product Measurement_ -[1*, s6.3, p273] [3*, s26.2, p638] +The extent to which the software process is institutionalized is important; +failure to institutionalize a software process may explain why “good” +software processes do not always produce anticipated results. Software +processes may be institutionalized by adoption within the local organizational +unit or across larger units of an enterprise. -Software process and product measurement are -concerned with determining the efficiency and -effectiveness of a software process, activity, or -task. The _efficiency_ of a software process, activity, -or task is the ratio of resources actually consumed -to resources expected or desired to be consumed -in accomplishing a software process, activity, or -task (see Efficiency in the Software Engineering -Economics KA). Effort (or equivalent cost) is the -primary measure of resources for most software -processes, activities, and tasks; it is measured in -units such as person-hours, person-days, staff- -weeks, or staff-months of effort or in equivalent -monetary units—such as euros or dollars. -_Effectiveness_ is the ratio of actual output to -expected output produced by a software process, -activity, or task; for example, actual number of -defects detected and corrected during software -testing to expected number of defects to be -detected and corrected—perhaps based on his- -torical data for similar projects (see Effectiveness -in the Software Engineering Economics KA). -Note that measurement of software process effec- -tiveness requires measurement of the relevant -product attributes; for example, measurement of -software defects discovered and corrected during -software testing. -One must take care when measuring product -attributes for the purpose of determining process -effectiveness. For example, the number of defects -detected and corrected by testing may not achieve -the expected number of defects and thus provide -a misleadingly low effectiveness measure, either -because the software being tested is of better- -than-usual quality or perhaps because introduc- -tion of a newly introduced upstream inspection -process has reduced the remaining number of -defects in the software. -Product measures that may be important in -determining the effectiveness of software pro- -cesses include product complexity, total defects, -defect density, and the quality of requirements, +#### 4.2. Quality of Measurement Results + -design documentation, and other related work -products. -Also note that efficiency and effectiveness are -independent concepts. An effective software pro- -cess can be inefficient in achieving a desired soft- -ware 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. -An efficient process can be ineffective in accom- -plishing the desired transformation of input work -products into output work products; for example, -failure to find and correct a sufficient number of -software defects during the testing process. -Causes of low efficiency and/or low effective- -ness in the way a software process, activity, or -task is executed might include one or more of the -following problems: deficient input work prod- -ucts, inexperienced personnel, lack of adequate -tools and infrastructure, learning a new process, -a complex product, or an unfamiliar product -domain. The efficiency and effectiveness of soft- -ware process execution are also affected (either -positively or negatively) by factors such as turn- -over in software personnel, schedule changes, a -new customer representative, or a new organiza- -tional policy. -In software engineering, productivity in per- -forming a process, activity, or task is the ratio of -output produced divided by resources consumed; -for example, the number of software defects dis- -covered and corrected divided by person-hours of -effort (see Productivity in the Software Engineer- -ing Economics KA). Accurate measurement of -productivity must include total effort used to sat- -isfy the exit criteria of a software process, activ- -ity, or task; for example, the effort required to -correct defects discovered during software test- -ing must be included in software development -productivity. -Calculation of productivity must account for -the context in which the work is accomplished. -For example, the effort to correct discovered -defects will be included in the productivity cal- -culation of a software team if team members -correct the defects they find—as in unit testing -by software developers or in a cross-functional -agile team. Or the productivity calculation -may include either the effort of the software -developers or the effort of an independent test- -ing team, depending on who fixes the defects -found by the independent testers. Note that this -example refers to the effort of teams of devel- -opers or teams of testers and not to individuals. -Software productivity calculated at the level of -individuals can be misleading because of the -many factors that can affect the individual pro- -ductivity of software engineers. -Standardized definitions and counting rules -for measurement of software processes and work -products are necessary to provide standardized -measurement results across projects within an -organization, to populate a repository of histori- -cal data that can be analyzed to identify software -processes that need to be improved, and to build -predictive models based on accumulated data. In -the example above, definitions of software defects -and staff-hours of testing effort plus counting -rules for defects and effort would be necessary to -obtain satisfactory measurement results. -The extent to which the software process is -institutionalized is important; failure to institu- -tionalize a software process may explain why -“good” software processes do not always pro- -duce anticipated results. Software processes may -be institutionalized by adoption within the local -organizational unit or across larger units of an -enterprise. +The quality of process and product measurement results is primarily determined +by the reliability and validity of the measured results. Measurements that do +not satisfy these quality criteria can result in incorrect interpretations and +faulty software process improvement initiatives. Other desirable properties of +software measurements include ease of collection, analysis, and presentation +plus a strong correlation between cause and effect. -_4.2. Quality of Measurement Results_ -[4*, s3.4–3.7] +The Software Engineering Measurement topic in the Software Engineering +Management KA describes a process for implementing a software measurement +program. -The quality of process and product measurement -results is primarily determined by the reliability -and validity of the measured results. Measure- -ments that do not satisfy these quality criteria -can result in incorrect interpretations and faulty -software process improvement initiatives. Other -desirable properties of software measurements -include ease of collection, analysis, and presenta- -tion plus a strong correlation between cause and -effect. -The Software Engineering Measurement topic -in the Software Engineering Management KA -describes a process for implementing a software -measurement program. +#### 4.3. Software Information Models + -4.3. Software Information Models -[1*, p310–311] [3*, p712–713] [4*, s19.2] +Software information models allow modeling, analysis, and prediction of +software process and software product attributes to provide answers to relevant +questions and achieve process and product improvement goals. Needed data can be +collected and retained in a repository; the data can be analyzed and models +can be constructed. Validation and refinement of software information models +occur during software projects and after projects are completed to ensure that +the level of accuracy is sufficient and that their limitations are known and +understood. Software information models may also be developed for contexts +other than software projects; for example, a software information model might +be developed for processes that apply across an organization, such as software +configuration management or software quality assurance processes at the +organizational level. +Analysis-driven software information model building involves the development, +calibration, and evaluation of a model. A software information model is +developed by establishing a hypothesized transformation of input variables into +desired outputs; for example, product size and complexity might be transformed +into estimated effort needed to develop a software product using a +regression equation developed from observed data from past projects. A model is +calibrated by adjusting parameters in the model to match observed results from +past projects; for example, the exponent in a nonlinear regression model might +be changed by applying the regression equation to a different set of past +projects other than the projects used to develop the model. -Software information models allow modeling, -analysis, and prediction of software process and -software product attributes to provide answers to -relevant questions and achieve process and product -improvement goals. Needed data can be collected -and retained in a repository; the data can be ana- -lyzed and models can be constructed. Validation -and refinement of software information models -occur during software projects and after projects -are completed to ensure that the level of accuracy -is sufficient and that their limitations are known -and understood. Software information models may -also be developed for contexts other than software -projects; for example, a software information -model might be developed for processes that apply -across an organization, such as software configu- -ration management or software quality assurance -processes at the organizational level. -Analysis-driven software information model -building involves the development, calibration, -and evaluation of a model. A software infor- -mation model is developed by establishing a -hypothesized transformation of input variables -into desired outputs; for example, product size -and complexity might be transformed into esti- -mated effort needed to develop a software prod- -uct using a regression equation developed from -observed data from past projects. A model is -calibrated by adjusting parameters in the model -to match observed results from past projects; for -example, the exponent in a nonlinear regression -model might be changed by applying the regres- -sion equation to a different set of past projects -other than the projects used to develop the model. -A model is evaluated by comparing computed -results to actual outcomes for a different set of -similar data. There are three possible evaluation -outcomes: +A model is evaluated by comparing computed results to actual outcomes for a +different set of similar data. There are three possible evaluation outcomes: -1. results computed for a different data set vary - widely from actual outcomes for that data - set, in which case the derived model is not - applicable for the new data set and should - not be applied to analyze or make predictions - for future projects; +1. results computed for a different data set vary widely from actual outcomes + for that data set, in which case the derived model is not applicable for the + new data set and should not be applied to analyze or make predictions + for future projects; +2. results computed for a new data set are close to actual outcomes for that + data set, in which case minor adjustments are made to the parameters of the + model to improve agreement; +3. results computed for the new data set and subsequent data sets are very + close and no adjustments to the model are needed. +Continuous evaluation of the model may indicate a need for adjustments over +time as the context in which the model is applied changes. - -Software Engineering Process 8-11 - -2. results computed for a new data set are - close to actual outcomes for that data set, - in which case minor adjustments are made - to the parameters of the model to improve - agreement; -3. results computed for the new data set and - subsequent data sets are very close and no - adjustments to the model are needed. - -Continuous evaluation of the model may indi- -cate a need for adjustments over time as the con- -text in which the model is applied changes. -The Goals/Questions/Metrics (GQM) method -was originally intended for establishing measure- -ment activities, but it can also be used to guide +The Goals/Questions/Metrics (GQM) method was originally intended for +establishing measurement activities, but it can also be used to guide analysis and improvement of software processes. -It can be used to guide analysis-driven software -information model building; results obtained -from the software information model can be used -to guide process improvement. -The following example illustrates application -of the GQM method: -- Goal: Reduce the average change request - processing time by 10% within six months. -- Question 1-1: What is the baseline change - request processing time? -- Metric 1-1-1: Average of change request - processing times on starting date -- Metric 1-1-2: Standard deviation of change - request processing times on starting date -- Question 1-2: What is the current change - request processing time? -- Metric 1-2-1: Average of change request - processing times currently -- Metric 1-2-2: Standard deviation of change - request processing times currently - -_4.4. Software Process Measurement Techniques_ -[1*, c8] - -Software process measurement techniques are -used to collect process data and work product -data, transform the data into useful information, -and analyze the information to identify process -activities that are candidates for improvement. -In some cases, new software processes may be -needed. +It can be used to guide analysis-driven software information model building; +results obtained from the software information model can be used to guide +process improvement. +The following example illustrates application of the GQM method: -Process measurement techniques also provide -the information needed to measure the effects of -process improvement initiatives. Process mea- -surement techniques can be used to collect both -quantitative and qualitative data. +- Goal: Reduce the average change request processing time by 10% within six + months. +- Question 1-1: What is the baseline change request processing time? +- Metric 1-1-1: Average of change request processing times on starting date +- Metric 1-1-2: Standard deviation of change request processing times on + starting date +- Question 1-2: What is the current change request processing time? +- Metric 1-2-1: Average of change request processing times currently +- Metric 1-2-2: Standard deviation of change request processing times currently +#### 4.4. Software Process Measurement Techniques -4.4.1. Quantitative Process Measurement -Techniques -[4*, s5.1, s5.7, s9.8] + +Software process measurement techniques are used to collect process data and +work product data, transform the data into useful information, and analyze the +information to identify process activities that are candidates for improvement. +In some cases, new software processes may be needed. -The purpose of quantitative process measurement -techniques is to collect, transform, and analyze -quantitative process and work product data that -can be used to indicate where process improve- -ments are needed and to assess the results of -process improvement initiatives. Quantitative -process measurement techniques are used to col- -lect and analyze data in numerical form to which -mathematical and statistical techniques can be -applied. -Quantitative process data can be collected as -a byproduct of software processes. For example, -the number of defects discovered during software -testing and the staff-hours expended can be col- -lected by direct measurement, and the productiv- -ity of defect discovery can be derived by calculat- -ing defects discovered per staff-hour. -Basic tools for quality control can be used to -analyze quantitative process measurement data -(e.g., check sheets, Pareto diagrams, histograms, -scatter diagrams, run charts, control charts, and -cause-and-effect diagrams) (see Root 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 Modeling, Prototyp- -ing, and Simulation in the Engineering Founda- -tions KA); these models can be used to assess the -impact of various approaches to software process -improvement. -Orthogonal Defect Classification (ODC) can -be used to analyze quantitative process measure- -ment data. ODC can be used to group detected -defects into categories and link the defects in -each category to the software process or soft- -ware processes where a group of defects origi- -nated (see Defect Characterization in the Soft- -ware Quality KA). Software interface defects, -for example, may have originated during an inad- -equate software design process; improving the -software design process will reduce the number -of software interface defects. ODC can provide -quantitative data for applying root cause analysis. -Statistical Process Control can be used to track -process stability, or the lack of process stability, -using control charts. +Process measurement techniques also provide the information needed to measure +the effects of process improvement initiatives. Process measurement +techniques can be used to collect both quantitative and qualitative data. +##### 4.4.1. Quantitative Process Measurement Techniques -4.4.2. Qualitative Process Measurement -Techniques -[1*, s6.4] + -Qualitative process measurement techniques— -including interviews, questionnaires, and expert -judgment—can be used to augment quantitative -process measurement techniques. Group consen- -sus techniques, including the Delphi technique, -can be used to obtain consensus among groups of -stakeholders. +The purpose of quantitative process measurement techniques is to collect, +transform, and analyze quantitative process and work product data that can be +used to indicate where process improvements are needed and to assess the +results of process improvement initiatives. Quantitative process measurement +techniques are used to collect and analyze data in numerical form to which +mathematical and statistical techniques can be applied. -**5. Software Engineering Process Tools** - [1*, s8.7] +Quantitative process data can be collected as a byproduct of software +processes. For example, the number of defects discovered during software +testing 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. -Software process tools support many of the nota- -tions used to define, implement, and manage -individual software processes and software life -cycle models. They include editors for notations -such as data-flow diagrams, state charts, BPMN, -IDEF0 diagrams, Petri nets, and UML activity -diagrams. In some cases, software process tools -allow different types of analyses and simula- -tions (for example, discrete event simulation). In +Basic tools for quality control can be used to analyze quantitative process +measurement data (e.g., check sheets, Pareto diagrams, histograms, scatter +diagrams, run charts, control charts, and cause-and-effect diagrams) (see Root +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 +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. +Orthogonal Defect Classification (ODC) can be used to analyze quantitative +process measurement data. ODC can be used to group detected defects into +categories and link the defects in each 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 the software design process will reduce the number of software +interface defects. ODC can provide quantitative data for applying root cause +analysis. Statistical Process Control can be used to track process stability, +or the lack of process stability, using control charts. -addition, general purpose business tools, such as -a spreadsheet, may be useful. -Computer-Assisted Software Engineering -(CASE) tools can reinforce the use of integrated -processes, support the execution of process defi- -nitions, and provide guidance to humans in per- -forming well-defined processes. Simple tools -such as word processors and spreadsheets can -be used to prepare textual descriptions of pro- -cesses, activities, and tasks; these tools also sup- -port traceability among the inputs and outputs of -multiple software processes (such as stakeholder -needs analysis, software requirements specifica- -tion, software architecture, and software detailed -design) as well as the results of software pro- -cesses such as documentation, software compo- -nents, test cases, and problem reports. -Most of the knowledge areas in this Guide -describe specialized tools that can be used to -manage the processes within that KA. In particu- -lar, see the Software Configuration Management -KA for a discussion of software configuration -management tools that can be used to manage the -construction, integration, and release processes -for software products. Other tools, such as those -for requirements management and testing, are -described in the appropriate KAs. -Software process tools can support projects -that involve geographically dispersed (virtual) -teams. Increasingly, software process tools are -available through cloud computing facilities as -well as through dedicated infrastructures. -A project control panel or dashboard can dis- -play selected process and product attributes for -software projects and indicate measurements that -are within control limits and those needing cor- -rective action. +##### 4.4.2. Qualitative Process Measurement Techniques + +Qualitative process measurement techniques - including interviews, +questionnaires, and expert judgment - can be used to augment quantitative process +measurement techniques. Group consensus techniques, including the Delphi +technique, can be used to obtain consensus among groups of stakeholders. -Software Engineering Process 8-13 +### 5. Software Engineering Process Tools -##### MATRIX OF TOPICS VS. REFERENCE MATERIAL + +Software process tools support many of the notations used to define, +implement, and manage individual software processes and software life cycle +models. They include editors for notations such as data-flow diagrams, state +charts, BPMN, IDEF0 diagrams, Petri nets, and UML activity diagrams. In some +cases, software process tools allow different types of analyses and simula- +tions (for example, discrete event simulation). In addition, general purpose +business tools, such as a spreadsheet, may be useful. -Fairley 2009 +Computer-Assisted Software Engineering (CASE) tools can reinforce the use of +integrated processes, support the execution of process definitions, and +provide guidance to humans in performing well-defined processes. Simple tools +such as word processors and spreadsheets can be used to prepare textual +descriptions of processes, activities, and tasks; these tools also support +traceability among the inputs and outputs of multiple software processes (such +as stakeholder needs analysis, software requirements specification, software +architecture, and software detailed design) as well as the results of software +processes such as documentation, software components, test cases, and +problem reports. -##### [1] - - -Moore 2009 - -##### [2] +Most of the knowledge areas in this Guide describe specialized tools that can +be used to manage the processes within that KA. In particular, see the +Software Configuration Management KA for a discussion of software configuration +management tools that can be used to manage the construction, integration, and +release processes for software products. Other tools, such as those for +requirements management and testing, are described in the appropriate KAs. +Software process tools can support projects that involve geographically +dispersed (virtual) teams. Increasingly, software process tools are available +through cloud computing facilities as well as through dedicated +infrastructures. -Sommerville 2011 +A project control panel or dashboard can display selected process and product +attributes for software projects and indicate measurements that are within +control limits and those needing corrective action. -##### [3] +### Matrix Of Topics vs. Reference Material +Fairley 2009 [1] +Moore 2009 [2] +Sommerville 2011 [3] +Kan 2003 [4] -Kan 2003 +1. Software Process Definition p177 p295 p28–29, p36, c5 + 1.1. Software Process Management s26.1 p453–454 + 1.2. Software Process Infrastructure p183, p186 p437–438 +2. Software Life Cycles c2 p190 + 2.1. Categories of Software Processes preface p294–295 c22, c23, c24 + 2.2. Software Life Cycle Models c2 s3.2 s2.1 + 2.3. Software Process Adaptation s2.7 p51 + 2.4. Practical Considerations p188–190 +3. Software Process Assessment and Improvement p188, p194 c26 p397, c15 + 3.1. Software Process Assessment Models s4.5, s4.6 s26.5 p44–48 + 3.2. Software Process Assessment Methods p322–331 s26.3 p44–48, s16.4 + 3.3. Software Process Improvement Models p187–188 s26.5 s2.7 + 3.4. Continuous and Staged Ratings p28–34 s26.5 p39–45 +4. Software Measurement s26.2 s18.1.1 + 4.1. Software Process and Product Measurement s6.3, p273 s26.2, p638 + 4.2. Quality of Measurement Results s3.4, s3.5, s3.6, s3.7 + 4.3. Software Information Models p310–311 p. 712–713 s19.2 + 4.4. Software Process Measurement Techniques s6.4, c8 s5.1, s5.7, s9.8 +5. Software Engineering Process Tools s8.7 -##### [4] +**Further Readings** -**1. Software Process Definition** p177 p295 +_Software Extension to the Guide to the Project Management Body of Knowledge®_ +(SWX) [5]. +SWX provides adaptations and extensions to the generic practices of project +management documented in the _PMBOK® Guide_ for managing software projects. +The primary contribution of this extension to the _PMBOK® Guide_ is descrip- +tion of processes that are applicable for managing adaptive life cycle software +projects. -p28–29, -p36, -c5 -1.1. Software Process Management s26.1 p453–454 - - -1.2. Software Process Infrastructure -p183, p186 -p437–438 - -**2. Software Life Cycles** c2 p190 - - -2.1. Categories of Software Processes preface p294–295 -c22, c23, -c24 -2.2. Software Life Cycle Models c2 s3.2 s2.1 -2.3. Software Process Adaptation s2.7 p51 - - -2.4. Practical Considerations p188–190 - -**3. Software Process Assessment and -Improvement** - p188, p194 c26 p397, c15 - - -3.1. Software Process Assessment Models -s4.5, -s4.6 -s26.5 p44–48 - - -3.2. Software Process Assessment -Methods -p322–331 s26.3 -p44–48, -s16.4 -3.3. Software Process Improvement -Models -p187–188 s26.5 s2.7 - - -3.4. Continuous and Staged Ratings p28–34 s26.5 p39–45 - -**4. Software Measurement** s26.2 s18.1.1 - 4.1. Software Process and Product - Measurement - - -s6.3, -p273 - - -s26.2, -p638 - - -4.2. Quality of Measurement Results - - -s3.4, -s3.5, -s3.6, -s3.7 -4.3. Software Information Models p310–311 p. 712–713 s19.2 - - -4.4. Software Process Measurement -Te c h n i q u e s - - -s6.4, -c8 - - -s5.1, -s5.7, -s9.8 - -**5. Software Engineering Process Tools** s8.7 - -##### FURTHER READINGS - -_Software Extension to the Guide to the Project -Management Body of Knowledge®_ (SWX) -[5]. - -SWX provides adaptations and extensions to the -generic practices of project management docu- -mented in the _PMBOK® Guide_ for managing -software projects. The primary contribution of -this extension to the _PMBOK® Guide_ is descrip- -tion of processes that are applicable for managing -adaptive life cycle software projects. - D. Gibson, D. Goldenson, and K. Kost, “Performance Results of CMMI-Based Process Improvement” [6]. -This technical report summarizes publicly avail- -able empirical evidence about the performance -results that can occur as a consequence of CMMI- -based process improvement. The report contains -a series of brief case descriptions that were cre- -ated with collaboration from representatives -from 10 organizations that have achieved notable -quantitative performance results through their -CMMI-based improvement efforts. +This technical report summarizes publicly available empirical evidence about +the performance results that can occur as a consequence of CMMI-based process +improvement. The report contains a series of brief case descriptions that were +created with collaboration from representatives from 10 organizations that +have achieved notable quantitative performance results through their CMMI-based +improvement efforts. _CMMI_ ® _for Development, Version 1.3_ [7]. -_CMMI_ ® _for Development, Version 1.3_ provides an -integrated set of process guidelines for develop- -ing and improving products and services. These -guidelines include best practices for developing -and improving products and services to meet the -needs of customers and end users. +_CMMI_ ® _for Development, Version 1.3_ provides an integrated set of process +guidelines for developing and improving products and services. These +guidelines include best practices for developing and improving products and +services to meet the needs of customers and end users. -_ISO/IEC 15504-1:2004 Information tech- -nology—Process assessment—Part 1: +_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 Capability Determination), includes multiple parts. Part 1 provides concepts and vocabulary for software development processes and related business- management functions. Other parts of 15504 define the requirements and -procedures for per- forming process assessments. +procedures for performing process assessments. -##### REFERENCES +**References** -[1] R.E. Fairley, Managing and Leading Software Projects , Wiley-IEEE Computer +[1] R.E. Fairley, Managing and Leading Software Projects, Wiley-IEEE Computer Society Press, 2009. -[2] J.W. Moore, The Road Map to Software Engineering: A Standards-Based Guide , +[2] J.W. Moore, The Road Map to Software Engineering: A Standards-Based Guide, Wiley-IEEE Computer Society Press, 2006. -[3] I. Sommerville, Software Engineering , 9th ed., Addison-Wesley, 2011. +[3] I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011. -[4] S.H. Kan, Metrics and Models in Software Quality Engineering , 2nd ed., -Addison- Wesley, 2002. +[4] S.H. Kan, Metrics and Models in Software Quality Engineering, 2nd ed., +Addison-Wesley, 2002. [5] Project Management Institute and IEEE Computer Society, Software Extension -to the PMBOK® Guide Fifth Edition , ed: Project Management Institute, 2013. +to the PMBOK® Guide Fifth Edition, ed: Project Management Institute, 2013. [6] D. Gibson, D. Goldenson, and K. Kost, “Performance Results of CMMI-Based Process Improvement,” Software Engineering Institute, 2006; http:// -resources.sei.cmu.edu/library/asset-view. cfm?assetID=8065. +resources.sei.cmu.edu/library/asset-view.cfm?assetID=8065. [7] CMMI Product Team, “CMMI for Development, Version 1.3,” Software Engineering Institute, 2010; http:// resources.sei.cmu.edu/library/asset-view.