A Comparison of Software Reuse in Software Development ...

Download PDF
2 downloads 1412 Views 112KB Size Report
Comment
for improving software development productivity and the quality of software. Research and practice has shown that software reuse can be used for developing ...
2011 5th Malaysian Conference in Software Engineering (MySEC)

A Comparison of Software Reuse in Software Development Communities Meena Jha CQUniversity & The University of New South Wales, Sydney NSW 2052, Australia [email protected]

ABSTRACT Software reuse has been regarded as one of the most important areas for improving software development productivity and the quality of software. Research and practice has shown that software reuse can be used for developing products from reusable assets in a routine manner, on an industrial scale. However successful application of software reuse is limited to certain domains and not widespread across the software industry. There is no clear consensus between input and, output artifacts and the requirements that an effective reuse process must have. To examine the issues and concerns in more detail we have completed surveys on software reuse in the conventional software engineering (CSE) community and in the software product line (SPL) community to compare and contrast the results for similarities and differences in software reuse philosophy. This paper outlines some of the identified differences and similarities of issues and concerns in software reuse in both communities and what one community can gain from the other to overcome the identified software reuse problems. The comparison highlights areas where the existing SPL and CSE communities provide extensive support in software reuse and those in which the SPL and CSE communities are deficient, suggesting an understanding of the factors resisting software reuse in both communities.

Keywords Software Reuse, Software Product Line Community, Conventional Software Engineering Community.

1. INTRODUCTION Systematic reuse is generally recognized as a key technology for improving software productivity and quality [1]. It is widely accepted that software reuse is a major component of many software productivity improvement efforts, because it can result in higher quality software at a lower cost and delivered within a shorter time period [2]. The concept of reusing software components is not new [25, 26]. However, Lim [27], Isoda [28], and Griss et al. [29] suggests a carefully implemented, systematic reuse strategy driven by a strong commitment from management is the key to maximizing the benefits of software reuse. Software development communities should focus on developing software assets for reuse and with reuse [5]. For reuse refers to systematic generalization of software components for later reuse, while with reuse deals with how existing components can be reused in existing and new applications and systems. Software reuse can have varying degrees of application, ranging from a case-by-case basis (ad-hoc) to

Liam O’Brien CSIRO IM&T & Australian National University, Canberra, ACT 2600, Australia [email protected]

fully systematic approaches [7]. Studies [1, 3] have shown that software reuse is a critical concern for organizations interested in the improvement of software development quality and productivity. Quality could be improved by reusing all forms of proven experience, including products and processes, as well as quality and productivity models. Productivity could be increased by reusing existing experience, rather than creating everything from scratch. The software reuse community initially concentrated its research on technical issues, such as repositories, tools for the search and retrieval of reusable artifacts, and programming language support [18]. Although software reuse has been studied in great depth in the SPL and CSE communities, there has not been much significant research that assesses and compares the impact of reuse in both communities, where failures and successes can have a much greater physical, social and economic impact. The benefits of software reuse from one community (SPL or CSE) can be transported to the other only if the issues and concerns from both communities are identified and compared. In this paper the factual evidence available from experiences of software engineers and others working in CSE and SPL communities have been analyzed to understand advantages and disadvantages of software reuse in both communities. We examine the role of domain knowledge and understanding in both SPL and CSE, reuse processes and planning, the key distinguishers between both communities, and we outline some of the lessons learned from one community that could fit to the other. We believe that CSE community can learn from the systematic reuse practices in the SPL community. The remainder of the paper is organized as follows. Section 2 outlines related work on surveying and classifying software reuse. It identifies and discusses some of the shortcomings of the work to date and discusses the contribution of this work. Section 3 describes the issues and lessons learned from the CSE community. Section 4 presents issues and lessons learned from the SPL community. Section 5 compares and contrasts the issues and concerns in both communities and outlines some of the lessons that can be learned between the communities. Section 6 summarizes and discusses our work. Section 7 concludes the paper and outlines some possible future work.

2. Related Approaches Morisio, Ezran and Tully [7] performed a survey and analyzed 24 projects in both large and small companies in Europe between 19941997 involving software reuse. Their results revealed that successful software reuse is based on an organization’s potential for reuse

