Page 1214 - The Mechatronics Handbook

0066_frame_C49.fm Page 9 Thursday, January 10, 2002 5:05 PM

49.3 Development Before the Fact

Thus far, this chapter has explained the derivation of software and attempted to show how it has evolved
over time to become the true “brains” of any automated system. But, like a human brain, this software brain
must be carefully architected to promote productivity, foster quality, and enforce control and reusability.
Traditional software engineering paradigms fail to see the software development process from the
larger perspective of the superorganism described at the beginning of this chapter. It is only when we
see the software development process as made of discrete, but well-integrated, components can we begin
to develop a methodology that can produce the very benefits that have been promised by the advent of
software decades ago.
Software engineering, from this perspective, consists of a methodology as well as a series of tools with
which to implement the solution to the business problem at hand. But even before the first tool can be
applied, the software engineering methodology must be deployed to assist in specifying the requirements
of the problem. How can this be accomplished successfully in the face of the issues needed to be addressed
outlined in the last section? How can this be accomplished in situations where organizations must develop
systems that run across diverse and distributed hardware platforms, databases, programming languages,
and GUIs when traditional methodologies make no provision for such diversity? And how can software
be developed without having to fix or “cure” those myriad of problems, which result “after the fact” of
that software’s development?
What is required is a radical revision of the way we build software, an approach that understands how
to build systems using the right techniques at the right time. First and foremost, it is a preventative
approach. This means it provides a framework for doing things right the first time. Problems associated
with traditional methods of design and development are prevented “before the fact” just by the way a
system is defined. Such an approach would concentrate on preventing problems of development from
even happening rather than letting them happen “after the fact,” and fixing them after they have surfaced
at the most inopportune and expensive point in time.
Consider such an approach in its application to a human system. To fill a tooth before it reaches the
stage of a root canal is curative with respect to the cavity, but preventive with respect to the root canal.
Preventing the cavity by proper diet prevents not only the root canal, but the cavity as well. To follow a
cavity with a root canal is the most expensive alternative, to fill a cavity on time is the next most expensive,
and to prevent these cavities in the first place is the least expensive option.
Preventiveness is a relative concept. For any given system, be it human or software, one goal is to prevent,
to the greatest extent and as early as possible, anything that could go wrong in the life cycle process.
With a preventative philosophy, systems would be carefully constructed to minimize development
problems from the very outset. A system could be developed with properties that controlled its very own
design and development. One result would be reusable systems that promote automation. Each system
definition would model both its application and its life cycle with built-in constraints—constraints that
protect the developer, but yet do not take away his flexibility.
The philosophy behind preventative systems is that reliable systems are defined in terms of reliable
systems. Only reliable systems are used as building blocks, and only reliable systems are used as mecha-
nisms to integrate these building blocks to form a new system. The new system becomes reusable for
building other systems.
Effective reuse is a preventative concept. That is, reusing something (e.g., requirements or code) that
contains no errors to obtain a desired functionality avoids both the errors and the cost of developing a
new system. It allows one to solve a given problem as early as possible, not at the last moment. But to
make a system truly reusable, one must start not from the customary end of a life cycle, during the
implementation or maintenance phase, but from the very beginning.
Preventative systems are the true realization of the entelechy construct where molecules of software
naturally combine to form a whole much greater than the sum of its parts. Or one can think of con-
structing systems from the tinker toys of our youth. One recalls that the child never errs in building

©2002 CRC Press LLC