The basic premise behind the Reuse Model is that systems should be built using existing components, as opposed to custom-building new components. The Reuse Model is clearly suited to Object-Oriented computing environments, which have become one of the premiere technologies in today’s system development industry.

Within the Reuse Model, libraries of software modules are maintained that can be copied for use in any system. These components are of two types: procedural modules and database modules. When building a new system, the developer will “borrow” a copy of a module from the system library and then plug it into a function or procedure. If the needed module is not available, the developer will build it, and store a copy in the system library for future usage. If the modules are well engineered, the developer with minimal changes can implement them.

The notion of reuse is really just a means of carrying the notion of object-oriented development to design. Instead of reusing classes and methods, we may be reusing entire systems – databases, services, or applications.

Here are a few benefits of the key benefits of reuse:

Improve ‘time to market’ by reducing analysis, development and QA cycles.

Reusing elements increases the return on investment for the initial creation of the reusable component.

Better quality product with fewer defects. Defect density is lower when reusing a component that has already survived the QA gauntlet and is working in production than with a newly developed product.

Reuse increases productivity. If considerable portions of a system are already developed and in place, it stands to reason that a smaller project team will be required than for new work. This frees the stakeholder to increase his shop’s productivity by either assigning those resources to other work that wouldn’t have been possible otherwise, or to cut costs by reducing headcount.

When designing systems, these two principles should be kept in mind:

Design TO reuse. Software design should first seek out functional, reusable elements and leverage those components and modules to as great an extent as possible.

Design FOR reuse. If reusing a currently available component is not feasible, design architects should seek to create components or systems that will be conducive to future reuse.

For some other “light reading” on the topic of reuse, take a look at these articles:

About the Author

Jonathan Babcock is a management and IT consultant with expertise in business analysis, process optimization and solution delivery methodology. Practical Analyst is his outlet for sharing what he's learned, and for interacting with solution delivery professionals across the globe.

Subscribe

Recommended Reading

If you're a business analyst transitioning to agile from traditional waterfall delivery, or would just like to know more about business analysis in an agile environment, I highly recommend Ryland Leyton's new book.

Practical, principle-based, and easy to read and use, professionals of any background or career level seeking an opportunity in business analysis stand to benefit from the revised and updated edition of Laura Brandenburg's classic.

Not just for dummies! Written by some of my favorite expert BAs, Kupe Kupersmith, Kate McGoey and Paul Mulvey, and with a small contribution of my own (see chapter 18!), this is a great end-to-end resource for beginning to intermediate analysts.