978-1-4577-1531-0/11/$26.00 ©2011 IEEE

313

because of commonality among applications, management commitment to introducing a reuse process, modifying non-reuse processes, and addressing human factors. The main causes identified for reuse failures are: not introducing reuse-specific processes, not modifying non-reuse processes, and not considering human factors. Orrego and Mundy [20] conducted a study of software reuse in NASA legacy systems and suggested that software reuse saves time and money. They also identified that there is little emphasis placed on improving quality or assessing the risks of software reuse. Ad-hoc reuse is 90% higher than systematic reuse which identifies the lack of a software reuse process. Morad and Kuflik [8] explored the possibilities of software reuse in a three-year project and found that software reuse implementation is not a straight forward task. It requires management support and resistance of developers to use something they did not develop on their own. Slyngstad, et al. [9] conducted a survey in the IT-department of a large Oil and Gas company in Norway (Statoil ASA), in order to characterize developers’ views on software reuse. They found no relation between reuse and increased rework. They found that benefits of reuse can be seen in terms of lower costs, shorter development time, higher quality of the Java Enterprise Framework Client and Java Enterprise Framework Integration components and a standardized architecture. However, they could not correlate reuse education to the practice of reuse done in the organizations. Joos [30] described reuse introduction efforts at Motorola. Their paper highlights the highly challenging task of introducing reuse in a multinational corporation, already involved in other cultural changes, from hardware-centric to software-centric, and towards process maturity. The key issues recognized are acquiring commitment from top-level management, and providing reuse training and incentives. A large reuse project was the REBOOT (Reuse Based on ObjectOriented Techniques) project [17], where the focus was on the importance of the organizational aspects of reuse. The issues identified were human factors, organizational factors, reuse processes, and business drivers. There are many more unidentified non-technical factors which are equally important or at least as important as the technological aspects. Frakes and Fox [10] conducted a survey in 1991-1992, where they answered 16 commonly asked questions about reuse. A total of 113 people from 28 organizations participated in the survey. They revealed that education influences reuse, developers actually prefer to reuse instead of building components from scratch. But they did not refer to software reuse education. They also found that a common reuse software process may be advantageous as identified by “STARS” program report, for example [19]. Software reuse is no longer solely restricted to the research community. Organizations that have adopted software reuse to enhance their development processes have reported useful improvements in development productivity and quality [4]. In our work we wished to look at why these improvements are not being exploited more widely within industry as a whole. We identified issues and concerns for software reuse within the SPL community and we also examined if reliability of software assets/components is an issue for reuse in the SPL community. This survey was built upon our previous survey on software reuse in the CSE community [11]. This latter survey was email based and carried out in mid 2008. A total of 51 questions were put together and organized into five subsections to suit the survey done in both communities. Our surveys were qualitative surveys rather than quantitative ones. As far as we know, this is the only work on the

314

comparison of issues and concerns in both the SPL and CSE communities to uncover or discover the similarities and differences of software reuse in both communities.

3. ISSUES AND LESSONS LEARNED FROM THE CSE COMMUNITY 3.1 Survey Participants and Responses In the CSE community, 75% of the survey participants had an educational level of postgraduate in IT. Only 25% had other professional qualification in IT. Our respondents’ experience ranges from 10 to 20 years. The total number of developers and software engineers that responded to the survey in mid 2007 was 79. Of these 79, 27% were from the open source software development community and the rest 73% were from 7 different companies.

3.2 Issues and Concerns Identified in the CSE Community Software engineers have many reusable assets available to them, but do they actually use them and find them valuable. 100% of the respondents (including those from the open source community) say that it is beneficial to reuse software for higher productivity, quicker time to market, better use of resources, and increased quality. From the survey results we concluded from the responses that 88% of the software engineers do not feel comfortable in reusing code. Some of the major concerns shown are lack of tool support, increased maintenance cost, and the Not-Invented-Here (NIH) syndrome. Only 45% of the respondents actively search for code to be reused. The low number is not strange when one considers that people creating components almost never certify the components in any way (either in-house or commercial). Only 8% use some sort of certification of components on a regular basis. Unfortunately 88% respondents found that components performing complex tasks were hard to find. M ov i ng D e a dl i ne s

