(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 developing and using paradigms that will significantly promote decreased effort in developing software products, increased quality of software products and decreased time-to-markets. Decreased effort and increased quality will decrease the overall cost of software and also decrease the time-to-market of the software. Our research thesis is that software manufacturing based upon a validated software reuse reference model proves to be a practical solution to decreased software development effort, increased software product quality, and decreased time-to-market, especially if it is applied in a systematic way across the software development life cycle, including reuse of requirements, specifications, designs, documents, codes and verification/validation plans. The critical problem in today’s practice of software reuse is a failure to conceptualize, define and develop necessary details to support a valid software reuse process reference model. The software development industry will not be successful in utilizing and managing software reuse paradigms until there is a conceptualized, well defined and "validated empirical reference model" for software manufacturing that incorporates best software reuse practice and that can be customized for different kinds of software development enterprises. In this research a theoretical model of the software reuse reference model is presented, based upon prior knowledge and expertise about software reuse. Then, this model is empirically validated using three different empirical studies. The definition and validation of this 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 case studies and surveys. 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 well-defined and validated reference model for the practice of software reuse. A secondary contribution is an initial set of case studies 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 features. Promoting the reference model 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.

1. SOFTWARE REUSE MANUFACTURING REFERENCE MODEL

1.1. Introduction

The industrial (manufacturing) world has been successful for many years in implementing a product-line approach to reuse using pre-fabricated (pre-manufactured and interchangeable) components. It is also a regular practice for these industries to assemble parts into products and use the same parts in more than one product within a "product-line" family. Therefore, can this same "manufacturing" approach be used in software engineering? [Kiely 98] To answer this question we have to look closely at the software industry and, in particular, at the practice of software reuse. Many software organizations believe that software reuse will improve their productivity (effort) and their products quality. Unfortunately, there is little data available supporting this thesis. The majority of current information available on software reuse comes from the literature, which contains unproved theories applied in a limited way to a few pilot projects or case studies [Sonnemann 95].

The present software reference models based on reuse research do not include or consider many of the software reuse technical and non-technical factors in the formulation of their quantitative models. Software developers need to achieve better understanding, estimation, evaluation, and quantification of the software reuse and business perspective factors as well as their predictive relationship to software effort and quality.

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].

In any software organization it is 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 and the organization’s relationships with a validated Software Reuse Reference Model (RRM) in terms of technical and non-technical activities.

The reason for identifying the activities of a validated software manufacturing RRM is that the RRM provides an important link between the technical and non-technical activities of software reuse and 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 non-technical activities needed for a successful software reuse implementation plan [Jacobson 97]. Software manufacturing (including: market domain model, common architecture, and product-line approaches) includes both business and engineering 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 their plans, as necessary, based on an empirically validated software RRM.

Moreover, at the conceptual level a software manufacturing RRM is a reusable structure, that is more comprehensive than patterns composed of one or more generic, generalized components that serve to represent a generic, generalized software manufacturing function [Rine 97].

In this paper a theoretical model of the RRM is first presented, and then empirically validated. The organizations used in this empirical study with high level of software RRM implementation (reuse capability) use the components depicted in Figure 1.

1.2. The Problem

Many software development organizations believe that investing in software reuse will improve its 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 investing in software reuse. The majority of current information available on software RRMs comes from the literature, which contains unproved theories or theory 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 conceptualize, define and develop necessary details to support a valid software RRM. The software development industry will not be successful in taking advantage of software reuse paradigms until there is a conceptualized, well defined and "validated empirical reference model" for software manufacturing that incorporates best software reuse practices and that can be customized for different kinds of software development enterprises. In this research a theoretical model of the RRM is presented, based upon prior knowledge and expertise about software reuse.

The main contribution of our research reported in this paper is an effective, efficient, well-defined and empirically validated RRM for the practice of software reuse. The research provides evidence that promoting the 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 case studies 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 reuse utilization and management features to our RRM model features.

1.3. Conclusions

