Introduction

This paper details the fundamentals of asset reuse methods. Asset reuse is the process of creating software systems from predefined software components. Reuse methods have two sides: 1) The development of reusable components and 2) the reuse of these components during the creation of new projects.

The reusability of components (other than coding) achieves greater benefit when used with software specifications, test cases, designs, prototypes, plans, frameworks and templates.

The use of reusing software components can cut development costs through:

·         Increased software productivity

·         Shorter software development cycles

·         Improved software system interoperability

·         Development of software with fewer people

·         Movement of developers more easily from project to project

·         Reduced software development and maintenance costs

·         Production of more standardised software

·         Production of better quality software

·         Provision for a more powerful competitive advantage

Reuse makes sense because the similarity found across software systems is enormous and undeniable. When we compare software systems, we usually find 60-70% commonality from one software application to another [cm96]. At all levels of the development cycle there are components that by their very nature do not change. Some software similarities can be predefined and built into software tools (such as reusable code patterns); others can be created as reusable components, which are stored in software reuse libraries.

The potential for reuse is enormous since the majority of each new application could be assembled from reusable components if the appropriate components could be predetermined and built prior to system development. Thus, it is a tremendous waste of resources to needlessly “re-invent-the-wheel” [cm96] as is advocated in traditional develop-from-scratch software process models.

Management commitment and support of system projects is easier to obtain when the business value of a system can be clearly demonstrated to management. Likewise, the support for reuse is easier to obtain when reuse is linked to business strategies.

Reuse must be viewed as a business strategy, and the reuse program for the company must be market-driven in the sense that the company invests in reuse components that can be used to build systems needed and wanted by the company. This means that the requirements of future systems must be identified, reusable components that can fulfill common requirements must be created, and all this must be done prior to developing these systems. In other words, to succeed with reuse, reuse must be planned [cm95].

An obstacle to reuse is the mistaken belief that reuse only applies to reusing parts of existing legacy systems, and therefore is based on old technology and old systems that do not reflect present and future company needs. Using its strategic plan to direct its reuse strategy, the company can assure that its reuse efforts are focused on identifying and acquiring or building the “right” reusable components; namely, those that can be used as building blocks in developing the systems that are of the greatest business value to the company now and in the future.

Domain Analysis

Introduction

Domain analysis is the second phase of reuse. Domain analysis is the process used to create a set of reusable components to be used in developing systems in a domain. A domain is a set of systems whose common properties make it advantageous to organise these into a collection of reusable components. These can then be used to construct future systems or versions of systems. Put simply, a domain is a family of related systems. Examples of a domain are systems that support a particular business function or particular application such as airline reservations. In the information-engineering world, a domain may correspond to a business area or business function or application family. While the focus of reusebased planning was the entire enterprise, the focus of domain analysis narrows down to a specific domain. Domain analysis may be performed multiple times, once for each domain in which reuse is proposed to be practiced.

Domain analysis is essential to formalising reuse. However, it is missing from most software development methods. Reuse engineering extends information engineering by adding the new stage “Domain Analysis” to provide a place in the life cycle where the most valuable reusable components for the domains of the enterprise can be identified and a library containing these components can be created.

Domain analysis is a process like enterprise modelling that lifts software development above the single system level. One way to think of domain analysis is as systems analysis performed for a family of systems. It is an activity that occurs before systems analysis. The objective of domain analysis is to capture and model the information that describes a domain for the purpose of gaining a better understanding of the domain and/or to use this information to develop future systems for the domain from sharable reusable components such as generic architectures and processes.

Bottom Up

The usual approach to domain analysis has been to study past systems and experiences. This is essentially a bottom-up approach and makes domain analysis similar to a reverse engineering process. The difference between domain analysis and reverse engineering is that the purpose of domain analysis is to focus on common components in existing systems to learn how to create generic reusable versions of these common components by studying examples of how they have been implemented in previous systems.

A possible criticism of domain analysis is that it is based on studying existing systems which represent outdated technology from the past while the current corporate needs is to develop new systems that harness new technology. Studying existing systems in the domain may not provide appropriate useful building blocks and architecture for developing future systems in the domain.

To avoid this problem we must review during domain analysis, systems and models, which incorporate new technologies and the environments required for future systems, planned for the domain. Existing systems are studied to identify domain specific functionality and data that are also required in future systems in the domain. This type of information describes what systems in the domain do. Systems and models which support emerging technologies, which are to be, used in future systems in the domain also are studied. This type of information represents how system requirements are implemented. As a general rule of thumb, at least three high-quality, well-documented existing systems should be studied during bottom-up domain analysis [cm95].