Never , 25%

Of ten , 45%

Of ten Rar el y Never

Rar el y , 30%

Figure 1: Moving Deadlines of Projects Meeting deadlines for projects is still an important issue in today’s software projects. Figure 1 show our survey result that 45% of the time the deadline of the respondent’s project is moved and 30% of the time it is rarely moved. The survey by The Standish Group [12] "CHAOS Summary 2009," shows only 32% of all projects succeeding which are delivered on time, on budget, and with required features and functions. This is very much inline with our survey findings. Over 57% of the respondents claimed that the majority of the projects they took part in encompassed more than 100,000 bytes. 65% of the respondents do not agree even somewhat that CASE

tools have promoted reuse. We conclude that CASE tools are not currently very effective in promoting reuse. Respondents also talked about the reuse philosophy and the need for it to be taught to software engineers and developers. 38% of the respondents feel that a company’s divisions or projects size is predictive of organizational software reuse. However they feel that the educational/professional background of the key people involved in the technical decision making is predictive. 78% of the respondents believe that if one is reusing code/components developed by others then there may be concerns about reliability, security, performance, etc. However, 82% also believe that if knowing that a component (maybe a service) has been used in the development of multiple systems this can help to build confidence in that component. Reusing software components may also alter time allocated in software development phases. The result we have collected say 50% of the time is used in analysis and design phase. However, if there are more reusable component more time can be saved out of this 50%. On average participants have said that they use 30% of their time in the analysis phase, 20% in the design phase, 30% in the implementation phase and 20% in the verification and testing phase. If the components are reused then probably the amount of time in analysis, design and testing can be brought down. Our survey has revealed that if the software architecture documentation is provided to software engineers, the respondents feel that they can make software reuse common in practice. Quality attributes such as reliability could be measured using architecture based software reliability. Our survey has shown a strong correlation between reuse and reliability, suggesting that quality concerns are very much related to the amount of external reuse. Almost 63% of our respondents stated that they had some element of reuse in their code but only 40% of these claimed that they tested the reused code in any way. The reason for this was primarily that they found writing test cases afterwards too tedious and the original test cases were not documented properly to be reused..

4. ISSUES AND LESSONS LEARNED FROM THE SPL COMMUNITY 4.1 Survey Participants and Responses The survey to the SPL community adapted the questions from the CSE survey to be more SPL specific. We selected the people from the SPL community whom we would like to contribute to our survey. Of the 29 survey respondents 17% had less than 5 years experience in SPL, 37% had experience of 5-10 years, 37% had experience of 10-20 years and only 9% had more than 20 years experience. 65% of the respondents were researchers and managers in SPL, 20% were product line architects, 6% were core asset architects, and 9% were R&D project leaders.

4.2 Issues and Concerns Identified in the SPL Community 100% of the respondents believed that reuse in SPL will achieve increased quality, planned productivity, capture of domain knowledge, and cost reduction. Our respondents believe that SPL necessitates effective strategic planning and product line road mapping; market analysis; change from bespoke customer relationships and projects toward market, product and service

