Reuse Readiness Rating
by Ross Gardler on 14 July 2009 , last updated
Introduction
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.
What is software reuse?
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.
Reusing software components
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 delivery 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.
Evaluating for reuse
The process of finding and evaluating software for reuse is similar, regardless of the mode of reuse. The key steps in the process are:
- Specifying the object to be created
- Searching the project, domain, and general databases for reuse candidates
- Evaluating the candidates to determine which (if any) should be used
- Modifying, if necessary, to fit specific needs
- Integrating the reusable component(s)
- Validating the system including the new component(s)
- Feeding back the knowledge regarding the payoff of reuse
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.
Requirements for a reusable software component
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.
Reuse readiness levels
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 Open Source 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.
Reuse Readiness Level Summaries
| Level | Summary | Description |
|---|---|---|
| 1 | Limited reusability; the software is not recommended for reuse. | Little is provided beyond limited source code or pre-compiled, executable binaries. There is no support, contact information for developers or rights for reuse specified, the software is not extensible, and there is inadequate or no documentation. |
| 2 | Initial reusability; software reuse is not practical. | Some source code, documentation, and contact information are provided, but these are still very limited. Initial testing has been done, but reuse rights are still unclear. Reuse would be challenging and cost-prohibitive. |
| 3 | Basic reusability; the software might be reusable by skilled users at substantial effort, cost, and risk. | Software has some modularity and standards compliance, some support is provided by developers, and detailed installation instructions are available, but rights are unspecified. An expert may be able to reuse the software, but general users would not. |
| 4 | Reuse is possible; the software might be reused by most users with some effort, cost, and risk. | Software and documentation are complete and understandable. Software has been demonstrated in a lab on one or more specific platforms, infrequent patches are available, and intellectual property issues would need to be negotiated. Reuse is possible, but may be difficult. |
| 5 | Reuse is practical; the software could be reused by most users with reasonable cost and risk. | Software is moderately portable, modular, extensible, and configurable, has low-fidelity standards compliance, a user manual, and has been tested in a lab. A user community exists, but may be a small community of experts. Developers may be contacted to request limited rights for reuse. |
| 6 | Software is reusable; the software can be reused by most users although there may be some cost and risk. | Software has been designed for extensibility, modularity, and portability, but software and documentation may still have limited applicability. Tutorials are available, and the software has been demonstrated in a relevant context. Developers may be contacted to obtain formal statements on restricted rights or to negotiate additional rights. |
| 7 | Software is highly reusable; the software can be reused by most users with minimum cost and risk. | Software is highly portable and modular, has high-fidelity standards compliance, provides auto-build installation, and has been tested in a relevant context. Support is developer-organized, and an interface guide is available. Software and documentation are applicable for most systems. Brief statements are available describing limited rights for reuse and developers may be contacted to negotiate additional rights. |
| 8 | Demonstrated local reusability; the software has been reused by multiple users. | Software has been shown to be extensible, and has been qualified through test and demonstration. An extension guide and organization-provided support are available. Brief statements are available describing unrestricted rights for reuse and developers may be contacted to obtain formal rights statements. |
| 9 | Demonstrated extensive reusability; the software is being reused by many classes of users over a wide range of systems. | Software is fully portable and modular, with all appropriate documentation and standards compliance, encapsulated packaging, a GUI installer, and a large support community that provides patches. Software has been tested and validated through successful use of application output. Multiple statements describing unrestricted rights for reuse and the recommended citation are embedded into the product. |
Topic levels
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:
- Documentation
- Extensibility
- Intellectual Property Issues
- Modularity
- Packaging
- Portability
- Standards compliance
- Support
- Verification and Testing
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:
Levels of Intellectual Property Issues
| Level | Summary |
|---|---|
| 1 | Developers have been identified, but no rights have been determined. |
| 2 | Developers are discussing rights that comply with their organizational policies. |
| 3 | Rights agreements have been proposed to developers. |
| 4 | Developers have negotiated on rights agreements. |
| 5 | Agreement on ownership, limited reuse rights, and recommended citation. |
| 6 | Developer list, recommended citation, and rights statements have been drafted. |
| 7 | Developer list and limited rights statement included in product prototype. |
| 8 | Recommended citation and intellectual property rights statement included in product. |
| 9 | Statements describing unrestricted rights, recommended citation, and developers embedded into product. |
Conclusion
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.
Further reading
Links:
- Earth Science Software Reuse Working Group [ http://earthdata.nasa.gov/our-community/esdswg/ ]
- The working group’s recommendation for a set of Reuse Readiness Levels v1.0 [ http://earthdata.nasa.gov//sites/default/files/esdswg/reuse/Resources/rrls/RRLs_v1.0.pdf ]
- Reuse Readiness Levels as a Measure of Software Reusability [ http://earthdata.nasa.gov/sites/default/files/esdswg/reuse/Resources/library/Publications/2008_IGARSS-RRL-Paper.pdf ]
Related information from OSS Watch: