commit - ebd51ffce5c8b80f223e558695b88fadea00c513
commit + e35dcdbef451fb5a74a474ba6e7b5e8e689e92a0
blob - 59277b6bc1b2830389ecdf7fcca408f5d0024b42
blob + 1adb64ed87fe8b2556df376db3d22d3ab193e490
--- 1_software_requirements.md
+++ 1_software_requirements.md
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**
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.
#### 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
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.
- 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
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
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;
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
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
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,
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.
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
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
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
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
#### 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
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
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
- 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.
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
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).
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
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
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
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.
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).
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.
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
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
<!-- [7] -->
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
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
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
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
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
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
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
**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**
- 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?
<!-- [2, c10s2.4] [3, c1s5, c9s1, c17] -->
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
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.
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.