orientation; effective requirements, scope, and release management of products and services. Respondents believed that software reuse “is not sufficiently domain based”. 87% of the respondents felt reuse education will definitely help them learn more about recent reuse technology in making reuse possible in their organization. Also companies need to have development policies that mandate reuse. The companies that are serious about SPL must educate all levels (technical management, higher level management, and developers) about what SPL is, how the company plans to achieve it and what their role will be in making the transition successful. 85% of the respondents felt that software engineering practice influences reuse. 100% of the respondents felt that SPL reuse has to be planned in advance. The responses to the use of a reuse repository improving code reuse were mixed. A clear idea behind the reuse repository in SPL could not be gathered. Several of the respondents commented that a reuse repository would improve code reuse as long as there are proper methods and practices around its use. The majority (97%) of the respondents believe that a company’s divisions or project’s size is not predictive of organizational reuse. People are of the opinion that the size has nothing to do with reuse. This is very contradictory with the theory already established where the complexity of the reuse increases with the size of the project [13]. The majority of the respondents (93%) felt that software quality does not inhibit reuse. Most code in each product is already of high quality as it is reused across multiple products. Quality concerns should actually support SPLs. But several of the respondents felt that conflicts on core assets (usually arising because of different stakeholders’ quality concerns) can limit the modification and/or use of core assets within products. It has been shown that domain knowledge is still the key to reuse of software [13]. All of our respondents also agreed on this question. Without domain knowledge common and variable artifacts cannot be anticipated. When asked if given an opportunity to build from scratch or reuse respondents believe that in a product line organization reuse is built in and is clearly not an option. Arbitrarily reusing assets that have not been prepared and proactively planned to be reused for a given task is of course problematic as we know from ad hoc reuse experiences. Respondents are of the opinion that if they find reusable software that fits to the architecture they would prefer to reuse rather than build from the scratch. So, the architecture is the main key issue that facilitates reuse. However one very interesting response was received: “Reuse can be done effectively if we know (1) which domain artifacts are available and (2) we can trust the domain artifacts to do the things we want them to do, why not reuse them? The issue then is do we know and how can we know these issues.” This is a very challenging question posed to the SPL community. Our survey has shown a strong correlation between reliability and testing, suggesting that quality concerns are very much related to amount of external reuse. 100% of the respondents stated that if a component is reliable they would like to reuse the component and would not bother to test it for reliability. Almost 63% of our respondents stated that they had some element of reuse in their code but only 40% of these claimed that they tested the reused code in any way. The other 60% would not test the code for reliability. When the participants were asked if they “test a single component, class or core component in any way?” the respondents said that single classes are typically not tested. 80% of the respondents said they do not test single components by themselves. Sometimes single components are tested, but most of the time some integration with other components

315

is already done and the integrated components are tested. Sometimes unit testing is performed on an assembly of components, as the simplest “unit” of test. Unit testing is not widespread. Our survey result shows that between 5%-20% of the time is spent in the analysis phase, 5%-60% of the time is spent in the design phase, 0%-50% in the implementation phase and 10%-30% for the testing phase. Some of the respondents said they spend 0% of time in implementation and 50% in testing meaning thereby that products are derived automatically from a configuration. Developing the configuration is considered design rather than implementation. When asked if in their opinion, the choice of framework (e.g., .NET, EJB, CORBA, etc.) affects the possibility for the software to be easily upgradeable in the long term, the responses we received were mixed. One of our respondents (3%) was not familiar with these frameworks, 34% of the respondents did not agree and the rest 63% of the respondents believed that the mainstream frameworks would probably be more upgradeable than others.

5. COMPARISONS OF SOFTWARE REUSE IN BOTH COMMUNITIES Based on a survey of the literature, it is evident that there are no standard definitions for software reuse. In our study we adopt the scope of software reuse to encompass concepts, tools, people, analysis, design, specifications, documentation, and domain knowledge in addition to component reuse [6, 22, 23, 24]. The goal of comparison is to find important commonality and differences between the issues and concerns of software reuse in both the SPL and CSE communities. The collected data set has been analyzed on different important issues which are described in the following sections.

5.1 Software Reuse Management and Measurement The SPL respondents believe that SPL necessitates effective strategic planning and product line road mapping; market analysis; change from bespoke customer relationships and projects toward market, product and service orientation; effective requirements, scope, and release management of products and services. On the other hand in the CSE community software engineers do not feel comfortable in reusing code. Even today, the CSE community is working on traditional phases of the software development life cycle (SDLC) described in waterfall, evolutionary or prototype approach. There is no planned phase of software reuse in the software development life cycle traditional process. Learning from one to another community: The CSE community could learn from SPL by integrating a software reuse process into the matured SDLCs used in their community. However, the SPL community does not have a matured process like SDLC and hence can learn from the CSE community in how to make SPL development processes more mature.

5.2 Disadvantages of Software Reuse in the SPL and CSE Communities The disadvantages associated with the software reuse in the SPL community were start up and maintenance cost. The major disadvantages respondents have highlighted are complexity – the “gravity” of software engineering: reuse can add complexity by creating dependencies between previously autonomous organizational units. Some of the problems with the dependencies identified by one of the respondents are a web of dependencies, coordination cost, cost of offering integration, process and tool divergence. However, the disadvantages associated with software

