Reuse Maturity Model
Software Reuse is the process of creating software systems from existing software systems, rather than building software system from scratch.”
REUSE MATURITY MODEL :
It is based on the experience within software development organization as well as experience with and observations of other development organizations.
LEVEL-1 : Single Project Source Based Reuse –
At the very first maturity level, organizations placed all their source code within a single project. After this, the single pool of source code will hold multiple applications as depicted in the following figure :
Project A is home to two applications A and B. There is no need to copy source files or compiled files from one project to another because there is only one project. But there is a limit that how well this practice will scale. When number of applications or number of developers increases, to maintain the single source code will become difficult.
LEVEL-2 : Multi Project Source Based Reuse –
In this stage, source code is divided into multiple projects and practice source-based reuse between projects. In this scenario, source-based reuse copies source developed in one project into another project. Main target of such reuse is utilities, which can be developed in one project and can be used in the another project. It is as shown in the following figure :
Project A is home to application A and project B is home to application B. The code which is common to both the projects is copied into both projects.
Problem with this is that, after copying, reused source code has to link back to the original. This cause all sorts of maintenance problems, since bug fixes will have to be applied to every project that reuse copied code. Also, two host projects evolve reused code will evolve with them, which makes maintenance more difficult.
LEVEL-3 : Ad hoc Binary Reuse –
This is next step after level 2. Organizations are advance to level and will realize drawback of level 2. Under this approach, project boundaries realign and there is no longer mirror boundaries. Projects at this level, can correspond to applications. Utility source cod that was copied from one project to another at previous level is now placed in its own project and has its own lifecycle independent of the application projects.
Application projects include binary artifacts of utilities project, and a dependency relationship between projects is established. Maintenance of utilities project is greatly simplified because rather than maintaining multiple diverging copies of utilities, only a single version needs to b maintained. Also application requires additional features, thus application features become available to all applications using utilities as shown in the following figure :
But in this, there are no release procedures or dependency management procedures. Adding new features makes it impossible to know exact version of utilities used in application. Also, with this when a bug is discovered it is difficult to know what version of code based= contained bug. After a fix is implemented, it is difficult to know whether newest version will be compatible with all applications projects that need utilities library.
LEVEL-4 : Controlled Binary Reuse and the Reuse/Release Equivalence Principle –
It is based on ad hoc binary reuse. The project boundaries remain same, with application projects and component projects. At this level, each release of a project is controlled and trackled with a version number.
At this level, when the bug is discovered, the exact version of the component with the bug can be identified.