Top Down

However, conducting domain analysis in a bottom-up fashion gives only half of the picture needed for discovering viable reusable components. We also must ask the question what components are likely to recur across future systems for the domain. Components that recurred in existing systems are only of reuse interest if they are also needed in the future to build new versions of existing systems of new systems. Information engineering, and in particular the enterprise models, can help fill in the other half of the picture. To analyse enterprise models in search of common, potentially reusable components for building future system, domain analysis must become a top-down process.

The most complete and effective way to perform domain analysis is as a combination of top-down and bottom-up processing. Reuse engineering incorporates domain analysis as a means of identifying, preparing and organising a collection of reusable components and generic architectures from the study of existing systems, predefined models and enterprise models.

When systems are studied during domain analysis, they are analysed from the perspectives:

·         Aspects that tend to change from system to system in the domain.

·         Aspects that tend to remain constant from system to system in the domain.

Domain analysis is the identification of commonality across a set of similar components to create a generic version of the component. Differences are the basis for creating a generic component that can be easily and safely adapted for each reuse.

Reuse-in-the-large

Common data and common processes are used as the basis for creating reusable components which enable component -based reuse or “reuse-in-the-small”. This has been the normal focus of reuse in the past [rpd91]. However, the bigger benefits from reuse are derived from practicing “reuse-in-the-large”. Common system structures are used as the basis for creating system design templates and system architectures to enable reuse-in-the-large.

Many of the decisions concerning the operation of the application are predefined and built into the application architecture. Then, when the architecture is reused, these decisions need not be remade. Also, the architecture serves as the construction framework for building new systems with reusable components that have been designed to fit into this generic architecture. The architecture is the “glue” for assembling system components, new and reused, to create a new application.

From a reuse engineering perspective, the purpose of domain analysis is to create a software reuse library that contains a critical mass of highly reusable components for a particular application domain.

Domain analysis is accomplished by performing the following steps:

·         Selecting the domain to be analysed.

·         Establish naming standards for the reuse components

·         Define a classification scheme

·         Examine in detail, samples of existing systems “bottom-up” and identify reusable components and generic architecture’s for implementation within a domain

·         Describe, document these reusable components and store them within a software reuse library.

Reuse-Based Design

During Reuse-based design, activities to support the two sides of reuse are included in the traditional information engineering system design process:

·         Use of available reusable components (such as reusable process designs, templates, design architectures and design prototypes)

·         Discovery and development of newly developed system components that can be used as the basis for creating new reusable components (such as application templates or design architecture) that can be used in order parts of the enterprise.

The reuse objectives are to improve the quality of the design produced and to reduce the cost of creating the system design by building it from reusable design components.

The basic steps for practicing reuse-based design are:

·         Look for existing reusable components to use in creating the system design

·         Follow standards when creating the system design

·         Check the design for redundancies, which can identify additional opportunities for using reusable component and improving the quality of the design

·         Check the design for ways to improve the reusability of the components

·         Look ahead to the building phase and modify the design if necessary to take full advantage of reuse opportunities at the next stage.

·         Review the design looking for new reusable components

Traditional system design as it is practiced in engineering provides a valuable base to support reuse because of the design standards it proposes and the design models it creates. Imposing design standards on user dialogs, function keys, network access, database access, documentation etc. not only produces a standardised system but also opens the door to more opportunities for practicing reuse.

An important reuse addition to the traditional engineering design process is to look for new reusable components that could be used in future system development. This requires expanding the programmer’s perspective from the single system, which is now being developed to other systems in the same family or domain.

Review of Reuse

Reuse engineering includes a “review of reuse” as the last stage of the methodology to evaluate the system quality and project success with respect to reuse goals. Reuse metrics are the basis for evaluating and determining reuse success. The review of reuse includes activities to review reuse costs, reuse value with respect to software and business goals, as well as the value of the process itself.

The objectives of the “review of reuse” are to:

·         Capture, evaluate and share reuse experiences, benefits and lessons learned in the project

·         Evaluate the value of practicing reuse in system projects

·         Learn how to improve the practice of software reuse in future system projects

The steps, which are performed during the “review of reuse”, are to:

·         Determine if the project achieved its reuse goals (explain results).

·         Make recommendations concerning tools needed to support the practice of reuse

·         Determine the cost of and the savings from practicing software reuse within the project

·         Make recommendations concerning how to justify the practice of software reuse within the project