Software manufacturing based upon a validated RRM proves to be a practical general solution to decreased software development effort, increased software product quality, and decreased time-to-market, especially if it is applied in a systematic way across the software development life cycle that includes reuse of requirements, specifications, designs, documents, codes and verification (or validation) plans.

1.4. Rationale

Organizations are looking for ways to develop a practice of software reuse. If an organization is to make a major investment in software reuse it needs to use an effective, efficient, and empirically validated software reuse manufacturing RRM. The statistical analysis of our survey and our case studies' results presented in this paper can be interpreted to show how software development enterprises can improve their competitive edge and time-to-market through decreased effort in the software development process and increased product quality.

2. BACKGROUND AND RESEARCH METHOD

2.1 Background

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

2.2. Technologies That Support Reuse (Tools)

Technologies that support reuse are the tools used to develop, find, understand, improve, integrate, and test reusable components. The problem is lack of technology that would support reuse. Some technological problems include lack of (1) techniques for building and maintaining component libraries [Gold 93]; (2) tools for promoting reuse; and (3) methodologies supporting modification and use of reusable components, especially for maintaining software.

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 conducted. 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 technology. Rather, the application of the technology is evaluated (both qualitatively and quantitatively).

2.2.1. Software Standards UML and CORBA

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 a standard way of describing components’ functions and properties, which would be critical to designing collaboration between components. The industry is rapidly adopting the Uniform Modeling Language (UML), which combines several design notations, as default standard.

Second, repositories are needed as a means of cataloging available components with a description of their features would let developer 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.

The Object Request Broker (ORB) specification is the part of the 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 wide-area network and makes meta information describing the objects in a system and their interfaces available to an object in the system, so that it may access other objects as a client without prior knowledge of their existence. 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.

The ORB specification is programming language, operating system, and platform independent. It allows vendors considerable flexibility in their choice of implementation methods. CORBA-compliant ORBs are currently available from a number of different vendors based on mechanisms such as RPC, TCP/IP and sockets. Furthermore, the ORB permits transparent communication between objects implemented using a variety of programming languages and operating systems.

The ORB is used to manage object interaction across a network or in memory. Clients’ requests for data or services are passed to the ORB that locates the requested object or service. The ORB will also return response or results to the client object. In effect, the ORB provides what is missing in computing middleware to make the network a fully distributed operating system. The CORBA specification describes protocols for communication between ORBs, which should allow ORBs of different vendors to communicate in a federation. Several vendors are now offering CORBA 2.0-compliant ORBs, although it is not clear that compatibility issues between ORBs from different vendors have yet been resolved.

Currently CORBA is the most widely supported ORB architecture. There has rarely been such industry-wide support for a standard with this level of enterprise-wide impact. OMG has adopted, or is in the process of adopting, specifications for a number of "services" as part of the CORBA standard. These services consist of descriptions and IDL specifications of modules to perform various common software engineering tasks such as transaction management, concurrency, security.

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. Currently few of the CORB services have commercial implementations, and it may be some time before implementation of many of the services become available.

2.2.2. Trends of COTS

Software reuse sources may come from inside an organization and from outside the enterprise. 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 Interment 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 Interment 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.).

Bollinger [Bollinger 91] states that "the underlying processes behind software reuse and commercial software marketing are strikingly similar." Both must have sufficient incentives to expand the reuse investment cost. Just as COTS vendors need to make a threshold number of sales to regain the initial development cost, reuse producers achieve net-cost benefits only when their software components have been reused enough to cover their cost of creating the reusable components.

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 design and implementation cannot be accomplished until the COTS components have been selected.

However, 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 [Nada 95].

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.3. Case Tools

Software engineering methods provide the technical "how to" for building software. Software engineering tools provide automated or semi-automated support for methods. A tool is an artifact that one uses to make task easier (or possible). It has no intrinsic value except what it enables one to build. The term "software environment" means a collection of tools, practices, and working conditions supporting software engineering efforts [Lamb 88]. When tools are integrated so that information created by one tool can be used by another, a system for the support of software development, called Computer-Aided Software Engineering (CASE), is established. Software procedures are the glue that holds the methods and tools together, and enabling rational and timely development of software products. Software that supports analysis, design, testing, maintenance activities, configuration management and even quality assurance combines to create a CASE environment [Pressman 92].

