The Lombard Hill Group empowers organizations
to implement
software
reuse programs that result in greater productivity,
quality and
shortened time-to-market
Lombard Hill Group is comprised of experienced professionals with extensive expertise in establishing successful software reuse programs in major corporations. Our mission is to enable organizations to reduce time-to-market while improving system quality and organizational productivity through the systematic institutionalization of reuse practices. Our clients have been in diverse industries such as investment banking, insurance, and electronics. As a firm of experienced practitioners, we emphasize a pragmatic approach to implementing and improving a reuse program.
The Lombard Hill Group has and always seeks collaborative partnerships with other service and product firms. If you have a proposal for such an arrangement, please contact us at
The Lombard Hill Group contact information:
Wayne C. Lim specializes in the strategic planning,
economic, organizational, and metric issues of software reuse. He is the author of numerous papers
and
a Prentice-Hall book, "Managing Software Reuse." Mr. Lim is the recipient of an IEEE Best Article
Award for his research in reuse. He helped start and manage the Corporate-wide Reuse Programs at
Hewlett-Packard and other organizations.
Mr. Lim completed his MBA degree at Harvard University
Lombard Hill Group is comprised of experienced professionals with extensive expertise in establishing successful software reuse programs in major corporations. Our mission is to enable organizations to reduce time-to-market while improving system quality and organizational productivity through the systematic institutionalization of reuse practices. Our clients have been in diverse industries such as investment banking, insurance, and electronics. As a firm of experienced practitioners, we emphasize a pragmatic approach to implementing and improving a reuse program.
The Lombard Hill Group has and always seeks collaborative partnerships with other service and product firms.
Dr. Wayne C. Lim specializes in the strategic planning, economic, organizational,
and metric issues of software reuse. He is the author of numerous papers and a Prentice-Hall book, "Managing
Software Reuse." Dr. Lim is the recipient of an IEEE Best Article Award for his research in reuse. He helped
start and manage the Corporate-wide Reuse Programs at Hewlett-Packard and other organizations. Previous work
includes strategic planning at Bain & Company and software engineering at Hewlett-Packard
Dr. Lim completed his undergraduate degree at Pomona College, MBA degree at Harvard University and Doctorate at Case Western Reserve University.
Reference:
Reference:
Poulin, Jeffrey S. Measuring Software Reuse: Principles, Practices, and
Economic Models. Addison-Wesley (ISBN 0-201-63413-9), Reading, MA, 1997.
Developed by Jeff S. Poulin.
Additional Development Cost (ADC)
The cost your organization incurred by writing reusable software for use by other organizations or projects. We calculate ADC by multiplying the historical cost to develop new code by the amount of code written for reuse and adjusting based on the RCWR. For example, with an RCWR = 1.5, the ADC represents an additional cost of 50% over new development.
Cost Avoidance
The financial benefit resulting from not having to expend resources. By reusing software, an organization avoids a cost proportional to the cost of having to develop that software new.
Cost Avoided by Others (ORCA)
The total financial benefit that other organizations experience by reusing your software.
Cost per Error
Your organization's historical cost to fix errors after releasing new software to the customer, in dollars per error. We recommend obtaining this value from your contracts or financial planning group; otherwise use $10,000/error as a default value. Uses dollars ($) for units.
Development Cost Avoidance (DCA)
The cost your organization avoided during the development phase of the project by reusing software. DCA combines with Service Cost Avoidance to equal the total Reuse Cost Avoidance (RCA) for your organization. We calculate DCA by multiplying the historical cost to develop new code by the amount of reused code (RSI) and adjusting based on the RCR. For example, with an RCR = 0.2, the DCA represents an 80% savings over new development. Uses dollars ($) for units.
Error Rate
The historical error rate in new software developed by your organization, in errors per thousand lines of code. We recommend obtaining this value from your contracts or financial planning group; otherwise use 0.5 errors/kLOC as a default value. Uses errors per thousand lines of code (errors/kLOC) for units.
External Reuse
Use of software from another organization or application; we count external reuse in our economic models.
Internal Reuse
Use of software within an organization; a normal procedure in software development that does not count as reuse.
Lines of Code (LOC)
(1) A logical line of code in a programming language source file, informally counted by the number of semi-colons in the code and formally counted according to rules established by organizations or code analysis tools. (2) An indicator of overall effort on a program.
New or Changed Source Instructions
The amount of software your organization actually wrote or modified for use only on this application (do not include Source Instructions Written for Reuse by Others). Uses lines of code (LOC) for units.
New Development Cost (Cost/LOC)
The historical cost to develop new software in your organization, in dollars per line of code. We recommend obtaining this value from your contracts or financial planning group; otherwise use the industry average of $100/LOC as a default value. Uses dollars ($) for units.
Organization (of people)
A programming team, department, or other autonomous group with software development responsibility. Many organizations may contribute to software development on a large project.
Organizational ROI
The total financial benefit to the project due to your organization's reuse effort. We calculate Organizational ROI by subtracting your Additional Development Cost (ADC) from your Reuse Cost Avoidance (RCA). Uses dollars ($) for units.
Productivity Index
A metric that shows how an organization changes productivity through reuse relative to an organization that does not participate in reuse, which has a productivity index equal to 1.
Project
A large software development effort, typically made up of many organizations.
Reengineering
The use of existing software in a new application, after modifying the software.
Relative Cost of Reuse (RCR)
The portion of the effort that it takes to reuse a component without modification versus writing it new. The RCR can vary depending on several factors and range from about .03 up to about 0.4. We recommend an RCR = 0.2, which means that it takes about 20% of the effort to reuse software as it takes to write it new.
Relative Cost of Writing for Reuse (RCWR)
The portion of the effort that it takes to write a reusable component versus writing it for one-time use only. The RCWR can vary depending on several factors and can range from about 1.0 up to about 2.2. We recommend an RCWR = 1.5, which means that it takes about 50% additional effort to write reusable software.
Reusability
The attributes or characteristics of software that affect a developer's ability to reuse the software. This calculator does not address software reusability.
Reuse
The incorporation into an application of unmodified software components obtained from other programs external to the application. These external sources typically include other applications, other organizations, and reuse libraries.
Reuse Cost Avoidance (RCA)
The total financial benefit to an organization resulting from reuse of software obtained from someplace else. Since your experience benefits both during development (because you don't have to write the code) and during maintenance (because you don't have to fix errors in the code) the RCA equals the sum of Development Cost Avoidance (DCA) and Service Cost Avoidance (SCA). Uses dollars ($) for units.
Reuse Level
The portion of a program coming from reused software, generally expressed as a percent of the total source lines for the program.
Reuse Leverage
An indicator of the multiplier effect of reuse, used as a productivity index.
Reuse%
The indicator of reuse level based on the definition of RSI.
Reused Source Instruction (RSI)
Software that complies with the reuse definition (counting rules) adopted by IBM, etc. See the reference below for a detailed discussion. Uses lines of code (LOC) for units.
Reuse Value Added (RVA)
A productivity index based on both the amount of reuse achieved by an organization and the amount of the organization's software actually reused by other organizations. We calculate the RVA by dividing the total amount of an organization's software in service by the amount of software the organization maintains.
Service Cost Avoidance (SCA)
The cost your organization avoided during the maintenance phase of the project by reusing software. SCA combines with Development Cost Avoidance (DCA) to equal the total Reuse Cost Avoidance (RCA) for your organization. We calculate SCA by multiplying your organization's historical error rate by the historical cost to fix those errors and by the amount of reused code (RSI). Uses dollars ($) for units.
Source Instructions Reused by Others (SIRBO)
The total amount of software produced for reuse by your organization that other organizations actually reuse. Calculated by taking the sum of your Source Instructions Written for Reuse by Others over every occurance of its use. Uses lines of code (LOC) for units.
Source Instructions Written for Reuse by Others (WRO)
The amount of software your organization wrote for reuse (reusable code). This software took extra effort to write, and therefore represents an investment in reuse. Uses lines of code (LOC) for units.
Total Source Instructions
The total number of lines of code in the application delivered by your organization. Calculated by taking the sum of New or Changed Source Instructions, Reused Source Instructions (RSI), and Source Instructions Written for Reuse by Others. Uses lines of code (LOC) for units.
Jeff Poulin owns this page.
The Reuse Needs Assessment
The Reuse Needs Assessment is an analytical and diagnostic tool for collecting both qualitative and
quantitative benchmark data on software development with reusable assets. The assessment benefits the
reuse program by analyzing the management, personnel, metrics, technology, process, and reusable asset
aspects of the reuse infrastructure; qualitatively identifying roadblocks to reuse as well as further
reuse opportunities; benchmarking the costs/benefits of reusable assets, and determining the current
levels of reuse by artifact in the organization. A representative sample of the deliverables from this
Assessment follows. (Note: Unless otherwise noted, the data shown below is hypothetical but
representative of actual data from past Assessments.)
Reuse Needs Analysis
Using hypothetical data, the keviat chart in figure 1, Reuse Needs Assessment Results, compares the
respondents' ratings of how important an area is to software reuse to how well the organization has
performed in this area.
The chart in figure 1 is based on responses to standardized questions answered by the target organization staff during the Reuse Needs Assessment process. The information from this chart provides an overview of the target organization and summarizes quantitative findings of the reuse needs assessment.
Further information on the organization's status within each of the six areas of software reuse is also available and presented when relevant. For example, in figure 2, more detailed ratings are provided for a subset of the management category, the overall investigation. Shown are the ratings for two of multiple questions that constitute the overall investigation subcategory.
Reuse Gap Analysis
Gap analysis is useful as a tool to identify reuse areas which require attention. As shown in figure 3,
the performance rating of a given area is mapped against its importance rating. For example, the reuse
areas in the northwest quadrant of the matrix are areas which are rated highly in importance but rated low
in terms of current performance. These are the areas on which an organization's efforts should be focused,
in order to migrate them to the northeast quadrant.
Reuse Metrics and Economics
If data is available from the organization, the Reuse Needs Assessment can optionally calculate the
improved quality, increased productivity and shortened cycle time from reuse. For example, we determined
for one reuse program that quality had improved by 24%, productivity had increased by 40% and the
time-to-market had been reduced by 42% through software reuse. In addition, the Reuse Needs Assessment
determines the cost/benefit of producing and reusing a reusable asset (not shown).
The Reuse Needs Assessment Process
Following are the steps of the Reuse Needs Assessment:
1) Identify target organization
2) Coordinate tasks with pilot project to undergo assessment
3) Gather initial information and deliver preliminary questionnaire and metric worksheets
4) Conduct assessment interviews
5) Analyze data and present findings
6) Create and deliver Reuse Needs Assessment report to organization (optional)
Benefits
The Reuse Needs Assessment benchmarks organizations that are considering or currently conducting reuse.
When data is available, the assessment benefits the organization by:
Attendees will be provided an overview and analysis of effective methods in three key reuse areas. Specifically, they will learn:
This tutorial offers an indepth analysis of some of the major concepts and tools necessary for adopting, tracking, evaluating, and improving upon a reuse program. The session will begin with an overview of a reuse adoption and institutionalization model. We will then focus on three specific concepts, reuse assessment, economics, and metrics, and show how each fits into the context of the model, and facilitates reuse institutionalization. We will discuss each concept in detail, including its importance within the reuse process, its implementation within the organization, and its proper use for furthering reuse goals. We will illustrate these concepts using industry examples whenever possible.
Half day
Utilizing the case method, attendees will be provided an overview and analysis of effective methods in several key areas. Specifically, they will learn:
This tutorial is an interactive, case-based seminar on establishing a software reuse program for your organization. This tutorial will cover the definition of software reuse and the evolution of the reuse concept, its benefits and costs, its obstacles and critical success factors, its strategic role in the organization, implementation strategies, staffing,organizing, financing, and marketing the reuse effort, legal issues, and measurement and tracking of the impact of reuse on the organization. Prior to the seminar, attendees are asked to read a case of an organization attempting to implement reuse.
Half day
To purchase surveys, go to the registration page
Lombard Hill Group Report No: AP-12000
This survey identifies twelve reuse prologues developed by both the private and public sectors. A prologue is a description of the information elements included with each software component.
Lombard Hill Group Report No: AP-12001
This report baselines reuse economic modeling by surveying and comparing seventeen economic models and presenting conclusions and recommendations for further research. Each model is described in its original terminology and translated using a common lexicon. The analyses indicate a great deal of commonality among the set of models. While this may indicate that researchers are arriving at similar models independently, it may also suggest that we should direct our efforts at forging new ground in reuse economics. Five areas for further research in reuse economics are recommended, and general guidelines for helping organizations decide on a suitable economic model are discussed. The 'Reuse Cost Calculator' spreadsheet that is now being bundled with the report was developed by the Data and Analysis Center for Software (DACS) (www.thedacs.com) as part of their Gold Practices Initiative. The DACS is a DoD-sponsored Information Analysis Center (IAC) administratively managed by the Defense Technical Information Center (DTIC). The DACS is technically managed by the Air Force Research Laboratory (AFRL) in Rome, NY and operated by ITT Industries, Advanced Engineering and Sciences.
ISBN 0135523737
Your copy may be ordered from amazon.com or a bookstore near you.
Managing Software Reuse is a comprehensive, step-by-step, guidebook to an integrated approach for investigating, planning, and implementing software reuse. With the reuse potential and aptitude model, the author shows when reuse should not be implemented in an organization and illustrates the case with reuse failures. He introduces the forward-thinking concept of Strategy-driven reuse, the deliberate choice and implementation of reuse for gaining competitive advantage. Examples and data from real-life reuse programs in companies such as Hewlett-Packard, IBM, GTE, Nippon Telegraph and Telephone Corporation, and First Boston are used to highlight key concepts. A useful outline is provided for the reader to create a reuse infrastructure and implementation plan.
Managing Software Reuse is an invaluable reference and includes the world's most extensive collection of surveys on reuse adoption strategies (eleven strategies), success factors (five studies), economic models (seventeen models), reuse maturity models (seven models), assessments (nine assessments), organizational structures (seven structures), metrics, processes (ten processes), domain analyses approaches (nine approaches), reusability guidelines (nine guidelines), prologues (five prologues), and certification levels (eight examples).
Included in the book is an extensive list and description of
companies reusing software in the aerospace, banking, computer and electronic equipment, information
systems and business applications, analytical instruments, insurance, manufacturing,
pharmaceuticals, telecommunications, transportation, and utilities industries.
Managing Software Reuse shows exactly how to:
OUTLINE FOR MANAGING SOFTWARE REUSE:
I. INTRODUCTION
1. THE SOFTWARE DEVELOPMENT CRUNCH
2. SOFTWARE REUSE - DEFINITION, SCOPE AND FRAMEWORK
3. EVOLUTION OF THE SOFTWARE REUSE CONCEPT
4. MAJOR TRENDS IN REUSE
5. REUSE IN INDUSTRY
6. ORGANIZATIONAL REENGINEERING FOR REUSE: A REUSE ADOPTION AND INSTITUTIONALIZATION MODEL
Appendix 6-A: A Survey of Reuse Adoption Strategies
II. INITIATING REUSE
7. THE ROLE OF A CORPORATE REUSE PROGRAM
8. IDENTIFYING REUSE POTENTIAL AND APTITUDE
Appendix 8-A: A Survey of Prior Research on Reuse Success Factors
9. SELECTING PILOT PROJECTS
III. INVESTIGATING REUSE
10. REUSE INVESTIGATION
11. BENEFITS AND COSTS OF SOFTWARE REUSE
12. A COST JUSTIFICATION MODEL FOR SOFTWARE REUSE
Appendix 12-A: A Survey of Reuse Economic Models
13. DECIDING ON REUSE AS A STRATEGY
Appendix 13-A: A Survey of Reuse and Maturity Models
14. CONDUCTING A REUSE ASSESSMENT
Appendix 14-A: A Survey of Reuse Assessments
IV. PLANNING FOR SOFTWARE REUSE
15. A REUSE VISION AND MISSION STATEMENT
16. STAFFING FOR SOFTWARE REUSE
17. ORGANIZATIONAL STRUCTURES FOR SOFTWARE REUSE
Appendix 17-A: A Survey of Prior Research on Reuse Organizational Structures
18. FINANCE AND ACCOUNTING FOR A REUSE PROGRAM
19. REUSE METRICS
Appendix 19-A: A Survey of Reuse Metrics
20. MARKETING REUSABLE SOFTWARE
21. LEGAL AND CONTRACTUAL ISSUES OF SOFTWARE REUSE
22. MANUFACTURING REUSABLE SOFTWARE
V. PROCESSES AND TOOLS
23. REUSE PROCESSES
Appendix 23-A: A Survey of Reuse Processes
Appendix 23-B: A Survey of Domain Analysis Approaches
Appendix 23-C: A Survey of Reusability Guidelines
24. REUSE TOOLS
Appendix 24-A: A Survey of Information Elements (Prologues)
Appendix 24-B: A Survey of Certification Levels
VI. IMPLEMENTING SOFTWARE REUSE
25. IMPLEMENTATION STRATEGY
VII. MONITORING AND CONTINUOUS IMPROVEMENT
26. MONITORING AND CONTINUOUSLY IMPROVING THE REUSE PROGRAM
VIII. FUTURE TRENDS
27. FUTURE TRENDS
APPENDIX A. A REUSE INFRASTRUCTURE AND IMPLEMENTATION PLAN OUTLINE
APPENDIX B: SOFTWARE REUSE LEXICON
.
Software reuse is the use of existing assets in
some form within the software product development process. More than just code, assets are products
and by-products of the software development life cycle and include software components, test suites,
designs and documentation. Leverage is modifying existing assets as needed to meet specific system
requirements.
Read More
Cluster analysis is "concerned with grouping of
objects into homogeneous clusters (groups) based on the object features. [Kusi]" Cluster analysis was
applied to software reuse at the Manufacturing Productivity (MP) section of the Software Technology
Division of HP to solve a problem concerning the maintenance of their reusable assets, called
"utilities".
Read
More
PURPOSE
The purpose of this document is to provide a brief introduction to software reuse. It defines software reuse and its basic mechanics, describes what motivates organizations to pursue reuse and how the engineer's and manager's tasks will change with reuse, and explains how to get started in reuse. If you feel that you would like more information after having read this document.
WHAT IS SOFTWARE REUSE?
Software reuse is the use of existing assets in some form within the software product development process. More than just code, assets are products and by-products of the software development life cycle and include software components, test suites, designs and documentation. Leverage is modifying existing assets as needed to meet specific system requirements. Because reuse implies the creation of a separately maintained version of the assets, it is preferred over leverage.
Current thinking is that reuse is most effective when it is practiced systematically. Systematic reuse is when reuse of assets is planned with well-defined processes and life cycles, commitments for funding, staffing, and incentives for production and use of the reusable assets.
Reuse can be achieved through different modes. Compositional reuse involves constructing new software products by assembling existing reusable assets, while generative reuse involves the use of application generators to build new applications from high level descriptions.
Leveraging involves the modification of previously developed software for a new product. When managed correctly, leveraging can be advantageous over creating software from scratch in that it requires less time and effort. On the other hand, because it is difficult to correctly predict the impact of modifications, leveraging may result in lower quality software. It can also lead to multiple versions of a software component and consequently, an increased maintenance burden.
MOTIVATIONS FOR REUSE
Today's organizations face competitive pressures in shortening the time required to bring a product to the market, reducing software development and maintenance costs, and increasing the quality of their software. While not a panacea, organizations have increasingly turned to a reuse strategy in order to meet their business goals. Implemented appropriately, reuse can aid in achieving some or all of the following goals:
* Increase productivity
After an initial investment, reuse of existing assets will enable projects to decrease the cost of developing and maintaining software. Hewlett-Packard (HP) reuse projects have reported productivity increases from 6 to 40%.
* Shorten time-to-market
By reusing software to shorten the critical path in delivering a product, organizations within HP have reported a reduction in time-to-market from 12 to 42%.
* Improve software quality
Software that has been used multiple times will possess fewer defects than freshly coded components. One HP organization had mature reused code that had a defect density which was ten times better than new code. Quality improvements in HP products from reuse have ranged from 24 to 76%.
* Provide consistency and interoperability across products
Standard interfaces and common use of components across products facilitates ease of use and interoperability. For example, when several software products reuse the same user interface scheme, terms and conventions are used consistently. Reuse also contributes to interoperability. For example, when a component that contains an error-message handling routine is reused by several systems, these systems can expect consistent behavior.
* Ensure product/system conformance with user requirements through prototyping
Because the availability of reusable components facilitates prototyping, user requirements may be more easily validated. This prototyping will also enable detection and resolution of defects earlier in the software life cycle - avoiding more costly fixes later in the life cycle.
* Reduce risk
Risk in creating new software is reduced when available reusable components already encompass the desired functionality and have standard interfaces to facilitate integration.
* Leverage technical skills and knowledge
Reuse enables specialists to optimize software architectures and assets which may then be reused by others who are focussing on meeting product features and market needs.
* Improve functionality and/or performance
Reuse allows for the investment of time to improve functionality and/or performance. Because this time can be amortized over multiple uses of the assets, this investment for such improvements is more economically justified than the case where they would only be for single product.
PROCESS OF REUSE
Experience has shown that reuse is not merely creating a repository, having engineers deposit assets and hoping that other engineers will reuse the repository's contents. Rather, successful implementation of reuse requires an infrastructure to support reuse. A critical aspect of the infrastructure is the process of reuse.
In its simplest form, the process of reuse consists of four major activities: manage the reuse infrastructure (MRI), produce reusable assets (PRA), broker reusable assets (BRA) and consume reusable assets (CRA). A few terms are defined to facilitate our discussion: Producers are those who create reusable assets with the specific goal of reusability. Consumers are those who use reusable assets to produce enduser products or further reusable assets. Each of the four major activities are now briefly defined.
The function of Manage the Reuse Infrastructure (MRI) is to establish the reuse rules, roles, and goals in the infrastructure to support reuse. MRI drives the reuse process. This includes designating conventions and standards; approving additions, deletions, and changes to the library; commissioning component construction; coordinating schedules and resources and aligning reuse goals to business goals. This function also establishes and awards incentives, interprets metrics data, and implements economic models. Overall, MRI is responsible for the planning of the reuse effort.
The Produce Reusable Assets (PRA) activity develops, generates, or reengineers assets with the specific goal of reusability. PRA includes domain analysis and domain engineering. Domain Analysis is the process of identifying, collecting, organizing, analyzing and representing the commonality and variability among systems in an application domain and software architecture from the study of existing systems, underlying theory, emerging technology and development theories within the domain of interest. Domain Engineering is the construction of components, methods, and tools and their supporting documentation to solve the problems of system/subsystem development by the application of the knowledge in the domain model and software architectures.
The Broker Reusable Assets (BRA) activity aids the reuse effort by qualifying or certifying, configuring, maintaining, promoting and brokering reusable assets. This process also includes classification and retrieval for assets in the reuse library.
The Consume Reusable Assets (CRA) activity occurs when systems are produced using reusable assets. Users utilize the library and associated tools to gain an understanding of the reusable assets available to them; identify and retrieve needed components; integrate the components into their system; and provide feedback to the librarian on existing and needed components.
ENGINEER'S TASKS
Reuse requires new job roles and different tasks for the engineer. This will be illustrated with an analogy to the task of home construction. The advent of prefabricated parts for home construction has provided home builders with a less costly alternative to construction from scratch. Home builders can rely upon standard parts which may be used to construct homes in a much shorter time than historically possible. However before such prefabricated parts are made available to the home builder, they must be specified, designed and created.
Analogously, one of the roles necessary with reuse is the producer engineer who creates the reusable assets. Among, the changes that the producer engineer will find in the task of creating reusable software relative to regular software product development are:
* Increased design time
In constructing prefabricated home parts, designing a door for a single instance of use is generally less complex than designing one that would accommodate usage for several rooms in a home or in several types of homes. Likewise, designing software for a one time use generally takes less time than that required to make the software reusable. The new challenge lies in designing the software for multiple products. New roles created include the domain expert and domain analyst who perform analyses to specify the requirements prior to the design of the assets. A is a domain expert person who is very knowledgeable about a particular domain. This person will generally be aware of existing and planned products in the domain. A domain analyst extracts and analyzes information about a domain from existing components, product plans, domain experts and other sources to produce domain models.
* Understanding of multiple contexts of use
Just as a home parts builder anticipates the conditions and contexts of how a door will be used (e.g. weather conditions), the producer engineer needs to anticipate how the asset will be used in future reuses.
* Reallocation of time
Without reuse, the engineers' time is spent developing software from scratch. With reuse, user engineers spend more of their time locating, understanding and integrating reusable components.
* Increased documentation
In order to facilitate understanding and therefore reuse of software, adequate documentation is required for the user.
The consumer engineer employs the reusable assets. Just as a home builder designs a home with the knowledge of what prefabricated parts are available, the user engineer practices asset-centered design, designing a product which takes advantage of the available reusable assets. Among the changes that the user engineer will find in the task of reusing software relative to regular software product development are:
* More time allowed for innovation
Reuse allows the engineer to avoid creating redundant assets, freeing time for the innovative aspects of development.
* Greater potential for prototyping
Having an existing set of assets encourages rapid prototyping to validate end-user requirements.
Engineers may also participate in a "reuse software evolution" or steering committee. This committee is the mechanism to bring the disparate producers and consumers together to facilitate decision making regarding the evolution of the reusable assets.
MANAGER'S TASKS
New tasks and roles will also be created for the managers. All managers will need to focus not just their own projects but also on how they can contribute to the success of the organization's portfolio of projects. An essential aspect of this view is to understand that reuse is a strategic investment requiring long term commitment which will pay back in the long run.
Managers of both producer and user engineers will find themselves helping or managing efforts at identifying commonality, utilizing metrics, and conducting assessments and reviews to ensure that the necessary assets are produced and used.
The new roles of reuse sponsor, champion, or manager may also be created.
The sponsor is usually a manager(s) who authorizes and reinforces the reuse program. The primary job of the sponsor is to oversee and ensure that the reuse program has adequate resources.
The reuse champion is the individual or group who advocates and supports the reuse program. This champion, who may be a manager or engineer, is an evangelist for software reuse and has the key role of convincing and selling the reuse concept to constituencies. Successful reuse champions are usually individuals who are well-respected for their technical and personal leadership.
The reuse manager has the overall responsibility for reuse planning, managing the flow of information and assets between producers and consumers, and for ensuring that the infrastructure supports the reuse effort. This manager may be directly responsible for the mechanics of reuse or indirectly through a reuse council, steering committee or review board. An effective reuse manager has the ability and skills to understand and handle process issues, coordinate collaboration of several different organizations, recognize and balance short and long term goals, identify and solve cultural and organizational impediments, and communicate and influence at multiple managerial levels.
It is important to note that many or a single individual can serve any or all of these roles.
GETTING STARTED
A successful program in reuse starts with the recognition of reuse potential. If your organization has substantial duplication across existing or new product lines and/or within a given product, then your situation may warrant further investigation into the feasibility of reuse. Stable, mature and well-understood domains offer the best possibilities for reuse. Assuming that the necessary management and resource commitments exist, the steps to implement reuse briefly consist of:
* Assess organizational readiness
Understand the people, process, product, technology, asset, economic, metric and management facets of the organization and how reuse will impact each of these aspects.
* Identify and collect metrics
While this activity is done throughout the reuse effort as necessary, collecting metrics early will enable us to benchmark the organization and show the impact when reuse is implemented. Metrics are identified based on those business goals reuse is assisting the organization in reaching.
* Select a target set of users and pilot project
Identify a set of product efforts that may be good candidates for reuse. Factors to consider include the readiness of the engineers and managers to apply reuse, whether reusable components can be made available to them within their development schedule, etc.
* Identify domains in the organization
Enumerate a list of domains that are in common within the organization. These may include horizontal domains (e.g., graphical user interfaces, error handling) and vertical domains (e.g., manufacturing applications, medical imaging).
* Collect an inventory of existing material
Locate candidate components for each identified domain.
* Analyze the domain
An informal domain analysis may be conducted for the chosen domain. This analysis includes determining features common to systems in the domain and assessing the range of variability.
* Examine the existing organizational structure
Consider establishing an independent producer group. This would dedicate resources to ensure that the necessary assets are created, managed and supported.
* Create and manage reusable assets
Make, buy or re-engineer existing assets for users. Bring these assets under a source control and configuration management system.
* Establish a process for producing, managing and using the reusable assets
After obtaining a clear understanding of the current process for software product development, determine a process for producing, managing and using reusable assets that address the particular needs of the organization.
* Utilize tools, technology, and standards
Examine whether to create or use existing tools, technology and standards for your reuse program.
* Conduct reviews and walkthroughs to reinforce reuse
Throughout the product development life cycles, perform reviews to ensure adherence to reusability objectives.
* Pursue continuous process improvement
Continuously monitor and pursue incremental improvements to the reuse program. Explicitly solicit feedback from the users, end-users and other participants in the reuse effort.
The Lombard Hill Group provides expertise in practical implementation and improvement of software reuse
programs.
Keywords: cluster analysis, group technology, manufacturing concepts, domain analysis.
Wemmerlov and Hyer [Wemm] highlight three ways that group technology benefits are achieved:
* By performing similar activities together, less time is wasted
in changing from one unrelated activity to the next
* By standardizing closely related items or activities,
unnecessary duplication of effort is avoided
* By efficiently storing and retrieving information related to
recurring problems, search time is reduced
One of the means for family identification in group technology is cluster analysis. Cluster analysis is "concerned with grouping of objects into homogeneous clusters (groups) based on the object features. [Kusi]" Cluster analysis was applied to software reuse at the Manufacturing Productivity (MP) section of the Software Technology Division of HP to solve a problem concerning the maintenance of their reusable assets, called "utilities".
The MP section produces large application software for manufacturing resource planning. The MP reuse program started in 1983 and continues to the present. The original motivation for pursuing reuse was to increase the productivity of the engineers to meet critical milestones [Nish]. MP has since discovered that reuse also eases the maintenance burden and supports product enhancement. Reuse was practised in the form of reusable assets (application/architecture utilities and shared files) and generated code. Total code size for the 685 reusable assets was 55 Thousand lines of Non-Commented Source Statements (KNCSS). The reusable assets were written in Pascal and SPL, the Systems Programming Language for the HP 3000 Computer System. The development and target operating system was the Multi-Programming Environment (MPEXL).
The utilities at MP are many (685 utilities) and small in size (lines of code range from 14 to 619 Non-Commented Source Statements). In manufacturing systems software developed by MP, a transaction constitutes a cohesive set of activities used for inventory management and is a subunit of the manufacturing systems software.
Within each transaction, calls are made to the appropriate utilities as required which are contained in an include file specific to the transaction. However, this has led to a proliferation of different include files since each transaction is usually created by a different engineer. When a utility is modified, all the include files which contain this utility need to be identified and updated with the new version. This has resulted in a tremendous amount of effort.
In an effort to reduce the potential amount of effort required for future updates, an analysis using cluster analysis was conducted on the use of utilities by transactions.
First, a 13 x 11 matrix was created by designating the rows as transactions and the columns as utilities. (Figure 1). A "1" indicates that a transaction makes a call to the particular utility, and a "0" indicates that a transaction does not make a call to the particular utility.
Input Matrix
(Rows are transactions; columns are reusable assets)
1 0 1 0 0 0 0 0 0 0 0
0 0 1 0 0 0 0 1 0 0 1
0 0 1 0 0 0 0 1 0 0 0
0 0 0 0 0 0 0 1 0 0 1
0 0 1 0 0 0 0 0 0 0 1
0 0 1 1 0 0 0 0 0 0 1
0 0 1 0 0 0 0 0 0 0 0
0 1 0 0 1 0 1 0 0 0 1
0 1 0 0 1 0 1 0 0 0 0
0 1 0 0 1 1 1 0 1 1 1
0 1 0 1 1 1 1 0 1 1 1
0 1 0 1 0 0 1 0 0 0 1
0 1 0 1 1 0 1 0 0 0 1
Column (Reusable assets):
1=Adj-summary-qty
2=Autobofill
3=check'store'up
4=invalid-fld-check
5=potency-inv-qty
6=prep'for'pcm
7=print-document
8=report-neg-qty
9=send'to'pcm
10=update'pcm'buff
11=write-stock-file
Rows (Transactions):
Figure 1
The matrix is then used as an input file to a clustering algorithm provided by Dr. Andrew Kusiak of the University of Iowa.
The output solution, as shown in figure 2, reorders the reusable assets into "clusters". The results suggest that we place utilities (depicted by the columns) 1, 3 and 8 into a single include file for transactions 1 to 7.
Utilities 2,5,6,7,9,10 should be placed into another include file for transactions 8,9,10,11,12,and 13.
Utilities 4 and 11 can either be placed in both include files or a separate one may be created for them.
Cluster Analysis Solution
(Rows are transactions; columns are reusable assets)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 2
Benefits of Cluster Analysis for Reuse
Cluster analysis is useful in the creation of include files with specified utilities that would reduce the effort required to maintain the files. In our example with the MP section, prior to cluster analysis, thirteen individual include files were maintained; one for each transaction. By utilizing cluster analysis, we were able to identify the commonalities and differences within the thirteen include files and specify a core set of two include files. By reengineering the thirteen include files into two, the number of files to maintain can be reduced by 85%.
Cluster analysis also has further applications in software reuse. It may be used to identify "families of systems" i.e. those that share the same features. For example, we can apply cluster analysis to a matrix where the columns depict the features of software systems/products and the rows, the software systems/products. The analysis would cluster the features to the software systems/products. thereby helping to identify families of systems which share common features. This information may be useful in determining specific reusable assets to create.
Acknowledgements
My acknowledgements to Dr. Andrew Kusiak, Dr. Sylvia Kwan and Alvina Nishimoto for their help and input to this paper.
[Kusi] Kusiak, Andrew and Wing Chow, Decomposition of Manufacturing Systems, IEEE Journal of Robotics and Automation, vol. 4, no. 5.
[Maar] Maarek, Yoelle and Gail Kaiser, Using Conceptual Clustering for classifying reusable Ada code, Using Ada: ACM SIGAda International Conference, ACM Press, New York.
[Nish] Nishimoto, Alvina, "Evolution of a Reuse Program in a Maintenance Environment", 2nd Irvine Software Symposium.
[Wemm] Wemmerlov, Urban and Nancy Hyer, Group Technology, chapter 17 in Handbook of Industrial Engineering, Gavriel Salvendy, ed., John Wiley & Sons.
|