"The use of commercial products can have profound and lasting impact on the spiraling cost and effort of building Defense systems, particularly information systems. It is important, however, to remember that simply 'using COTS' is not the end in itself, but only the means."--David Carney

Assess Reuse Risks and Costs

Requirements, algorithms, functions, business rules, architecture, source code, test cases, input data, and scripts can all be reused. Reuse offers the potential for lower cost of development, shorter development schedules, lower cost of sustainment, and better quality. Architecture reuse is the primary means for achieving the cost savings potential of code reuse.
 
However, reuse can also be a significant constraint on a program, actually slowing it down and making the overall design of the system unwieldy, and unstable. It can actually increase the long-term cost of the system.
The distinguishing characteristic between these two scenarios is whether reuse was appropriate. Reuse is NOT a "silver bullet." Rather it is powerful tool that can help significantly when used correctly.
To exploit reuse, the development team must recognize the realities of reused products.

• The product being reused must closely match the need that it is trying to solve. Certainly, the reused software must provide the functions that are needed. Additional functionality provides unnecessary overhead and potential for failure. In addition, if the reuse product is not a good "fit" in the new system, the components with which it interfaces will become more complex.
   
• The reused product should be well documented. This is especially true if the provider of the reuse software is not going to provide maintenance support. Key to success is a well-understood interface.
   
• The reuse product should have been designed for a scenario similar to that for which it is going to be used. If not, extensive testing should be conducted to verify the correctness of the product. Typically, reused modules are assumed to work properly because they have already been tested and used in an operational scenario. This assumption decays rapidly as the developer changes the operational environment of the software.
   
• The reuse product should be stable. Any change to the product (as errors are identified and fixed by other users) must be incorporated into the current development.
   
• The key to successful reuse is determining the components and functions that are needed before forcing a decision to reuse products.

Reuse is a powerful technique, because it allows functionality to be provided rapidly to the user. A decision to reuse a software product is also a constraint on the development team. Rather than being allowed to structure the system in the most effective way possible, a decision to reuse software limits the options available.
 
Recognize also that reuse of commercially available software has some unique disadvantages. Commercial entities are motivated to limit a user's ability to change products. This is often accomplished by including and then recommending the use of proprietary features. In addition, the update cycle for a commercial package can be a significant drain on maintenance resources. The costs of keeping personnel current in and then integrating new product releases should be assessed as a part of overall life cycle costs.

top

---