(1) Dr. David C. Rine, Professor of Computer Science and Information & Software Systems Engineering, School of Information Technology and Engineering, George Mason University, Fairfax, Virginia, 22030-4444, (703) 993-1530, drine@cs.gmu.edu. (2) Dr. Nader Nada, School of Information Technology and Engineering, George Mason University, Fairfax, Virginia 22030-4444, (703) 993-1530, nnada@osf1.gmu.edu.

Address correspondence to author (2)

(Short running title:Software Reuse Investment Success Factors')
 

'An Empirical Study of a Software Reuse Reference Model'

Abstract: In software engineering there is need for technologies that will significantly decrease effort in developing software products, increase quality of software products and decrease time-to-markets. The software development industry will not be successful in utilizing and managing software reuse until there is an "empirically validated reference model" that can be customized for different kinds of software development enterprises. Our research thesis is that software development based upon a validated software reuse reference model proves to be a practical solution to help improve the competitive edge and time-to-market of many software development enterprises. The definition and validation of such a model have been carried out using four steps. First, the reference model is developed based on prior work. Second, this "theoretical" reference model is empirically validated using both legacy studies and lessons learned studies. Third, the impact of the reference model on software development effort, quality, and time-to-market is empirically derived. Fourth, an initial set of successful cases based upon the software reuse reference model utilization are identified. The main contribution of this paper is a validated reference model for the practice of software reuse. A secondary contribution is an initial set of cases from software development enterprises having a high success from the practice of reuse in terms of decreased effort and increased quality and a high correlation in their application of our software reuse reference model activities.

1. SOFTWARE REUSE REFERENCE MODEL

1.1. Introduction to Reference Models

Reference models serve as a means of comparing different systems in a domain. A reference model provides a guide against which systems in the domain can be evaluated. An example of a domain is the set of systems such that each is the software engineering activities of a given enterprise incorporating assets reuse.

It is the authors’ general thesis that the lack of a clear reference model, within which the scope and limitations of existing software reuse technical and organizational factors can be identified, makes it difficult to design improved reuse approaches in a systematic manner. The task of generating robust default reference models for software development activities under exploratory or directed investigation, or automating the production of such defaults and assisting the users to refine them, relies on having 'standard' representations that satisfy established or specified criteria for interpretation. Robertson [Robertson 94] and Sommerville [Sommerville 96] point to the importance of reference models in software development, both for software products and for software development activities.

1.2. Importance of Reuse Reference Models

Many organizations in both the private and public sectors are proposing to invest, and have already invested in, large sums of money, time, and resources into software reuse with the hope of improving their competitive edge and time-to-market through decreased effort in the software development process and increased quality in the software products developed [Rine 97]. For many software organizations it will therefore become increasingly important to investigate and quantify the relationship between the level of the organization’s software reuse utilization and management plan effectiveness in terms of effort with reuse, product quality, and time-to-market.
 

The reason for identifying the activities of a validated software Reuse Reference Model (RRM) is that the RRM provides important relationships between the technical and organizational activities of software reuse within a software engineering process. Utilization of an appropriate validated software RRM in a software development organization allows software engineering management to identify both technical and organizational activities needed for a successful software reuse implementation plan [Jacobson 97, Lim 98]. Software development (including: market domain model, common architecture, and product-line approaches) includes both business (organizational, cultural) and engineering (technical) activities. Any organization, either starting or currently practicing reuse, should review its current or intended reuse implementation plan, compare its plan to the plans of successful leaders in the reuse industry, and revise (reengineer) their plans, as necessary, based on an empirically validated software RRMs.

In this paper a theoretical model (RRM) is first presented, and then empirically validated. Related to RRM, levels of the utilization of RRM are also developed as a qualitative RRM Level (RRML) metric in section 2.2.4. The organizations used in this empirical study (See section 3.1) with high RRML levels of RRM (reuse capability) practice the activities depicted in Figure 1 ( a graphical illustration of the model). The boxes depict reuse activities, and the arrows depict concurrent flow between the activities.

We have found that the present software RRMs based on our reuse research [Nada 97] do not include or consider many of the software reuse technical and organizational factors in the formulation of their quantitative models. Software developers need to achieve better understanding, estimation, evaluation, and quantification of software reuse and business perspective factors as well as their predictive relationship to software effort and quality.

Furthermore, our researched RRM, reported in this paper, serves as a point of reference for groups of similar software development organizations who are interested in adopting, utilizing, or managing software reuse. Moreover, our developed RRM implementation Level (RRML, see section 2.2.4.) is a measure representing an organization’s utilization levels of the RRM activities (features) in the ordinal range. The ordinal range is divided into five linearly ordered level values: L1 to L5, that represent the amount of RRM activities utilized or practiced(examples of reuse activities: product-line, domain model, COTS, etc.).

1.3. The Problem

Many software development organizations believe that investing in software reuse will improve their process productivity and product quality, and are in the process of planning for or developing a software reuse capability. Unfortunately, there is still little data available on the state-of-the-practice of utilizing or managing software reuse. The majority of current information available on software RRMs comes from the literature [Nader 97, Rine and Sonnemann 98], which contains non-validated assertions applied in a limited way to a few pilot projects or case studies. The critical problem in today’s practice of software reuse is a failure to develop necessary details to support a valid software RRM.

The main contribution of our research reported in this paper is an empirically validated RRM for the practice of software reuse. The research provides evidence that using a valid RRM among the software reuse community will help improve the competitive edge and time-to-market of many software development enterprises through decreased effort in the software development process and increased product quality. A secondary contribution is an initial set of legacy studies and lessons learned studies [Zelkowitz and Wallace 98] from software development enterprises. Many of these enterprises have a high RRML from the practice of reuse in terms of decreased effort and increased quality and a high correlation in their reuse utilization and management features to our RRM model features.

2. RESEARCH HYPOTHESIS AND RESEARCH METHOD

This research hypothesizes [Nada 97] that there is need of a more effective and validated software RRM that incorporates both the technical and organizational facets of software reuse and that identifies its impact on software development effort, quality, and time to market.

2.2. Background of Technological and Organizational Factors in RRM

The software RRM incorporates both technical and organizational factors or activities that might be needed to establish a successful software reuse practice in the organization. Technical activities (See Figure 1) consist of: (1) technologies (tools) that support reuse: CASE tools and common interface, e.g., CORBA, DCOM, and COTS; and (2) software development with reuse processes (technical procedures): domain modeling, product-line approach, common architecture, quality control, and best development practices. Organizational activities (organizational procedures) include management of reuse a program, market place analysis, financing and marketing forecast, and training.

2.2.1. Technologies That Support Reuse (Tools)

Once the software development organization has been assessed and a plan of software reuse defined, a set of activities that support reusable assets based methodology installation should be incorporated. These activities include the training of both the management and technical staff, the selection and installation of appropriate methods and tools, and the definition of evaluation criteria. Implementation does not end with the transfer of software engineering reuse technology. Rather, the application of the technology is evaluated (both qualitatively and quantitatively). For example, sometimes the introduction of object technology has led to major failure [Fichman 97]. Reuse success may not always be synonym of object technology use.

2.2.1.1. Software Uniform Modeling and Design Notation

The software community has been looking for and proposing solutions to "software problems" for many years. Until Components-Based Development (CBD), object technology was the last "solution." One of the keys to CBD’s success is a standard infrastructure for components. Infrastructures need three main elements [Kiely 98].

First, a uniform design notation is needed that provides an accepted way of describing components’ functions and properties, which would be critical in designing collaboration between components. Much of the industry is adopting the Uniform Modeling Language (UML), which combines several prior modeling and design notations.

2.2.1.2. Software Component Interfaces

Second, repositories are needed as a means of cataloging available components with a description of their features that would let developers find the components appropriate for an application. The Object Management Group (OMG) is developing a repository specification, whose core will be the Microsoft Repository, currently the dominant specification.

Third, a standardized CBD interface is needed that lets any application in any language access components’ features by, for example, binding to the component model or interface definition language. The OMG is trying to make both Microsoft’s Distributed Component Object Model (DCOM) and Sun Microsystem’ JavaBeans specifications interoperable with its final Common Object Request Broker Architecture (CORBA) specification and whose infrastructure will conform to UML.

The Object Request Broker (ORB) specification is the part of CORBA from the OMG that describes a "software bus"-- a mechanism that handles communication between distributed objects. The ORB allows for client-server interaction between heterogeneous objects distributed over a network and makes meta information describing objects in and their interfaces available to an object in the system, so that it may access other objects as clients without prior knowledge of their locations. Any object connected to the ORB can play the role of both a client and server object. That is, it can initiate calls to other objects and respond to requests for services from other objects on the ORB.

It is hoped that software vendors will provide modules implementing these descriptions, and that software developers will use them, thus allowing users to mix and match (interchangeable) software modules, reusing software components, and reducing development time by avoiding duplication. Some CORBA services exist that have commercial implementations, but it may be some time before implementation of many of the services become widely available.

2.2.1.3. Trends of COTS

Software reuse sources may come from inside the organization and from outside the organization. For at least some of the reused software, an organization may find it to be more cost-effective with less time-to-market to reuse existing Commercial-Off-The-Shelf (COTS) or Internet distributed software than to reuse in-house-developed software components. This is related to the traditional buy-versus-build tradeoffs. However, even though COTS or Internet distributed software may require less effort and less time to acquire, this externally acquired software for reuse may be very expensive and time-consuming to port between computer systems and to integrate between incompatible interfaces. In order to solve this problem, should one decide to acquire instead of build, externally reusable software must be both portable/interoperable and easily integrated.

COTS components provide an excellent source of reusable software components, that are often overlooked [Staringer 94]. COTS is especially applicable for horizontal reuse (math routines, screen formatting, graphics, data visualization, database building, etc.).

Two important technical sets of problems facing the use of COTS are design/specification interfacing problems and integration problems. Let us consider interfacing problems in COTS components reuse. COTS components generally provide several functions needed for software products but not necessarily all of them. As a result of this fact, a precise mapping between specification/design and implementation cannot be accomplished until the COTS components have been selected. Here, the intent to maximize COTS introduces a number of design variables. COTS components may not deliver all interfaces specified in the design. Also they may not match the interface specifications, or they may provide some of the designed functions in an incomplete manner. Such situations could lead to a need to develop "glue software," so-called because it is needed to "glue" the COTS components into the overall implementation architecture. Since alternative COTS components may provide different fits into the architecture, they will have differing requirements for glue software. The desire to minimize the amount of glue code that needs to be developed suggests the need for studying trade-offs in the reuse of COTS [EOSDIS 94].

Let us turn to integration problems in COTS components reuse. Sometimes it is not an easy task to integrate COTS components. In such case software developers have to find other options to overcome such problems. For example, when NASA was interested in reducing the effort and time needed to develop the glue software for the Earth Observation System Data Information System (EOSDIS), NASA considered CORBA for handling communications between the different system objects or modules.

2.2.2. Software Development with Reuse Processes (Technical Procedures)

2.2.2.1. Domain Modeling

Referring to Figure 1, domain analysis is a systematic approach for identifying the commonalties, similarities, and variabilities necessary to characterize and standardize a product-line for a domain. While domain knowledge can be represented using domain modeling, a domain is often realized for a product-line or product family, and its associated process for producing instances of that family. Domain engineering (procedure) is an ongoing activity for defining, implementing, and evolving a domain and its domain model. Domain engineering uses business objectives and domain knowledge to create and standardize the product-line that the domain model supports. Domain engineers specify the family of systems' architecture, and the design of adaptable components. On the basis of business objectives the domain manager creates a "master plan" for the development and evolution of the domain [O'Connor 94].

