What is software reuse?

Software reuse is a term used for developing the software by using the existing software
components. Some of the components that can be reuse are as follows;

▪ Source code

▪ Design and interfaces

▪ User manuals

▪ Software Documentation
▪ Software requirement specifications and many more.

What are the advantages of software reuse?

▪ Less effort: Software reuse requires less effort because many components use in the
system are ready made components.

▪ Time-saving: Re-using the ready made components is time saving for the software
team.

▪ Reduce cost: Less effort, and time saving leads to the overall cost reduction.

▪ Increase software productivity: when you are provided with ready made
components, then you can focus on the new components that are not available just
like ready made components.

▪ Utilize fewer resources: Software reuse save many sources just like effort, time,
money etc.
▪ Leads to a better quality software: Software reuse save our time and we can
consume our more time on maintaining software quality and assurance.

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 :
Figure : Level-1

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 :

Figure : Level-2

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 code 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 :

Figure : Level-3

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 tracked with a version number. At this
level, when the bug is discovered, the exact version of the component with the bug can be
identified.

Reuse Oriented Model

Reuse Oriented Model (ROM), also known as reuse-oriented development (ROD), it can be
steps of the software development for specific duration in which software is redesigned
through creating a sequence of prototypes known as models, every system is derived from the
previous one with constant series of defined rules.

The reuse-oriented model isn’t always sensible in its pure form due to cause of an entire
repertoire of reusable additives that might not be available. In such cases, several new system
components need to be designed. If it is not done, ROM has to compromise in perceived
requirements, leading to a product that does not meet exact requirements of user. This model
depends upon perception that maintenance might be viewed as a pastime involving reuse of
existing system components.
The reuse model has 4 fundamental steps which are followed :
 1. To identify components of old system that are most suitable for reuse.

2. To understand all system components.

3. To modify old system components to achieve new requirements.

4. To integrate all of modified parts into new system.

Advantages :

• It can reduce total cost of software development.

• It can save lots of time and effort.

• It is very efficient in nature.

Disadvantages :

• Reuse-oriented model is not always worked as a practice in its true form.

• Compromises in requirements may lead to a system that does not fulfill requirement
of user.

• Sometimes using old system component, that is not compatible with new version of
component, this may lead to an impact on system evolution.