·         Examine the system to determine if it or any part of it, including any associated project deliverables, could be used as the basis for creating new reusable components for reuse in future projects.

Reuse Metrics

Introduction

Reuse metrics are an essential part of reuse engineering. They help determine the extent by which reuse should be practiced in system development projects and what components should be created and stored for future reuse in the SRL (Software Reuse Libraries). The strategy of reuse engineering is to practice “selective reuse”, in other words, only in those projects where the payback from reuse is certain and only those components whose reuse presents the greatest value.

Selective reuse makes good business sense because practicing reuse is expensive and time-consuming and the effort increases with the number of things that are development and supported for reuse. Reuse metrics help zero in on these few, highly valuable components.

The metrics of reuse engineering are defined as:

·         Commonality of a component is used to measure how frequently a component recurs across a set or family of systems.

·         Reuse Threshold of a component is used to indicate the minimum number of times a reusable component must be reused to payback the investment in creating / preparing it for reuse.

·         Reuse Merit of a component is used to measure the reusability of a component relative to the average reusability of a component of the same type.

·         Reuse Creation Cost of a component is used to measure the cost of creating / preparing a component for reuse. This includes the costs of purchasing / developing the component, identifying it via domain analysis and preparing it for reuse.

·         Reuse Usage Cost of a component is used to measure the reuse-related costs incurred each time the component is reused. This includes the costs of finding, understanding, modifying / specialising and integrating the reusable component.

·         Reuse Maintenance Cost of a component is used to measure the costs of supporting a reusable component.

·         Degree of Commonality of a system (or business area) is used to measure the proportion of a system’s components that are common.

·         Degree of Reusability of a system (or business area) is used to measure the proportion of a system’s components that are reusable. Note: that the degree of reusability is probably less the degree of commonality because it is not cost-effective to create and support for reuse all common components.

·         Reuse Target Level of a system (or business area) is used to indicate the minimum proportion of a system that is reusable.

·         Reuse Merit of a system (or business area) is used to measure the proportion of a system that is reusable relative to the average proportion for a system in one Business area or Domain.

Types of Component Reuse

A prerequisite for practicing reuse is to have something to reuse. The types of components that the company plans to reuse must be decided early in the reuse program and in a software project because the types of reusable components must be known, in order to define the requirements for the software reuse library and how the software process must be changed to accommodate both the creation and use of these types of reusable components.

Reusable components that are used during the early stages of development are very important to achieving reuse benefits because reuse opportunities become more limited the further we move through the development process. Also, higher-level reusable components lead to and enable to reuse of lower level components.

Reusable code is usually the first type of reuse that comes to mind (utility functions, standard interfaces, error-handling, auditing etc.). However, there are many other types of reusable components that should be considered. The following table describes a list of reusable components, which can be reused.

The secret for maximising reuse benefits is to reuse bigger, higher-level components – bigger meaning reusable generic architectures rather than single modules and high meaning above the code level.

Application Template

Data Model

Data Structure

System Architecture

Process Model

Process Definition

Prototype

Plan Skeleton

HCI/GUI

Process Skeleton

·         Plan / Analyse / Evaluation

·         Acquire / Purchase / Make

·         Use / Maintain / Operate

·         Control / Monitor

·         Report / Record

·         Update / Change / Modify

·         Dispose / Deliver/ Distribute

Utility Components

·         Security

·         Audit

·         Checkpoint / Restart

·         Backup / Recovery

·         Error Handling

·         Command Processor

·         Query

·         Help

·         Database Access

The best way to drive home the importance of reuse metrics is through IBM’s Return on Investment (ROI) model [jp97], which has the following goals:

·         Reuse metrics must reflect real effort saved

·         Reuse metrics must encourage reuse

As a starting point, however reuse must be defined. Reuse in its most broad terms can be considered as reuse of any component or item, which has been developed within the software development process. A metric can be described as a process attribute of software that is either directly measured or computed from the software. The most simple reuse metric can be the percentage of software reused to total software developed.

Poulin & Caruso

Poulin & Caruso proposed a number of metrics for measuring reuse while working for the IBM Research Centre, New York. The ROI model was proposed during that time.

Reuse % Model

Poulin & Caruso basic model states that the measurement of reuse within a product is accomplished through calculating the percentage of reuse [jp97]. This percentage is determined by dividing the number of Reuse Source Instructions (RSI) by the total number of statements as given by:

Reuse % = RSI x 100

The equation above seems to be a simple calculation for measuring reuse; however Poulin’s definition [jp97] of RSI is complex, based on what he defines as reuse. Two basic rules of thumb are applied; if a software item crosses a boundary, it is considered external and counts as reuse. If a software item is developed within the boundary and used within that boundary, it is internal and is not counted as reuse. The second rule of thumb is through asking the question “would the organization have to develop the component if they had not obtained it from somewhere else” [jp97]. If the answer to this is ‘Yes’, then the component should be counted as reuse.

The boundary issue is, as can be expected, defined differently depending on the circumstances. A boundary can be between development teams, projects etc…

Although the actual metric itself is quite straightforward and simple to calculate, the guidelines as to what constitutes, as reuse is quite detailed and complete. As long as a consistent definition exists throughout the software lifecycle, then the resulting metric values can be used and compared meaningfully.

Reuse cost avoidance metric

The Reuse Cost Avoidance (RCA) metric shows the benefits of software reuse in individual team or project environments. The RCA calculates the financial benefits in terms of the money being saved by reusing software. RCS only recognises the cost in the development and maintenance cycle. Therefore, RCA is calculated as:

RCA = Development cost avoidance + Service cost avoidance

Development Cost Avoidance (DCA) is directly related to the cost of reusing a component. In general, the cost of reusing a component is about 20% of the cost of developing one from scratch [jp97]. Therefore, reuse saves 80% of the total cost.

DCA = (Reuse source instruction) x (1- relative cost of reuse) x (new code cost) = RSI x 0.8 x (new code cost)

Service Cost Avoidance (SCA) is directly related to the cost of maintaining a system. Poulin [jp97] assumes all of the reusable components are well tested, and well designed. As a result, they are error free, and the maintenance fee is approaching zero. Because of that, software reuse can save all the normal maintenance costs associated with the non-reusable code. SCA is calculated as:

SCA = RSI x (error rate) x (error cost)

This metric only gives the benefits in terms of money saved and thus may not be an ideal metric for comparison. Also it assumes error free software will be reused. This seems to be a highly improbable case.

Project Level ROI

Software reuse at the project level is small and the development time is short [jp97], ROI calculation does not take the net –present-value into consideration. It is simply calculated as the cost avoided by the organisation less the additional development cost.

ROI = the sum of reuse cost avoided – additional development cost

Additional Development Cost (ADC) is the reuse cost that takes the overhead cost of producing software into consideration. ADC is calculated by multiplying the relative cost of writing for reuse with the amount of software produced for reuse.

ADC = (relative cost of writing for reuse – 1) x (code written for reuse by others) x (new code cost)

This metric takes into consideration the ADC, which is an important factor for software reuse. This is so because most metrics presented here do not take into account the cost of adapting for reused software to the software being developed.

Terry & Frakes

They view reuse metrics as those, which can be defined as “metrics that are used to assess and monitor a reuse improvement effort by tracking percentages of reuse for the life cycle objects” [tf96]. This metric in its general form is:

Reuse Level = Amount of life cycled object reused

Total size of Life Cycle Object

This measurement assumes that a system is comprised of components at various level of abstraction. To allow this measurement to have any useful meaning, these components must be clearly defined. The reuse level within a Java based system could be expressed in terms of files, classes, packages, objects, methods, functions and lines of code can be declared as internal or external. An internal lower level item is one, which has been developed for a higher-level item. An item, which is considered to be external, is one that was created for a different item or for general use [tf96]. If you consider a higher-level item comprised of lower level items, then the following can be defined.

·         L = Total number of unique lower level items within a high level item

·         E = Total number of unique lower level items from an external repository within the higher level item

·         I = Total lower level items within the higher level item which are not from an external repository

·         M = The number of items not from an external repository that are used more than once

Given these definitions, then:

·         External Reuse Level = E / L

·         Internal Reuse Level = M / 1, and

·         Total Reuse Level = External Reuse Level + Internal Reuse Level

The reuse levels listed will take on a value of between 0 and 1, indicating no reuse with a value of zero, complete or 100% reuse with a value of 1, or something in between. To use these metrics, we must clearly define the hierarchy; define what is considered as the external repositories and what the “use” relationship is [tf96].

Threshold

To add flexibility to this model, a minimum threshold level has been added. The purpose of this threshold level is to determine when an item or component is considered as being reused [tf96]. The item therefore would only be counted as being reused once the threshold is exceeded. The mnemonics used to identify the inclusion of this threshold is:

·         ITL = Internal Threshold Level

·         ETL = External Threshold Level

