| Return on Investment with 001 |
| 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
a system. 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 system—the 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 AXES. 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 relativity—that 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? |