Component reuse is often domain-specific. If a component is written for some domain such as the Biogeochemical Application for Distributed Data Active Archive Center (DADC), it is unlikely to be reusable cost effectively in other domains such as Atmospheric Dynamics and Global Biosphere [Asrar 95]. Some general domains (such as the user interface domain) are used in many different types of applications, so reuse across applications is possible. Domain analysis and modeling are concerned with understanding the domain so that domain abstraction can be modeled as reusable requirements, design patterns, or code component [Sommerville 96]. A domain-specific, architecture-driven approach to reuse will yield the greatest reuse impact and, thus, is important to address from both an engineering and a management perspective [STARS 95].

In 1978 Booch [Booch 78] developed an extensive classification structure for software components (called "Booch Components") and discussed how generalized components can be implemented. In 1991 Rumbaugh [Rumbaugh 91], presented an object-oriented approach (OMT) to software development based on modeling objects from the real world and then promoted the use of OMT models to build language-independent design organized around those modeled objects. For the most part the software industry is adopting the Uniform Modeling Language (UML), which combines several design notations (such as the Booch, OMT and OOSE methods).

2.2.2.2. Product-Line Approach

Organizations that have developed similar products have a higher probability of success in developing new products in the same area or domain. Organizations whose strategy is to continually enter new areas (pop up businesses), and who are not associated with a given area or application domain, are not likely to be able to fully leverage reuse. A product-line is a group or family of closely related products made by the same process and for the same purpose, differing only in style, model, or size. A product-line approach (Figure 1) groups related systems into application families and leverages commonality and leverages across the family. Because these products are related (have similar functionality or user requirements), there is usually a degree of high commonality across a given product-line [Sonnemann 95]. Moreover, product-line have a sufficiently market life time so that an organization can make a profit from it.

Product-line is closely related to the concepts of horizontal and vertical reuse. Horizontal reuse provides generic reusable components that can support a variety of products. Vertical reuse focuses on developing the preferred parts supporting a given family of related products or product-line [Wasmumd 93].

Product-line support is the justification behind the concepts of preferred parts, design for manufacturability, and a flexible software development approach. It was in Japan that the experience of actually setting up and optimizing hardware manufacturing organizations was applied to extend these early ideas of a software factory. Software products need to be designed around the available software components, rather than waiting until the design is done, and then looking for matching components. This will change the way we design software and software parts, and will require different organizations (called "software factories") to support and enforce these models [Griss 93].

2.2.2.3. Common Architecture

A common architecture (Figure 1) provides standard interfaces and data formats, as well as common experience leveraged from earlier developments. The architecture defines the rules for developing software components. This aids in the interchangeability of reusable software components across the product-line. Just as important, a common architecture lessens the need to make reusable software components highly generic or flexible because the environment in which they will be used is well defined and fixed. The architecture links developed and reusable software components to the physical problem space (hardware, operating system, and application packages such as database or graphics).

The next step beyond defining a common architecture is an object management architecture. Presently, MITRE is heading a number of industry and government technical working groups to define object wrappers. Object wrappers allow existing objects to be abstracted and encapsulated into higher level modules with well-defined interfaces. It is a way of increasing the flexibility of existing object-oriented code without reverse engineering the code to make it more reusable. A common architecture across a product-line should allow an organization to more quickly develop a critical mass of reusable software components [Sonnemann 95].

A layered software application architecture (such as the seven-layered ISO communications model) can greatly simplify rehosting an application on a number of different platforms (hardware and operating systems). This ability to rehost or scale (mainframe, mini, or workstation) an application increases the marketability of products and further allows an organization to leverage their reusable software components [Frakes 94a].

