'Investments in Reusable Software:
A Study of Software Reuse
Investment Success Factors'
(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. Robert M. Sonnemann, The US Air Force, Omaha, Nebraska.
(Short running title: 'Software Reuse Investment Success Factors')
'Investments in Reusable Software: A Study of Software Reuse Investment Success Factors'
(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@cne .gmu.edu. (2) Dr. Robert M. Sonnemann, The US Air Force.
Abstract: This research supports the thesis that there is a set of success factors which are common across organizations and have some predictability relationships to software reuse. For completeness, this research also investigated to see if software reuse had a predictive relationship to productivity and quality. The individual success factors were grouped into the following categories: management commitment, investment strategy, business strategy, technology transfer, organizational structure, process maturity, product-line approach, software architecture, availability of components, and quality of components. A questionnaire was developed to measure software reuse capability, productivity, quality, and the set of software reuse succ ess factors. A survey was conducted to determine the state-of-the-practice. The data from the survey was statistically analyzed to evaluate the relationships among reuse capability, productivity, quality, and the individual software reuse success factors. The results of the analysis showed some of the success factors to have a predictive relationship to software reuse capability. Software reuse capability also had a predictive relationship to productivity and quality. Based on the research results, the le ading 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 requirement s to the components which support them.
1. INVESTMENTS IN REUSABLE SOFTWARE
1.1. Introduction
In this paper we examine a part of the problem of building an information technology (IT) infrastructure. We examine the IT infrastructure of businesses involved in the development of software products. The software products of these b usinesses are those built by a software engineering process. Hence, these products are generally 'large scale', and these businesses are generally devoted to building product lines and families of software products within given application domains. Theref ore, it is reasonable to consider the possibility of leveraging software reuse in attempting to increase reliability and decrease costs and effort of producing software products. Hence, the part of the IT we wish to examine is that part of software develo pment businesses dealing with reusable software components and architectures as part of the infrastructure of product development. In this paper we therefore examine software reuse investment successs factors, and it is our premise that software businesse s applying software engineering will find these software reuse investment success factors useful within their software business management.
Many organizations in both the private and public sectors are proposing to invest, and have already invested, large sums of money, time and resources into software reuse with the hope of improving their competitive edge through greater productivity in the software development process and higher quality in the software products developed. Various technology organizations such as The Virginia-based Software Productivity Consortium (SPC), The U. S. Government-based Software Technology for Adaptable, Reliable Systems (STARS) program and U. S. Department of Defense-funded Software Engineering Institute (SEI) have proposed certain conceptual frameworks for reuse. While some organizations naively equate software reuse with a particular tech nology, such as object-oriented technology, in fact it is becoming quite clear that successful software reuse practice has much more to do with organizational management, infrastructure, and technical factors un-related to object-oriented technology. In t his paper we will report on our Study of Software Reuse Investment Success Factors, and, from this study, proposed an effective 'model' for investment in software reuse. (Sonnemann, 1995)
1.2. The Problem
Many software development organizations believe that investing in software reuse will improve their product and process productivity and quality, and are in the process of planning for or developing a software reuse capability. Unfortu nately, there is still little data available on the state-of-the-art-practice of investing in software reuse. A 1991 study of Japanese Software Factories stated that in 1991 the Japanese software factories were the only organizations successfully applying software reuse McCain, 1991). This 1991 study and a second 1992 study of U.S. software developers covering 29 organizations (Frakes and Fox, 1995) are, until now, the only major studies involving a large number of organizations. The majority of current i nformation available on software reuse investment comes from the literature, which contains unproved theories or theory applied in a limited way to a few pilot projects or case studies.
Our research (to be reported in this paper) investigated the relationships between software reuse investment, productivity, and quality, as well as many of the theories proposed by the literature to provide greater software reuse capabi lity (i.e., what are the success factors for software reuse).
1.3. Conclusions
Investment in software reuse is predictive of productivity and quality. However, a product-line management approach and a software architecture technology approach are higher predictors of productivity and quality than software reuse al one.
This study, like the previous 1992 study(Frakes and Fox, 1995), found no relationship between software reuse capability and the library approach (i.e., the strategy of collecting a large set of components from previous projects and maki ng them available to other projects; a.k.a., an ad hoc library approach).
The organizations sampled in this study with the highest software reuse capability (and investment) have the following features:
product-line approach,
architecture which standarizes interfaces and data formats,
common software architecture across the product-line,
design for manufacturing approach,
domain engineering,
software reuse process,
management which understands reuse issues,
software reuse advocate(s) in senior management,
state-of-the-art reuse 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 (systems, subsystems,
and/or software modules) which support them. (Sonnemann, 1995)
1.4. Rationale
Organizations are looking for ways to develop a program of software reuse. If organization is to make a major investment in software reuse it needs to know what factors to consider. The statistical analysis in this paper can be interpr eted to show relationships that exist between the independent variables and software reuse capability. These independent variables can, therefore, be used as predictors of software reuse capability.
2. RESEARCH METHOD
2.1. Background
Software reuse is widely believed to be the most promising technology for significantly improving software quality and productivity. (Frakes, 1992) It is believed that constructing systems from existing software components should sh orten development time, lessen duplication across projects, and lower development costs. One can easily see the productivity gains from not writing code.(Tirso and Gregorious, 1993) In plain language, reuse is based on the principle of not reinventing the wheel. (Troy, 1994) Constructing systems from existing operationally proven software components can lead to increases in quality. (Sonnemann, 1995; Tirso and Gregorious, 1993)
Unfortunately, software reuse has proven difficult to achieve. Organizations attempting to implement a software reuse program face both technical and non-technical problems. Technical problems include interchangeability and classificati on. Non-technical problems include changing the organizational structure, processes, and culture, as well as the up-front investment to build a software reuse infrastructure.
The manufacturing and construction worlds have successfully implemented a product-line approach to reuse for many years. It is commonplace for these industries to assemble parts into products and use the same part in more than one produ ct within a product-line family. So, what is the problem with doing this in software? The problem, for example, is that what are routine procedures in other engineering disciplines are research areas in software engineering, e.g. domain analysis, intercha ngeability of parts, and common architecture across product-lines.
2.1.1. Domain Analysis
Domain analysis and domain modeling is one kind of technology proposed to support software reuse. Looking for commonality and variability across products, i.e. domain analysis, is standard operating procedure in manufacturing. Howev er, domain analysis is a research area in software engineering. The United States (US) Advanced Research Projects Agency (ARPA) Domain Specific System Architecture (DSSA) project is working with universities, government laboratories, and industry to perfe ct this technology. (Tracz, 1994; Armitag, 1993) Other than a few on-going pilot projects, it will be a while before this technology becomes commonplace in software engineering.
2.1.2. Interchangeable Parts
A second kind of technology proposed to support software reuse is based on a manufacturing paradigm that uses interchangable parts. Presently, however, the majority of computer code is still hand-crafted from raw programming langua ges by artisans using techniques they neither measure nor are able to repeat consistently. Before the industrial revolution, there was a nonspecialized approach to manufacturing goods that involved very little interchangeability and a maximum of craftsman ship.
In April 1994, the National Institute of Standards and Technology (NIST) announced that it was creating an Advanced Technology Program to help engender a market for component-based software. Financial incentives and marketing pressures will force companies to find cheaper ways to produce software. Even when the technology is ready, components will find few takers unless they can be made cost-effective. And the cost of software parts will depend less on the technology involved than on th e kind of market that arises to produce and consume them. (Gibbs, 1994)
2.1.3. Common Architecture Across Product-Lines
A third kind of technology proposed to support software reuse is based on defining a common architecture across a product-line. Defining a common architecture across product-lines is a fundamental problem that is complementary to de veloping interchangeable parts. Structured modeling focuses on defining an interchangeable architecture with predictability. This interchangeable architecture defines the ground rules, i.e. interface requirements, which all the programmers must follow. Th is method forces the software to behave like hardware components and provides an engineering framework for system integration.
Domain modeling looks at the commonality and variability across systems. Knowing the amount of variability of the systems in the problem domain would help define the extent of the problem of their interoperability. Determining commonali ty, i.e. duplication, among systems is the first step towards identifying potential reuse components and architectures.
2.1.4. Reuse Failure Modes Model
Technical problems associated with reuse include, but are not limited to, finding, understanding, testing and integrating components and sub-architectures (Sommerville, 1996) Insight into the software reuse implementation problem ca n be had by considering the probabilistic aspects of the reuse failure modes model. The seven software reuse failure modes are: (1) No attempt to reuse; (2) Part not integratable; (3) Part not understood; (4) Part not valid; (5) Part does not exist; (6) P art not found; (7) Part not available. Each failure mode in the model can be assigned a probability. When this is done, an overall probability of reuse failure, or success, can be calculated. Although this is a simplifying assumption, the easiest way of c alculating an overall probability is by assuming independence of the failure modes. The overall probability of reuse success then is given by: Prob(reuse success) = Sum of (1 - f
i), where f i is the probability of failure mode i. The probability of reuse failure is: Prob(reuse failure) = 1 - Prob(reuse success). This model emphasizes that even if a reuse program is quite good, and the proba bility of reuse failure at any step is low, the overall probability of successful reuse can still be relatively low. Assume, e.g., that each failure mode has a 0.10 probability and there are seven failure modes. The probability of successful reuse will th en be only 0.48. (Frakes and Fox, 1994c)
These same failure modes could apply to doing a literature search in the library. For example: part not found could be the article is available in the library, but the title does not match the keywords used by the library user. The foll owing section will expand on the library metaphor.
2.1.5. Library Metaphor
Another kind of technology proposed to support support reuse is based on a metaphor of a library of software documents, with authors, publications, and librarians. The library metaphor focuses on the management of these documents. T his introduces librarians, catalogs, classification schemes, and browsing to the reuse field and has inspired several researchers to investigate various retrieval schemes based on faceted classification, keywords, or free-text document retrieval. Other re searchers are investigating the interoperability and interconnection of local and branch libraries, and the problems of interlibrary loan, copyright, etc. (Griss, 1993)
The library metaphor can be broadened into a trading infrastructure concept. The elements of a marketplace are derived from suppliers offering parts and customers requiring parts. Therefore, information about offerings and requirements is necessary. As in any trading environment, some kind of accounting is required in order to record exchanges and associated costs and savings, and to measure the effectiveness of the trading infrastructure. (Wasmund, 1993)
A library must be focused on the needs of the consumers or users. The library approach to reuse comes from a traditional way of thinking about the reuse problem. It reflects an ad hoc approach that might be used by an individual program mer. The whole point is to develop a repository of components that are actually usable. This is where many companies fail; they put parts in the initial library that are not relevant to the population of people using them. Organizations acquire components and make them available before they understand their domain and the needs of their software engineers. Or the organization incorrectly thinks that by simply getting a library they have a program. Fonash (Fonash, 1993) presents a concise description of wh y the Department of Defense (DoD) Reuse Initiative failed using the "library" approach, i.e. lack of a consumer focus.
Our discussion of the library and manufacturing metaphors is a relevant background for the next topic, how to evaluate the reuse capabilities of an organization using the Reuse Capability Model (RCM). Having a library will get an organi zation a "level 2" in the RCM rating, which is just above having an ad hoc approach to software reuse, a "level 1" in the RCM rating. An organization moves up the RCM rating scale through incorporating reuse into their software development processes, incl uding maintenance, and continual process and product improvement to ensure that reusable software components meet user needs, i.e. strong customer focus. (SPC, 1993)
2.1.6. Reuse Capability Model
Advanced Research Projects Agency (ARPA) has funded a number of software reuse projects to further the practice, such as the Reuse Adoption Guidebook. (Davis, 1994; SPC, 1993) This guide was developed by the SPC under contract to th e Virginia Center of Excellence for Software Reuse and Technology Transfer. This document also contains a Domain Assessment Model and a Reuse Capability Model (RCM), as well as questionnaires to support each. The RCM is most important to our research beca use it provides a method for determining the software reuse capability of an organization .(SPC, 1993)
The RCM has five levels each building upon the previous level. This hierarchical structures is very similar to the SEI Capability Maturity Model (CMM). The RCM levels are from lowest (level 1) to highest (level 5):
Level 1 Ad hoc - no reuse process.
Level 2 Opportunistic - libraries supporting projects.
Level 3 Integrated - reuse and development process integrated.
Level 4 - Leveraged - distinct product-line life cycle with specialized
processes
Level 5 - Anticipating - applications optimize reuse.
Hence, the RCM provides a way of categorizing and determining an organization's software reuse level. Given this knowledge, one has a "yardstick" with which to evaluate other relationships, such as the following twelve questions in the next section.
2.1.7. Research Questions - A Proposed Model of Software
Reuse Success Factors
Our literature search uncovered a number of possible software reuse success factors, as well as a reuse relationship with productivity and quality. This section addresses productivity and quality together, and each of the possible softw are reuse success factors individually. The twelve questions derived from our literature search and related theoretical work presents us with a model comprising a theory of software reuse success factors.
Productivity and Quality
After reviewing literature including (Bell Canada, 1993; Boehm and Papaccio, 1987; Boehm and Scherlis, 1992; Frakes, 1992; Frakes and Riddle, 1993; Frakes and Isoda, 1994a; Frakes and Fox, 1994b; Frakes and Fox, 1995; Griss, 1993; J oos, 1994; Lim, 1994; O'Connor et. al., 1994; Parnas, 1976; Tirso and Gregorious, 1993; Troy, 1994) the following question(s) were introduced:
Question 1. Is software reuse level predictive of productivity?
Question 2. Is software reuse level predictive of quality?
Management Commitment
After reviewing literature including (Fafchmaps, 1994; Frakes and Riddle, 1993; Frakes and Isoda, 1994a; Frakes and Fox, 1994c; Frakes and Fox, 1995; Griss, 1993; Joos, 1994; McCain, 1991; O'Connor et. al., 1994; Tirso and Gregoriou s, 1993; Tracz, 1986; Tracz, 1989) the following question(s) were introduced:
Question 3. Is management commitment predictive of software reuse level?
Investment Strategy
After reviewing literature including (Card and Comer, 1994; Frakes and Riddle, 1993; Frakes and Isoda, 1994a; Griss, 1993; Joos, 1994; McCain, 1991; O'Connor et. al., 1994; Staringer, 1994; Tirso and Gregorious, 1993; Tracz, 1986; T racz, 1989; Troy, 1994) the following question(s) were introduced:
Question 4. Is investment strategy predictive of software reuse level?
Business Strategy
After reviewing literature including (Card and Comer, 1994; Fafchamps, 1994; Frakes and Riddle, 1993; Frakes and Fox, 1994b; Frakes and Fox, 1995; Griss, 1993; Joos, 1994; O'Connor et. al., 1994; Tirso and Gregorious, 93; Troy, 1994 ) the following question(s) were introduced:
Question 5. Is business strategy predictive of software reuse level?
Technology Transfer
After reviewing literature including (Card and Comer, 1994; Fafchamps, 1994; Frakes and Riddle, 1993; Frakes and Fox, 1994c; Frakes and Fox, 1995; Gross, 1993; Joos, 1994; McCain, 1991; O'Connor et. al., 1994; Tracz, 1986; Tracz, 19 89; Tirso and Gregorious, 1993; troy, 1994; Wasmund, 1993) the following question(s) were introduced:
Question 6. Is technology transfer predictive of software reuse level?
Organizational Structure
After reviewing literature including (Boeing, 1994; Fafchamps, 1994; Frakes and Riddle, 1993; Griss, 1993; Loral, 1994; O'Connor et. al., 1994; SPC, 1993; Troy, 1994; Unisys, 1994; Wasmund, 1993; Withey, 1993) the following questi on(s) were introduced:
Question 7. Is organizational structure predictive of software reuse level?
Process Maturity
After reviewing literature including (Bell, 1993; Card and Comer, 1994; Frakes and Fox, 1994b; Armitage, 1993; Griss, 1993; Tirso and Gregorious, 1993; Troy, 1994; Wasmund, 1993) the following question(s) were introduced:
Question 8. Is process maturity predictive of software reuse level?
Product-Line Approach
After reviewing literature including (Fafchamps, 1994; Frakes and Riddle, 1993; Frakes and Isoda, 1994a; Griss, 1993; Joos, 1994; McCain, 1991; O'Connor et. al., 1994; Parnas, 1976; Staringer, 1994; Tracz, 1986; Tracz, 1989; Wasmund , 1993) the following question(s) were introduced:
Question 9. Is product-line approach predictive of software reuse level?
System Architecture
After reviewing literature including (Abowd, 1993; Armitage, 1993; Boettcher et. al., 1994; Cohen, 1994; Frakes and Isoda, 1994a; Ferrentino, 1994; Gacek et. al., 1994; Griss, 1993; Kogut and Wallnau, 1994; Leary, 1994a; Leary, 1994 b; O'Connor et. al., 1994; Staringer, 1994; Troy, 1994) the following question(s) were introduced:
Question 10. Is system architecture predictive of software reuse level?
Availability of Components
After reviewing literature including (Bell, 1993; Frakes, 1992; Frakes and Fox, 1994b; Griss, 1993; O'Connor et. al., 1994; Staringer, 1994; Tirso and Gregorious, 1993; Troy, 1994; Wasmund, 1993) the following question(s) were intr oduced:
Question 11. Is availability of components predictive of software reuse level?
Quality of Components
After reviewing literature including (Basili and Musa, 1991; Bell, 1993; Bollinger and Pfleeger, 1991; Card and Comer, 1994; Frakes, 1992; Frakes and Fox, 1994b; Griss, 1993; McCain, 1991; O'Connor et. al., 1994; Sommerville, 1996; Tirso and Gregorious, 1993; Tracz, 1986; Tracz, 1989; Troy, 1994; Wasmund, 1993) the following question(s) were introduced:
Question 12. Is quality of components predictive of software reuse level?
2.2. Problem and Research Hypothesis
This research hypothesizes (Sonnemann, 1995) that there is a set of success factors which are common across organizations and have some predictability relationships to software reuse. Hence, our research hypotheses are that (1) soft ware reuse level is predictive of productivity and quality; and (2) management commitment, investment strategy, business strategy, technology transfer, organizational structure, process maturity, product-line approach, system architecture, availability of components, and quality of components are predictive of software reuse level. The twelve questions associated with each of the hypotheses were previously presented in section 2.1.7.
2.3. Research Approach
In this section we summarize the research approach taken by means of six steps.
Step 1. Define a set of software reuse success factors. This was done by conducting a literature search to utilize the best theory recorded in the literature. This step includes our first version of a model comprising success fac tors for software reuse. This is derived from section 2.1.7.
Step 2. Down-size the number of success factors to those with the highest probability of impacting software reuse. This was done by comparing and contrasting software reuse lessons learned from the literature search, as well as u tilizing the results of the previous software reuse empirical studies (Frakes and Fox, 1994c; Griss, 1993). The down-sizing was required to limit the number of questions in the questionnaire (questionnaire-survey instrument), which in turn increases the chances that someone will fill out the questionnaire. This step includes the refining of the model comprising success factors for software reuse.
Step 3. Develop a questionnaire to survey industry and government and to gather empirical data to answer the twelve research questions and to validate our hypotheses. The questionnaire evaluated each of the organization's environ ment (stratification of the population), qualifications to answer a given question (reliability of the data - is the data based on a domain analysis or best guess?), reuse capability (level on the SPC's Reuse Capability Model), and the presence or absence of success factors. The questionnaire-survey instrument was further improved by means of a pre-survey validation procedure.
Step 4. Print and distribute the questionnaire. Because of the immaturity of the practice of software reuse and lack of a completely defined statistical population to sample, highly randomized sampling was determined not to be fe asible. Hence, 3750 surveys were distributed. Selection of groups to which surveys were distributed was based upon a groups general interest in the topic of software reuse. Surveys were not distributed to groups that were not interested in software reuse. Of those responding to survey question Q10, 54 percent of the projects believed their organizations had effective to extremely effective software reuse programs, while 46 percent either had no formal software reuse program or had one that was only minima lly effective. The cost of preparing, printing and distributing the instrument was supported by U.S. Department of Defense government funding.
Step 5. Collect and analyze the data. The statistical tool JMP from SAS (SAS Institute, Inc.) was used to analyze the data. After determining the normality of the data, the correct method for determining if a given independent va riable is predictive of the dependent variable was used. The dependent variables were software reuse level, productivity, and quality. The ten independent variables were management commitment, investment strategy, business strategy, technology transfer, o rganizational structure, process maturity, product-line approach, system architecture, availability of components, and quality of components, based on section 2.1.7.
Step 6. Report the results. A summary of results relevant to the paper is presented in the next section. This step includes the empirical validation of the model (section 2.1.7) comprising success factors for software reuse.
3. RESULTS
This section describes the results of the 1995 software reuse survey and answers the twelve research questions listed in the previous section 2.1.7. Of the 3750 questionnaires sent out results from 109 responses are presented. Selec tion of groups to which surveys were distributed was based upon a groups general interest in the topic of software reuse. Surveys were not distributed to groups that were not interested in software reuse. Of those responding to survey question Q10, 54 per cent of the projects believed their organizations had effective to extremely effective software reuse programs, while 46 percent either had no formal software reuse program or had one that was only minimally effective. All projects reporting said that the y had some kind of formal or informal software reuse initiative related to their project. No group was included in the survey or in the responses which had no interest or knowledge in software reuse within their project.
3.1. Results by Question
This section summarizes the results of the percentage (frequency) analysis for each of the questions from the software resue survey instrument.
3.1.2 Demographics
Refer to Table 1 for Demographic Results.
Table 1. Demographics
_____________________________________________________________
Survey Question Category Frequency Result
_____________________________________________________________
Q1. AE 41 (Application Engineer)
C 11 (Consultant)
DE 13 (Domain Engineer)
O 13 (Other)
SM 21 (Senior Management)
Q2. *
Q3. N 43 (No)
Y 56 (Yes)
Q4. N 25 (Strongly Disagree (SD) to Mildly
Agree (MA))
Y 30 (Agree (A) to Strongly Agree (SA))
Q5. N 31 (SD-MA)
Y 67 (A-SA)
Q6. N 33 (SD-MA)
Y 34 (A-SA)
Q7. AE 20
DE 20
Q8. N 48 (SD-MA)
Y 50 (A-SA)
Q9. N 59 (SD-MA)
Y 40 (A-SA)
_____________________________________________________________
* Q2. There was no positive or negative conclusion regarding he number of people assigned to the application engineering section (project team) supporting the identified project during peak activity.
99 projects were reported, covering 83 different organizations from five different countries. The projects covered different domains from embedded to management information systems. The primary end users of the products developed by the projects were well distributed among government, commercial, internal, research and development, and other, with government being slightly larger. Respondents' roles in their organization (Q1) (senior management, application engineering, domain engineeri ng or reuse repository, consultant to include academia and other) varied greatly, with consultants being the smallest group with 11 percent and application engineering being the largest with 41 percent. 56 percent of the projects were supported by domain engineering (Q3), and of these 54 percent believed the domain engineering support was effective and efficient (Q4). 68 percent of the projects were supported by a software reuse repository, and of these projects 52 percent believed the repository support was effective and efficient (Q6), i.e., Reuse Capability Model (RCM) level 2. 20 percent of the projects used application engineering (Q7) to develop 100 percent of their reusable software components. Another 20 percent of the projects used domain engine ering (Q7) to develop greater then 70 percent of their reusable components. 50 percent of the organizations had a precedence of developing similar products in the past (Q8). 40 percent of the projects had a stable environment (Q9).
When asked to identify the percentages of primary end users of the projects developed by the identified project (Q73), 46/96 reported at least 80 percent of their primary end users was government while 37/96 reported that 100 percent of their primary end users was non-government. 16/96 reported that at least 80 percent of their primary end users was commercial while 71/96 reported that 100 percent of their primary end users was non-commercial. 16/96 reported at least 90 percent was inte rnal while 60/96 reported 100 percent non-internal. 2/96 reported at least 80 percent was R&D while 79/96 reported 100 non-R&D. 4/96 reported at least 90 percent other while 87/96 reported 100 percent non-other.
When asked to identify the domain that the products developed by the indentified project compete (Q74) 14/90 identified aerospace, while the rest of the frequencies were generally a count of 1 or 2 over 63 other domains.
When asked to identify the primary business of the organization (standard industrial classificaion code) (Q75) 26/93 identified other, 10/93 identified engineering & management services, 8/93 identified computer integrated systems d esign, 7/93 identified computer programming services, and the others identified smaller frequencies of the additional 18 SIC codes. 8 of the SIC codes were not identified.
When asked to identify the country in which the project developed 91/97 identied the US.
3.1.3. Technology Transfer
Refer to Table 2 for Technology Transfer Results.
Table 2. Technology Transfer
_____________________________________________________________
Survey Question Category Frequency Result
_____________________________________________________________
Q10. N 45 (Not Apply (NA) - Minimally Effective(ME))
Y 53 (Effective(E( - Extremely Effective(EE))
Q11. T 37 mean (Technical(T))
NT 63 mean (Non-Technical(NT))
Q12. N 28 SD-MA
Y 70 A-SA
Q13. N 78 SD-MA
Y 20 A-SA
Q14. N 56 SD-MA
Y 42 A-SA
Q15. N 32 SD-MA
Y 66 A-SA
Q16. N 74 SD-MA
Y 23 A-SA
Q17. N 84 SD-MA
Y 14 A-SA
Q18. N 81 SD-MA
Y 17 A-SA
Q19. N 72 SD-MA
Y 26 A-SA
Q20. N 77 SD-MA
Y 21 A-SA
Q21. N 89 SD-MA
Y 9 A-SA
_____________________________________________________________
54 percent of the projects believed their organizations had effective to extremely effective software reuse programs (Q10). The responses to the barriers to software reuse (Q11) averaged out to be: 63 percent non-technical and 37 pe rcent technical. 71 percent of the respondents believe developing an effective and efficient software reuse infrastructure requires significant investment and substantial time to mature(Q12). 20 percent of the projects have seen senior management demonstr ate their support for software reuse by allocating funds and manpower over a number of years(Q13). 42 percent of the respondents reported that there is a corporate sponsor(s) in senior management who advocates and supports developing a software reuse capa bility(Q14). 67 percent of the respondents reported that there are respected technical leaders in the organization advocating software reuse(Q15). 23 percent of the respondents reported that pilot projects were used effectively to refine software reuse "b est practices" prior to adopting them for routine use(Q16). 15 percent of the respondents reported that the organization has an effective software reuse working group to advocate software reuse, as well as provide guidance and assistance throughout the or ganization(Q17). 17 percent of the respondents reported that the organization has an effective software reuse education and training program(Q18). 26 percent of the respondents reported that education for senior management is the most important aspect of their software reuse education and training program(Q19). 21 percent of the respondents reported that manager(s) understand software reuse issues(Q20). 9 percent of the respondents reported that projects document their software reuse lessons learned, whic h in turn are used to improve the organization's software reuse process(Q21).
3.1.4. Software Reuse Strategy
Refer to Table 3 for Software Reuse Strategy Results..
Table 3. Software Reuse Strategy
_____________________________________________________________
Survey Question Category Frequency Result
_____________________________________________________________
Q22. N 54 SD-MA
Y 44 A-SA
Q23. N 62 SD-MA
Y 36 A-SA
Q24. N 78 SD-MA
Y 20 A-SA
Q25. N 61 SD-MA
Y 37 A-SA
Q26. N 77 SD-MA
Y 21 A-SA
Q27. N 57 SD-MA
Y 18 A-SA
Q28. N 59 SD-MA
Y 14 A-SA
Q30. N 88 SD-MA
Y 9 A-SA
Q31. N 57 SD-MA
Y 41 A-SA
Q32. R 61/98 (98 for those that follow)
S 60
D 77
C 90
DOC 68
T 68
DAT 57
Q33. N 80 SD-MA
Y 18 A-SA
Q34. OUT 30 percent
IN 70 percent
Q35. N 69 SD-MA
Y 29 A-SA
Q36. REV 49 percent
FOR 51 percent
Q37. N 69 SD-MA
Y 30 A-SA
Q38. N 64 SD-MA
Y 35 A-SA
Q39. N 78 SD-MA
Y 21 A-SA
Q40. N 58 SD-MA
Y 41 A-SA
Q41. COM 50 percent
VAR 50 percent
Q42. N 39 NO
Y 60 YES
Q43. N 56 SD-MA
Y 41 A-SA
Q44. N 66 SD-MA
Y 31 A-SA
Q45. N 79 SD-MA
Y 18 A-SA
_____________________________________________________________
45 percent of the respondents reported that their organization tends to specialize, building variations of products for different customers(Q22). 37 percent of the respondents reported that applications the organization develops are wel l understood by project team members(Q23). 20 percent of the respondents reported that their organization is taking a library approach to software reuse(Q24). 37 percent of the respondents reported that their organization is taking a preferred parts appro ach to software reuse(Q25). 21 percent of the respondents reported that their organization is taking a design for manufacturability approach to software reuse(Q26). Of those with a software reuse repository, 24 percent do customer surveys to determine wha t reusable components should be placed in the repository(Q27). Of those with a software reuse repository, 18 percent do market analysis of their products and their competitor's products to determine what reusable software components should be placed in th eir repository(Q28). Of those with a software reuse repository, 20 percent have established a candidates library to eliminate duplication among their projects(Q29). 9 percent of the respondents reported that they have an effective requirements analysis to ol which links their most common end-user requirements with the reusable software component(s) which satisfy them(Q30). 42 percent of the respondents reported that their software development process supports a product line(Q31). The respondents reported t hat their organization's software reuse strategy plans to reuse the following artifacts(Q32): 62 percent requirements, 61 percent specifications, 78 percent design, 90 percent code, 69 percent documentation, 69 percent test cases, 58 percent data. 18 perc ent of the respondents reported that the software reuse technology used by the organization is leading edge(Q33). 70 percent of the respondents reported that the majority of their software reuse technology (techniques, practices, methods, tools, etc.) is being (was) developed internal to the organization(Q34). 29 percent of the respondents reported that their organization assigns its best software engineers to producing reusable software components(Q35). The responses to the organization's strategy for de veloping reusable software components(Q36) averaged out to be: 49 percent reverse engineering and 51 percent forward engineering. 30 percent of the respondents reported that they have a good set of highly effective and available horizontal (across domains ) reuse components(Q37). 35 percent of the respondents reported that they have a good set of highly effective and available vertical (domain specific) reuse components(Q38). 21 percent of the respondents reported that they have done a thorough domain anal ysis of their products(Q39). 41 percent of the respondents reported that they have a good understanding of the commonality and variablity of their products(Q40). The responses to the commonality and variability across the organization's products (software reuse potential)(Q41) averaged out to be: 50 percent commonality and 50 percent variability. 60 percent of the respondents reported that they have a common architecture across their product line(Q42). 42 percent of the respondents reported that their arc hitecture has proved useful in standardizing interfaces and data formats(Q43). 32 percent of the respondents reported that their architecture has greatly simplified re-hosting their applications to different platforms(Q44). 18 percent of the respondents r eported that their architecture has lessened 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(Q45).
3.1.5. Software Reuse Process
Refer to Table 4 for Software Reuse Process Results.
Table 4. Software Reuse Process
_____________________________________________________________
Survey Question Category Frequency Result
_____________________________________________________________
Q46. N 69 SD-MA: same for the rest below
Y 30 A-SA: same for the rest below
Q47. N 63
Y 36
Q48. N 74
Y 25
Q49. N 89
Y 10
Q50. N 53
Y 46
Q51. N 86
Y 13
Q52. N 91
Y 7
Q53. N 81
Y 18
Q54. N 84
Y 15
Q55. N 70
Y 28
Q56. N 51
Y 17
_____________________________________________________________
30 percent of the respondents reported that their projects are under the control of a stable and effective project management system for planning and tracking (software cost, schedules, and functionality),i.e. Capability Maturity Model (CMM) level 2 (Q46). 36 percent of the respondents reported that their organization's software development process includes both software engineering and management process: it is practiced, documented, enforced, and trained across the organization, i.e. CMM level 3 (Q47). 15 percent of the respondents reported that productivity and quality are measured for important software process activities across all projects as part of an organizational measurement program, i.e., CMM levevl 4 (Q48). 10 percent of th e respondents reported that their software processes are improved by using statistical process controls to identify problems, i.e. CMM level 5 (Q49). 46 percent of the respondents reported that project team members are assigned to similar projects and tak e the initiative to reuse software components from other projects (Q50). 13 percent of the respondents reported that software developers and maintainers follow a software reuse process which is defined and integrated with the organization's software devel opment process, i.e., RCM level 3 (Q51). 7 percent of the respondents reported that performance of the software reuse process is measured and analyzed to identify weaknesses, and plans are established to address the weaknesses, i.e., RCM level 4 (Q52). 18 percent of the respondents reported that their configuration management system keeps track of the projects which use each reusable software component (Q53). 15 percent of the respondents reported that their configuration management system notifies projec ts when a problem is discoverd with a given reusable software component or when an updated version is available (Q54). 28 percent of the respondents reported that their organization has effective procedures to prevent uncontrolled cloning (Q55). Of those with a software reuse repository, 27 percent of the respondents reported that their repository has few components having the same or slightly different names - closing (Q56).
3.1.6. Software Reuse Capability
Refer to Table 5 for Software Reuse Capability Results.
Table 5. Software Reuse Capability
_____________________________________________________________
Survey Question Category Frequency Result
_____________________________________________________________
Q57. O 23 percent
COTS 13 percent
OP 20 percent
UN 44 percent
Q58. R 41/98 (98 for the rest below)
S 42
D 55
C 81
DOC 51
T 37
D 30
Q59. DM 45/98 (98 for the rest below)
FM 23
WLC 12
IR 6
RR 5
Q59-61. DM (45 + 21 + 13)/(98 + 98 + 97) same for rest
FM (23 + 15 + 13)
IR (6 + 21 + 14)
WLC (12 + 12 + 12)
RR (5 + 13 + 12)
LM (1 + 2 + 17)
Q62. N 71
Y 26
Q63. N 79
Y 19
Q64. N 84
Y 14
Q65. N 57
Y 40
Q66. N 56
Y 42
Q67. N 78
Y 20
Q68. N 77
Y 20
Q69. N 73
Y 25
Q70. N 73
Y 25
Q71. N 80
Y 17
_____________________________________________________________
The percentage of reusable software components used in the identified project (Q57)averaged out to be: 23 percent reused developed components from other projects, 13 percent reused commercial off-the-shelf components, 20 percent develop ed components for reuse by other projects, 44 percent developed components unique to the identified projects. The software artifacts reused from other projects by the identified project were(Q58): 41 percent requirements, 42 percent specifications, 55 per cent design, 81 percent code, 51 percent documents, 37 percent test cases, 30 percent data. The respondents reported their highest priority motives for implementing software reuse were:(Q59-Q61) 46 percent reduce development and maintenance costs, 23 perc ent faster time to market, 12 percent write less new code, 6 percent improved reliability, 5 percent reduce redundancy across projects. The respondents reported that their top three motives for implementing software reuse were(Q59-Q61): 27 percent reduce development and maintenance costs, 17 percent faster time to market, 14 percent improved reliability, 12 percent write less new code, 10 percent reduce redundancy across projects, 7 percent do less maintenance, 4 percent better understanding of customer r equirements, 3 percent better bid estimates, 2 percent successfully enter new markets, 2 percent increase market share, 2 percent better workload estimates. 27 percent of the respondents reported that they observed significant improvement in the previousl y mentioned areas(Q62). 19 percent of the respondents reported that they have a critical mass of reusable software components which enables them to develop effective prototypes with real functionality in a relatively short time(Q63). 14 percent of the res pondents reported that they have a critical mass of reusable components to draw upon which gives them leverage in negotiations with customers (driving them to more generic requirements in trade for shorter development time)(Q64). 41 percent of the respond ents reported that they are able to assemble new products much faster than they could two years ago(Q65). 43 percent of the respondents reported that their reusable software components are considered highly valuable by project team members(Q66). 20 percen t of the respondents reported that management has created new business opportunities that take advantage of the organization's software reuse capability and reusable assets, i.e. RCM level 5(Q67). 21 percent of the respondents reported that their decision s to bid on new projects or enter new markets are based heavily on their software reuse capabilities(Q68). 26 percent of the respondents reported that they have fewer software components to maintain due to the effectiveness of their software reuse program (Q69). 25 percent of the respondents reported that their reusable software components have proven through operational use to be highly reliable(Q70). 17 percent of the respondents reported that time spent on maintenance (correcting defects) has decreased( Q71).
3.2. Software Reuse Capability
Given the importance of measuring software reuse capability for this research, it was measured six different ways in the questionnaire using:
measurement 1. The Reuse Capability Model (RCM)
Level 1, Ad Hoc - no process (default level),
Level 2, Opportunistic - libraries supporting projects,
Level 3, Integrated - reuse and development integrated,
Level 4, Leveraged - reuse process measured,
Level 5, Anticipating - creates new business.
measurement 2. The respondents rated their organization's software reuse
program
Level 1, N/A, we do not have a formal software reuse program,
Level 2, Minimally effective - benefits are not clear,
Level 3, Effective - has observable benefits,
Level 4, Highly effective - benefits are predictable,
Level 5, Extremely effective - provides a competitive edge to gain
market share.
measurement 3. The software artifacts reused from other projects by the
identified project
Level 1, Reuses code only or no code reuse,
Level 2, Reuses code and something else,
Level 3, Reuses design, code, and something else,
Level 4, Reuses requirements, design, and code,
Level 5, Reuses all seven artifact types.
measurement 4. Their horizontal and vertical reuse capability
Level 1, Default level,
Level 2, Mildly Agree on both questions or a single Strongly Agree or
a single Agree,
Level 3, Mildly Agree on one question and a Strongly Agree or Agree
on the other question,
Level 4, Agree on both questions or one Agree and one Strongly
Agree,
Level 5, Strongly Agree on both questions.
measurement 5. The percentage of reusable software components (reused
developed components from other projects and reused
commercial off-the-shelf components) used in the
identified project
Level 1, 0-20,
Level 2, 21-40,
Level 3, 41-60,
Level 4, 61-80,
Level 5, Greater Than 80.
measurement 6. Measurement 5 plus developed components for reuse by
other projects
Level 1, 0-40,
Level 2, 11-69,
Level 3, 70-84,
Level 4, 85-94,
Level 5, Greater Than 95.
The RCM, measurement 1, proved to be unstable and continually scored the lowest correlations with the other measurements. The RCM is a hirarchical model with each level building on the previous level. The RCM produced substantially diff erent results depending on whether or not the level questions were answered bottom up or top down. The six measurements for software reuse capability did not correlate very well. Measurements 5 and 6 were the exception. They correlated well with each othe r because measurement 5 is a subset of measurement 6.
A hybrid measurement was developed from measurement 5 (which favored reverse engineering) and measurement 6 (which favored forward engineering) to solve the poor correlation problem. Given the small sample size, the new reuse capability measurement used three levels (high(H), medium(M), and low(L)). A second hybrid measurement was also developed which further identified the extremes (very high(VH), high(H), medium(M), low(L), and very low(VL)). Very low was assigned to projects scoring level 1 on both the percentage measurements 5 and 6 and is a subset of the low in the H-M-L measurement. Very high was assigned to projects scoring level 5 on both percentage measurements 5 and 6 and is a subset of high in the H-M-L measurement. Both the H-M-L and the VH-H-M-L-VL measurements correlations with the other reuse capability measurements were significant.
The VH-H-M-L-VL and the H-M-L measurements (software reuse capability or level) were used to evaluate the predictability of the various independent variables. The strength of the relationships between software reuse capability and the i ndependent variables were assigned based on the highest F Ratio resulting from the H-M-L and the VH-H-M-L-VL analysis using the following scale:
Verbal Relation Highest F Value at 95 Percent Confidence
No Relationship - less than 5 or the Prob > F is high,
Weak Relationship - 5 to less than 7.5,
Relationship - 7.5 to less than 10.0,
Strong Relationship - 10.0 or greater.
In the reports on the research questions reported below in section 3.3, with each verbal relation there is also reported the numerical valued relation in the triple form (Questions, Highest F Value, Prob > F Value). We use the verbal relation reporting because it is easier to understand in that form. The Questions are those on the survey questionnaire experimental instrument. For the most part we have only reported data in those cases where there is a relationship. The key things we looked for in our Oneway Anova are the means for each group, a strong F ratio (strength of the relationship) and low Std Error for each of the means with no Std Error twice the size as another. For example, under Productivity below we have
Research Question 1. Is software reuse level predictive of productivity?
Based on the reuse capability data there is
' a strong relationship between reuse capability and having the ability to create new business opportunities. (67, 13.3066, 0.0000)' because in the Analysis of Variance of RCM Level 5 Q67 By RC H-M-L F Ratio is 13.3066 (Analysis of Variance of RCM Level 5 Q67 By RC VH-H-M-L-VL F Ratio is 7.5371), Prob > F is 0.0000; and in the Means for Oneway Anova, Means for Levels (1, 2, 3) are (2.97222, 4.19231, 4.87500), and Std Errors are (0.25708, 0.30250, 0.27267).
3.3. Research Questions
In this section research questions stated in section 2.1.7 will be answered.
The results report both relationships (positive answers) and no relationships (negative answers).
Productivity
Research Question 1. Is software reuse level predictive of productivity?
Based on the reuse capability data there is
* a relationship between reuse capability and the organization achieving its productivity goals. (62, 9.0941, 0.0000)
* a relationship between reuse capability and having the ability to assemble new products much faster than they could two years ago.
(65, 9.7023, 0.0000)
* a strong relationship between reuse capability and having the ability to create new business opportunities. (67, 13.3066, 0.0000)
* a weak relationship between reuse capability and an organization's decision to bid on new projects or enter new markets.
(68, 6.5313, 0.0022)
* a relationship between reuse capability and having fewer software components to maintain due to the effectiveness of their software reuse program. (69, 7.8528, 0.0000)
Quality
Research Question 2. Is software reuse level predictive or quality?
Based on the reuse capability data there is
* a relationship between reuse capability and reusable software components have proven through operational use to be highly reliable.
(70, 7.76179, 0.0000)
* no relationship between reuse capability and time spent on maintenance (correcting defects) has decreased. (71, 3.9801, 0.0051)
Management Commitment
Research Question 3. Is management commitment predictive of software reuse level?
Based on the reuse capability data there is
* a relationship between reuse capability and senior management has demonstrated their support for software reuse by allocating funds and manpower over a number of years. (13, 9.3650, 0.0002)
Investment Strategy
Research Question 4. Is investment strategy predictive of software reuse level?
Based on the reuse capability data there is
* no relationship between reuse capability and developing an effective and efficient software reuse infrastructure requires significant investment and substantial time to mature. (12, 0.7398, 0.5673)
Business Strategy
Research Question 5. Is business strategy predictive of software reuse level?
Based on the reuse capability data there is
* no relationship between reuse capability and an organization taking a library approach to software reuse. (24, 2.7021, 0.0355)
* a weak relationship between reuse capability and an organization taking a preferred parts approach to software reuse. (25, 5.5387, 0.0054)
* a strong relationship between reuse capability and an organization taking a design for manufacturability approach to software reuse.
(26, 11.1518, 0.0000)
* a relationship between reuse capability and doing customer surveys to determine what reusable software components should be placed in the software reuse repository. (27, 8.3863, 0.0005)
* no relationship between reuse capability and doing market analysis to determine what reusable software components should be placed in the software reuse repository.
* no relationship between reuse capability and establishing a candidates library to eliminate duplication among projects.
* no relationship between reuse capability and an organizational strategy to develop reusable software components using reverse engineering (or forward engineering).
* no relationship between reuase capability and who in the organization develops the reusable software components (application engineering or domain engineering).
* a weak relationship between reuse capability and an organization assigning its best software engineers to develop reusable software components. (35, 6.0105, 0.0035)
Technology Transfer
Research Question 6. Is technology transfer predictive of software reuse level?
Based on the reuse capability data there is
* a strong relationship between reuse capability and having a corporate sponsor(s) in senior management who advocates and supports developing a software reuse capability. (14, 15.7704, 0.0000)
* a weak relationship between reuse capability and having respected champions in the organization advocating software reuse.
(15, 7.0549, 0.0014)
* a weak relationship between reuse capability and using pilot projects to refine software reuse "best practices" prior to adopting them for routine use. (16, 5.7776, 0.0044)
* a relationship between reuse capability and having an effective software reuse working group to advocate software reuse. (9.4718, 0.0002)
* no relationship between reuse capability and having an effective software reuse education and training program.
* no relationship between reuse capability and education for senior
management being the most important aspect of our software reuse education and training program.
* a strong relationship between reuse capability and having managers who understand software reuse issues. (20, 10.2890, 0.0001)
* a weak relationship between reuse capability and projects documenting their software reuse lessons learned.
Organizational Structure
Research Question 7. Is organizational structure predictive of software reuse level?
Based on the reuse capability data there is
* a strong relationship between reuse capability and having a domain engineering section. (3, Crosstabs analysis since answers were boolean)
* no relationship between reuse capability and the effectiveness of the domain engineering section.
Product-Line Approach
Research Question 9. Is product-line approach predictive of software reuse level?
Based on the reuse capability data there is
*a strong relationship between reuse capability and having a software development process built around a core set of reusable software components as the foundation for their products. (31, 15.5181, 0.0000)
System Architecture
Research Question 10. Is system architecture predictive of software reuse level?
Based on the reuse capability data there is
* a strong relationship between reuse capability and having a common software architecture across the product-line. (42, Crosstabs analysis since answers were boolean)
* a strong relationship between reuse capability and having a software architecture which has proved useful in standardizing interfaces and data formats. (43, 12.2459, 0.0000)
* a relationship between reuse capability and having a software architecture which has greatly simplified re-hosting applications to different platforms.
(44,8.6967, 0.0003)
* no relationship between reuse capability and having a software architecture which has lessened the need to make reusable software components highly generic.
Availability of Components
Research Question 11. Is availability of components predictive of software reuse level?
Based on the reuse capability data there is
* a relationship between reuse capability and having a critical mass of reusable software components which enables an organization to develop effective prototypes with real functionality in a relatively short time.
(63, 8.3804, 0.0005)
* a strong relationship between reuse capability and having a critical mass of reusable components to draws upon which gives an organization leverage in negotiations with customers (driving them to more generic requirements in tr ade for shorter development time).
(64, 13.7882, 0.0000)
* a strong relationship between reuse capability and having a horizontal reuse capability. (37, 10.0625, 0.0001)
* a strong relationship between reuse capability and having a vertical reuse capability. (38, 12.3504, 0.0000)
Quality of Components
Research Question 12. Is quality of components predictive of software reuse level?
Based on the reuse capability data there is
* a relationship between reuse capability and reusable software components being considered highly valuable by project team members.
(66, 9.5374, 0.0000)
* no relationship between reuse capability and reusable software components being certified to some quality levels.
Results of our research also included relationships between reuse capability and the software engineering process and the maturity of the software engineering process. However, we have chosen to report on this work separately. Intereste d readers may refer to (Sonnemann, 1995).
3.4. Further Multivariate Statistical Analysis
Because of the low response rate in our sampling, it was decided to use statistical techniques (methods) that do not require the assumption of large samples. Hence, we used F test values to justify the assumption of the equality of variances, which is needed in the t test where the t test is applied to test the differences between the means (Hoel, 1954) of the variables in our study.
Our analysis demonstrated that many success factors behave significantly differently. In some cases software reuse capability steadily increases with increased levels of a success factor. While other success factors only make a differen ce going from the low to medium to high software reuse capability groups. This is why the statistical analysis of Questions versus Reuse Capability were run. Many of the relationships are dynamic and will change as an organization's software reuse capabil ities increase.
If someone were to develop a software reuse model and migration guidebook as follow-on to this study, they would have to have a good understanding of the relationships among the independent variables. Using the data from this study one could do multivariate analysis to better understand the interactions (multiplier effects, reverse correlations, etc.). For a proof of concept, using an analysis from our study, let us consider the following independent variables:
1. Product-line approach,
2. Architecture standardizes interfaces and data formats,
3. Design for manufacturability approach,
4. Preferred parts approach,
5. The organization assigns its best software engineers to developing
reusable components,
6. The organization has a precedence of developing similar products in the
past,
7. There are respected technical leaders in the organization advocating
software reuse,
8. The organization has an effective requirements analysis tool which links
their most common end-user requirements with the software
components which satisfy them.
The statistical analysis of Questions versus Reuse Capability were was used to select variables including both strong predictors and on-predictors of software reuse capabilty.
The following Table 6 summarizes the results of the multivariate analysis of the variables selected. F Ratios have been rounded up to the next whole number. In all cases Prob > F is not significant and equal to or close 10 0.0000.
Table 6. Summarizing the Results of the Multivariate Analysis F Ratios
________________________________________________
| PL | A | M | PP | BD | P | T | R | |
| Product-Line (PL) | 16 | 21 | 22 | 18 | 13 | 10 | 16 | 14 |
| Architecture (A) | 21 | 13 | 18 | 13 | 13 | 8 | 15 | 12 |
| Manufacturing (M) | 22 | 18 | 12 | 13 | 14 | 7 | 17 | 13 |
| Preferred Parts (PP) | 18 | 13 | 13 | 6 | 10 | 5 | 9 | 8 |
| Best Develop (BD) | 13 | 13 | 14 | 10 | 7 | 6 | 9 | 8 |
| Precedence (P) | 10 | 8 | 7 | 5 | 6 | 1 | 6 | 5 |
| Technologist (T) | 16 | 15 | 17 | 9 | 9 | 6 | 8 | 11 |
| Requirements (R) | 14 | 12 | 13 | 8 | 8 | 5 | 11 | 6 |
________________________________________________
The F Ratio for PL versus software reuse capability is 16. The F Ratio for A versus software reuse capability is 13. The F Ratio of PL and A combined versus software reuse capability is 21. And so forth.
4. MANAGEMENT STRATEGIES FOR INFORMATION
TECHNOLOGY INVESTMENT - CONCLUSION AND
CONTRIBUTIONS
This section contains our interpretations of the research results presented in the previous section (Section 3).
State-of-the-Practice
The low response rate to the survey and the answers to the questionnaire indicate that software reuse practices are not institutionalized in our software development and maintenance organizations. However, some campanies within narr ow well defined domains have had great success (increased market share) due to their software reuse capabilities.
It was surprising that the literature search authors provided almost no responses. The authors were contacted to find out why. In general they said that they did not respond because the questionnaire was to measure software reuse in pra ctice (requiring knowledge of an individual software development or maintenance project). They pointed out that they were theorists and not practitioners. We were surprised to learn that the majority of the articles referenced in the study were based on t heory without any practical application.
Top Predictors of Software Reuse Capability
Based on the results of this research, the top individual predictors of software reuse capability are:
1. commonality across products (Q41),
2. software reuse process (Q51),
3. domain engineering (Q3),
4. design for manufacturability approach (Q26),
5. product-line approach (Q31),
6. software architecture - standardizes interfaces and data formats (Q42),
7. common software architecture across the product-line (Q42),
8. leading edge reuse technology (Q33),
9. management understands software reuse issues (Q20),
10. strong influential individual(s) in senior management who advocate(s)
and support(s) developing a software reuse capability (Q14),
11. kind of software artifacts (requirements, design, code, documentation,
test cases, data) reused (Q58).
Research Results Matched Predicted Results
The listed software reuse predictors are believed because they are consistent with predicted results in other areas. Prior to beginning the experiment (questionnaire and survey), relationships were identified that could be expected to be true based on the literature theory and on common sense. From this a model based on a set of possible reuse successfactors was proposed. These relationships occurred as predicted and so the model was validated. The following examples show some of th e strong relationships to software rese capability that were expected, and show that the research results were validated to be true.
As expected, a strong relationship was found between software reuse capability and:
1. percentage of reused components in their project,
2. respondent's intuition about their software reuse capability,
3. availability of reusable components to build or assemble systems,
4. reuse potential (amount of commonality across their products),
5. simplest way to achieve reuse (assign project team members to similar
projects, so they reuse their own code).
Because of the low response rate in our sampling, it was decided to use statistical techniques (methods) that do not require the assumption of large samples. Hence, we used F test values to justify the assumption of the equality of vari ances, which is needed in the t test where the t test is applied to test the differences between the means(Hoel, 1954) of the variables in our study.
Measurement of software reuse capability produced strong F Ratios (> 10) when compared to:
1. percent of components reused from previous projects and percent of
commercial off-the-shelf components reused in the project,
2. percent of components reused from previous projects, percent of
commercial off-the-shelf components reused in the project, plus percent
of developed components for reuse by other projects,
3. respondents self assessment of their reuse program,
4. respondents self assessment of the amount of reusable components they
have,
5. respondents self assessment of their horizontal reuse capability,
6. respondents self assessment of their vertical reuse capability,
7. respondents self assessment of their understanding of the amount of
commonality and variability across their products,
8. respondents self assessment of the amount of commonality across their
products,
9. respondents self assessment of whether project team members are
assigned to similar projects.
Observations of real-world practices, personal experience, interviews with industry experts, and textbook concepts on operations research, systems engineering, and manufacturing, all indicate that the practices associated with top predi ctors of software reuse capability match the successful practices used in hardware manufacturing. It is a well substantiated belief, based upon years of data, in this industry, that product-lines, architecture, design for manufacturability, and domain eng ineering increase productivity and quality. Moreover, similar observations indicate that the practices associated with top predictors of software reuse capability match sound business practices. Most organizations do studies and analyses to determine if a given practice is cost effective to implement. The greater the potential to reuse components (the greater the savings or profits), the more likely an organization will implement and invest in reuse practices.
In this paper we have reported on our comprehensive Study of Software Reuse Investment Success Factors (Sonnemann, 1995), and, from this study, proposed an effective 'model' for investment in software reuse.This research established met rics for measuring software reuse capability, and in doing so developed a model which normalized the inluence of an organization's reuse strategy (reverse or forward engineering), validating this model using real world data. Hence, the research has given managers of software engineering projects a strategy for investing in reusable software.
A major goal of software engineering product development is to increase productivity and quality. Our research has shown that there is a strong relationship between software reuse success and productivity. So how does one achieve softwa re reuse success? Our research has shown that there is a strong relationship between the independent variables business strategy (e.g. design for manufacturability approach), technology transfer (e.g. corporate sonsorship advocating and supporting develop ment of a software reuse capability), organization structure (e.g. having a domain engineering section), product-line approach (e.g. a software development process built around a core set of reusable software components as the foundation for product devel opment), system architecture (e.g. a common software architecture across the product-line, to standardize interfaces and data formats) and availability of components (e.g. reusable components to leverage with customers, driving them to more generic requir ements in trade for shorter development time), and the dependent variable software reuse success. Therefore, large scale software business investment in these six or more factors, which we have measured, will payoff in improved productivity.
REFERENCES
Abowd, C., et. al., Structured Modeling: an Application Framework and
Development Process for Flight Simulators, CMU/SEI-93-TR-14,
Software Engineering Institute, Pittsburgh, Pennsylvania, 1993.
Armitag, J. , Process Guide for the Domain-specific Software
Architectures Process Life Cycle, CMU/SEI-93-SR-21,Software
Engineering Institute, Pittsburgh, Pennsylvania, 1993.
Bassett, P., Framing Software Reuse: Lessons from the Real World, Prentice Hall, 1997
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 and P. Papaccio, 'Understanding and controlling software costs',
IEEE Transactions on Software Engineering, 14(10) October (1987).
Boehm, B., and W. Scherlis, Megaprogramming (preliminary version),
ARPA Paper, 1992.
Boeing Defense and Space Group, Experience reports - The Navy/STARS
Demonstration Project, ARPA Report, 13 July 1994.
Boettcher, K., et al., A Case History: Development and Use of an
Information Architecture for Ballistic Missile Defense Battle
Management, Command, Control, and communications (BMC3), ARPA
Report, 1994.
Bollinger, T., and S. Pfleeger, Economics of Reuse: Issues and
Alternatives, INFO SOFT, December 643-653 (1991).
Card, D., and E. Comer, Why do so Many Reuse Programs Fail?', IEEE
Software, September, 114-115 (1994).
Cohen, S., A Model Base for Software Engineering, SEI Briefing Charts,
June 1994.
Davis, T., The Reuse Capability Model, CrossTalk, The Defence Software
Engineering Report, 5-9, March 1994.
Fafchamps, D., Organizational Factors and Reuse, IEEE Software,
September, 31-41 (1994).
Ferrentino, A., SNAP: The Use of Reusable Templates to Improve
Software Productivity and Quality, Template Software, Inc., Herndon,
Virginia, 1994.
Fonash, P., Metrics for Reusable Software Code Components, PhD
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 S. Isoda, 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 C. Fox, Quality Improvement Using a Software Reuse
Failure Modes Model, Software Engineering Guild Draft Paper,
November, 1-13 1(994c).
Frakes, W., and C. Fox, Sixyeen Questions about Software Reuse,
Communications of the ACM, 38(6), 75-87 and 112, June (1995).
Gacek, C., et al., Focus Workshop on Software Architectures: Issue Paper,
USC Center for Software Engineering Paper, 1 April 1994.
Gibbs, W., Software's Chronic Crisis, Scientific American, September, 86-
95 (1994).
Griss, M., Software Reuse: from Library to Factory, IBM Systems Journal,
32(4), 548-566 (1993).
Hoel, P., Introduction to Mathematical Statistics, John Wiley and Sons,
New York, 1954.
Joos, R., Software Reuse at Motorla, IEEE Software, September, 42-47
(1994).
Kogut,P., and K. Wallnau, Software Architecture and Reuse: Senses and
Trends, Tutorial for Tri-Ada Conference, 7 November (1994).
Leary, J., Information Architecture - an Architectural Basis for Evolution
of Large Scale Software Systems, Software Engineering Institute (SEI)
Paper for NPGS Workshop, 2 February, 1994a.
Leary, J., Information Architecture Notions, briefing slides presented to
Defense Simulation and Modeling Office meeting, 19 October 1994.
Lim, W., Effects of Reuse on Quality, Productivity, and Economics, IEEE
Software, 11(5), 23-30, September (1994).
Loral Federal Systems, Air Force/STARS demonstration project
experience report, ARPA Report, 25 July 1994.
McCain, R., Introduction to Reuse Technology and Application, slides -
Defense Systems Management College, 24 September 1991.
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).
Sommerville, I., Software Engineering, 5th Edition, Addison-Wesley, New
York, 1996.
Sonnemann, R., Exploratory sSudy of Software Reuse Success Factors,
PhD Dissertation, George Mason University, Fairfax, Virginia, Spring
1995.
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, Pittsburg, 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, pp. 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, Pittsburg,
Pennsylvania, November 1993.