·         IU = Number of internal lower level items that are used more then ITL

·         EU = Number of external lower level items that are used more than ETL

·         T = Total number of lower level items in the higher item, both internal & external

Reuse Frequency

The reuse frequency follows the same guidelines as reuse level except that it counts the references or calls to reused items within the higher-level item. The measurement of reuse frequency can be defined as:

·         IUF = Total number of references within the higher level item to reused internal lower level items

·         EUF = Total number of references in the higher level item to reused external lower level items

·         TF = Total number of references to lower level items, both internal and external

Based on the above metrics using the threshold levels, reuse can now be described as:

·          Internal Reuse Level = (IU / T) Internal Reuse Frequency = (IUF / TF)

·          External Reuse Level = (EU / T) External Reuse Frequency = (EUF / TF)

·          Total Reuse Level = ((IU + EU) / T) Total Reuse Frequency = ((IUF + EUF) / TF)

The last measurement is that of complexity. This is an attempt to put a relative size or magnitude weighting to the items that you reuse. It can be described as the sizes of all reused internal lower level items, divided by the sum of the sizes of all the internal lower items within the higher-level item [tf96].

These metrics are very versatile in that it provides good feedback of both how much is being reused in the form of a count of items being measured, and how often the various items are being reused. Through the use of the threshold values, these measurements can be tailored for the specific project or environment. The downside, these metrics do not have any means to count modified reused items.

Gaffney & Durek

The calculation of software reuse should not be short term, but also needs to take long-term benefits into consideration [jp97]. Gaffney and Durek define an equation for relative cost.

C = Ru x 1 + R x (b + E/n)

·         Ru = Portion of newly written code

·         R = Portion of reused code

·         B = Relative cost of integrating reused code

·         E = Relative cost of creating reusable code

·         n = Number of use over which the reused code is to be amortised

Productivity = 1 / C

McCabe’s Cyclomatic Complexity Metric

A measure of the complexity of a program was development by Tom McCabe. He developed a system, which he called the cyclomatic complexity of a program. This system measures the number of independent paths in a program, thereby placing a numerical value on the complexity. In practice it is a count of the number of test conditions in a program [tc76]. The cyclomatic complexity (CC) of a graph (G) may be computed according to the following formula:

CC(G) = Number of decision points in a routine + 1

Decision points are taken to be:

·         If

·         While

·         Repeat

·         For

·         And

·         Or

·         Each branch of a case statement

If the routine has a score of 5 or less, it is fairly simple. If the score is 6-10, it has been suggested that you start to think about ways to simplifying it. Greater than 10 you should simplify the routine.

Halstead’s Software Science

The software science Halstead development principally attempts to estimate the programming effort [cm95].

The measurable and countable properties are:

·         n1 = Number of unique or distinct operators appearing in that implementation

·         n2 = Number of unique or distinct operands appearing in that implementation

·         N1 = Total usage of all of the operators appearing in that implementation

·         N2 = Total usage of all of the operands appearing in that implementation

From these metrics Halstead defines:

·          The vocabulary n as n = n1 + n2

·          The implementation length N as N = N1 + N2

Operators can be “+” and “*” but also an index “[…]” or a statement separation “.. ; ..”. The number of operands consists of the number of literal expressions, constants and variables.

Length Equation

It may be necessary to know about the relationship between length N and vocabulary n. “Length Equation” is as follows. ‘ on N means it is calculated rather than counted:

N’ = n1log2n1 + n2log2n2

It is experimentally observed that N’ gives a rather close agreement to program length.

Quantification of Intelligence Content

The same algorithm needs more consideration in a low level programming language. It is easier to program in Pascal rather than assembler. The intelligence Content determines how much is said in a program.

In order to find quantification of intelligence content we need some other metrics and formulas:

Program Volume

This metric is for the size of any implementation of any algorithm.

V = Nlog2n

Program Level

It is the relationship between Program Volume and Potential Volume. Only the clearest algorithm can have a level of unity.

L = V* / V

Program Level Equation

Is an approximation of the equation of the Program Level. It is used when the value of Potential Volume is not known because it is possible to measure it from an implementation directly.

L’ = n*1n2 / n1N2

Intelligence Content

I = L’ x V = (2n2 / n1N2) x (N1+N2) log2 (n1+n2)

In this equation all terms on the right -hand side are directly measurable from any expression of an algorithm. The intelligence content is correlated highly with the potential volume. Consequently, because potential volume is independent of the language, the intelligence content should also be independent.

Programming Effort