316

reuse in CSE community are the lack of tool support, increased maintenance cost, Not-Invented-Here (NIH) syndrome (unwillingness to reuse code built by another), maintaining a component library and finding reusable components. Our findings are also supported by the study done in NASA where ad-hoc reuse is 90% higher than systematic reuse [20]. Learning from one to another community: The NIH syndrome of the CSE community can be overcome by adopting the capture of domain knowledge as is done in the SPL community. And both the SPL and CSE communities need to avoid ad-hoc software reuse or reusing a component without a strategy.

5.3 Is Software Reuse Domain Based? In the SPL community the respondents believe that software reuse “is not sufficiently domain based”. On the other hand in the CSE community respondents have concerns of Not-Invented-Here (NIH) syndrome. The NIH syndrome can be taken care of by certifying reusable components in the CSE community. However, the SPL community suggests that the software reuse can be done even in the presence of NIH syndrome. Learning from one to another community: Certification of components is required in the CSE community. Certification is not normally done in the SPL community but in some cases it is. However because software components are used across multiple products the NIH syndrome is not an issue in the SPL community. The SPL community can adopt from CSE community that domain knowledge is desirable but not essential to have software reuse.

5.4 Reuse Planning The SPL community respondents believe that software reuse has to be planned in advance. The CSE community also requires planning for software reuse, because software reuse is done on an ad-hoc basis and should be more systematic. In addition the CSE community also requires the understanding of development with software reuse and for software reuse. According to respondents from the SPL community, software reuse is a part of SPL, meaning that it is already concerned with software development for and with reuse. Learning from one to another community: Software reuse has to be planned in advance in both communities. The CSE community needs to adopt the idea from the SPL community that reuse should be an integral part of conventional software engineering. If software engineers think in this way then reuse will potentially become a lot more widespread and will become a standard part of engineering of software systems.

5.5 Reuse and Software Quality Our respondents from the SPL community feel that the quality of software components to be reused in an SPL is already considered to be very high as components are normally reused across multiple products. The majority felt that no testing is required for the components getting reused. However, all the domain artifacts that are explicitly designed to be reused must be tested extensively to uncover both functional and non-functional flaws. In the CSE community software reuse is not a core concept. The respondents also felt that the software architecture could be used to measure quality attributes, such as reliability, of the component to be reused. Learning from one to another community: Within the CSE community if software reuse is adopted to a sufficient level and the quality of reusable components can be guaranteed to a certain level, then there will be less of a need to test components which are reused. If the hurdle of having to test components can be reused it would make it easier for software reuse to become a core part of software development.

5.6 Software Reuse: Language or Domain Specific The SPL community enjoys the Domain-Oriented reusability concept where domain analyses and modeling deals with identifying reusable abstractions and architectures for the development of a family of software systems as opposed to the CSE community which believes more in language specific reuse. However, the identified concerns in the SPL community are “how to identify frequently reusable components”, “how assets should be managed systematically,” “what are the domain roles,” and how “to know which domain artifacts are available for reuse”. The respondents from the CSE community believe that language is of most importance for reuse, and advocates that features of languages such as Ada, C++, Smalltalk, and Java provide better reuse support. Most existing programming languages including object-oriented languages provide features that support reuse. However, simply writing code in those languages does not confirm the software reuse philosophy. Components must be designed for reusability using those features. Learning from one to another community: Software reuse in the SPL community is domain specific and hence components in one domain may not be reusable across different products in other domains. However, software reuse in the CSE community focuses more on language. The CSE community can do software reuse across different products having the same language base. This idea could be learned by the SPL community to move away from domain specific reuse.

5.7 Software Reuse and Technical Aspects The large volume of literature on reuse CASE tools and their growing market show that many organizations regard CASE tool as a way to improve reuse. The SPL community is using different types of CASE tools. Model-Driven tools and environment seem to be the way to go and less so with traditional CASE tools. In Model-Driven Development (MDD) and Model-Driven Architecture (MDA) reuse happens at the model level. On the contrary in the CSE community the data from our respondents shows that CASE tools have not promoted reuse across projects in organizations. The CSE community needs to have a reusable platform like the SPL community. The domain engineering process is responsible for establishing the reusable platform [14]. Learning from one to another community: Tools and environments adopted in the SPL community could be adopted by the CSE community to better support reuse. Techniques such as MDD and MDA could make significant improvement in how software reuse is carried out in the CSE community.

