1.1 INTRODUCTION

Reuse, in the context of software engineering, can be defined as "the process of creating software systems from existing software systems, rather than building software systems from scratch" [1]. It has also been defined more fully as "the systematic process of developing software from a stock of building blocks, so that similarities in requirements and/or architecture between applications can be exploited to achieve substantial benefits in productivity, quality and business performance" [2]. Most traditional engineering disciplines make far more use of reusable components than Software Engineering does at present. Mechanical and Electrical engineers, for example, do not design systems which require the majority of parts to be produced specifically for that system. They base the design around existing tried and tested components, everything from nuts and bolts to entire engines [3]. Software designers have not yet made the same advances, despite there being some 100 billion lines of code in existence [4]. The concept of reuse is explained more fully in section 1.2, and a description of the types of components and products which can be reused can be found in section 1.3. There are many benefits to reusing components of systems. These include more efficiency in the use of time, money and skills, and also more reliable and better quality software [3]. The benefits of reuse are explained more fully in section 1.6. These technical benefits will lead to associated business and economic benefits which are explained in section 1.6.3. There are different types of reuse, and different levels at which a company can operate within the reuse framework. These are explained in sections 1.4 and 1.7 respectively. There are also several different activities associated with implementing a reuse programme, these are covered in section 1.8.

1.2 WHAT IS SOFTWARE REUSE?

As stated in section 1.1, software reuse at its most basic level consists of making use of any existing information, artefact or product when designing and implementing a new system or product. There are differing opinions as to which activities constitute genuine software reuse. For example, using a library routine for calculating square roots in several different programs is a good example of successful reuse, but calling that same routine many times within the same program does not technically constitute reuse [1]. Replication of an entire software program does not count as reuse. Reuse of assets is dependent upon both similarities and differences between the applications in which the component is being used [2]. Many organizations already practice a limited form of reuse, for example, most developers have libraries of components that they have developed in previous projects, or they use standard libraries which are available with many programming languages [5]. About 30% of most code is developed with this type of reusable components where the developer is simply using his own work from previous projects [6]. This is a very ad-hoc method of reuse, and while it will work very well on a small scale, for example an individual programmer or a small team, it will not be suitable for entire organisations [7]. Instead, businesses need to implement a systematic reuse program in order to gain the full advantages of reuse. Organisations need to have mature processes which are used throughout the company and metrics to measure the success of the reuse process. They need to understand how reuse can benefit the whole organisation and how they need to build a reuse program into their way of working.

1.3 WHAT CAN BE REUSED?

The definition of a reusable component is "any component that is specifically developed to be used, and is actually used, in more than one context" [5]. This does not just include code, other products from the system lifecycle can also be reused, such as specifications and designs [3], and even requirements on occasion [8]. 'Components' in this case can be taken to include all potentially reusable products of the system lifecycle, including code, documentation, design, requirements etc. There are various criteria which should be satisfied in order for an asset to be successfully reusable. These are grouped into General, Functional and Technical requirements [2]. General requirements focus on aspects such as compliance with relevant standards, completeness, modularity and simplicity. All components should conform to the General requirements. Functional requirements includes such concerns as which business processes it will simulate or automate, and how well it does this. Functional requirements mainly concern Vertical or Domain-specific assets (explained further in section 1.4) and tend to be very specific to each information domain. Lastly, Technical requirements refer to criteria such as interoperability, portability, communication, security etc [2]. There are different levels of reuse which can be considered [3]. At the highest level, entire applications can be reused on different platforms provided they are portable. Sub-systems can be reused within different applications, possibly within different domains, for example, a login system could be used in a database application as well as a control application. At a lower level modules or objects can be reused, and at the very lowest level single functions can be reused. This is also known as classification of the granularity of components. Fine grained is used to describe those smaller and more generic components, for example file access functions, or I/O functions. Course grained is used for the more complex components, for example user-interface packages [5]. Reusable assets can be built in-house, retrieved from legacy systems or can be bought from an external source [9]. Many components are available free of charge from Universities or non-profit-making organisations as it is very difficult to make a profit selling generic components [5]. The provision of a repository of components is something which must be considered before a company introduces a reuse programme as components may need to be adapted before they can be put into the repository [9].

1.4 TYPES OF REUSE

Three types of software reuse have been identified - Vertical or Domain reuse, Horizontal or General reuse and Product-line reuse. Vertical reuse occurs when a component is specific to an application domain for example assets which capture the business knowledge such as the design and code for a customer management model, or financial object models. These can be reused in other applications within the same domain [2]. This type of reuse will not work within all domains, for example, it will be difficult to achieve successful reuse for domains which have time and space constraints. Companies have attempted to turn domain-specific reuse into a marketable opportunity, by carrying out domain analysis and developing components to sell, but not many have succeeded so most successful programmes are internal [5]. The reuse of Horizontal assets, sometimes called General reuse, are those which can be reused within other application domains, for example user interfaces or database connections libraries [2]. Components tend to be abstract data types with common behaviour throughout different domains [5].