Another terribly harsh, but true, stereotype is that most organizations woefully under-supply their developers with good tools. Indeed, most software development organizations have tools that, figuratively speaking, are at the level of banging rocks together. Traditional software development tools embody knowledge only about source code (e.g., editor, compiler, linker loader), but since object-oriented architectures highlight a sea of abstractions and corresponding mechanisms, it is desirable to use tools that can exploit these richer semantics. In addition, the macro process, with its emphasis upon the rapid development of releases, demands tools that offer rapid turnaround, specially for the edit/compile/execute/debug cycle [Booch 96]. Sometimes the introduction of object technology has led to major failure [Fichman 97]. Reuse success may not always be synonym of object technology use.

One of the early decisions to make in any software project is which programming language to use. An Object-Oriented Programming (OOP) languages like C++, Java, Smalltalk, Ada83, and Eiffel are coming into the mainstream of computing. Moreover, object-based languages such as Ada83 or C++ are moving into object-oriented languages such as Ada95 or Java. One major consideration in deciding whether or not to commit to an OOP language, is how programs written in these languages perform compared to computationally equivalent programs written in earlier languages such as C, Pascal, or FORTRAN [Rine 95b]. It is important to choose languages and tools that scale well. A tool that works for a solitary developer writing a small stand-alone application will not necessarily scale to production releases of more complex applications. Indeed, for every tool, there will be a threshold beyond which the tool's capacity is exceeded, causing its benefits to be greatly outweighed by its liabilities and clumsiness [Booch 96].

2.3. Software Development with Reuse Processes (Technical Procedures)

2.3.1. Domain Modeling

Domain analysis is a systematic approach for identifying the commonalties, similarities, and variabilities necessary to characterize and standardize a product-line as a domain. A domain is 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. Domain engineering uses business objectives and domain knowledge to create and standardize the product-line. Domain engineers specify the systems' architecture (interchangeability), 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].

Generally, 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] has 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 used the model to build a language-independent design organized around those objects. Effective object-oriented modeling and design promotes better understanding of requirements, cleaner designs, and more maintainable and reusable systems.

2.3.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 business), 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 group 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 flexible manufacturing systems. It was in Japan that the experience of actually setting up 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.3.3. Common Architecture

A common architecture provides standard interfaces and data formats. 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.3.4. Quality Control

Quality is an essential characteristic of all software products. Software quality is conformance to customer requirements when such requirements have been explicitly documented as a foundation for software development (also, fitness for purpose, or degree of excellence). Software quality assurance (SQA) is a set of verification and validation procedures that are applied throughout the software engineering process.

Reliability is part of software quality growth models that represent the change in reliability. These models can be used to predict when the required reliability will be achieved. There are 2 kinds of reliability: (1) Fault-free reliability, and (2) Fault-tolerant reliability. Fault-free reliability means that the executing software conforms to its execution requirements specifications. Of course, there may be faults in the specification or the software may not reflect the real needs of the user. Therefore fault-free software does not necessarily mean that the software will always behave as the user wants. Fault- tolerance means that the software can continue in operation after some system failures have occurred. Fault-tolerance is needed in situations where system failure would cause some catastrophic accident or where a loss of system operation would cause large economic loss (e.g., air traffic system). The reliability of a system or product is directly related to the reliability of the individual components or parts. A system's reliability can never be better than the individual reliability of its least reliable component [Sonnemann 95].

The most important dynamic quality factor of most software systems is their reliability. The reason for this is that costs of dealing with system failures often exceed the costs of developing the software system. There are several different reliability metrics. The most appropriate metric for a specific system depends on the type of system and application domain. Statistical testing is used to estimate software reliability [Fenton 91].

It is hypothesized that the effect of software component reuse, of course, should be positive, principally because of the higher opportunity that reuse provides for fault reduction. 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].

