Deficiencies of Less Formal Approaches 1
25.1.1 Deficiencies of Less Formal Approaches 1
The methods discussed for analysis and design in Parts Three and Four of this book made heavy use of natural language and a variety of graphical notations. Although careful application of analysis and design methods, coupled with thorough review can and does lead to high-quality software, sloppiness in the application of these methods can create a variety of problems. A system specification can contain con- tradictions, ambiguities, vagueness, incomplete statements, and mixed levels of
Although a good abstraction. document index
Contradictions are sets of statements that are at variance with each other. For cannot eliminate
example, one part of a system specification may state that the system must monitor contradictions, it can
help to uncover them. all the temperatures in a chemical reactor while another part, perhaps written by Spend the time to
another member of staff, may state that only temperatures occurring within a cer- create a
tain range are to be monitored. Normally, contradictions that occur on the same page comprehensive index
of a system specification can be detected easily. However, contradictions are often for specifications and
other documents. separated by a large number of pages. Ambiguities are statements that can be interpreted in a number of ways. For exam- ple, the following statement is ambiguous:
The operator identity consists of the operator name and password; the password consists of six digits. It should be displayed on the security VDU and deposited in the login file when an operator logs into the system.
In this extract, does the word it refer to the password or the operator identity? Vagueness often occurs because a system specification is a very bulky document.
“Making mistakes is Achieving a high level of precision consistently is an almost impossible task. It can human, Repeating
lead to statements such as “The interface to the system used by radar operators should ‘em is too.”
be user-friendly” or “The virtual interface shall be based on simple overall concepts
Malcolm Forbes
that are straightforward to understand and use and few in number.” A casual perusal of these statements might not detect the underlying lack of any useful information.
Incompleteness is probably one of the most frequently occurring problems with system specifications. For example, consider the functional requirement:
The system should maintain the hourly level of the reservoir from depth sensors situated in the reservoir. These values should be stored for the past six months.
1 This section and others in the first part of this chapter have been adapted from work contributed by Darrel Ince for the European version of the fourth edition of Software Engineering: A Practi- tioner's Approach.
This describes the main data storage part of a system. If one of the commands for the system was
Effective use of formal The function of the AVERAGE command is to display on a PC the average water level for a technical reviews
particular sensor between two times.
during specification can eliminate many of
Assuming that no more detail was presented for this command, the details of the these problems.
command would be seriously incomplete. For example, the description of the com- However, some will
mand does not include what should happen if a user of a system specifies a time that not be uncovered.
Therefore, be on the was more than six months before the current hour. lookout for deficiencies
Mixed levels of abstraction occur when very abstract statements are intermixed ran- during design, code,
domly with statements that are at a much lower level of detail. For example, state- and test.
ments such as The purpose of the system is to track the stock in a warehouse. might be intermixed with When the loading clerk types in the withdraw command he or she will communicate the
order number, the identity of the item to be removed, and the quantity removed. The sys- tem will respond with a confirmation that the removal is allowable.
While such statements are important in a system specification, specifiers often man- age to intermix them to such an extent that it becomes very difficult to see the over- all functional architecture of a system.
Each of these problems is more common than we would like to believe. And each represents a potential deficiency in conventional and object-oriented methods for specification.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more