Software reuse can save time, save money, and increase the reliability of resulting products. However, an attempt to reuse software that is not easily reusable can have the reverse effect. There are a number of models for measuring the maturity of software components for reuse, but these tend to focus on a scoring system rather than clearly defining a maturity model. Since maturity models allow projects to measure their performance and thus set targets for improving reusability, it can be argued that they are of more value than scoring systems. The NASA Earth Science Data Systems (ESDS) Software Reuse Working Group (WG) has developed Reuse Readiness Levels as a model for such measurement and evaluation. This document introduces the concept of Reuse Readiness Levels and explores their applicability to open source software.
Software reuse is the reapplication of knowledge encapsulated in software code in order to reduce the effort of developing and maintaining a new software system. There are many things that need to be considered for reuse, not just the software itself. For example, even when software cannot be reused, data formats, high-level designs, algorithms or other items may be. Consequently, when considering software reuse we must examine each item of interest. These items are known as artifacts, assets and components.
An artifact is any item produced at some point during the software development life cycle. An artifact that can be reused, that is an artifact that is recognised as having a particular value, is known as an asset. A component is a clearly delineated piece of software that performs a useful function within a software system.
Reusable Software Components (RSCs) are software entities that are intended for reuse. In principle, many different artifacts produced during the software development life cycle can be reused, including: source code, analysis and design specification, plans (project management), data (testing), documentation, expertise and experience, quality assurance processes, and any information used to create software and software documentation. However, while all of these items are useful, software is the artifact that is most often reused.
There are many examples of software code being reused, especially if we look towards open source software for inspiration. Reusable software components range from small libraries, such as those in the Apache Commons project, through frameworks for building complete applications, such as the Eclipse Rich Client Platform to complete applications that can be extended through plugin systems, such as the Mozilla Firefox.
There are two types of software reuse, black-box and white-box. Black-box means that the code implementation is hidden from the end user by well-defined and documented interfaces, usually an application programming interface (API), which allow the consumer to use the component without needing to know how it has been implemented. Black-box components can be more expensive to produce than white box components, but they will typically deliver greater overall savings for the end user in cases where the component is a natural fit to the user's needs. Black-box reuse is therefore most common for general use cases, such as libraries for common activities within an application; for example, libraries for managing logging and error reporting can often be reused in this way. When reusing black-box components for web applications, such as javascript libraries, it is also possible to use a component from a content network network (CDN), which results in accessing it over the internet, rather than bundling the component with the application.
White-box reuse is reuse in which the user requires access to the internal implementation of the component in order to make modifications. It is more popular with many implementers because the component can be tailored to fit the exact needs of the target system. However, the productivity benefits of reuse can rapidly diminish as more modifications are introduced. White-box reuse is more common where systems overlap one another but have distinct requirements for their given domain. For example, web browsers will often be customised for specific use cases.
Open source software often presents the best of both worlds. Those wishing to reuse a component as a black-box can do so by downloading the binary releases of the software, whilst those requiring white-box reuse can obtain the project's source code in order to make modifications. There is no need to decide in advance whether black-box or white-box is required, since one can move to the white-box model if limitations in the black-box model are identified. Furthermore, an open source project that is developed using an open development model will help project teams ensure that local modifications do not prevent upgrades to new versions of the component in the future.
The process of finding and evaluating software for reuse is similar, regardless of the mode of reuse. The key steps in the process are:
Perhaps the hardest of these steps is 'Evaluating the candidates to determine which (if any) should be used'. Failure to reject unsuitable components at the earliest opportunity will result in wasted effort in later stages. Reuse Readiness Levels (RRLs) are specifically designed to assist in this evaluation, by clearly defining a set of criteria against which a component can be evaluated for reuse. Applying a consistent set of criteria to components ensures that all aspects are considered and that all components are considered equally.
Using the RRLs to guide evaluation allows one to rate the component on a reuse maturity scale. The higher up this scale a component is rated, the easier reuse is likely to be. The lower down the scale, the more effort is required for reuse. Any software component can be measured against this scale, regardless of the development process adopted. However, since open source components allow the user to modify the component directly, reuse of lower-level components is often significantly easier for open source components than for closed source.
A reusable software component will typically be self-contained and have clearly defined boundaries with respect to what it does and does not do. At these boundaries it will present an equally clearly defined set of interface points that will allow easy integration with other components. For most users, the interface will be sufficient to allow reuse; that is, the implementation will be hidden through encapsulation.
For those users who need to modify the internals of the component in some way, for example to add a feature, or fix a previously undiscovered defect, a clear, unambiguous, and understandable specification for the component will be required. The component will then conform to the specification and user-reproducible tests will validate this conformance. This allows users to modify implementation details, assuming source code is available, without fear of breaking existing systems using the component.
When distributing a reusable software component, it is also important to provide clear documentation on how to reuse it, along with example applications and installation guides and scripts. Finally, it is critical that the component is correctly licensed and full details are made available to the end user.
Maturity models are not a new or unique concept. They are commonly used in many areas of endeavour to measure and manage progression along a scale of maturity. For example, the Carnegie Mellon Capability Maturity Model Integration provides a number of models for software development, acquisition and service provision. The Open Source Maturity Model, Software Sustainability Maturity Model and Qualification and Selection of Opensource Software are all examples of evaluative techniques that address software component maturity. However, each of these models focuses on open source components rather than software components in general.
The Reuse Readiness Levels are designed to allow evaluation of any software component, regardless of the development methodology of that component. In the case of black-box reuse, evaluation using these levels is sufficient in most cases. However, white-box reuse of open source requires engagement with the project community, for example to make sure local modifications can be fed back to the original project. As such, white-box reuse requires an evaluation of the development methodology and project community. The Reuse Readiness Levels do not provide a mechanism for such an evaluation. Therefore, we suggest also evaluating using one of the other models mentioned above.
The Reuse Readiness Levels consist of nine levels of reuse, which are shown in the table below. While these levels are useful, they are often found to be too broadly defined. Consequently, a number of Topic Levels have been defined. These provide a means for evaluating specific aspects of reuse and are discussed in the next section.
A component is evaluated across a number of topic levels, each of which provides guidance about what one can expect at each reuse level. The topic levels defined are:
Once each topic has been evaluated, it is possible to arrive at an overall reuse level for the software component as a whole. For example, we may decide that the lowest level achieved across all topics is the level of the component as a whole, or we may add a weighting to one or more topic levels.
As an example of the topic levels, a summary of the Intellectual Property Issue levels is provided below:
Software component reuse can enable considerable savings in the development of new systems. However, evaluation of components for reuse can be difficult when considering non-technical issues. Reuse Readiness Levels (RRLs) provide a structured way of evaluating a component for reuse. Having such a structure helps ensure that all aspects of reuse are considered and allows users to make more informed choices, while developers can set priority targets for improving reusability of the component. RRLs have advantages over other evaluation systems in that they allow a comparison of software components, regardless of the development methodology adopted. For black-box reuse, this makes RRLs widely applicable. However, where white-box reuse (requiring modifications to the component) is to be considered, RRLs fail to evaluate the suitability of the project development methodology for such reuse. In these cases RRLs should be supplemented with existing open source maturity tools. For an exploration of the wider issues in software procurement, OSS Watch has produced a guide to the Decision factors for open source software reuse.
It is licensed under the
Creative Commons Attribution-ShareAlike 2.0 England & Wales licence.
OSS Watch is funded by the Joint Information Systems Committee.