Agresti [Agresti 92] conducted a study to predict defect (fault) density, a software quality measurement based on characteristics of Ada83 designs and code inspection. Sixteen subsystems were used from the Software Engineering Laboratory (SEL) of NASA’s Goddard Space Flight Center. The SEL project database provided data on the extent of reuse and subsystem identification for each compilation unit, and reported defects and non defect modifications. Collectively, approximately 149 KSLOC (kilo-source lines of code) were analyzed. The project database showed that the reuse ratios (fraction of compilation units reused verbatim or with slight modification, <= 25% of lines changed) were between 26% and 28%. Defect densities were between 3.0 and 5.5 total defects per KSLOC. Four example Table 1 summarizing the project characteristics of the subsystems show that a high level of reuse correlates with a low defect density (size is in KSLOC units). Figure 2 represents the inverse relationship between defect density (defects found by source code inspection) and percent of source code ruse [Agresti 92].

2.3.5. Best Practices

Applying a certain paradigm or technology requires a change in attitude and needs to allow sufficient time for the 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 use 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 products should always be considered as the basis for work before creating new products. In addition, experiences, processes, and workproducts should always be recorded for learning, and the workproducts should be designed to facilitate reuse [STARS 95].

The reality is that, a development team will likely fail if it sets out to craft a framework from scratch. The most successful framework seems to come from harvesting results and generalizing experience from earlier successful systems in the same domain.

A smaller number of developers should be skilled in crafting new classes. A smaller number still should be adept at discovering patterns of classes and able to carry out their realization. Only a very small number of developers need to be the authors of new, strikingly creative patterns. Furthermore, the fact that in successful projects these roles overlap in time permits a team that's under an intense schedule pressure to overlap the learning process [Booch 95].

Experience 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.3.6. Reuse Metrics

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 articulates three assumptions on which predictor metrics are based:

Fonash [Fonash 1993] grouped the software 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?

• 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].

The following metrics could be used as 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]

2.4. Software Development with Reuse Processes (Non-technical Procedures)

2.4.1. Management of Reuse Program

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].

Maximum reuse leverage can be achieved from a business strategy that looks beyond current projects, i.e., a feed-forward mechanism that you may take by considering the requirements of future or concurrent projects explicitly as you develop software to satisfy the current project requirements. Because software reuse is a business strategy it requires training at higher levels of management than are customarily involved in new technology adoption [Card 94].

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].

Horizontal reuse is reuse across domains. Vertical reuse is reuse within a domain. The reverse engineering approach allows software engineers to recover reusable components from existing requirements, design and code, and then use them to populate the reuse library. Forward engineering, or designing for reuse, is a strategy in which special efforts are taken to make newly developed software reusable [Joose 94].

2.4.2. Financing Marketing Forecast

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 4 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 nonreusable 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].

Software components created as part of an application system development are unlikely to be reusable. These components are geared towards the requirements of the system in which they are originally included. To be reusable, they have to be generalized to satisfy a wider range of requirements. Some components can be reused without change. More commonly, however, it will be necessary to adapt the component in some way to take account of the particular requirements for the system being developed.

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. As Figure 5 illustrates, a certain number (N) of reuses of components are necessary to break even on any reuse investment (Io). The figure illustrates that more than N2 reuses are needed for the case depicted.

2.4.3. Market Place

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, none of the existing software cost or quality estimation models 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.

Prior to entering the software reuse market, a business should perform a reuse capability analysis. If business capabilities are not correctly assessed and aligned with the potential opportunities, the target market share may be quite small. Such a situation could make for financial failure. The objective is to maximize the actual reuse within an identified target for reuse opportunities with respect to business capabilities. The software asset producer, broker, and consumer roles are important, separable aspects of reuse that form distinctive patterns of activity within the reuse engineering idiom [STARS 95].

Management should fund the creation of components (by "producers"), and also encourage product developers ("consumers") to make use of available reusable components, rather than write their own. This would ensure that producers are aware of, and responsive to, the needs of the consumers and that reuse funding is not diverted [Griss 93]. 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].

