|The 001 environment significantly cuts expenses and
time to market while building better systems resulting in unprecedented productivity
savings. This is because 001 is based on Development Before the Fact (DBTF). With DBTF
every object is a system oriented object (SOO). Every system is an object; every object is
Compared to a traditional development, the
productivity of 001 developed systems is from 10 to 100 times greater (see Figure 1).
According to these results if a system is estimated to cost, say, $60 million using
traditional approaches, a 10 to 1 savings (at the lower end of the spectrum) would cost at
most $6 million with a preventative approach. Upon further analysis, it was discovered
that the productivity was higher the larger and more complex the systemthe opposite
of what one finds with traditional systems development. This is in major 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.
But 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 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
things inherently take place because of the nature of DBTF's formal systems language, 001
Not only does the DBTF approach significantly increase productivity,
but as more reuse is employed, productivity continues to increase. Measuring
productivity becomes a process of relativitythat is, relative to the last system
developed. Older methods for measuring productivity are no longer applicable.
An area of great interest with 001 users has been that of
capitalizing on the power of reuse within DBTF environments. A SOO as 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--for example,
particular Function Map (FMap) and Type Map (TMap) User Defined Structures (which are
FMaps with variable functions and TMaps with variable types), the more information we have
on estimating costs for the overall system.
Figure 2 illustrates what can be saved with the additional use of
just a couple of User Defined Structures in FMaps or TMaps which have certain attributes.
Here if it takes 40 nodes on a map to define a user defined structure (see lower left hand
corner in table) and it takes 3 nodes to use it, then if there were 1000 uses of the
structure there would be 3040 nodes used (statements to write as part of a definition)
with the use of the structure and 40,000 nodes (statements to write) without it. If
productivity is measured in terms of statements, say, for requirements or test cases
(software is often measured in terms of lines of code), then with the use of these
structures in the manner described, the productivity would be increased by approximately
13 to 1 (the productivity using these structures over not using them).
This productivity is in addition to what is already saved by
transitioning from a traditional approach to a DBTF approach.
Development Before the Fact's preventative philosophy, to solve a
given problem as early as possible, means 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.
The Transition from a Traditional Environment to DBTF
Changing from a traditional environment to a preventative one is
like going from the typewriter to the word processor. Initial overhead is needed for
learning the new way of doing things. But, as with the word processor, can one afford not
to make such an investment?