commit e35dcdbef451fb5a74a474ba6e7b5e8e689e92a0 from: Sergey Bronnikov date: Fri Jan 14 18:35:44 2022 UTC Fix formatting issues Follows up #2 Follows up #3 Follows up #4 Follows up #5 Follows up #6 Follows up #7 commit - ebd51ffce5c8b80f223e558695b88fadea00c513 commit + e35dcdbef451fb5a74a474ba6e7b5e8e689e92a0 blob - 59277b6bc1b2830389ecdf7fcca408f5d0024b42 blob + 1adb64ed87fe8b2556df376db3d22d3ab193e490 --- 1_software_requirements.md +++ 1_software_requirements.md @@ -48,7 +48,7 @@ one-off activity performed at the outset of a software The Software Requirements KA is related closely to the Software Design, Software Testing, Software Maintenance, Software Configuration Management, -Software Engineering Manage- ment, Software Engineering Process, Software +Software Engineering Management, Software Engineering Process, Software Engineering Models and Methods, and Software Quality KAs. **BREAKDOWN OF TOPICS FOR SOFTWARE REQUIREMENTS** @@ -86,7 +86,7 @@ the requirements can be verified within available reso Requirements have other attributes in addition to behavioral properties. Common examples include a priority rating to enable tradeoffs in the face of finite resources and a status value to enable project progress to be monitored. -Typically, software requirements are uniquely identi- fied so that they can be +Typically, software requirements are uniquely identified so that they can be subjected to software configuration management over the entire life cycle of the feature and of the software. @@ -126,7 +126,7 @@ Characteristics in the Software Quality KA). #### 1.4. Emergent Properties Some requirements represent emergent properties of software that is, -requirements that can- not be addressed by a single component but that depend +requirements that cannot be addressed by a single component but that depend on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system, information system, and the operators all interacted under actual operating @@ -179,10 +179,10 @@ the overall software engineering process. The objective of this topic is to provide an understanding that the requirements process -- is not a discrete front-end activity of the soft- ware life cycle, but rather +- is not a discrete front-end activity of the software life cycle, but rather a process initiated at the beginning of a project that continues to be refined throughout the life cycle; -- identifies software requirements as configu- ration items and manages them +- identifies software requirements as configuration items and manages them using the same software configuration management practices as other products of the software life cycle processes; - needs to be adapted to the organization and project context. @@ -209,7 +209,7 @@ stakeholders include (but are not restricted to) the f - Customers: This group comprises those who have commissioned the software or who represent the software’s target market. - Market analysts: A mass-market product will not have a commissioning - customer, so marketing people are often needed to estab- lish what the market + customer, so marketing people are often needed to establish what the market needs and to act as proxy customers. - Regulators: Many application domains, such as banking and public transport, are regulated. Software in these domains must comply with the @@ -236,7 +236,7 @@ their requirements elicited. This section introduces the project management resources required and consumed by the requirements process. It establishes the context for the first topic (Initiation and Scope Definition) of the Software Engineering Management KA. -Its principal purpose is to make the link between the pro- cess activities +Its principal purpose is to make the link between the process activities identified in 2.1 and the issues of cost, human resources, training, and tools. #### 2.4. Process Quality and Improvement @@ -246,7 +246,7 @@ the requirements process. Its purpose is to emphasize requirements process plays in terms of the cost and timeliness of a software product and of the customer’s satisfaction with it. It will help to orient the requirements process with quality standards and process improvement models for -soft- ware and systems. Process quality and improvement is closely related to +software and systems. Process quality and improvement is closely related to both the Software Quality KA and Software Engineering Process KA, comprising - requirements process coverage by process improvement standards and models; @@ -267,7 +267,7 @@ customer. It is variously termed “requirements captu discovery,” and “requirements acquisition.” One of the fundamental principles of a good requirements elicitation process is -that of effective communication between the various stake- holders. This +that of effective communication between the various stakeholders. This communication continues through the entire Software Development Life Cycle (SDLC) process with different stakeholders at different points in time. Before development begins, requirements specialists may form the conduit for this @@ -295,7 +295,7 @@ promote awareness of the various sources of software r frameworks for managing them. The main points covered are as follows: - Goals. The term “goal” (sometimes called “business concern” or “critical - success factor”) refers to the overall, high-level objec- tives of the + success factor”) refers to the overall, high-level objectives of the software. Goals provide the motivation for the software but are often vaguely formulated. Software engineers need to pay particular attention to assessing the value (relative to priority) and cost of goals. A feasibility study is a @@ -307,7 +307,7 @@ frameworks for managing them. The main points covered approach in the knowledge domain. Relations between relevant concepts within the application domain should be identified. - Stakeholders (see section 2.2, Process Actors). Much software has proved - unsatisfactory because it has stressed the require- ments of one group of + unsatisfactory because it has stressed the requirements of one group of stakeholders at the expense of others. Hence, the delivered software is difficult to use, or subverts the cultural or political structures of the customer organization. The software engineer needs to identify, represent, @@ -324,7 +324,7 @@ frameworks for managing them. The main points covered greatly affect software feasibility and cost as well as restrict design choices. - The organizational environment. Software is often required to support a - business process, the selection of which may be condi- tioned by the + business process, the selection of which may be conditioned by the structure, culture, and internal politics of the organization. The software engineer needs to be sensitive to these since, in general, new software should not force unplanned change on the business process. @@ -381,7 +381,7 @@ elicitation; the principal ones are these: requirements reflecting the concerns of a few outspoken (and perhaps senior) people that are favored to the detriment of others. - Observation. The importance of software context within the organizational - environment has led to the adaptation of observa- tional techniques such as + environment has led to the adaptation of observational techniques such as ethnography for requirements elicitation. Software engineers learn about user tasks by immersing themselves in the environment and observing how users perform their tasks by interacting with each other and with software tools @@ -533,7 +533,7 @@ required, and so on) may be allocated to the braking h hydraulic assemblies) and an antilock braking system (ABS). Only when a requirement for an antilock braking system has been identified, and the requirements allocated to it, can the capabilities of the ABS, the braking -hardware, and emer- gent properties (such as car weight) be used to identify +hardware, and emergent properties (such as car weight) be used to identify the detailed ABS software requirements. Architectural design is closely identified with conceptual modeling (see @@ -675,7 +675,7 @@ the quality of software requirements specification to such as cost, acceptance, performance, schedule, and reproducibility. Quality indicators for individual software requirements specification statements include imperatives, directives, weak phrases, options, and continuances. -Indicators for the entire software require- ments specification document +Indicators for the entire software requirements specification document include size, readability, specification, depth, and text structure. ### 6. Requirements Validation @@ -778,7 +778,7 @@ software to be built, or that has been built, are key software engineering process. Not every organization has a culture of documenting and managing requirements. -It is com- mon in dynamic start-up companies, driven by a strong “product +It is common in dynamic start-up companies, driven by a strong “product vision” and limited resources, to view requirements documentation as unnecessary overhead. Most often, however, as these companies expand, as their customer base grows, and as their product starts to evolve, they discover that @@ -858,7 +858,7 @@ identified. #### 7.4. Requirements Tracing -Requirements tracing is concerned with recover- ing the source of requirements +Requirements tracing is concerned with recovering the source of requirements and predicting the effects of requirements. Tracing is fundamental to performing impact analysis when requirements change. A requirement should be traceable backward to the requirements and stakeholders that motivated it (from @@ -896,7 +896,7 @@ Tools for dealing with software requirements fall broa tools for modeling and tools for managing requirements. Requirements management tools typically support a range of activities - including documentation, tracing, and change management and have had a significant impact on practice. -Indeed, tracing and change management are really only prac- ticable if +Indeed, tracing and change management are really only practicable if supported by a tool. Since requirements management is fundamental to good requirements practice, many organizations have invested in requirements management tools, although many more manage their requirements in more ad hoc blob - 4331bb5143a23f3fefd2690ad019d7f137008e77 blob + fd494b199841eb1dc2dca9533d56ae6bf8c57abe --- 2_software_design.md +++ 2_software_design.md @@ -17,7 +17,7 @@ PDL Program Design Language Design is defined as both “the process of defining the architecture, components, interfaces, and other characteristics of a system or component” and “the result of [that] process” [1]. Viewed as a process, software design is the -software engineering life cycle activity in which software require- ments are +software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction. A software design (the result) describes the software architecture - that is, how software is @@ -107,7 +107,7 @@ Software Design 2-3 - Detailed design describes the desired behavior of these components. The output of these two processes is a set of models and artifacts that record -the major decisions that have been taken, along with an explana- tion of the +the major decisions that have been taken, along with an explanation of the rationale for each nontrivial decision. By recording the rationale, long-term maintainability of the software product is enhanced. @@ -241,7 +241,7 @@ to reason about the system, which comprise software el them, and properties of both” [14]. During the mid-1990s, however, software architecture started to emerge as a broader discipline that involved the study of software structures and architectures in a more generic way. This gave rise -to a number of interesting concepts about software design at different lev- els +to a number of interesting concepts about software design at different levels of abstraction. Some of these concepts can be useful during the architectural design (for example, architectural styles) as well as during the detailed design (for example, design patterns). These design concepts can also be used @@ -279,8 +279,8 @@ organization. Various authors have identified a number styles: - General structures (for example, layers, pipes and filters, blackboard) -- Distributed systems (for example, client- server, three-tiers, broker) -- Interactive systems (for example, Model-View- Controller, +- Distributed systems (for example, client-server, three-tiers, broker) +- Interactive systems (for example, Model-View-Controller, Presentation-Abstraction-Control) - Adaptable systems (for example, microkernel, reflection) - Others (for example, batch, interpreters, process control, rule-based). @@ -340,7 +340,7 @@ to match the skills, experience, and expectations of i rapidly start work- ing with the software. - _User familiarity_. The interface should use terms and concepts drawn from the experiences of the people who will use the software. -- _Consistency_. The interface should be consis- tent so that comparable +- _Consistency_. The interface should be consistent so that comparable operations are activated in the same way. - _Minimal surprise._ The behavior of software should not surprise users. - _Recoverability._ The interface should provide mechanisms allowing users to blob - afaa7eb63b2a929f2d4439fcdd120dfc3d469463 blob + 583f1db9a6ea5d8eb58da1ea87447be510c306af --- 3_software_construction.md +++ 3_software_construction.md @@ -107,7 +107,7 @@ by the testers and users during independent testing an Specific techniques that support constructing for verification include following coding standards to support code reviews and unit testing, organizing code to support automated testing, and restricting the use of complex or -hard-to-understand lan- guage structures, among others. +hard-to-understand language structures, among others. #### 1.4. Reuse @@ -172,11 +172,11 @@ construction as an activity that occurs only after sig work has been completed - including detailed requirements work, extensive design work, and detailed planning. The more linear approaches tend to emphasize the activities that precede construction (requirements and design) -and to create more distinct sep- arations between activities. In these models, +and to create more distinct separations between activities. In these models, the main emphasis of construction may be coding. Other models are more iterative - such as evolutionary prototyping and agile -development. These approaches tend to treat construc- tion as an activity that +development. These approaches tend to treat construction as an activity that occurs concurrently with other software development activities (including requirements, design, and planning) or that overlaps them. These approaches tend to mix design, coding, and testing activities, and they often treat the @@ -242,7 +242,7 @@ level, and that design work tends to be dictated by co real-world problem that is being addressed by the software. Just as construction workers building a physical structure must make -small-scale modifica- tions to account for unanticipated gaps in the builder’s +small-scale modifications to account for unanticipated gaps in the builder’s plans, software construction workers must make modifications on a smaller or larger scale to flesh out details of the software design during construction. @@ -397,7 +397,7 @@ Software Construction 3-7 Construction with reuse means to create new software with the reuse of existing software assets. The most popular method of reuse is to reuse code from the libraries provided by the language, platform, tools being used, or an -organizational repository. Asides from these, the applica- tions developed +organizational repository. Asides from these, the applications developed today widely make use of many open-source libraries. Reused and off-the-shelf software often have the same - or better - quality requirements as newly developed software (for example, security level). @@ -405,7 +405,7 @@ developed software (for example, security level). The tasks related to software construction with reuse during coding and testing are as follows: -- The selection of the reusable units, data- bases, test procedures, or test +- The selection of the reusable units, databases, test procedures, or test data. - The evaluation of code or test reusability. - The integration of reusable software assets into the current software. @@ -570,8 +570,8 @@ down the software - are also used. Exceptions are used to detect and process errors or exceptional events. The basic structure of an exception is that a routine uses _throw_ to throw a -detected exception and an exception han- dling block will _catch_ the exception -in a _try-catch_ block. The try-catch block may process the erro- neous +detected exception and an exception handling block will _catch_ the exception +in a _try-catch_ block. The try-catch block may process the erroneous condition in the routine or it may return control to the calling routine. Exception handling policies should be carefully designed following common principles such as including in the exception message all information that led @@ -671,7 +671,7 @@ multiple processes or threads in a concurrent programm A monitor is an abstract data type that presents a set of programmer-defined operations that are executed with mutual exclusion. A monitor contains the -declaration of shared variables and pro- cedures or functions that operate on +declaration of shared variables and procedures or functions that operate on those variables. The monitor construct ensures that only one process at a time is active within the monitor. A mutex (mutual exclusion) is a synchronization primitive that grants exclusive access to a shared resource by only one process @@ -697,7 +697,7 @@ Software Construction 3-11 A distributed system is a collection of physically separate, possibly -heterogeneous computer sys- tems that are networked to provide the users with +heterogeneous computer systems that are networked to provide the users with access to the various resources that the system maintains. Construction of distributed software is distinguished from traditional software construction by issues such as parallelism, communication, and fault tolerance. blob - 2414d6e86f2e2e6356636b1a9d62958218b812e3 blob + 886c778dfe29f8ebd07000bac46af26e72f5ab27 --- 4_software_testing.md +++ 4_software_testing.md @@ -1123,16 +1123,13 @@ We categorize the available tools according to their f been exercised amongst all those required by the selected test coverage criterion. The analysis can be done thanks to program instrumenters that insert recording probes into the code. - - - _Tracers_ [1*, c1s7] record the history of a program’s execution - paths. - - _Regression testing tools_ [1*, c12s16] support the reexecution of - a test suite after a section of software has been modified. They - can also help to select a test subset according to the change - made. - - _Reliability evaluation tools_ [9*, c8] support test results - analysis and graphical visualization in order to assess - reliability-related measures according to selected models. +- _Tracers_ [1*, c1s7] record the history of a program’s execution paths. +- _Regression testing tools_ [1*, c12s16] support the reexecution of a test + suite after a section of software has been modified. They can also help to + select a test subset according to the change made. +- _Reliability evaluation tools_ [9*, c8] support test results analysis and + graphical visualization in order to assess reliability-related measures + according to selected models. ### Matrix of topics vs. Reference material blob - 88ceac8cee7a706bdaec2ea5057246e2ec685f4a blob + c26b9d221d75ac28ab19010e7971c76e72476fc6 --- 5_software_maintenance.md +++ 5_software_maintenance.md @@ -60,7 +60,7 @@ for software maintenance: ISO/IEC/IEEE 14764 [1].^1 In engineering, software maintenance is essentially one of the many technical processes. -1 For the purpose of conciseness and ease of read- ing, this standard is +1 For the purpose of conciseness and ease of reading, this standard is referred to simply as IEEE 14764 in the subsequent text of this KA. The objective of software maintenance is to modify existing software while @@ -167,7 +167,7 @@ Three categories (types) of maintenance have been defi adaptive, and perfective [2*, c4s3]. IEEE 14764 includes a fourth category–preventative. -- Corrective maintenance: reactive modifi- cation (or repairs) of a software +- Corrective maintenance: reactive modification (or repairs) of a software product performed after delivery to correct discovered problems. Included in this category is emergency maintenance, which is an unscheduled modification performed to temporarily keep a software product operational pending @@ -188,11 +188,12 @@ IEEE 14764 classifies adaptive and perfective maintena enhancements. It also groups together the corrective and preventive maintenance categories into a correction category, as shown in Table 5.1. -Table 5.1. Software Maintenance Categories - -Correction Enhancement +| | Correction | Enhancement | +|-----------:|:------------|-------------| +| Proactive | Preventive | Perfective | +| Reactive | Corrective | Adaptive | -Proactive Preventive Perfective Reactive Corrective Adaptive +Table 5.1. Software Maintenance Categories ### 2. Key Issues in Software Maintenance @@ -514,7 +515,7 @@ The maintenance process contains the activities and ta an existing software product while preserving its integrity. These activities and tasks are the responsibility of the maintainer. As already noted, many maintenance activities are similar to those of software development. -Maintainers perform analysis, design, cod- ing, testing, and documentation. +Maintainers perform analysis, design, coding, testing, and documentation. They must track requirements in their activities - just as is done in development - and update documentation as baselines change. IEEE 14764 recommends that when a maintainer uses a development process, it must be @@ -690,17 +691,13 @@ that covers migration requirements, migration tools, c data, execution, verification, and support. Migrating software can also entail a number of additional activities such as -- notification of intent: a statement of why - the old environment is no longer to be sup- - ported, followed by a description of the new - environment and its date of availability; -- parallel operations: make available the - old and new environments so that the user - experiences a smooth transition to the new - environment; -- notification of completion: when the sched- - uled migration is completed, a notification is - sent to all concerned; +- notification of intent: a statement of why the old environment is no longer + to be supported, followed by a description of the new environment and its + date of availability; +- parallel operations: make available the old and new environments so that the + user experiences a smooth transition to the new environment; +- notification of completion: when the scheduled migration is completed, a + notification is sent to all concerned; Software Maintenance 5-11 blob - 51103d23cbb2ca8a1a69123f6956bf8552683eb6 blob + c29e7c8d28e8f7ffc343521fab878b15793a666b --- 6_software_configuration_management.md +++ 6_software_configuration_management.md @@ -2,21 +2,21 @@ **Acronyms** -CCB Configuration Control Board -CM Configuration Management -FCA Functional Configuration Audit -PCA Physical Configuration Audit -SCCB Software Configuration Control Board -SCI Software Configuration Item -SCM Software Configuration Management -SCMP Software Configuration Management Plan -SCR Software Change Request -SCSA Software Configuration Status Accounting -SDD Software Design Document -SEI/ CMMI Software Engineering Institute’s Capability Maturity Model -Integration -SQA Software Quality Assurance -SRS Software Requirement Specification +- CCB Configuration Control Board +- CM Configuration Management +- FCA Functional Configuration Audit +- PCA Physical Configuration Audit +- SCCB Software Configuration Control Board +- SCI Software Configuration Item +- SCM Software Configuration Management +- SCMP Software Configuration Management Plan +- SCR Software Change Request +- SCSA Software Configuration Status Accounting +- SDD Software Design Document +- SEI/ CMMI Software Engineering Institute’s Capability Maturity Model + Integration +- SQA Software Quality Assurance +- SRS Software Requirement Specification **Introduction** @@ -198,7 +198,7 @@ considered: - Legacy: how will projects use (or not) the new tools? - Financing: who will pay for the tools’ acquisition, maintenance, training, and customization? -- Scope: how will the new tools be deployed— for instance, through the entire +- Scope: how will the new tools be deployed - for instance, through the entire organization or only on specific projects? - Ownership: who is responsible for the introduction of new tools? - Future: what is the plan for the tools’ use in the future? @@ -618,7 +618,7 @@ or a capability of a larger, integrated tool environme Reported information can be used by various organizational and project -elements—including the development team, the maintenance team, project +elements - including the development team, the maintenance team, project management, and software quality activities. Reporting can take the form of ad hoc queries to answer specific questions or the periodic production of predesigned reports. Some information produced by the status accounting @@ -870,12 +870,12 @@ Stephen P. Berczuk and Brad Appleton, _Software Config Patterns: Effective Teamwork, Practical Integration_ [6]. This book expresses useful SCM practices and strategies as patterns. The -patterns can be imple- mented using various tools, but they are expressed in a +patterns can be implemented using various tools, but they are expressed in a tool-agnostic fashion. “CMMI for Development,” Version 1.3, pp. 137–147 [7]. -This model presents a collection of best prac- tices to help software +This model presents a collection of best practices to help software development organizations improve their processes. At maturity level 2, it suggests configuration management activities. @@ -888,7 +888,7 @@ IEC/IEEE, 2010. Software Engineering , IEEE, 2012. [3] A.M.J. Hass, Configuration Management Principles and Practices , 1st ed., -Addison- Wesley, 2003. +Addison-Wesley, 2003. [4] I. Sommerville, Software Engineering , 9th ed., Addison-Wesley, 2011.