1.5 WHY IS REUSE NOT VERY COMMON?

There are many reasons why reuse is not very common in many organisations. One problem is that many managers cannot be convinced of the benefits of reuse until they are demonstrated in real projects, which of course cannot be done until it is introduced in the organisation [3]. There may be problems with starting to collate resources for the reuse repository, and with the categorising and indexing of them [10]. Managers may also feel that a reuse programme may lead to a loss of budget for them, due to the higher levels of productivity cited, or they may feel that a failure in the programme would involve their budget being used to deal with the problem [9]. There are other considerations on the programmers side, for example, the not-invented-here issues where the developers may feel that they cannot trust the quality of the components, or a fear that the measurements being brought in to determine the success of the reuse programme, may be used to measure their performance as well [9].

1.6 BENEFITS OF REUSE

There are several potential benefits to an organisation of implementing a successful reuse process. The main technical benefits include improving the productivity of the development team, and increasing the quality of the software products produced [11], leading to business related benefits including reduced costs, reduced time-to-market and better customer service because of reduced costs etc.

1.6.1 Improving Productivity

The first main aim of reuse is to improve the productivity of the developers [11]. This is achieved because of the reduced development time, due to the fact that the components have already been built. The components have also already been tested, although not within the new system, but potentially within a number of systems if they have been reused several times [3]. In order for a component to be suitable for reuse, it must have appropriate documentation and have been tested thoroughly, and ideally should also have been certified to confirm their quality. Productivity is increased and the development time reduced which helps with the ever-decreasing time-to-market or Lead Time factor which is becoming the most important factor in the highly competitive and rapidly changing technology market [5]. Businesses can capitalise on this reduced time-to-market by becoming more competitive and providing a better service for their customers. They can produce more products in a shorter time, or they can provide better support for their existing products. Reuse will help to reduce both the development and the maintenance time required for a product [12]. There can be a cost associated with reuse, that is of developing the components the first time (Development for reuse), as this may take longer than usual due to the more complex nature of the product to abstract it and provide a reusable component, but this should be seen as an investment for the company [5]. There will also be a cost involved in setting up and maintaining the reuse repository.

1.6.2 Improving Software Quality

The quality of the software produced is increased by the introduction of a reuse programme because the components used will have already been tested in 'live' programs and in a variety of situations if they have been used in other projects, and therefore any problems should have been rectified already [7]. The reuse of components also improves the reliability of the system for the same reasons. The reused components have been tested in a variety of realistic operating conditions and therefore should be more reliable [3]. Components can also be used for prototyping which will help the client to clarify their requirements and thus reduce potentially costly changes later in the development process [7]. The introduction of a reuse programme will also help to implement quality standards within software development. Not only will reusable components introduce standards by default, but also it is easier to enforce the use of components which already satisfy the standards than it is to check new components for compliance [12]. The introduction of standards into a development process will help to improve the quality of the software.

1.6.3 Business Benefits

The organisation will benefit both economically and otherwise from a reuse programme. The improvements in productivity will lead to quicker production of products and components, and also to higher profits or cheaper products. This will give them a shorter time-to-market which will improve the competitiveness of the organisation within its own domain. The improvements in product quality will lead to better service for the customers and ultimately a better image for the business. Other, less obvious benefits include the chance of both direct and indirect new business opportunities as the components themselves can be sold, or new markets can be identified [12]. Economic benefits will include saving money on the development of new products, saving money on the productivity of the development team, and reducing the time-to-market of a new product.

1.7 LEVELS OF REUSE

There are typically four levels of reuse which a company can be achieving. Which level an organisation is working at can indicate how mature their reuse processes are and what can be done to improve them, leading to the benefits listed in Section 1.6.

Figure 1.1 - Levels Of Reuse [Lim 1998, page 166]

The four levels of reuse are

1) Ad Hoc - at this level engineers tend to reuse their own libraries and code fragments when they notice a similarity between the projects. Most organisations practice this level of reuse, even if they are not aware of it [7]. There is no systematic reuse plan, and sharing of resources tends to occur accidentally or informally [9].
2) Systematic Reuse - this is driven by a well ordered process and co-ordinated planning. Resources are allocated specifically for a reuse program and it is fully supported by the management [7].
3) Domain-Oriented Reuse - at this level the company focuses on creating a library of reusable assets within the existing and future business domains. This allows the organisation to build up a repository of reusable components and therefore to be more competitive [7].
4) Strategy-Driven (or Cultural) Reuse - this is the highest level of reuse. Reuse helps to define the development of new products and processes. For example, a manager may ask "how can I diversify in such a way which allows me to reuse as much as I can of the products we already produce?" [7]. Reuse is accepted as part of the process of development, and should no longer require targets or incentives [9].

