KEY MATERIAL FROM PART A
The sole purpose of this chapter is to provide an overview of those software engineering con-cepts that the students need to understand to comprehend Part B before studying Part A, so that they can start their software engineering team projects as soon as possible. Most of the problems in this chapter are of the form “Define X” or “Distinguish between Y and Z.” This is to ensure that the students truly understand the key concepts.
10.1: A life cycle is the actual series of steps followed in the building of a specific product,
whereas a life-cycle model is a theoretical description of how to build software.
10.2: A software product is a model of the real world, and the real world is continually chang-
ing. In particular, the client’s requirements frequently change while the software is
10.3 Incrementation adds functionality, whereas iteration improves the quality of an increment.
10.4: The requirements workflow, analysis workflow, design workflow, implementation work–
flow, and test workflow.
10.5: The aim of the requirements workflow is to determine exactly what the client needs. The
aim of the analysis workflow is to analyze and refine the requirements to achieve the
detailed understanding of the requirements. The aim of the design workflow is to refine
the artifacts of the analysis workflow until the material is in a form that can be imple-
mented by the programmers. The aim of the implementation workflow is to implement
the target software product in the chosen implementation language(s). The aim of the
testing workflow is to ensure that all the artifacts are correct.
10.6: The Unified Process is a methodology for developing software. The Unified Process
uses a graphical language, the Unified Modeling Language, to represent the software
10.7: A model is a set of UML diagrams that represent one or more aspects of the software
product to be developed.
10.8: Most software products are too large (or too complex) to be built by one software
engineering professional within the given time constraints.
10.9: Determining whether a possible course of action would be profitable by comparing esti-
mated future benefits against projected future costs.
10.10: Size, cost, duration, effort, quality.
10.11: A CASE tool assists in just one aspect of the production of software. A CASE work-
bench is a collection of tools that together support one or two activities. A CASE envi-
ronment supports the complete software process.
10.12: Whenever an artifact is changed, whether during development or maintenance, there will
be two versions of the artifact: the old version and the new version. The specific version
of each artifact from which a given version of the complete product is built is called the
configuration of that version of the product.
10.13: A fault is injected into a software product when a human makes a mistake. A failure is
the observed incorrect behavior of the software product as a consequence of a fault, and
the error is the amount by which a result is incorrect. The word defect is a generic term
for a fault, failure, or error.
10.14: The quality of software is the extent to which the product satisfies its specifications.
10.15: Execution-based testing is running test cases, and non-execution-based testing is care–
fully reading through an artifact.
10.16: Coupling is the degree of interaction between two modules; cohesion is the degree of
interaction within a module.
10.17: Reuse refers to using components of one product to facilitate the development of a differ-
ent product with a different functionality.
10.18: The work to be done: the resources with which to do it; and the money to pay for it all.