A common architecture makes a solid base on which to build systems [O'Connor 94]. A standard architecture can lessen the impact of major changes in end-user requirements. [Staringer 94]

2.2.2.4. Software Component Quality Control Based upon Reuse

A system's reliability can never be better than the individual reliability of its least reliable component, and the effect of software component reuse is positive, principally because of the higher opportunity that reuse provides for fault reduction [Sonnemann 95].

Software reusability can be used to achieve much higher levels of software reliability by amortizing the debugging costs among products incorporating the reusable component [Lubars 86]. In one project the building-block (reuse) code's quality (number of errors per lines of code) was about nine times better during the function test and 4.5 times better during the component and system test than the non-building-block's code [Lenz 87].

2.2.2.5. Best Practices

Applying a certain technology, such as reuse, requires a change in attitude and needs to allow sufficient time for development team members to mature in their roles. Every developer must have the time to reach some level of maturated experience. Most developers need to be able to reuse their existing assets to build new ones and to learn something useful from their past experience.

Reuse should be applied as a "first principle." That is, reusable assets should always be considered as the basis for work before creating new products. In addition, experiences, processes, and work products should always be recorded for learning, and the work products should be designed to facilitate reuse [STARS 95].

Some valid experiences with preferred parts and group technology approaches in manufacturing can also be applied to software. For software, this suggests that we introduce design methods (or models) based on preferred (qualified) software parts. Commonality and standardized requirements lead to preferred parts. The most effective reuse programs concentrate on the identification and development of a small, high-quality set of needed and useful components. In fact, as the amount of a new product made from existing components increases, we observe corresponding improvements in costs, time, and quality. It takes more than the parts’ library alone to achieve these results [Griss 93].

2.2.2.6. Component Reuse Metrics in Quality Control

Metrics (Figure 1) play an important role in the determination of quality for both the technical and organizational reuse factors. Metrics are distinguishing traits, characteristics, or attributes. These attributes are both static and dynamic. A software metric is any measurement that relates to a software system, process, or related documentation. Metrics fall into two classes: (1) Control metrics are used by management to control the software process, e.g. effort expended, elapsed time and disk usage; estimates and measurements of these metrics can be used in the refinement of the project, and (2) Predictor metrics are measurements of a product attribute that can be used to predict an associated product quality such as system clarity [Kitchenham 90].

Considering the use of metrics for technical factors, for example, Fonash [Fonash 1993] grouped the software component reuse metrics into five major categories: general, quality, parameterization, coupling, and cohesion. Quality, parameterization, coupling, and cohesion are software engineering principles that correspond to the reuse attributes. The general category is for attributes that are not in the four software engineering categories.

• General Metrics

Understandability: The relative amount of effort required to comprehend the algorithms, data structures, and control structures of the module. The more understandable the module the greater the likelihood that the module is reusable.

Size: The extent of the module. Size provides information about the quantity of software contained in the module, e.g., lines of code or number of Ada statements.

Type of module: Ada has several different types of modules. These can be grouped into two major categories: specifications and bodies. Specifications declare the interface, types, exceptions, variables, parameter types, procedures, tasks, and functions. Bodies contain the algorithms used to implement the declared functions and data. [Booch 83]

• Quality Metrics

Ease of Change: The degree to which software has been designed to be easily modified. The level of difficulty that a designer and programmer experience in comprehending and incorporating this module into a new system.

Comments: How useful, understandable, complete, and accurate are the comments provided to a designer or programmer who wants to incorporate the module into a new system?

Formatting: How understandable and readable is the code in the module? [Oman 92]

• Parameterization Metrics

Functional and data parameterization: the number of functional or data parameters in a module.

• Coupling Metrics

Coupling is the strength of the interconnection and dependency among modules. The higher the coupling the less independent the module.

System Coupling: The relative hardware and operating system dependence of the software. Other modules coupling: The amount of interconnection and dependency on other modules.

• Cohesion Metrics

Cohesion metric is the strength of how well function fits together. A component should implement a single logical function or should implement a single logical entity. All of the parts of the component should contribute to this implementation. If the components include parts that are not directly related it has a low degree of cohesion. [Sommerville 96] The functional cohesion metric is concerned with the degree to which each part of the module is necessary for performing a single function. The data cohesion metric addresses the degree to which the module has a single-data type associated with it.

• Complexity Metrics

Complexity is categorized in terms of computational complexity, (i.e., a formal specification of algorithm structure, efficiency, and application) and psychological complexity (i.e., a measure of human factors that affect software development). Software control structures use graph theory to measure internal procedural characteristics such as number of branches or processing paths [Pressman 82]. Complexity is commonly used as a term to capture a totality of all internal attributes. The cognitive and structural notions of complexity should be summarized by a single number. This number should therefore be a powerful indicator of all the attributes that one normally associates with "complex" systems, such as understandability, testability, and maintainability [Fenton 91].

More generally, the following are suggested organizational level reuse metrics:

- Reuse team size (persons)

- Reuse percentage (Size)

[Levels: 25% Low, 26-60% Average, 61-90% High]

- Reuse percentage may consist of the following categories:

[Levels: 25% Low, 26-60% Average, 61-90% High]

- Decreased level of development time (Month)

[Levels: 25% Low, 26-60% Average, 61-90% High]

- Decreased level of time-to-market (Month)

[Levels: 25% Low, 26-60% Average, 61-90% High]

- Increased level of product quality (Reliability = errors/KSLOC)

[Levels: < = 2 High, 3-5 Average, > 5 Low]

- Maintenance cost reduction (Man-Month)

[Levels: 3 times Low, 4-6 times Average, 7-up times High]

- Overall software development cost reduction (Man-Month)

[Levels: 20% low, 21-50% Average, 51-up% High]

- Return-On-Investment (ROI= $)

[Levels: 2-5 times Low, 6-10 times Average, 11-up High].

We will take a closer look at these factors in the next section.

2.2.3. Organizational Factors Influencing Software Development with Reuse

2.2.3.1. Management of Reuse Success Factors

In 1995 Sonnemann [Sonnemann 95] conducted an exploratory study of software reuse success factors. His research investigated the relationship between software reuse and many of the theories proposed by literature to provide greater reuse capability (success factors). Sonnemann identified several leading indicators of software reuse capability (success factors) including management commitment, investment strategy, business strategy, organizational structure, reuse process maturity, management that understands reuse issues, and software reuse advocate(s) in senior management.

The development team is another important aspect enhancing the management of any reuse program. Failure to try to reuse components is primarily a management problem. According to survey respondents, the most common root cause of this failure mode is resource constraints, followed by lack of incentive to reuse, time constraints, lack of clarity on reuse utility, and lack of education [Frakes 94b].

Since software components that are specified in the software product model (e.g., using UML) are directly derived from requirements specifications, it is a common practice that the decision to pick up particular reusable code components for product development happens during the design phase. Therefore, it is best to offer consultation and advice to project management during the design phase [Wasmumd 93].

Systematic software reuse is a key business strategy that software mangers can employ to dramatically improve their software development processes, to decrease time-to-market and costs, and to improve product quality [Griss 93]. However, the precise best practice steps to employ in such a strategy are not well known.

The four strategies for developing reusable software components are: horizontal and vertical reuse, and reverse and forward engineering. Most organizations will do a mix of the four [Sonnemann 95].

2.2.3.2. Financial and Market Forecasting Factors

The funding profile for reuse projects is quite different from conventional software projects. Typically, several years of up-front investment are needed before payoff is realized. Managers are reluctant to make long-term investment without some guarantee of success. They must consider market opportunities versus investment risks. The solution may be to develop return-on-investment (ROI) models. Software reuse is not a new strategy; however, the current emphasis on systematizing reuse and focusing such efforts toward narrow, well-defined application areas, or product lines is novel. This restricted focus enables reuse of large-scale components, such as software architectures and entire subsystems, that best leverage the knowledge, expertise and resources within an organization, thereby enabling greater future payoff after initial investment in software reuse. As Figure 2 illustrates, given an initial investment cost (Io) in a corporate reuse program, an enterprise would expect to break even at some point in time of its product-line life cycle phase.
 

If software developers do market analysis and forecast user needs, they should be able to predict user needs [Griss 93]. Writing reusable software costs more than non-reusable software; however, software reuse is an investment for the future, and management support is necessary to make that investment possible [Tirso 93]. Management must understand and accept the need to invest not just in enabling technology, but also in projects to product reusable components. Reuse requires real commitment and strategic thinking. Organization must adopt a long-term perspective [Cards 94]. Incremental investment can spread costs and risk over time [O'Connor 94]. Software reuse programs require significant investment and substantial time to mature. Middle managers have been reluctant to adopt software reuse because of the up-front costs and slow return on investment (three or more years). Realizing this, senior management must accept responsibility for initiating reuse. Substantial management support is required to develop reusable software that takes significantly more time than schedules usually allow [Joos 94].

Adapting components to make them reusable may involve making different types of changes such as: name generalization, operation generalization, attribute generalization, and exception generalization. The generalized component should meet certain quality metrics and may be certified as having reached the required quality standards.

2.2.3.4. Market Place Factors

Market place, domain modeling, and product-line approach are related and all are required to enhance and support the software engineering business strategy based on reuse. Although, these are potential factors that influence both software productivity and quality, many of the previous software cost or quality estimation models did not take them into consideration. Yet, one of the important motives of reuse is the potential for leveraging valuable assets as part of the effort in developing quality products, as well as leveraging time to introduce products to markets.

If a software developer’s products are of a higher quality and produced at a lower cost than its competitors, it should be able to gain a larger share of the market or at least increase profit [Frakes 93]. The future of the software-intensive-systems marketplace belongs to organizations that can profitably deliver high-quality products in response to diverse or rapidly changing customer needs [O'Conner 94].

Made-to-order software is becoming a luxury. Quality and cost reduction are two key values to emerge in a demand-led market that is no longer satisfied with the high cost and long production time associated with made-to-order software development. The solution lies in customizable products. Designed for mass market, these products have two major advantages over made-to-order software: low cost and proven quality [Troy 94]. One major element of market-driven quality is the demand for dramatically increased reuse of valuable assets such as software, designs, and experiences to prevent redundant development and maintenance efforts [Wasmumd 93].

Software reuse will help software developers to have better, more accurate, and early bid estimates, because they know more about the system because a significant portion will be built from reusable components. Software development and building new systems out of reusable components will bring systems to market faster [Frakes 92].

For many kinds of software development, reducing time-to-market can be more important than direct-cost reduction. Shorter production cycles can have great impact on overall profit and competitive advantage than non-reuse development, or even cost-focused reuse-based development. Figure 4 represents the marketing trends for certain domain products.

2.2.3.5. Training Factors

As technology and business culture changes, it is essential that a continual program of training about evolving technological and organizational factors be instituted for software organizations. Often, the press of current project schedules and pre-existing "fire-fighting mentality" cause attempts at training to be short-circuited. Most software professionals recognize the need for training, but subordinate it to the need to "get projects out the door." Recommendations that propose a training regimen must take ongoing projects into account and should be scheduled so that minimal conflict arises.

The object-oriented technology insertion stage of transition defines the development environment and allocate the required resources. The critical activities during this stage include defining techniques, selecting tools, and training the development team. [Fayad 96] An organization with a corporate reuse education program has significant higher median levels of code reuse [Sonnemann 95]. Technical, organizational, and educational infrastructure is essential to reuse, and must be designed and managed to support it [STARS 95].

Classroom training is only one of the number of educational vehicles and is not sufficient by itself. Work in a classroom should be supplemented by literature and additional courseware. Software engineering requires: three kinds of education should be conducted:

- Generic methods and concepts, directed toward both management and technical staff to focus on generic software engineering concepts and methods;

- Tools and technologies, provided for practitioners and focusing on a specific software tools and its use; and

- General business practices, intended for all business professionals, management, and staff to improve their skills and communication [Pressman 88].

2.3. Research Method

2.3.1. Deriving the Reuse Reference Model

In this section we summarize the research approach taken in deriving and validating our Reuse Reference Model by means of fourteen steps.

Step 1. Develop a theoretical software reuse reference model (RRM).

A. Review literature on software reuse to identify the reuse technical and organizational factors and explore their relationship to software development effort, quality, and time to market.

B. Develop a modified version of the Sonnemann and Rine [Rine 98] model by:

i. Eliminating candidate factors that are weak or irrelevant to reuse by comparing and contrasting software reuse lessons learned from literature search, and

ii. Utilizing of the results of the previous software reuse empirical studies [SER 96; QSM 95; Sonnemann 95; Patterson 95; Owens 95; Applied Expertise 94; Fonash 93; Griss 93; Frakes 94; Kiel 91; Boehm 81].

This step includes the refining of the studies comprising different technical and organizational activities of software reuse.

Step 2. From the theoretical software RRM decompose the research problem into the following four sub-problems:

- Determine if the implementation level of the software reuse reference model activities

predictive of:

reuse reference model activities.

- Determine at which phase of the software life cycle may organizations get the greatest

reuse benefits.

- Determine how far organizations collect and utilize reuse metrics and incorporate

reuse effort estimation as part of their software development life cycle.

- Determine if the reuse process is a common practice and an integrated part of the

organizations’ software development process.

Step 3. Identifying potential participants to be considered as Reuse Case Studies.

In order to understand the specific context of each case study, an overview template is provided based on 20 attributes have been defined to characterize the applications represented within each case study.

Step 4. Contact and interview the case studies’ participants.

Step 5. Identify the software reuse population:

- Software reuse factors (Sonnemann' list, 109)

- NASA software reuse workshop (Patterson' list, 200)

- Reusable software components resources (Levine' list, 50)

- IEEE Software Reuse Group (workshop list, 90)

- Software Productivity Consortium members (list, 200 )

Limitations:

Software reuse is still an immature function. There is no national or international software engineering database or census bureau representing a population of software developers who practice software reuse.

Step 6. Stratified groups identification :

- Stratification (organization size, organization type, application type, etc.)

- Control variables (Software Reuse Reference Model implementation Level "RRML" (See section 2.2.4.)

Application Size)

- Dependent variables (effort , quality, time-to-market)

- Independent variables (RRM activities)

Step 7. Develop an instrument to survey the industry and government from the Software Reuse Population.

The survey instrument includes 34 questions on the RRM technical and organizational activities, effort, quality, time-to-market levels with respect to percentage of reuse.

Step 8. Print and distribute the survey instrument.

Step 9. Compare selected projects’ effort, development time (time-to-market) from different domains with the QSM (Quality Software Management Corp. Database) software industry averages.

Step 10. Results collection and analysis of the case studies and the survey data. The statistical SAS and JMP software packages are used to determine the survey frequencies and the correlation’s between the dependent variable and the independent variables.

Step 11. Compare the results of both the survey and case studies.

Step 12. Interpret the results against the research hypothesis:

Step 13. Conclusion.

Step 14. Report the results and interpretations and mailing the summary of results to all the survey and case studies’ participants.

2.3.2. Research Questions about our Proposed Software Reuse Reference Model

Our literature search and related theoretical work uncovered a number of possible software reuse activities, as well as reuse relationships with productivity, quality, and time-to-market. The goal of our research is to develop RRM whose utilization in software development lifecycle will increase productivity and quality and decrease time-to-market. From this goal the following five questions about RRM are derived:

Question 1. Is the implementation level of the software reuse reference model activities

(RRML, see section 2.2.4.) predictive of:

A. Products development effort level

B. Time-to-market level

C. Product quality level

Question 2. Is the reuse percentage predictive of the implementation level of the software

reuse reference model activities?

Question 3. At which phase of the software life cycle may organizations get the greatest reuse benefits?

Question 4. How organizations collect and utilize reuse metrics and incorporate reuse

effort estimation models as part of their software development life cycle?

Question 5. Is the reuse process common practice and an integrated part of the organizations’ software development process?

We have tried to answer these questions through interpretation of the results reported in the next section.

2.2.4. Reuse Reference Model Levels (RRML) Analysis

The RRML levels were assigned to each project based on the following model:

Level 1 (L1), Very Low,

Level 2 (L2), Low,

Level 3 (L3), Average,

Level 4 (L4), High, and

Level 5 (L5), Very High

The hierarchical RRML intended to produce realistic results. Level 3 requires neutral ansewrs on questions Q3-Q21 and Q30-Q33 (the total median) , Levels 4, and 5 require agree or strongly agree answers on the same questions. Level 2 requires disgree answers. Level 1 will be made up of those projects which fail the level 2.

3. RESULTS

This section describes the results of the 1997 software reuse case studies and survey to answer the four research questions listed in the previous section 2.5.

3.1. Summary of Case Studies Empirical Results.

Considering our previous research [Nada 97] using the case studies' results summarized in Table 2. we found the following to be true: (Interpretation of Case Studies Results)

1. The Software Reuse Reference Model (RRM) implementation levels, derived from technical and organizational features, are predictive of effort, quality, and time-to-market.

2. The fact that reuse is still not a common practice in many companies is due to three factors (Figure 4.). First, companies considering the introduction of reuse have to face economical and financial problems. Second, companies considering the introduction of reuse have to face organization-culture change impacts the software development life-cycle. Third, companies considering the introduction of reuse have to face assessment and evaluation of the actual benefits of reuse in terms of time and cost savings, improvement in the quality of products, and decreased effort.

3. When software is reused multiple times, the defects fixed from each reuse accumulate, resulting in higher quality. Furthermore, reuse reduces the time-to-market and effort needed to develop and maintain a software product, and increases the ROI.

Considering the RRM activities (See Figure 1) and the corresponding case studies' results we conclude the following:

1. RRM Activities: Best Development Practices, Management of Reuse Process.

Results: The presented results concern experience at IBM, NASA, HP, GTE, Boeing, Northgrum, Netron, and Sun span over a longer period of time, as compared to the experience at Semantic designs, Rolls-Royce, UNISYS, Motorola, CSC and TI. They also involve relatively higher investments in term of resources, especially if reuse implemented at the enterprise level such as in the case of IBM, Boeing, and GTE (Table 2. Exp. Yr. and Team Size). Talking about these organizations’ investments and their relevance as far as the achievement of significant reuse rates is concerned, it must also be emphasized how a strong commitment on the management side is essential to reach the break even threshold [Sonnemann 95 & SER 96].

2. RRM Activities: Reuse Metrics, Quality Control and Effort Models.

of reduced time-to-market, improvement in products quality, decreased effort, and costs savings [Nada 97].

3. RRM Activities: Domain Model, Common Architecture, Product-line Approach, Best Development Practices and Experiences.

Results: Overall, the pilot projects carried out at IBM, NASA, HP, GTE, Boeing, Northgrum, Netron, Semantic Designs were quite successful from several points of view:

a. achievement of the objectives set at the beginning of the experiments;

b. identification of guidelines for the development of reusable components (development FOR reuse);

c. general guidelines for the development of new applications from reusable components (development WITH reuse);

d. construction of a prototype repository, component model definition, components classification scheme definition, domain model, common architecture, product-line approach [SER 96].

4. RRM Activities: Management of Reuse Process and Best Development Practices and Experiences.

Results: The pilot reuse project results at IBM, NASA, HP, GTE, Boeing, Northgrum, Netron, Semantic Designs attracted the management attention and convinced them of the validity of a reuse introduction on a larger scale. Therefore the top management became more committed to support further effort to widen the reuse culture and to spread reuse across the company [Sonnemann 95; SER 96].

5. RRM Activities: Reuse Metrics and Effort Models, Best Development Practices and Experiences and Management of Reuse Process.

Results: As it is shown by the previously mentioned case studies in IBM, NASA, HP, GTE, Boeing, Northgrum, Netron, and Semantic Designs, there is a practical solution to address the uncertainty related to the introduction of a new technological approach, such as software reuse. The solution includes the launching of limited scale programs as pilot applications rather than initiating a full scale reuse plan. Such a solution is often chosen by top management of medium and large size organizations. These pilot projects are usually monitored to determine the weaknesses in the adopted implementation process and to identify possible areas for improvement before the introduction in enlarged to the enterprise level. At the same time cost saving trends are identified and the basis for a future Return-On-Investment (ROI) expectations is established.

This incremental approach to reuse introduction is very sensible and usually recommended, but as far as the objective data that can be obtained from the pilot applications should always consider that they are usually only partial results. In other words, real savings may be obtained only in the long term and there is no quick silver bullet that can lead to fully appreciate the benefits of software evolution and reuse programs for minimal costs, and create order of magnitude improvements in less than several years (3-5 years based on the SER experiences) [SER 96].

6. RRM Activities: Training, Management of Reuse Process, Market Place and Demands, Product-line approach, Common Architecture, Financing and Marketing Forecast.

Results: Reuse culture dissemination within the IBM, NASA, HP, GTE, Boeing, Netron, and TI, Semantic Design, and ASC organizations required the following:

Results: In the cases of IBM, NASA, HP, GTE, Boeing, Northgrum, Netron, and TI systematic reuse requires accurate analysis of organization-specific needs, long term, top-down management support, implementation of reuse measurements, identification of expected key benefits, and adequate technological support. Once the necessary organizational, methodological and technical issues related to reuse have been identified and put into practice, a complete reuse program also needs an appropriate automatic support, especially if the number of the reusable assets grows over the threshold of few components and/or if the organization is geographically distributed.

8. RRM Activities: Use of Software Standards CORBA and DCOM, Reuse Metrics and Effort Models, Best Development Practices and Experiences, Case-Tools.

Results: Experience in Motorola, CSC, Rolls-Royce, Intecs, 3M, Xetron, ASC, Semantic design, NASA, Northgrum, Sun, ASSET, Raytheon, UNISYS, CSC, Motorola, and DoD demonstrated that the following problems are among the major inhibitors causes:

a. difficulties in easily finding suitable software components in the repository;

b. lack of comprehensive standards and reuse metrics;

c. some reuse technologies are not amateur yet, and a lack of enough empirical data on their effectiveness and efficiency makes many organizations hesitates to adopt them.

9. RRM Activities: Domain Modeling, Product-Line, Market Place and Demands, Management of Reuse Process.

Results: Further details are necessary to understand the reasons behind the organizations diverse achievements. In particular, at HP, Intecs, Draco, DoD, Xetron, 3M, NASA, GTE, IBM, Computing Devices, Semantic Designs, Netron, DCSCORP, and TI the high achieved reuse rate seems to be strictly related to the characteristics of the application domain: a different trend is usually observed for single-product versus multi-product (i.e., homogeneous versus heterogeneous) domains as well as for stable versus unstable domains. That is to say, the possibility of reusing is higher for organizations working in a narrow market sector where there exists a certain homogeneity among the developed products or for company departments dealing with specific product lines as compared to the rates achievable by companies operating in a diverse market sector.

Of course it is also important to take into account the relative size of the company or department and the number of product lines in the same market sector.

Furthermore, the stability of the domain highly influences the possibility of significant reuse rates. In fact, when the software requirements are stable in time and do not undergo continuous dramatic changes, reuse can be achieved at very high levels (i.e., up to 80 to 90%) such as in NASA [SER 96] and Semantic Designs cases.

10. RRM Activities: Management of Reuse Process, Domain Modeling, and Case-Tools.

Results: From the diversity of domain and size of the presented organizations case studies we can infer that there is no real influence of using certain methodology rather than another. It is reasonable to assume that any approach could work as long as it takes into account the entire range of technical and organizational aspects that make a software producing company work: organizational, managerial, methodological as well as technical and technological.

11. RRM Activities: Management of Reuse Process, and Case-Tools.

Results: The reasons for choosing certain reuse technology or tools depend on:

a. the nature of the technology that may facilitate the organization to experiment with it and to evaluate its effectiveness in meeting the needs through a small to medium size pilot project;

b. the customizability of the technology or the tools to the organization environment which means that the organization should be able to request ad-hoc enhancements where necessary;

c. The technology should provide the organization with the capability to manage the intermediate transition period of redevelopment of existing applications.

12. RRM Activities: Management of Reuse Process and Quality Control.

Results: In order to applications evolve to continually meet the needs of user and organizations, changes are continually being made. It is estimated that over half of a developer's time is actually spent maintaining software, from small bug fixes to large alterations, such as a database management system change. This leads to applications that are poorly understood and badly (if indeed at all) documented, so that rather than being an organization's main asset, these software systems are a continual drain on valuable resources, in terms of both money and people. IBM, HP, Netron, DCSCORP and SUN achieved a higher level of reduction in software maintenance effort by incorporating reuse in their software development life-cycle.

13. RRM Activities: Common Architecture, Domain Modeling, and Management of Reuse Process.

Results: Some organizations such as DoD, Xetron, Robbins-Gioia, Computing Device, and 3M develop their product based on ad-hoc reuse approach without any organized or planned attempt to exploit commonalties between applications, although significant overlaps in requirements between applications in the same domain usually exist. Ad hoc reuse of parts from existing applications may occur, even reuse of an entire application by adapting it to satisfy a slightly different set of requirements, without any formal recording of the commonalties [Jacosbson 97]. This results in disparate applications, with no formal knowledge about commonalties, and no common maintenance and evolution of parts from the same origin.

14. RRM Activities: Common Architecture, Domain Modeling, and Product-Line.

Results: HP, IBM, Boeing, NASA, GTE, Semantic Designs, applications do in fact form part of an informal application family, and could have been created from common architecture, with a set of reusable components providing the tailoring for specific product requirements and platforms.

This common architecture approach offers many benefits in terms of:

Results: IBM, HP, Boeing, NASA, GTE, Semantic Designs used the domain engineering method to analyze and model the requirements in the domain, to identify what were stable and what were varied and assessed the applicability of the common architecture approach to the domain. The analysis of existing applications provided major input to this analysis. The analysis convinced these organizations that the common architecture approach would fulfill their needs. Also the models that were produced proved useful as a means to conciliate the views of different product teams.

16. RRM Activities: Common Architecture, Domain Modeling, Product-Line, Software Standards CORBA or DCOM, and Market Place and Demands.

Results: ASC, HP, IBM, NASA, Netron, Northgrum, GTE, ASSET, Semantic Designs, and TI achieved faster time to market and/or improved quality, because they decided to base future development on common architecture and product-line approaches. The objective is to develop one common architecture for several types of applications, and in have it to comply with the standards of more than one market.

3.2. Summary Interpretation of Corresponding Survey Results

The survey of industry, academia, and government software developers was carried out to validate the software RRM and to determine whether or not the RRM activities are applicable across organizations and are predictors of software reuse capability such as ‘success.’ It has been hypothesized that incorporation of such a RMM would promise three things:

1. Decreased products development effort;

2. Decreased time-to-market;

3. Increased product quality.

The survey examined 34 questions about the software RRM that incorporates both the technical and organizational activities that might be needed to establish a successful software reuse practice in the organization.

A. Technical Activities by Question Number:

1. Technologies (or Tools e.g., Software Standards CORBA, DCOM, COTS), metrics, effort models that support reuse and Case-Tools.

Survey Questions: SQ14, SQ18, SQ21, SQ22, SQ34

2. Software development with reuse activities (technical procedures) such as: Domain Modeling, Product-line Approach, Common Architecture, Quality Control, and Best Development Practices experience.

Survey Questions: SQ3, SQ4, SQ5, SQ8, SQ11, SQ12, SQ15, SQ16, SQ17, SQ23-SQ25, SQ32, SQ33

B. Organizational Activities (Organizational Procedures) by Questions Number:

Management of Reuse Program, Market place, Financing Marketing Forecast and Training.

Survey Questions: SQ6, SQ7, SQ9, SQ10, SQ13, SQ19, SQ20, SQ21, SQ23-SQ25, SQ27-SQ31.

We also divided the survey population into four groups (categories) as follows:

1. Small organizations with small projects (G11)

2. Small organizations with large projects (G12)

3. Large organizations with small projects (G21)

4. Large organizations with large projects (G22)

Ninety-three responses were received. Most of them were sent by on-line web site submission forms. Some other forms were submitted by personal interview, mail, or fax.

We tried to avoid having more than one project from the same organization. We sometimes accepted more than one project from the same organization if they each belonged in different categories (G11, G12, G21 and G22).

3.2.1. Technologies (or Tools e.g., Software Standards CORBA, DCOM, COTS), Metrics, Effort Models that Support Reuse.

Survey Questions: SQ14, SQ18, SQ21, SQ22, SQ34.

SQ14. We have an efficient requirements analysis tool that links our most common end- user requirements with the reusable software component(s) that satisfy them.

Findings: 62% of the projects ‘do not use requirements analysis tool’ that links their most common end-user requirements with the reusable software component(s)

SQ18. Our architecture has proved at least one of the following: CORBA/OLE/DCOM..., etc., to be useful means in standardizing interfaces and data formats. (Use of Standards CORBA, DCOM..., etc.)

Findings: about 50% of the projects did consider or approve at least one of the following:

(CORBA/OLE/DCOM...,etc.) to be a useful means of standardizing interfaces and data formats.

SQ21. Our configuration management system does an exceptional job keeping track of the projects which use each reusable software component.

(Management of Reuse Process, Reuse Metrics, Effort Models, and Case Tools)

Findings: 57% of the projects keep track of the projects that use each reusable software component.

SQ22. Identify the percentage of reusable and unique software components used in the identified project.

____ % Reused developed components from other projects.

____ % Reused Commercial Off-The-Shelf components.

____ % Developed components for reuse by other projects.

____ % Developed components unique to the identified projects.

Total = 100 %.

Findings: 59% of the projects reuse about 41-80% from other projects and COTS according to the following percentage reuse of assets:

Level 1, 0-20,

Level 2, 21-40,

Level 3, 41-60,

Level 4, 61-80, and

Level 5, Greater Than 80.

SQ34. My organization uses an effort estimation model that incorporates SW reuse as a factor. (Metrics and Effort Estimation Models)

Findings: 34% of the projects are using an effort estimation model that incorporates software reuse as a factor

3.2.2. Software Development With Reuse Activities (Technical Procedures) including: Domain Modeling, Product-line Approach, Common Architecture, Quality Control and Best Development Practices Experience.

Survey Questions: SQ3, SQ4, SQ5, SQ8, SQ11, SQ12, SQ15, SQ16, SQ17, SQ23-SQ25, SQ32, SQ33.

SQ3. If you have a domain engineering section supporting the identified project, do you believe that the section support is (was) very effective and efficient. (Domain Modeling and Product Line)

Findings: 42% of the projects do not have a domain engineering section supporting the identified project at all. (No Domain Modeling) 38% of do have a domain engineering section.

SQ4. If you have software reuse repository support to the identified project do you think that the repository support is (was) effective and efficient. (Domain Modeling and Product-line)

Findings: 25% of the projects do not have software reuse repository, 41 % of the respondents who do have software reuse repositories think that the repository support is (was) effective and efficient.

SQ5. The organization has developed similar products in the past (in context of the identified project) and they are well understood by project team members. (Best Development Practices Experience.)

Findings: 47% of the projects have developed similar products in the past (in context of the identified project) and they are well understood by project team members.

SQ8. Pilot projects were used effectively to refine software reuse "best practices" prior to adopting them for routine use. (Best Development Practices Experience.)

Findings: 45% of the projects have used pilot projects effectively to refine software reuse "best practices" prior to adopting them for routine use. This confirms RQ5 and supports our findings from the case studies. (Best Development Practices Experience.)

SQ11. Projects document their software reuse lessons learned, which in turn are used to improve the organization's software reuse process. (Best Development Practices Experience and Management of Reuse Process)

Findings: 35% of the projects document their software reuse lessons learned, which in turn are used to improve the organization's software reuse process. 10% do not practice any documentation about reuse lessons leaned at all.

SQ12. Our software reuse efforts are concentrated on the identification and development of a small, high-quality set of needed and useful components. (Reuse Quality and Quality Control)

Findings: 59% of the projects considered reuse of a high-quality set of needed and useful components.

SQ15. Our software development process is built around a core set of reusable software components as the foundation for our products. (Common Architecture, Domain Modeling, Product line, Marketing Forecast, Management of Reuse Process)

Findings: 76% of the projects considered a core set of reusable software components as the foundation for their products in their development process. Many of the projects (57%) considered that during the requirement analysis phase, 43 % during the design phase, and 38% during coding phase (SQ26 - SQ28).

SQ16. We have done a thorough domain analysis of our products. (Domain Modeling)

Findings: 39% of the projects do practice a thorough domain analysis, 40% do not.

*** This confirms the SQ3 findings about Domain Modeling

SQ17. We rely heavily on a common architecture across our product line. (Common Architecture and Product-Line)

Findings: 59% of the projects rely heavily on a common architecture across their product line. 25% do not use the common architecture or product-line approach.

• Software reuse promises numerous benefits. Rank your organization top

three motives for implementing software reuse. Please select from the list

of available choices.

1. Better bid estimates.

2. Reduce development effort and costs.

3. Faster time to market

4. Better predict user needs.

5. Increase market share.

6. Successfully enter new markets.

7. Increased commonality across projects.

8. Better understanding of customer requirements

9. Improved quality.

10. Decreased product maintenance.

SQ23. Primary Motives ___

SQ24. Secondary Motives ___

SQ25. Tertiary Motives ___

(Common Architecture, Quality Control, Market Place, Marketing Forecast, Reuse effort Models, Management of Reuse Process)

SQ23. Findings: 59% of the projects considered the development effort and costs reduction as their primary reuse motive. 10% considered the faster time to market their primary reuse motive. 8% of the projects considered the better bid estimates their primary reuse motive.

SQ24. Findings: 29% of the projects considered the faster time-to-market the as their secondary reuse motive. 25% considered the increased commonality across projects as their secondary reuse motive. 18% considered the development effort and costs reduction as their secondary reuse motive. 9% of the projects considered the improved quality their secondary reuse motive.

SQ25. Findings: 19% of the projects the increased commonality across projects as their tritary reuse motive. 17% of the projects considered the improved quality their tritary reuse motive. 16% of the projects considered the decreased product maintenance their tritary reuse motive. 15% considered the faster time to market as their tritary motive

14% considered the improved quality their tritary motive

SQ23, SQ24, and SQ25 findings: the projects main reuse motives are:

Findings: 51% of the projects achieved significant improvement in the above mentioned areas.

*** This confirms our findings from the case studies

SQ27. During (after) the project requirements phase we realized high commonality with the requirements of previous project(s). (Common Architecture, Domain Modeling, Product-line, and Management of Reuse Process)

Findings: 57% of the projects realized high commonality with the requirements of previous project(s) during (after) the project requirements phase.

SQ28. During (after) the project design phase we realized high commonality with the design of previous project(s). (Common Architecture, Domain Modeling, Product-line, and Management of Reuse Process)

Finding: 43% of the projects realized high commonality with the design of previous project(s) during (after) the project design phase.

SQ29. During (after) the project coding phase we realized high commonality with the code (documentation) of previous project(s) during (after) the project coding phase. (Common Architecture, Domain Modeling, Product-line, and Management of Reuse Process)

Finding: 38% of the projects realized high commonality with the code (documentation) of previous project(s).

*** SQ27, SQ28, and SQ29 finding: the projects tried to get most of reuse benefits by considering the reuse approach during the early phases of the software development life cycle.

SQ31. Our decisions to bid on new projects or enter new markets are based heavily on our software reuse capabilities. (Market Place, and Financing and Marketing Forecast)

Finding: 36% of the project teams think that their decisions to bid on new projects or enter new markets are based heavily on their software reuse capabilities. (Market Place and Marketing Forecast)

SQ32. Our reusable software components have proven through operational use to be highly reliable. (Quality Control and Reuse Quality)

Findings: 60% of the projects reusable software components have proven through operational use to be highly reliable.

*** this confirms the case studies' findings.

SQ33. We have a valuable process for certifying reused software components. (Quality Control and Management of Reuse Process)

Finding: 45% of the projects do not have a process for certifying the reused software components.

3.2.3. Organizational Activities (Organizational Procedures) by Questions Including:

Management of Reuse Program, Market place, Financing Marketing Forecast, and Training.

Survey Questions: SQ6, SQ7, SQ9, SQ10, SQ13, SQ19, SQ20, SQ21, SQ23-SQ25, SQ27-SQ31.

SQ6. Senior management has demonstrated a strong support for software reuse by allocating funds and personnel over a number of years. (Management of Reuse Program, Financing Reuse)

Findings: 56% of the projects senior management has demonstrated a strong support for

software reuse by allocating funds and personnel over a number of years.

SQ7. There is a strong influential individual(s) in senior management who actually advocates and supports developing a software reuse capability. (Management of Reuse Program)

Finding: 52% of the projects agreed that there is a strong influential individual(s) in senior management who actually advocates and supports developing a software reuse capability.

*** SQ6 and SQ7 support each other

SQ9. Our staff has a very competent software reuse education and training courses (internal and/or commercial). (Training)

Finding: 29% of the staff in the projects have a very competent software reuse education

and training courses (internal and/or commercial).

*** Lack of training

SQ10. Education for senior management is a very important aspect of our software reuse education and training program. (Training and Management of Reuse Program)

Finding: 51% of the project teams believe that the education for senior management is a very important aspect of their software reuse education and training program.

SQ13. We conduct market analysis of our products market place to effectively determine what domains to be modeled (or what COTS to be used) in order to develop reusable SW components to be placed in our software reuse repository. (Market Place, Market Forecast, Domain Model, COTS, Product-line)

Findings: only 29% of the projects conducts market analysis of our products market place to effectively determine what domains to be modeled (or what COTS to be used) in order to develop reusable software components

*** SQ13 finding confirms SQ3 finding.

*** Low level of Domain modeling achieved

SQ19. Software developers and maintainers precisely follow a software reuse process that is defined and integrated with the organization's software development process. (Management of Reuse Program)

Finding: 33% of the projects' developers and maintainers precisely follow a software reuse process that is defined and integrated with the organization's software development process.

*** Reuse process is not common and integrated part of most of the organizations’ software development process.

SQ20. Performance of the software reuse process is carefully measured and analyzed to identify weaknesses, and plans are established to address the weakness. (Management of Reuse Program, Best Practices and Experiences)

Findings: 24% of the projects measure and analyze the software reuse process carefully to identify weaknesses, and plans are established to address these weaknesses.

*** Lack of software reuse metrics

*** This also confirms SQ19 finding about the lack of integrating the software reuse with the organizations’ software development process.

SQ30. Management has created new business opportunities that take advantage of the organization's software reuse capability and reusable assets. (Management of Reuse Program, Financing and Marketing Forecast, Market Place)

Findings: 34% of the projects Management has created new business opportunities that take advantage of the organization's software reuse capability and reusable assets.

*** Limited success of market forecasting based on reuse

*** This confirms the findings of SQ24, and SQ31.

Table 3. represents the survey summary.
 

3.3. Research Questions

In this section five research questions stated in section 2.2.3 will be answered.

Research question 1. Is the implementation level of the software reuse reference model activities predictive of:

Research question 2. Is the reuse percentage predictive of the implementation level of the software reuse reference model activities?

Based on the survey data analysis there is no correlation between the reuse percentage and the implementation level of the software reuse reference model activities

Research question 3. At which phase of the software life cycle organizations get the greatest reuse benefits?

Based on the following results:

- 57% of the projects realized high commonality with the requirements of previous project(s) at requirements phase.

- 43% of the projects realized high commonality with the design of previous project(s) at design phase.

- 38% of the projects realized high commonality with the code (documentation) of previous project(s).

We concluded that considering the reuse approach during the early phases of the software development life cycle organizations get the greatest reuse benefits. (Questions 27-29)

Research question 4. How organizations collect and utilize reuse metrics and incorporate reuse effort estimation models as part of their software development life cycle?

Considering the survey data analysis we found that here is a lack of collecting reuse metrics and using effort estimation models with reuse.

Only 24% of the projects measure and analyze the software reuse process carefully to identify weaknesses, and have plans established to address these weaknesses.

Research question 5. Is the reuse process common practice and an integrated part of the organizations' software development process?

Considering the survey data analysis only 33% of the projects developers and maintainers precisely follow a software reuse process that is defined and integrated with the organizations’ software development process.

3.4. Summary Interpretation of Corresponding QSM Study

Quality Software Management (QSM), Inc. has over 15 Years of Software Industry Research. They have database of over 4000 software development projects collected Worldwide.

QSM helped us to compare 19 selected projects out of the George Mason University (GMU) data set with their database to quantify the real benefits of software reuse. The data analysis demonstrated evidence of the gains realized.

With the QSM database we have carried out the following:

4. SOFTWARE REUSE REFERENCE MODEL CONCLUSION AND CONTRIBUTIONS

This section contains summary interpretations of the research results presented in the previous section (Section 3).

The objectives of this research are: 1. The developing of a theoretical software RRM, 2. Empirically validating the RRM, 3. Providing the empirical impact of the software RRM implementation level on the software effort, quality, and time-to-market.

To validate the theoretical model we used three different research approaches:

1. Carrying out 25 case studies of industry and government software developers;

2. Surveying the industry and government software developers;

2. Carrying out Quality Software Management (QSM) study of 19 selected projects.

At the conceptual level a software RRM is a reusable structure composed of one or more generic, generalized components that serve to represent a generic, generalized software development function.

The organizations used in the empirical part of this dissertation with the highest software reuse capability use the components depicted in Figure 1.

The empirical part of this research also validates that the RRM is domain independent in that the framework does not depend on any particular applications software domains.

The research results support the 1995 [Sonnemann 95] early study thesis that there is a set of success factors (software reuse leading indicators) that are common across organizations and have some predictability relationships to software reuse. Based on the case studies and survey results, we confirm that the leading indicators of software reuse capability are: product-line approach, architecture which standardizes interfaces and data formats, common software architecture across the product-line, design for manufacturing approach, domain engineering, management which understands reuse issues, software reuse advocate(s) in senior management, state-of-the-art tools and methods, precedence of reusing high level software artifacts such as requirements and design versus just code reuse, and trace end-user requirements to the components that support them.

This research also investigated to see if software reuse had a predictive relationship to effort, time-to-market and quality.

Based on the survey and the case studies' results we concluded that software RRML (See section 2.2.4.) in the organization is predictive of products development effort, time-to-market, and product quality. So the organizations that scored high RRML achieved the following:

- Decreased level of development effort (or increased productivity)

- Increased level of product quality

- Decreased level of development time

- Decreased level of time-to-market

These findings will help software developers in the implementation of the RRM. These findings will also serve as guidance for systematic best practices reuse in an organization.

REFERENCES

Applied Expertise, Inc., Software Reuse Benchmarking Study: Learning from Industry and Government Leaders, Report for the US Department of Defense Software Reuse Initiative, January, (1996).

Agresti, W., Evanco, W., Projecting Software Defects From Analyzing Ada Designs, IEEE Transactions on Software Engineering (TSE), 18(11), 988-997 (1992).

Asrar, G., Data and Knowledge System for Mission to Planet Earth, Remote Sensing Reviews, 13, 1-25 (1995).

Baldo, J.; Moor, J. and Rine, D., Software Reuse Standards, Standard Views: ACM Perspectives on Standardization, 5(2), 50-57 (1997).

Bareiss, E., Proceedings of the 3rd. Workshop on Case-based Reasoning (DARPA), Washington DC, Kaufmann, (1991).

Booch, G., Object Solutions, Managing the Object-Oriented Project, Addison-Wesley, (1996).

Basili, V. and J. Musa, The Future Engineering of Software: a Management Perspective, COMPUTER, September, 90-96 (1991).

Bell Canada, Software reuse case study - TRILLIUM, ARPA Report, 13 September 1993.

Boehm, B., Software Engineering Economics, Englewood Clifs, Prentice-Hall, NJ., 1981.

Boehm and P. Papaccio, 'Understanding and controlling software costs', IEEE Transactions on Software Engineering, October, 14(10), (1987).

Boehm, B., and W. Scherlis, Megaprogramming (preliminary version), ARPA Paper, (1992).

Bollinger, T., and S. Pfleeger, Economics of Reuse: Issues and Alternatives, INFO SOFT, December, 643-653 (1991).

DARPA, Proceedings from the CBS Workshop, Washington D.C., May,. Morgan Kaufmann, 8-10 (1991).

Card, D., and E. Comer, Why do so Many Reuse Programs Fail?', IEEE Software, September, 114-115 (1994).

Cruickshank, R., and Gaffney, J., The Economics of Software Reuse, REUSE-ECON-MODEL- 91128-MC, Software Productivity Consortium, Herndon, Virginia, (1991).

Cusumano, M., Japan’s Software Factories: A Challenge to U.S. Management, NY, Oxford University Press, (1991).

Fafchamps, D., Organization Factors and Reuse, IEEE Software, September, 31-41 (1994).

Fayad, M., Tsai, W., and Fulghum, M., Transition to Object-Oriented Software Development, Communication of the ACM, February, 39(2), 109-121(1996).

Fichman, R., Kemerer, C., Object Technology and Reuse: Lessons from Early Adopters, IEEE Computer, October, 47-59(1997).

Fonash, P., Characteristics of Reusable Software Code Components, Ph.D. Dissertation, George Mason University, 1993.

Frakes, W., and Isoda, S., Success Factors of Systematic Reuse, IEEE software, Septmber, 15-191(994).

Ferrentino, A., SNAP: The Use of Reusable Templates to Improve Software Productivity and Quality, Template Software, Inc., Herndon, Virginia, 1994.

Fonash, P., Metrics for Reusable Software Code Components, Ph.D. Dissertation, George Mason University, Fairfax, Virginia, Fall 1993.

Frakes, W., Software Reuse Empirical Studies, Virginia Polytechnic Institute and State University, Department of Computer Science, Blacksburg, Virginia, 11 October 1992.

Frakes, W., and W. Riddle, Instituting and Maturing a Practical Reuse Program, International Perspectives in Software Engineering, Summer 2nd Quarterly, 18-26 (1993).

Frakes, W., and Isoda, S., Success Factors of Systematic Reuse, IEEE Software, September 15-19 (1994a).

Frakes, W., and C. Fox, Sixteen Questions about Software Reuse, Software Engineering Guide Draft Paper, November, 1-25 (1994b).

Frakes,W., and Fox, C., Quality Improvement Using a Software Reuse Failure Modes Model, Software Engineering Guild Draft Paper, November, 1-13 1(994c).

Frakes, W., and Fox, C., Sixteen Questions about Software Reuse, Communications of the ACM, 38(6), 75-87 and 112, June (1995).

Gibbs, W., Software's Chronic Crisis, Scientific American, September, 86- 95 (1994).

Gold, J., Reusabilty Promise Hinges on Libraries, IEEE Software, 13(1), January 86-92(1993).

Griss, M., Software Reuse: from Library to Factory, IBM Systems Journal, 32(4), 548-566 (1993).

Hammond, Proceedings of the Workshop on Case-based Reasoning (DARPA), Clearwater, Florida, Morgan Kaufmann, (1988).

Hoel, P., Introduction to Mathematical Statistics, John Wiley and Sons, New York, (1954).

Jacobson, I., Griss, M., Jonsson, P., Making the Reuse Business Work, IEEE Computer, October, 36-42(1997).

Joos, R., Software Reuse at Motorola, IEEE Software, September, 42-47 (1994).

Kiely, D., Are Components the Future of Software?, IEEE Computer, February, 10-11 (1998).

Kogut,P., and K. Wallnau, Software Architecture and Reuse: Senses and Trends, Tutorial for Tri-Ada Conference, 7 November (1994).

Kolodner, J., Proceedings of the Workshop on Case-based Reasoning (DARPA), Clearwater, Florida, Morgan Kaufmann, (1988).

Kolodner, J., Case-Based Searching", San Mateo, CA; Morgan Kaufmann, (1993).

Lamb,D., Software Engineering: Planning for Change, Prentice Hall, (1988).

Leary, J., Information Architecture - an Architectural Basis for Evolution of Large Scale Software Systems, Software Engineering Institute (SEI) Paper for NPGS Workshop, 2 February, 1994a.

Leary, J., Information Architecture Notions, briefing slides presented to Defense Simulation and Modeling Office Meeting, 19 October 1994.

Lim, W., Effects of Reuse on Quality, Productivity, and Economics, IEEE Software, September, 11(5), 23-30, (1994).

Lim, W., Managing Software Reuse’, Englewood Cliffs, NJ. Prentice-Hall, (1998).

Loral Federal Systems, Air Force/STARS demonstration project experience report, ARPA Report, July (1994).

McCain, R., Introduction to Reuse Technology and Application, slides - Defense Systems Management College, September (1991).

McClure, C., The Three Rs of Software Engineering: Reengineering - Repository - and Reusability , Englewood Cliffs, NJ. Prentice-Hall, (1992).

Nada, N., Software Reuse-Oriented Functional Framework, Ph.D. Dissertation, George Mason University, Fall (1997).

O'Connor, J., et al., Reuse in Command-and-Control Systems, IEEE Software, September, 70-79 (1994).

Parnas, D., On the Design and Development of Program Families, IEEE Transactions on Software Engineering, SE-2, 1-9 (1976).

Patterson, F., Reengineerability: Metrics for Software Reengineering for Reuse, Ph.D. Dissertation, George Mason University, Fall (1995).

Pfleeger, S., Software Engineering, The Production of Quality Software, Macmillan publishing Company, (1987).

Pfleeger, S., An Investigation of cost and productivity for Object Oriented Development, Doctoral Dissertation, George Mason University, Fall (1995).

Pfleeger, S., Design and Analysis in Software Engineering, Part 1: The Language of Case Studies and Formal Experiments, Software Engineering Notes , (19) 4, 18-19 (1994).

Pfleeger, S., Design and Analysis in Software Engineering, Part 3: Types of Experimental Design, Software Engineering Notes, 20 (2), 14-16 (1994).

[Pfleeger, S., Design and Analysis in Software Engineering, Part 5 Analyzing the Data, Software Engineering Notes, (20) 5, 14-16 (1994).

Pressman, R., Making Software Engineering Happen: A Guide for Instituting the Technology, Prentice Hall, (1988).

Pressman, R., Software Engineering: A Practitioner’s Approach, McGraw-Hill, (1992).

Quality Software Management (QSM), Inc., Report on Independent Research Study of Software Reuse: Using Frame Technology, September (1994).

Rine, D., Supporting Reuse With Object Technology, Special Issue on Software Reuse Processes and Products, October, Computer, 43-45, IEEE Computer Society (1997).

Rine, D., Development of Reusable Software for the World Wide Earth Observing and Earth Information System : EOEIS, October, Internet News, (1997).

Rine, D., and Sonnemann, R., Investments in Reusable Software: A Study of Software Reuse Investment Success Factors., The Journal of Systems and Software, (1998).

Software Evolution and Reuse Consortium (SER), Solutions for Software Evolution and Reuse, SER Deliverable SER-D2-A, (1995).

Robertson, P., and De Ferrari, Systematic approaches to visualization: is a reference model needed?, Scientific Visualization, Academic Press Ltd., Ch.18, 287-305 (1994).

Sonnemann, R., Exploratory Study of Software Reuse Success Factors, Ph.D. Dissertation, George Mason University, Fairfax, Virginia, Spring (1995).

Sommerville, I., Software Engineering, 5th Edition, Addison-Wesley, New York, (1996).

Software Productivity Consortium (SPC), Reuse Adoption Guidebook, SPC-92051-CMC, Ver 02.00.05, Software Productivity Consortium, Herndon, Virginia, November (1993).

Staringer, W., Constructing Applications from Reusable Components, Software, IEEE Computer Society, September, 61-68 (1994).

Tirso, J., and H. Gregorious, Management of Reuse at IBM', IBM Systems Journal, 32(4), 612-615 (1993).

Tracz, W., Software Reuse: Motivators and Inhibitors, Stanford University paper presented at the Workshop on Future Directions in Computer Architecture and Software, 5-8 May (1986).

Tracz, W., Where does Reuse Start?, transcript - keynote address for the Reuse in Practice Workshop sponsored by IDA, SEI, and SIGAda at Software Engineering Institute, Pittsburgh, Pennsylvania, 11-13 July (1989).

Tracz,W., Domain-specific Software Architecture Frequently Asked Questions, ACM SIGSOFT Software Engineering Notes, 19(2), 52-56, April (1994).

Troy, R., Software Reuse: Making the Concept Work, Engineering Software, Special Editorial Supplement, 16-20, 13 June (1994).

Unisys Corporation, Army STARS Demonstration Project Experience Report, ARPA Report, 25 August 1994.

Wasmund, M., Implementing Critical Success Factors in Software Reuse, IBM Systems Journal, 32(4), 595-611 (1993).

Withey, J., Implementing Model Based Software Engineering in Your Organization: an Approach to Domain Engineering, technical report, CMU/SEI-93-TR, Software Engineering Institute, Pittsburgh, Pennsylvania, November 1993.

Zelkowitz, M. and Wallace, D. Experimental Models for Validating Technology, Computer, 31(5), 23-31, IEEE Computer Society (May 1998).