1.8 REUSE ACTIVITIES

There are two main reuse activities - Development For Reuse and Development With Reuse. The difference between the two activities is that development for reuse is when new components are designed in order to be reused, and development with reuse is when existing components are made use of within a new system. Ideally the two activities should be carried out in conjunction with each other to create an environment of reuse within a company. Early introduction of development for reuse can help to encourage the use of reuse driven development, as there will be a large store of products available for reuse within the company.

1.8.1 Development With Reuse

Development with reuse, or reuse driven development, is the activity of reusing components within a new system. It has been defined as "the search for, evaluation, adaptation and integration of existing components in a new context" [5]. Developers must consider the use of existing components at the design stage of the process rather than the implementation, as it is in other traditional engineering disciplines, for example, mechanical engineers design new engines from a stock of parts rather than designing the engine and then checking if any existing parts will be suitable [3]. Components should be thoroughly investigated to ensure that they suit the requirements and that they have appropriate test records and development documentation [5]. Components need to be fully documented to facilitate easy searching, evaluation of the component, investigation, adaptation and integration. This means that a component must have three types of documentation: Engineering Documentation, Product Documentation and Maintenance Documentation. These will cover all aspects of the component from the development process through to the future evolution and maintenance [5]. To carry out reuse driven development successfully there are three conditions which an organisation must fulfil. They must a) have sufficient resources which are easy to find and catalogue; b) have introduced standards which will ensure confidence in the components behaviour, and c) have associated documentation for the use of the user to help them understand the component [3]. The following process is proposed for development with reuse:

Figure 1.2 - Process for Development With Reuse [Karlsson, page 346)]

The process described above will allow the successful identification and adaptation of a component into a software system. First the requirements for the component must be identified, and a search made for existing components which satisfy these requirements. When a component has been located, it must be understood and potential adaptations noted in order for it to be easily compared with others. Once a suitable component has been selected from those located by the search, it should be adapted as necessary and integrated into the system. Finally, a report should be written on the adapted component in order to assist future users of the product. [5].

1.8.2 Development For Reuse

Development for reuse is the activity of designing new components with reuse in mind. It has been defined as "the planned activity of constructing a component for reuse in contexts other than the one for which it was initially intended" [5]. This makes them more difficult to design as the generic nature must be taken into account, and possibly a component designed to include excess functions which are not needed immediately but will improve the marketability of the product later on.

1.9 SUMMARY

There are many benefits and a few costs associated with the introduction of a reuse programme into an organisation. There are the obvious direct costs for the set-up and maintenance of the software repository as well as the increased development costs to initially develop reusable components. However, these are far outweighed by the benefits which include enhanced productivity of developers leading to reduced development costs, reduced maintenance and testing costs due to the increased reliability of the software components, and therefore better quality software. The business benefits include reduced time-to-market, increased software quality and therefore a better customer image and improved service to consumers. The majority of components from the system lifecycle can be reused, some more easily and more successfully than others.

Bibliography

[1] C. W. Krueger, "Software Reuse," ACM Computing Surveys, vol. 24, 1992.
[2] M. M. Ezran, Maurizio; Tully, Colin, Practical Software Reuse: the essential guide: SURPRISE Project, 1999.
[3] I. Sommerville, Software Engineering. Harlow, Essex: Addison Weslet Longman Limited, 1995.
[4] I. G. Jacobson, Martin; Jonsson, Patrik;, Software Reuse: Architecture, Process and Organisation for Business Success. New York: ACM Press, 1997.
[5] E.-A. Karlsson, Software Reuse: A Holostic Approach. Chichester, UK: John Wiley & Sons Ltd, 1995.
[6] F. P. Brooks, The Mythical Man-Month, 2nd ed: Addison Wesley Longman, Inc, 1995.
[7] W. C. Lim, Managing Software Reuse. London: Prentice-Hall Inc, 1998.
[8] M. K. Mannion, Barry; Kaindl, Hermann; Wheadon, Joe, "Reusing Single System Requirements from Application Family Requirements," presented at 21st International Conference on Software Engineering, 1999.
[9] A. a. L. Lynex, Paul J, "Organisational considerations for software reuse," Annals of Software Engineering, vol. 5, pp. 105 - 124, 1998.
[10] H. Gomaa, "Reusable Software Requirements and Architectures for Families of Systems," Journal of Systems and Software, vol. 28, pp. 189-202, 1995.
[11] A. M. d. W. Cima, Claudia M L; Cerqueira, Alessandro A C, "The Design of Object-Oriented Software with Domain Architecture Reuse," presented at 3rd International Conference on Software Reuse, 1994.
[12] W. P.-d. Schafer, Ruben; Matsumoto, Masao, Software Reusability. Hemel Hamstead, UK: Ellis Horwood Limited, 1994.