Web Development Reusability : Improve Reliability Quality and Productivity

WHAT IS REUSABILITY?

Reusability is one of the simplest and the oldest concepts in programming. It is also the most underutilized concept. When implemented correctly and purposefully, it can save time and money, as well as create an inventory for valuable and reusable software assets.

Reusability is an integral part of all engineering disciplines. For example, mechanical engineers do not design an engine from scratch for each car coming off an assembly line; chemical engineers do not develop the formulas for each can of detergent; hardware engineers do not re-create chips for every computer that is sold; and aerospace engineers do not build solid rocket boosters from ground zero for each space shuttle.

In all of these examples, the architecture and design of an item is reused to produce and manage a product line. Software can also be acquired, developed, maintained and managed via a product-line approach. Reusability also helps in maintainability, modularity, portability, productivity, interoperability, reconfigurability, commonality, adaptability, reliability and quality.

In a line, software reuse is the practice of using existing tested and proven software components to develop new applications.

WHY IS REUSABILITY IMPORTANT?

Here are a few isolated examples of how reuse has helped:

• The American Navy experienced a 26% reduction in required labor hours to develop and maintain its Restructured Naval Tactical Data Systems (RNTDS).
• Raytheon saw a 50% increase in productivity in its Missile Systems Division
• Fujitsu's Software Development for Electronic Switching Systems (ESS) began delivering 70% of its ESSs on schedule (as opposed to only 20% before adopting reuse principles).
• The American Army estimated a cost avoidance of $479.9 million for its Tactical Command and Control system, allowing additional mission requirements to be addressed during a period of funding shortfalls.
• Magnavox developed the Force Fusion System Prototype (FFSP) in 20% of the projected, estimated time for a totally new system development.

Apart from these, most of a programmer's time is spent in modifying programs - making corrections, additions and improvements. When you have a general and specific tool for each of these needs, the time spent on these modifications would dramatically reduce since the tools put into a reuse library are already tested and proven. Reusability has proven itself in hardware - computers can now be made out of reusable components with well-defined interfaces.

These are just a few examples to demonstrate how important and helpful reusability can be. Unfortunately, reuse does not just happen. Both technical and organizational issues must be tackled in order to successfully transition to a reuse-based culture. Once these issues are managed, the benefits discussed above can be got.

Apart from the obvious, why does it matter that reinvention is rampant? That programmers have more work to do? Extra work for the programmers is not exactly a blessing, even from the programmer's viewpoint! Time spent reinventing anything that is already available, is time that is not available to improve user interfaces, or to make the program run faster, or to chase down the proverbial Last Bug. Every time that a line of code is retyped is a new chance for bugs to be introduced. There is always the temptation to take shortcuts based on how the code is used - shortcuts that could turn around and bite the programmer when the program is modified and used for something unexpected.

WHAT CAN BE REUSED?

Normally, all reusability efforts are directed at "code reuse". Reusability is not a concept that is limited to the coding phase of the software life cycle. It must be a highly visible item from requirement analysis to the retirement of the product. It is essential to identify the life-cycle phases that can be helped by reusability. A broader approach to reuse should be emphasized. There are various types of assets that can be made reusable:

• Code
• Requirements
• Architecture/design documentation
• Test Plans
• Specifications
• Design
• Manuals
• Templates
• Design decisions
• Or, anything associated with software

The benefits of reuse help the project, and return greater benefits. However all this is not without its challenges, and technology has not fulfilled its promise in this area. Solutions on how to store, represent, search and retrieve designs and tools are still being developed - Enterprise Integrated Modeling, I-CASE, etc.

COMPONENTS

A component is defined as "a nontrivial, nearly independent, and replaceable part of a system that fulfills a specific function within a system's architecture." Similar ideas have emerged in other branches of design and engineering, as discussed above. For example, hi-fi systems can be purchased in component forms. The only things that the user needs to take care of are the individual component's functionality. The interfaces between components are standardized so that components from different manufacturers can be used together.

For components to be reusable they need to be clearly specified, portable and adaptable. Portability defines how the component interacts with the underlying platform. A code snippet can be recompiled on various platforms with very little modification, whereas an executable component may be bound to a specific platform. A higher level of portability will increase the number of potential platforms for the component, resulting in a broader use.

To make a component truly reusable, it has to be designed in a way so as to allow adaptation. Adaptability is necessary because the developers of a component cannot predict the requirements for all the systems and scenarios in which it will be reused.

The specification for any component should refer to the various interfaces that will or can be used to communicate with the component, rather than the internal architecture. A specification with interfaces will allow the architecture of a component to be altered without any disruptions to other systems that depend on it. Repositories of such components need to be made available and easily accessible to developers.

FEW PROBLEMS WITH REUSABILITY

• Sometimes, it is indeed better to reinvent the tool than to find a suitable one, or to learn how to use a suitable one.
• In a large library of tools, advanced tools are needed to search for the right tools.
• Reusability is also at odds with efficiency - the higher level the language, the less likely it is to execute rapidly.
• General tools are hard to learn, but specialized tools are less likely to meet your needs.
• It takes MORE time to design for reusability. Of course, this again is the producer's point of view. A consumer's point of view would be, it takes less time to design WITH reuse!
• If a particular functionality is made reusable it should take into account all the various scenarios that the functionality can be used from, used with and used for. Take for example, a simple send mail script. When made reusable, it should take into consideration scenarios where the function can be called - to send out an e-mail to multiple recipients, support styled text or plain text, etc. This could be a very time-consuming task for a more complex functionality to be made generalized.