Explain reusability What parts of a software can be reusable

Explain re-usability. What parts of a software can be re-usable?

Solution

Re-usability :

reusability is the use of existing assets in some form within the software product development process. Assets are products and by-products of the software development life cycle and include code, software components, test suites, designs and documentation. Leverage is modifying existing assets as needed to meet specific system requirements.

Software reuse is the process of implementing or updating software systems using existing software components. A good software reuse process facilitates the increase of productivity, quality, and reliability, and the decrease of costs and implementation time. An initial investment is required to start a software reuse process, but that investment pays for itself in a few reuses.

Types of Reuse:

1) Horizontal reuse:

Horizontal reuse refers to software components used across a wide variety of applications. In terms of code assets, this includes the typically envisioned library of components, such as a linked list class, string manipulation routines, or graphical user interface (GUI) functions. Horizontal reuse can also refer to the use of a commercial off-the-shelf (COTS) or third-party application within a larger system, such as an e-mail package or a word processing program.

2) Vertical reuse :

Vertical reuse, significantly untapped by the software community at large, but potentially very useful, has far reaching implications for current and future software development efforts. The basic idea is the reuse of system functional areas, or domains, that can be used by a family of systems with similar functionality. The study and application of this idea has spawned another engineering discipline, called domain engineering. Domain engineering is \"a comprehensive, iterative, life-cycle process that an organization uses to pursue strategic business objectives.

Prerequisites to Creating Reusable Software :

Unfortunately, software reuse doesn\'t just happen. also known as opportunistic reuse, doesn\'t reap the same large-scale benefits as a domain engineering approach. And it\'s not just a technical issue; it is highly managerial in nature. As much as libraries of reusable code and other assets are important, they will not be fully utilized without management and process support of reuse.

Organization and Process

The classical software development process does not support reuse. Reusable assets should be designed and built in a clearly defined, open way, with concise interface specifications, understandable documentation, and an eye towards future use. Typically, customer, client, and contract projects are built as \"one-time only,\" without reuse in mind, and tend to be tightly bound within themselves, without the more robust open interfaces which ease the reuse process.

Technical Expertise:

Transferring to a product line approach requires some different technical skills than traditional software development processes, along with many of the current familiar techniques, such as layered architectures, object-oriented programming, information hiding, and abstract interfaces, to name a few. One \"new\" addition, an aspect of domain engineering, is domain analysis, which involves producing a domain model of the product line that identifies common members and allowable variations for each. A product line software architecture is built based on the domain model, the backbone for all current and future product line family members.

3. Reuse Costs - The Investment:

There is no denying the large cost associated with starting a reuse program. It is an extra cost on top of the traditional development costs, since designing reusable assets takes more time and care than designing a one-time specific system. The upfront investment spans organizational, technical, and process changes, as well as the cost of tools to support those changes, and the cost of training people on the new tools and changes.

Process

The software development process must be enhanced to include reuse activities. A reuse library or repository must be created and maintained, and tools must be acquired or developed to access the assets, and many new procedures must be specified:

Domain Analysis and Software Architecture Design

To implement a product line approach, a group of domain experts must be established and maintained to perform domain analysis and develop architectures for the domain. In their analysis, this group must partition the domain into segments that can be developed independently and can evolve for future changes. This partitioning usually involves the determination of specific functional areas, along with roles and responsibilities.

4. Reuse Advantages - The Payoff:

With all the costs and prerequisites outlined above, software reuse may seem like more effort than it is worth. However, the number of success stories with increases in productivity, quality, and reliability, and decreases in production time, hint toward a goal worth achieving.

Higher quality products are produced due to repeated use and test, and intentional design for robustness and reuse. Each successive use of a given software asset will retest it, and the more tests performed, the more likely defects will be found and corrected. Every successful reuse of an asset increases it reliability level, increases its usefulness in the reuse repository, and decreases the risk of failure.