|
For more than a decade, there has been growing dissatisfaction
with conventional strategies for systems development, and an increasing number
of proposals for replacing them with new, more formal approaches. The problem
is that conventional development methods cannot cope with the size and complexity
of the systems we are now able to implement. These system characteristics are
possible because of the ever-increasing capacity and capability of computer hardware.
Systems having up to a million lines of high-order source code are already commonplace,
and others are on the horizon that will require ten or more times that amount.
The inadequacies of the development methods were first apparent in large
business and commercial systems, but as digital technology came into use in real-time
embedded systems, they too became subject to the same problems. We are past the
stage of wondering whether formal development methods are really needed. The question
is, Can we keep pace with the capabilities of the technology using the methods
we already have? What further extensions and improvements can we make to them?
Can we devise better and more comprehensive methods?
 A problem with past system specification
methods has been that they each tend to address only one aspect of the system,
whereas systems actually have many aspects, all of which need to be addressed.
The methods described in this book seek to overcome this problem by addressing
a number of these aspects in an integrated manner. From the functional requirements
point of view, they address the aspects of processing, control, and timing. From
the physical requirements point of view, they address the architectural specification
of the system, and most importantly, they take account of the hierarchical and
iterative nature of systems and of systems development. Figure 1.1 illustrates
how the whole universe may be thought of as a hierarchy of systems. Any individual
system may itself be expressed as such a hierarchy, and the progression down through
its levels involves defining the requirements for the level below, then making
decisions on the architecture or design of that level to meet those requirements,
then repeating this procedure for the next level down, and so on. This perspective
makes clear the adage that one person's requirements are another person's design:
a cause of considerable confusion in earlier development methods, but an integral
part of the methods addressed here.
Before we delve into the details of the methods, we
will give a brief historical account of their development. This will help you
understand the situations that create the need for such methods, and will give
you some insight into what it might take to introduce them into your own organization. 1.1
The Birth of the Requirements Model The requirements specification model
described in this book evolved at a major avionics systems development company.
This evolution started in late 1982, and culminated two years later in the successful
Federal Aviation Administration certification of a complex real-time, embedded
avionics system for a commercial airliner. The system is now in widespread use
in the airline industry.
At the time, the development effort
was the largest we had ever undertaken. Previously, we had been without formal
procedures for integrating the efforts of our system and software developers:
We had depended on their individual communications with each other, and on the
abilities of a few overworked lead engineers, in order to keep the various subsystems
consistent.
There comes a point at which this just won't
do, a point at which the interactions between the subsystems are at least
as complex as the subsystems themselves. Faced with this dilemma, and with the
very real threat of a major disaster if we did not improve our performance, we
investigated the formal development methods that already existed. We found a fairly
mature set of methods that had been developed in the 1970s for large mainframe
business applications, and that had been successfully applied in that field.
Several of the existing requirements definition methods were capable of
representing the information processing parts of our systems, but they could not
handle the complex control structures that large real-time systems also typically
include. Since these control structures can be represented using finite state
machinery theory, we decided that we needed to integrate an established requirements
definition method with finite state machine theory in a unified structure, and
to do it so as to retain the benefits of both.
The requirements
definition method that seemed to have the most merit was DeMarco's structured
analysis [4], so we chose this as the starting point. One of the greatest merits
of the DeMarco method is its attention to human readability and understandability
through the use of graphics. In addition, it shares with most other requirements
definition methods the attributes of information abstraction, built-in self-consistency
checking, and the ability to be self-indexing.
Because the project was already underway, we needed
a requirements definition method immediately. During just two weeks of brainstorming
and trial and error, we found the approach we were looking forÑa way to partition
a large finite state machine into pieces corresponding to the pieces of a structured
analysisÑand the requirements model described in this book was born. One week
later, a group of development engineers took the first class in the new method.
That first teaching effort was not a polished presentation, but the substance
was there. As we gained experience in its use, we made some further improvements
in our emerging method, but, surprisingly, it has never needed any fundamental
changes.
The existing and widely used structured design method
[11,19] was applicable (with very little modification) to the design definition
of our real-time systems. Introducing the model The approach
we took to introduce our new methods was contrary to that advocated by methods
experts, who advise that methods be introduced on a small, low-visibility project.
We did not have (and have never had) such a project, and in fact introduced the
method on the largest, most critical project we had ever undertaken. To offset
the risks in this situation, we established a Methods TeamÑa group of six people
whose sole role was to make the methods work. The team members prepared and taught
classes, provided consultation, solved problems as they arose, made improvements
to the methods, and investigated ways to automate them.
If
critical projects are the only kind your shop, too, ever has to work on, and you
are about to introduce revolutionary new development methods, we recommend this
approach of dedicating a team to support them.
It would
be misleading to suggest that the requirements and design definition methods alone
were responsible for the success of the project. We made a number of other changes
at the same time: For example, a large scientific computer was dedicated to the
project; each system and software engineer was provided with an interactive terminal;
an efficient, modular working environment was installed; we scaled the project
using the Putnam model [15]; and we used a more detailed and comprehensive progress
tracking procedure than we had ever used before. The relative contributions of
the individual factors are hard to judge, but their combined effect was greatly
improved productivity.
One of the earliest decisions made
with regard to the requirements model was to make it freely available to anyone
wishing to use it, rather than to copyright it, or treat it as proprietary information.
Our rationale was first, that our business is avionics, not development methods;
second, that it would be to our advantage to have the rest of the industry follow
our lead; and further, that it would be particularly advantageous to have automated
tool developers embed our methods in their tools. As a result of this early decision
(and because of the success of the requirements model in its first application),
the method has become widespread in the industry. Many diverse companies are using
it, and there are currently at least six automated CASE tool developers [21] supporting
it (some more completely than othersÑwe neither endorse nor recommend against
these or any other CASE tools; you must evaluate them relative to your own needs
and environment). In addition, there are seminars [20] available giving instruction
in the use of both the requirements and the architecture models'. This popularity
has given rise to constant demands for more available information on the method,
and those demands provided our principal motivation for writing this book. 1.2
The Birth of the Architecture Model While this change in approach to the
development of one major avionics system was taking place, the airframe manufacturer
that needed the system was wrestling with an even broader problemÑthat of multiple
system integration. Because land-, sea-, air-, and space-based vehicles are now
filled with complex interacting systems, the problems of handling this complexity
have moved up a level from subsystems within a system to systems within a vehicle.
The issues at this level have a different nature, however. The total
vehicle with all its embedded systems may be considered to be one supersystem.
The power of modern technology can allow unconventional partitionings of this
supersystem. Many previously separate functions might be included in one system,
or functions that traditionally have been performed by analog processing might
now be done digitally. The resulting systems must fit into a well-defined physical
structure, interconnected by communication buses with rigid protocols, and they
must meet many requirements beyond their basic functionality, such as safety,
reliability, and maintainability. Frequently, the systems will be developed by
different contractors, so the issue of precise interface definition becomes paramount.
This scenario, in which functional requirements at
one level must be rigorously allocated to a physical structure with nonfunctional
requirements added, gave rise to the architecture model, described in Parts IV
and V. 1.3 Compatibility of the Models The requirements
and architecture models complement each other well. Processes in the requirements
model can be allocated to slots in the architecture model, and this procedure
can be repeated many times over going down through increasing levels of detail.
Similarly, in the upward direction, the vehicle itself may be considered to be
just one system within a network of systems, such as the air traffic control for
a region. Again, the functional requirements for this larger system may be defined
using the requirements model, and then allocated to the physical communications
network using the architecture model. This leveled repetition of functional requirements
definition, followed by physical allocation, is fundamental to the nature of large
systems development. 1.4 Applicability of the Models Although
the methods were developed around avionics systems, the technology explosion has
reached all areas of the industry, and systems of unprecedented complexity are
appearing in manufacturing, process control, and even in the very business applications
in which the original methods were first applied. The methods described in this
book are applicable in any of these areas, and indeed have gained acceptance in
applications including communications, instrumentation, medical systems, process
control, and military systems. The need for the methods is much more a function
of size and complexity than of application area. 1.5 The System
Life Cycle Before studying the requirements and architecture methods, we
must understand what purpose they serve. One way to illustrate this is to look
at what the methods do and where they fit in the total system life cycle. This
is shown in Figure 1.2 in which the development levels correspond to the hierarchical
levels of Figure 1.1.
The figure illustrates that the requirements and architecture
models apply throughout all levels of systems development and both are applied
at each level. A set of requirements is generated at a given level, using the
requirements model. These requirements are allocated to physical units or modules
using the architecture model. The requirements for each unit are then expanded
to more detail, and the whole process is repeated at the next level.
Of course, most projects will only deal with perhaps one or two of these
iterative cycles, but on the other hand, most projects fit into a larger pictureÑthey
may be part of a complete aircraft, or of a manufacturing plant, or of a communication
networkÑin which many more cycles will occur. It is good to have an understanding
of the larger framework in which your project fits.
The
final level, at which implementation is to take place, may require modification
to the architecture model, or may require a language-dependent representation
(Ada PDL, for example), depending on the language or implementation needs.
While we do not address testing activities in this book, we have found
that structured development proves to be very beneficial in this area. Having
the system defined both functionally and physically in a layered hierarchy of
processes and units leads to a similar organization of the test procedures. The
testing can proceed very methodically from the bottom up, verifying the functionality
and the structure at each level up to the top. Some caveats Some key
points illustrated in Figure 1.2 need to be emphasized: The life cycle does
not end at the point of system delivery, as is so often implied: It continues
on into the service phase, usually for much longer than the development and build
phases. It is customary for modifications and upgrades to occur while the system
is in service. This is illustrated in Figure 1.2 via the loop from System in Service
through Deploy System and Field Issues and back to the development cycle. These
changes, together with the system maintenance cost, can make the cost during the
service much higher than during development. The benefits of formal methods are
most obvious at the development phase, but in fact, their benefits can be multiplied
many times over during the service phase because of the ease with which changes
can be made after the original developers are gone.  Contrary again to common misconceptions,
the development does not occur in simple sequential steps. There is extensive
overlap, feedforward, and feedback between each phase and its neighbors. The process
is, in fact, iterative, both within each phase and over multiple phases. The requirements
and architecture models record their respective definitions regardless of the
order in which they are done. As we shall show in the chapters that follow, everything
is traceable between levels and between phases so risk of confusion due to iterative
updates is minimized. In large, software-intensive systems, the activities
of defining the requirements, the architecture, and the hardware and software
design are (or should be) much more extensive than the actual implementation.
In fact, with the advent of tools that will generate code automatically from requirements
statements, we are rapidly approaching the point at which, for all intents and
purposes, the definition is the implementation. The two methods exist specifically
to support this front-end definition activity. Systems themselves, and
the process of developing them, are leveled hierarchies. In the extreme, we can
consider the whole universe, the elementary particles of which it is composed,
and every structure in between, as one huge leveled hierarchy of systems, as was
shown in Figure 1.1. The particular systems in which we are interested fall somewhere
in this range, and the points we choose to call "top level" and "implementation"
are quite arbitrary. This perspective makes it clear why there is so much confusion
over the definitions of "requirements" and "design." The fact
is that one person's requirement is another person's design, depending on the
particular interests of those people relative to hierarchy. The methods exactly
reflect this hierarchical nature of large systems. |
