Page 1221 - The Mechatronics Handbook

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

for finding most errors are no longer needed because those errors no longer exist. Tools to support prog-
ramming as a manual process are no longer needed.
Compared to the development using traditional techniques, the productivity of DBTF developed systems
has been shown to be significantly greater. Upon further analysis, it was discovered that the larger and more
complex the system, the greater the productivity—the opposite of what one finds with traditional systems
development. This is, in part, because of the high degree of DBTF’s support of reuse. The larger a system,
the more it has the opportunity to capitalize on reuse. As more reuse is employed, productivity continues to
increase. Measuring productivity becomes a process of relativity—that is, relative to the last system developed.
Capitalizing on reusables within a DBTF environment is an ongoing area of research interest. An
example is understanding the relationship between types of reusables and metrics. This takes into con-
sideration that a reusable can be categorized in many ways. One is according to the manner in which its
use saves time (which translates to how it impacts cost and schedules). More intelligent tradeoffs can
then be made. The more we know about how some kinds of reusables are used, the more information
we have to estimate costs for an overall system. Keep in mind also that the traditional methods for
estimating time and costs for developing software are no longer valid for estimating systems developed
with preventative techniques.
There are other reasons for this higher productivity as well, such as the savings realized and time saved
due to tasks and processes that are no longer necessary with the use of this preventative approach. There
is less to learn and less to do—less analysis, little or no implementation, less testing, less to manage, less to
document, less to maintain, and less to integrate. This is because a major part of these areas has been
automated or because of what inherently take place because of the nature of DBTF’s formal systems language.
In the end, it is the combination of the technology and that which executes it that forms the foundation
of successful software. Software is so ingrained in our society that its success or failure will dramatically
influence both the operation and the success of an organization. For that reason, today’s decisions about
systems engineering and software development have far-reaching effects.
Software is a relatively young technological field that is still in a constant state of change. Changing
from a traditional software environment to a preventative one is like going from the typewriter to the
word processor. Whenever there is any major change, there is always the initial overhead needed for
learning the new way of doing things. But, as with the word processor, progress begets progress.
Collective experience strongly confirms that quality and productivity increase with the increased use
of properties of preventative systems. In contrast to the “better late than never” after the fact philosophy,
the preventive philosophy behind DBTF is to solve—or if possible, prevent—a given problem as early as
possible. Finding a problem statically is better than finding it dynamically. Preventing it by the way a
system is defined is even better. Better yet is not having to define (and build) it at all.
Reusing a reliable system is better than reusing one that is not reliable. Automated reuse is better than
manual reuse. Inherent reuse is better than automated reuse. Reuse that can evolve is better than one that
cannot evolve. Best of all is reuse that ultimately approaches wisdom itself. Then, have the wisdom to use it.
The answer continues to be in the results just as in the biological system; and the goal is that the
systems of tomorrow will inherit the best of the systems of today.

References

1. Software Engineering Institute. Capability Maturity Model, Pittsburgh, PA: Carnegie, Mellon University,
1991.
2. Stroustrup, B., The C++ Programming Language, Reading, MA: Addison-Wesley, 1997.
3. Gosling, J., Joy, B., and Steele, G., The Java Language Specification, Reading, MA: Addison-Wesley,
1996.
4. Lientz, B.P., and Swanson, E.B., Software Maintenance Management, Reading, MA: Addison-Wesley,
1980.
5. Jones, T.C., Program Quality and Programmer Productivity, IBM Tech. Report TR02.764 January: 80,
San Jose, CA: Santa Teresa Labs, 1977.
©2002 CRC Press LLC