6. CONCLUSIONS AND FUTURE WORK This paper has presented a perspective on why successful application of software reuse has not become an engineering discipline and is limited to certain domains and not widespread across the software engineering community as a whole. The comparison shows that the coverage of actual software reuse activities in educational courses in software engineering is rather incomplete and needs to be taught to software engineers. The awareness of software reuse needs to be advertised more. Software reuse has not been addressed sufficiently in modernization activities. Modernization approaches need reuse of many activities of software development life cycle. Software reuse should be an explicit activity in software development life cycle and within modernization approaches.

An important consideration in initiating software reuse in the CSE and SPL community is developing a systematic software reuse process. It would be of little use to attempt a software reuse program without having in place a systematic and consistent software reuse process for reaping the benefits of software reuse. A software reuse program must provide significant economic benefit to the CSE and SPL communities to receive enthusiastic support and even to survive. Software reuse exists in SPLs and has been shown to give economic, and technical, benefits because of expertise and reuse knowledge employed by the software engineers. The cost and complexity associated with having software reuse in the SPL and CSE communities can be improved with the awareness of systematic software reuse rather than employing different types of reuse in the same context. Thus an organization should approach software reuse in a pragmatic way. Sufficient reuse based knowledge should be given to software engineers in the CSE community before they proceed with software reuse. Software engineers should be able to find out commonality in current and anticipated software projects that must exist to justify investment in reuse. Thus the CSE community should assess one or more areas of emphasis in which requirements for similar software frequently recur. In this case the CSE community should make a business decision as to whether or not to invest in a reuse program. Another very important asset for reuse is the availability of professional personnel with knowledge and experience in the area of software reuse. There should be a well constructed educational course in software reuse that would raise the level of knowledge and skills of software engineers in industry. This course should be taught as part of academic software engineering programs and to software engineers working in industry. Better education in software reuse and in particular the need to teach more about reuse in industry is needed to convince managers about the benefits of investing in reuse and meeting the project schedule at the same time and also to have reuse done systematically and to have it institutionalized.

7. REFERENCES [1] Lee, N. Y. and Litecky, C.R., An Empirical Study of Software Reuse with Special Attention to Ada, IEEE Transactions on Software Engineering, vol. 23, no. 9, Pages:537-549, September 1997. [2] Jacobson, I., Griss, M. and Johnsson, P. P., Software Reuse, Architecture, Process, and Organization for Business Success, Adision-Wesley, Reading, MA, 1997. [3] Hoffman, D. M, and Weiss, D. M., Software Fundamentals: Collected Papers by David Parnas, Addison-Wesley 2001. [4] Clements, P. and Northrop, L., Software Product Lines: Practices and Patterns, Addison Wesley: Boston, MA, 2002. [5] Sindre, G., Conradi, R., and Karlson, E., The REBOOT Approach to Software Reuse, Journal of Systems and Software, 30, 3 (September 1995), Pages: 201-212. [6] Kruger, C. W., Software Reuse, ACM Computing Surveys, Vol. 24 No. 02, Pages: 131-183, June 1992. [7] Morisio, M., Ezran, M., and Tully, C., Success and Failure Factors in Software Reuse, IEEE Transactions on Software Engineering, Vol. 28, No. 4, April 2002. [8] Morad., S. and Kuflik, T., Conventional and Open Source Software Reuse at Orbotech- an Industrial Experience, Proceedings of the IEEE International Conference on Software-

317

Science, Technology & Engineering (SwSTE’2005) 0-76952335-8/05.

Version I, USAF Material Command, Electronic Systems Center, Hanscom AFB, 1996.