The programming effort is restricted to the mental activity required to convert an existing algorithm to an actual implementation in a programming language. In order to find programming effort we need some metrics and formulas:

Potential Volume

Is a metric for denoting the corresponding parameters in an algorithm’s shortest possible form. Neither operators nor operands can require repetition.

V’ = (n*1 + n*2) log2 (n*1 + n*2)

Effort Equation

The total number of elementary mental discriminations is:

E = V / L = V2 / V’

The implementation of any algorithm consists of N selections. Making as many mental comparisons as the program volume equation determines, because the program volume V is a measure of it, generates a program. Another aspect that influences the effort equation is the program difficulty. Each mental comparison consists of a number of elementary mental discriminations. This number is a measure for the program difficulty.

Time Equation

A concept concerning the processing rate of the human brain, developed by the psychologist John Stroud, can be used. Stroud defined a moment as the time required by the human brain to perform the most elementary discrimination [cm95]. The Stroud number S is then Stroud’s moments per second with 5 <= S <= 20. Thus we can derive the time equation where, except for the Stroud number S, all of the parameters on the right are directly measurable:

T’ = (n1N2(n1log2n1 + n2log2n2) log2n) / 2n2S

Reuse Capability Maturity Model

The following table describes the reuse capability model as used by IBM [cm95] to show reuse intent levels.

Classification Scheme

If there is nothing to reuse, reuse is impossible. If there are too many things to reuse, reuse also is impossible. This is because the effort to locate a reusable component may be greater than the effort to create it from scratch. Unless reusable components are fast and easy to find, they are unlikely to be reused in practice. Developing an appropriate classification scheme for reusable components can solve this problem.

The purpose of a classification scheme is to enable the easy and fast location and retrieval of an appropriate reusable component from the library where it is stored and managed. Each component stored in the library for future reuse is described in terms of a set classification description, which become its classification. Reuse engineering uses the naming conventions from Information Engineering as the basis for creating a simple, but effective classification scheme. The classification scheme is a set of the following five descriptors which includes the components name:

(Name, Type, Application Area, Medium, Certification Level, Technology)

Where:

The developer uses the classification of a component to locate components for possible reuse by choosing a value for each classification descriptor and then searching the reuse libraries for reusable components whose descriptors match this classification descriptor. If the developer wants to retrieve all possible reuse candidate components, then the value of each descriptor, which is not needed to qualify the search, is set to an asterisk.

Reusable Plan using Classification Scheme

Planning

New/Used Components

These are components, which need to be added to the reuse library. They may also be components, which have been altered for a specific project; this will need to be added as an amendment to the component. Components must have a document trail supplied. The reuse group should reject any component, which does not have a document trail.

Reuse Group

This area is responsible for the management and support of the reuse library. This group will maintain all component additions. This group is also responsible for the execution of the testing cycle for the component.

Component Classification Models

The reuse group will be responsible for the adding of components to the reuse library. Each component added to the library is given a “component classification” by which ALL access is governed.

Reuse Libraries

This is where the component references are stored.

Domain Specific Library

These are specifically domains, which make up a group of components to meet a business requirement. This library would typically include plans, project documentation, frameworks, templates or prototypes.

Generic Library

This library is specifically for fragments of code and templates, which can be used in

isolation of a business area.

Source Code Control

Any code stored within the library is actually stored within a source code control system and referenced within the library. Each component added to the library will be stored here and all alterations to that component with respect to reuse will be referenced here. Source Code, which has not been tested, will be excluded from this area until successful completion of the test (this allows for reuse integrity).

History of a Component

This area is responsible for giving a complete history of the component (who has used this, which project or business area and how often it has been used).

Bugs

Any problems with components held within the reuse library will be tracked with a bug reference. This reference is held here and tracked here by the reuse group.

Metrics / Statistics

This area is responsible for the definition of metrics associated to the component. It

is also responsible for the statistics held against the component in order to determine

use, obsolescence etc…

Testing Tools

This area holds all test tools for the component (the actual test scripts / tools are held in the source code control system). Any component, which has been added, will also have a testing method.

Documents

This area holds the components documentation, examples and other material required by the components user.

Security Infrastructure

This area is responsible for the management of access to the reuse library. This will be a standard level security layer, which verifies the user has access to the reuse library (local or remote). All access to the reuse library are audited and access is through a standard browser (external users to have access). From this security infrastructure there is a possibility to implement additional elements to the component classification to include security grouping (implementing a portal to the reuse library, for those who only require a subset of the reuse area).

Bibliography