Software Reuse

Software reusability is the likelihood a piece of source code that can be used again to add new functionalities with slight or no modification. Programmers have always reused sections of code, functions and procedures. Code reuse is the idea that a partial or complete computer program written at one time is being or should be used in another program written at a later time. The concept of software reuse emerged as a recognized area after proposed basing of industry on reusable components. To achieve full potential of reuse, we need to focus our attention on development for reuse.

Organizations implementing systematic software reuse programs must be able to measure their progress and identify the most effective reuse strategies. Metrics and models with various reuse readiness levels can be used to measure reuse and reusability. Current reuse techniques focus on the reuse of software artifacts on the basis of desired functionality. Nonfunctional properties of a software system are also crucial.

Quality concerns, therefore, should also be the focus for software reuse. This Mathematical Theory of Intelligence structures objects in such a way that they become maximally reusable, interoperable and archival. The theory claims that reusability of an object is maximized if the object itself is defined as having been produced by maximizing reuse of the operations that were used to produce it. Many metrics and models have been developed for software reuse and reusability.

Introduction of Software Reuse:

Software reuse is the process of creating software systems from existing software rather than building software systems from scratch. Something that was originally written for a different project will usually be recognized as reuse. Code reuse is the idea that a partial or complete computer program written at one time can be, should be, or is being used in another program written at a later time. The reuse of programming code is a common technique which attempts to save time and energy by reducing redundant work. Software assets, or components, include all software

products, from requirements and proposals, to specifications and designs, high level designs, data formats, algorithms to user manuals and test suites.

Anything that is produced from a software development effort can potentially be reused. Software developed and used repeatedly by the same people on the same project, Product maintenance and new product versions, use of operating systems, database management systems, and other system tools doesn’t amount to reuse. Software engineering has been more focused on original development but it is now recognised that to achieve better software, more quickly and at lower cost, we need to adopt a design process that is based on systematic software reuse.

For systematic reuse to succeed organizations must recognize that good components, frameworks, and software architectures require time to design, implement, optimize, validate, apply, maintain, and enhance. Creating reusable software assets requires a mature organization whose developers and architects can distinguish key sources of variability and commonality in their application domain. Identifying and separating these concerns for complex networked applications requires an iterative development process since it's hard to design reusable  artifacts correctly the first time using a topdown “waterfall” software lifecycle model.

Why Software Reuse:

A good software reuse process facilitates the increase of productivity, quality, and reliability, performance and the decrease of costs, effort, risk and implementation time. An initial investment is required to start a software reuse process, but that investment pays for itself in a few reuses. In short, the development of a reuse process and repository produces a base of knowledge that improves in quality after every reuse, minimizing the amount of development work required for future projects, and ultimately reducing the risk of new projects that are based on repository knowledge.

Reusing code saves programming time, which reduces costs. If one person or team has already solved a problem, and they share the solution, there's no need to solve the problem again (with some potential caveats see Drawbacks).

• Sharing code can help prevent bugs by reducing the amount of total code that needs to be written to perform a set of tasks. Generally, the more code a system contains the more bugs it's likely to have. The shared code can also be tested separately from the applications which use it.

• Separating code into common libraries lets programmers specialize in their particular strengths. A security library, for example, can be built by securityexperts while a user interface which uses the library can let UI experts focus on
their tasks.

• Repeatedly, separating code into specialized libraries lets each be tuned for performance, security, and special cases. For example, a Python application might delegate graphics functionality to a C library for performance.

• Delegation of tasks into shared modules allows offloading of some functionality onto separate systems. For example, a system specialized for fast readonly database queries can be used for reporting and accessed by multiple
desktop applications.

• Proper and efficient reuse of code can help avoid code bloat. Bloated code contains unnecessary duplication and unused instructions. By efficiently sharing code across systems each individual component avoids duplicate or unneeded functionality.