ITI built client-server applications using key components of networking, transaction processing, graphical user interfaces, relational databases, UNIX, and object-based programming. Their architecture paradigm was to build a common interface to the key components. This common interface could then be layered on a particular vendor's solution. In this way, an application built on this common interface could easily be migrated from similar but disparate vendor provided solutions. Hence the name of the company: independence.
The biggest product built was a health insurance claims processing system. Internal claims processing clients would process claims. The claims would be routed through the system using a work flow graph. A claim would be represented as relational data and images of the original form. The system was deployed to about a thousand clients talking to a multi-processor server. This system took 50 person years to build the tool kit and 15 person years to build the application.
The software engineering methodology used was cyclical. Small incremental changes to the application were done, shown to the customer, and iterated upon. There was no requirement document except for a very general one-page statement. The architecture was well defined by the tools.
What was missing was a total lack of quality assurance. Less than 0.5 person years was spent on testing before the product went live at the customer's site. Needless to say, the system was not reliable and not well accepted. Now the company had to concentrate on doing nothing but bug fixes. With no formal regression testing suite, each bug fixed would most likely create, or uncover, another bug. After several months, the system was rejected by the customer and the company soon went out of business.
The individual responsible for quality assurance would generate reports with the same conclusion: performed as expected. To a casual reader this meant high quality with no real problems. However, the quality assurance person meant something entirely different. He expected low quality and found low quality. Hence the report: performed as expected.
The tool kit was sold. Having gone through the first application, the tool kit was some what real. The tool kit was also later abandoned. The architectural goal of independence was not accomplished. The applications were independent of vendor specific systems, but now the application was dependent on the tool kit. In fact, the tool kit was just another vendor. A better approach to independence would have been to use accepted standards as the foundation of the tool kit.
See tables 7.9
and 7.10 starting on page
![[*]](cross_ref_motif.gif)
.
|