[9] Slyngstad, O. P, N., Gupta, A., Conradi, R., Mohagheghi, P., Ronneberg, H., and Landre, E., An Empirical Study of Developers Views on Software Reuse in Statoil ASA, International Symposium on Empirical Software Engineering ’06, September 21-22,2006, Rio de Janeiro, Brazil ACM 159593-218-6/06/0009.

[20] Orrego, A. S. and Mundy, G. E., A Study of Software Reuse in NASA Legacy Systems, Innovations System and Software Engineering, 3:167-180 DOI 10.1007/s11334-007-0027-y Springer-Verlag London Limited, 2007.

[10] Frakes, W. B., and Fox, C. J., 16 Questions on Software Reuse, Communications of the ACM, 38, 6 (June 1995), Pages: 75-87. [11] Jha M., O’Brien L., and Maheshwari P., Identify Issues and Concerns in Software Reuse, Proceedings of the Second International Conference on Information Processing (ICIP’08), Bangalore, India, 2008. [12] Weiss, D. M. and Lai, C. R., Software Product Line Engineering: A Family-Based Software Development Process. Addison-Wesley, 1999. [13] Pohl, K., Bockle, G., and Linden, F. v.d., Software Product Line Engineering: Foundations, Principles, and Techniques, 1st ed. New York, NY:Springer, 2005. [14] Linden, F. v.d, Software Product Families in Europe: The ESAPS & CAFÉ Projects, IEEE Software, Vol. 13, No. 3, Pages: 41-49, 2002. [15] Jha, M., and O’Brien L., Identifying Issues and Concerns in Software Reuse in Software Product Lines, 11th International Conference on Software Reuse (ICSR) 2009, Virginia, USA 2630 September 2009. [16] Torkar, R, and Mankefors, S., A Survey on Testing and Reuse, Proceedings of the IEEE International Conference on SoftwareScience, Technology & Engineering, 0-7695-2047-2/03, 2003. [17] Daneva, M., Practical Reuse Measurement in ERP Requirements Engineering, Proceedings of 12th International Conference on Advanced Information Systems Engineering, Vol 1789, Pages: 309-324, May 2000, ISBN: 3-540-67630-9. [18] Mili, H., Mili, F., and Mili, F. A., Reusing Software: Issues and Research Directions, IEEE Transactions on Software Engineering, vol. 21, no. 6, Pages: 528-561, June 1995. [19] Software Technology for Adaptable, Reliable Systems, Air Force/STARS Demonstration Project Experience Report,

318

[21] Ramachandran, M., Software Reuse Guidelines, ACM SIGSOFT Software Engineering Notes, Volume 30 Number 3 Pages:1-8, May 2005. [22] Wegner, P., Varieties of Reusability. In Tutorial: Software Reusability. Edited by Peter Freeman. Washington, D.C.: IEEE Computer Society Press, Pages: 24-38, 1987. [23] Biggerstaff, T. and Richter, C., Reusability Framework, Assessment, and Directions. In Software Reusability: Volume 1-Concepts and Models, edited by T.J.Biggerstaff and A.J. Perlis. New York, ACM Press, 1989(b), Pages: 1-17. [24] Freeman, P., Reusable Software Engineering: Concepts and Research Directions. In Tutorial: Software Reusability. Edited by Peter Freeman. Washington, D.C.: Computer Society Press of the IEEE, 1987(b), Pages:10-23. [25] Incorvia, A. and Davis, A., Case Studies in Software Reuse, Proceedings of the 14th Annual International Computer Software and Applications Conference (COMPSAC 90), Pages: 301-306, 1990. [26] Trauter, R., Design Related Reuse Problems - An Experience Report, Proceedings of the 5th International Conference on Software Reuse, Pages: 176-183, 1998. [27] Lim, W. C., Effects of Reuse on Quality, Productivity, and Economics, IEEE Software 11(5), Pages: 23-30, 1994. [28] Isoda, S., An Experience of Software Reuse Activities. Proceedings of the 15th Annual International Computer Software and Applications Conference (COMPSAC 91), Pages: 8-9, 1991. [29] Griss, M. and Wosser, M., Making Reuse Work at HewlettPackard, IEEE Software 12(1), Pages:105-107, 1995. [30] Joos, R., Software Reuse at Motorola, IEEE Software, Pages: 42-47, Sept 1994.