If a software company can leverage the reusable components in another market, it should be able to enter a new market with little retooling [Griss 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 nonreuse development, or even cost-focused reuse-based development. Figure 6 represents the marketing trends for certain domain products. 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].

2.4.4. Training

In a technology that is changing as rapidly as software engineering, it is essential that a continuing program of methodological training be instituted for large 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 project must be preceded by an effective software planning process that includes object oriented (OO) techniques’ consideration [Fichman 97]. A critical part of these early activities is changing the culture. The OO 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:

- 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.5. Problem and Research Hypothesis

This research hypothesizes [Nada 97] that there is exist an effective and validated software manufacturing RRM that incorporates both the technical and non-technical facets of software reuse and identifies its impact on software development effort, quality, and time to market.

2.6. Research Questions and A Proposed Software Reuse Reference Model

Our literature search uncovered a number of possible software reuse activities, as well as a reuse relationship with productivity, quality, and time-to-market. The five questions derived from our literature search and related theoretical work presents us with a reference model comprising a theory of software reuse implementation approach.

We tried to answer the following research questions:

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

predictive of:

A. Products development effort level

B. Time-to-market level

C. Product quality level

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?

2.7. Research Approach

In this section we summarize the research approach taken by means of fourteen steps.

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

A. Review literature on software reuse to identify the reuse technical and non-technical 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; Applied Expertise 94; Fonash 93; Griss93; Frakes 94; Boehm 81].

This step includes the refining of the studies comprising different technical and non-technical 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:

software 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.

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 features have been defined to characterize the applications represented within each case study. Table 2. represents the case studies features template.
 

                                                                             Table 2. Case Studies Features Template
 

1. Application domain	2. Software Type   (e.g. data-intensive applications, embedded, client/server, ...etc.)
3. Average size of applications  and programming language(s)	4. Organization experience with reuse (how many years)
5. Reuse program history (including achievement and/or obstacles)       -  Reuse experience time       -  Motives       -  The investments in the reuse introduction program          (incentives, organizational  restructuring,  resources and training )      -  Senior management support and commitment       -  inhibitors       -  Achievements	6. Reuse metrics       - Reuse percentage %       - Productivity        - Defect density ratio (quality)              - The decreased level of development effort       - The decreased level of development time       - The decreased level of time-to-market      - Return-on-investment (ROI)
7. Reuse team size (persons)	8. Reuse team experience (average)
9. Focus (single product line, family or group of products), vertical   (specific product area), horizontal (general purpose)	10. Reuse percentage (average)   [ levels: 25% Low , 26-60% Average , 61-90%High]
11.  The decreased level of development effort (average)   [ Levels: 25% Low , 26-60% Average , 61-90% High]	12.  The decreased level of development time (average)   [ Levels: 25% Low , 26-60% Average , 61-90% High]
13.  The decreased level of time-to-market (average)   [ Levels: 25% Low , 26-60% Average , 61-90% High]	14. The increased level of product quality (errors/KSLOC)   [ Levels: < = 2 High, 3-5 Average, > 5 Low]
15. Reuse Technology(s)   - Repositories,   - Quality Assurance SW Tools  - Configuration & Version   - Management SW   - Domain Engineering ( domain modeling OMT/UML)  - COTS   - Distributed Object Computing (e.g. CORBA, OLE, Java, etc.)	16. Reuse program methodology and future strategy
17. Maintenance cost reduction   [Levels: 3 times Low, 4-6 times Average, 7-up times High]	18. Overall software development cost reduction   [Levels: 20% low, 21-50% Average, 51-up% High]
19. Return-On-Investment (ROI)   [Levels: 2-5 times Low, 6-10 times Average, 11-up High]	20. Organization software development SEI-CMM level (1-5)

 

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", Reuse Capability Model level "RCM," 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 non-technical 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.

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 3. 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 non-technical 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. 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. - 80% of case studies achieved "average or high" reduced effort;

    - 78% of case studies achieved "average or high" less schedule;

    - 70% of case studies achieved "average or high" less Time-to-Market;

    - 70% of case studies achieved "average or high" better quality;

    - 41% of case studies achieved "average or high" less Maintenance effort;

    - 63% of case studies achieved "average or high" Cost reduction

    - 41% of case studies achieved "average or high" better Return-On-Investment "ROI"

4. 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 3. 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.

Results: The results concerning the organization reuse metrics adaptations at IBM, NASA, HP, GTE, Intecs, Raytheon, ASSET, CSC, DCSCORP, SUN, TI, Boeing, Northgrum, Netron gave them the advantage over other organizations such as Draco, 3M, Xetron, and others to be able to assess and evaluate the actual benefits of reuse in terms 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].

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.

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 non-technical 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.

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 manufacturing 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 RRM 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 manufacturing RRM that incorporates both the technical and non-technical 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. Non-technical Activities (Non-technical 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 and Case-Tools.

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. (CASE Tools)

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 reuse levels:

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. Non-technical Activities (Non-technical 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 4. represents the survey summary.

3.3. Research Questions

In this section research questions stated in section 2.5. 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 help of QSM we have carried out the following:

Table 5. Summary of the QSM Study Results    

Industry  Domain	Project Productivity  Index	Industry  Productivity  Index	Schedule Change	Development Effort   Change	Project Productivity Index Change
Business	19.6	17.3	Decreased	Decreased	Increased
System Software	13.9	13.6	Decreased	Even	Increased
Telecommunications	12.0	11.8	Even	Decreased	Increased
Command and Control	11.3	11.3	Even	Decreased	Even
Real-time	9.4	7.5	Decreased	Decreased	Increased
Avionics	12.3	8.3	Decreased	Decreased	Increased

 

Also we found that the RRM is domain independent that means that the reference model does not depend on any particular applications software domains.

4. SOFTWARE REUSE MANUFACTURING 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 manufacturing RRM is a reusable structure composed of one or more generic, generalized components that serve to represent a generic, generalized software manufacturing 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 early study thesis that there is a set of success factors that are common across organizations and have some predictability relationships to software reuse. This research also investigated to see if software reuse had a predictive relationship to effort, time-to-market and quality.

Based on the case studies and survey results, we also 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.

We also provided the empirical impact of the software RRM implementation level on the software effort, quality, and time-to-market.

Based on the survey and the case studies' results we concluded that software RRM implementation level in the organization is predictive of products development effort, time-to-market, and product quality

So the organizations that scored high RRM level 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

REFERENCES

Agresti, W. and Evanco, W., Projecting Software Defects from Analyzing Ada Designes, IEEE Transactions on Software Engineering, 18(11), November, 988-997(1992).

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).

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), June, 50-57 (1997).

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

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).

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

Carbonell, J., Derivational analogy; A Theory of Reconstructive Problem Solving and Expertise Acquisition. In Michalski, R., Carbonell, J. and Mitchell, T. (eds.): Machine Learning – An Artificial Intelligence Approach, Vol. II, Morgan Kaufmann, 371-392 ( 1986).

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).

Fenton, N., Software Metrics: A Rigorous Approach, Chapman and Hall, NY, (1991).

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

Fichman, R., Kemerer, C., Object-Oriented and Conventional Analysis and Design Methodologies, comparison and Critique, IEEE Computer, October, 22-39(1992).

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 (1994c).

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.

Lenz, M., Schmid, H., and Wolf, P., Software Reuse Through Building Blocks, IEEE Software, April, 34-42(1987).

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

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 Clifs, NJ. Prentice-Hall, (1992).

Nada, N., Software Reuse for Earth Observing System Data Information system and Change Data Information System (EOSDIS/GCDIS) and Beyond, Progress Report for the Earth Science System Fellowship Program, NASA, (1995).

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, Septmber (1994).

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

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

Rine, D., 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).

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W., Object-Oriented Modeling and Design, Prentice-Hall, (1991).

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, IEEE Software, 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.