ASE Logo

Software Reuse
Executive Primer

April 15, 1996

produced by the
DOD Software Reuse Initiative
Program Management Office
5600 Columbia Pike
Falls Church, VA 22041

Note: this document is slightly modified from the original, mainly by adding a hyperlink to an area for further study elsewhere on the ASE01_03 CDROM.

WHAT IS REUSE?

Reuse is the process of implementing or updating software systems using existing software assets.

Assets can be specifications, design, code, user documentation, or anything associated with software. Reuse may occur within a software system (e.g., common data and operations for all objects of a particular subclass); across similar software systems (e.g., report generators for database management systems); or in widely different software systems (e.g., WYSIWYG user interfaces for thousands of different application packages). Reuse is an integral part of every engineering discipline. For example, mechanical engineers do not design a combustion engine from scratch for each car rolled off an assembly line; chemical engineers do not develop the formula anew for each bottle of cleaner that is placed on a hardware store's shelf; Microsoft software engineers do not recreate the interaction between an application and its icon in the Windows environment for each new product; and aerospace engineers do not build solid rocket boosters from ground zero for each space shuttle. In all of these examples, the architecture and design of an item is reused to produce and manage a "product line". Software can also be acquired, developed, maintained, and managed via a "product-line" approach.

 

 

 

 

 

 

WHAT IS IN THE PRIMER?

The Reuse Executive Primer provides a brief introduction to the concept of software reuse.

The Primer presents the issues involved in transitioning to reuse-based development, maintenance, and acquisition processes, and discusses strategies that can best address these issues. Specifically, the Primer focuses on developing the seed of understanding for the executive who desires to:

Transition the technology.

Development, maintenance, and acquisition-oriented organizations must successfully manage the transition of their organizations' methods, processes and tools to those based on reuse principles;

Minimize the risks.

Risks that are associated with the development of a reuse program and with the insertion of reuse requirements into software acquisition, development, maintenance, and migration efforts must be minimized; and

Make informed decisions.

It is essential that program executives become informed about the issues associated with reuse in order to employ systematic, rather than opportunistic, reuse.

The Reuse Executive Primer discusses both technical and organizational issues, and successful management techniques.

Strategic guidance is offered for the development of reuse programs, the acquisition of systems, as well as the development and reuse of software system life-cycle products. No specific knowledge of reuse is assumed.

WHO WILL BENEFIT FROM THE PRIMER?

Program Executive Officers and Program Managers.

The Reuse Executive Primer's primary audience comprises Program Executive Officers (PEOs) and Program Managers (PMs) who are responsible for implementing reuse within software acquisition, development, maintenance and, eventually, migration efforts within the Department of Defense (DOD). These managers decide how to implement reuse within their programs, when and what to reuse, and when and what to design for reuse. The managers of real-time, embedded, command and control (C2), and automated information systems (AIS) will be addressed.

WHY SHOULD I "REUSE"?

Software reuse provides a basis for dramatic improvements in increased quality and reliability and in long-term decreased costs for software development and maintenance.

Improving the quality and reliability of systems under an organization's responsibility in an era of decreasing budgets challenges both management and technical skills. Combine this dilemma with ever increasing responsibilities for systems of greater complexity, and a nearly impossible situation seems to be forming. One response to this situation that has proven successful is the integration of software reuse principles into the software engineering process. fig -2

Software reuse provides a basis for dramatic improvement in the way software-intensive systems are developed and maintained over their life-cycle. Improvements manifest themselves in increased quality and reliability and in long-term decreased costs for software development and maintenance. Other benefits of adopting reuse include improved interoperability and support for rapid prototyping activities. Since reuse is merely a by-product of disciplined software engineering, there is less initial risk for development, maintenance and acquisition activities.

WHY IS REUSE IMPORTANT?

Software reuse principles have been demonstrated in isolated examples in industry and DOD to provide one of the greatest returns on investment for reducing cost, time and effort throughout the software life-cycle.

Both the Department of Defense and Congress have stressed the importance of reducing the cost, time, and effort required to build and maintain software systems for the DOD. This applies to in-house and contractor-developed systems. Software reuse principles have been demonstrated in isolated examples in Industry and the DOD to provide one of the greatest returns on investment for reducing cost, time and effort throughout the software life-cycle:

  • The Navy experienced a 26% reduction in required labor hours to develop and maintain its Restructured Naval Tactical Data Systems (RNTDS).

  • Raytheon saw a 50% increase in productivity in its Missile Systems Division.

  • Fujitsu's Software Development for Electronic Switching Systems (ESS) began delivering 70% of its ESSs on schedule (as opposed to only 20% before adopting reuse principles).

  • The Army estimates a cost avoidance of $479.9 million for its Tactical Command and Control system, allowing additional mission requirements to be addressed during a period of funding shortfalls.

  • Magnavox developed the Force Fusion System Prototype (FFSP) in 20% of the projected, estimated time for a totally new system development.

Unfortunately, software reuse doesn't just happen. Both technical and organizational issues must be tackled in order to successfully transition to a reuse-based culture. Once these issues are managed, the benefits discussed above can be garnered. The Reuse Executive Primer discusses both technical and organizational issues, successful management techniques, and refers the reader to published works for greater detail (see Bibliography).

The Department's Software Reuse Initiative (SRI) faces the challenge of coordinating and guiding the transition to a reuse-based culture. Providing the lessons learned from the reuse experiences of Industry and Government in this Primer is just one of the ways that the SRI Program Management Office (PMO) anticipates fulfilling its mission and being of service to the Department.

WHAT DO I REUSE?

Considering that coding consumes only 10-15% of the time and effort on a project, it is astounding that almost all reuse efforts have been directed at code reuse.

fig-3
It is essential to identify the life-cycle phases that will be supported by a reuse project. Considering that coding consumes only 10-15% of the time and effort on a project, it is astounding that almost all reuse efforts have been directed at code reuse. The DOD SRI emphasizes a broader approach, advocating the reuse of all software product items (e.g., designs, specifications, concepts of operation, user documentation). It is estimated that the introduction of reuse processes into early development and maintenance activities, for example, specification and design (for development), and scope of impact/sphere of influence for functions and data identified through reverse engineering (for maintenance), will produce ripple effects throughout the project and return greater benefits, such as productivity and cost savings. However, this is not without its challenges, and technology has not fulfilled its promise for supporting this area. Specifically, how to store, represent, search and retrieve designs and tools are just now being developed (e.g., hypertext with hot buttons, enterprise integration modeling, and I-CASE).

HOW IS REUSE DONE?

Reuse is a by-product of disciplined software engineering. The essential elements can be addressed through discussions of foundation and technologies.

Foundation

The characteristics of disciplined software engineering are common to every engineering field. It is a well-defined methodology that addresses a complete life-cycle; characterizes mechanisms to manage and achieve traceability throughout the life-cycle; and establishes milestones in the life-cycle for which buy-in can be obtained from stakeholders.

A complete life-cycle is that of a "product line", not a single software system. This product-line approach provides for the manufacture of many products from one architecture and design. When the architecture and/or design are modified, new and better products can be manufactured. Some examples are:

The first Space Shuttle, Enterprise, was designed from ground zero. However, new shuttles are not; they are manufactured from the original, and modified, architecture and design.

Cars differ significantly in design, but rarely architecture: there still exist common elements (axles, tires, combustion engines) and ways that these components interact.

Personal computers are assembled from manufactured parts, normally not produced by the assembler. Each manufactured part is itself an instance of reuse within a product line.

The product-line approach, as applied to software engineering, involves domain analysis and architecting. Domain analysis organizes, catalogs, and creates representations of knowledge within and about a particular functional area, or domain, (e.g., command and control systems). Features and problems common to the family of software applications within a domain are also identified during domain analysis. Candidate solutions to these problems and common feature characterizations are represented by domain-specific software architectures (DSSAs). The DSSA is a collection of structural views of a system. The DSSA represents a solution to the hardware and software platform, speed, performance, reliability, integration, interfacing, cost, modifiability, testability, and logical requirements.

An architecture includes both dynamic and static structures. Dynamic structures persist through execution, such as bulletinboards or client/server. Static structures exist only at design time, such as code modularity. Representing both dynamic and static structures, and the requirements listed previously, requires an architecture to be able to accommodate multiple structural views. This representation allows an architecture to assist both developing fig -4 for, and developing with, reuse.

An example of a software architecture is the Open Software Foundation's (OSF) Distributed Computing Environment (DCE) Client/Server architecture. A high level illustration of the functional components of this architecture can be seen in Figure 4, from Alex Berson's Client/Server Architecture (McGraw-Hill, 1992).

An architecture such as that illustrated above must be further defined to be of value for the development of whole families of client/server applications. For example, the dataflow between the DCE Client Executive and the Operating System and Network Interface could be characterized in terms of existing or proposed standards. This characterization then becomes a candidate solution for multiple applications using the client/server architecture. Specifically, an architecture:

  1. provides a basis to clarify and negotiate requirements with users;

  2. assists in the identification, development, assembling, compatibility assessment, and integration of pre-existing assets and assets to be designed for reuse;

  3. aids in the development and maintenance of system interoperability; and

  4. defines the core structural integrity of the system which must be maintained throughout modifications.

Technologies

The widespread use of architectures as part of a software engineering approach is relatively new and, as such, tools and technology have yet to provide adequate support. However, research groups, such as at the University of Southern California's Center for Software Engineering, are experimenting with TRW's Rational Universal Network Architecture Services (UNAS) middleware package. Hewlett-Packard has begun to develop domain-specific kits that include frameworks that capture the architecture of the domain's family of system solutions, sets of reusable components, design fragments, glue code, tests, templates, documentation, and tools to support both the construction and execution environments. Eventually, tools will be available that can adequately support multiple structural views for development and maintenance activities. These tools should be integrated or integratable with tools and technologies that facilitate reuse.

Reuse can be accomplished by using a variety of technologies, for example, application generators, I-CASE and CASE tools, repositories, and object-oriented languages.

An important issue to consider in the selection of a technology to facilitate reuse is the relationship between the generality of the technology selected and its power to facilitate reuse. This relationship is an inverse one: the more general a technology is, the less it is a facilitator of reuse. That is, the more specifically a technology addresses a problem domain, the greater is the technology's potential for providing an environment that can adopt reuse principles and practices easily. Described below are three commonly used facilitators of reuse.

Object-Oriented Development (OOD) techniques offer encapsulation of data and functions into integrated, modular units that lend themselves to being shared and reused. In addition, classes of objects can be defined, and their attributes and functions are inherited by members of subclasses.

Computer-Aided Software Engineering (CASE) tools and Designware offer reusable application programs in fully loaded CASE repositories and, when used with the tools, allow users to customize applications.

Libraries store the reusable assets, facilitate search and retrieval of assets, and can have certification mechanisms for ensuring that only the highest quality assets are incorporated into the library.

A list of technologies is provided below in descending order of ability to easily incorporate reuse principles:

  • Application generators
  • I-CASE tools
  • Architecture development tools
  • Problem-oriented languages
  • Code skeletons
  • Composition tools
  • CASE tools
  • Modelling tools
  • Object-oriented knowledge bases
  • Libraries/repositories
  • Natural languages
  • Application languages
  • Dataflow languages
  • Object-oriented languages
  • Very high-level languages
  • Formal methods
  • High-level languages
  • Assembly languages

Each of these technologies has its costs, by-products, considerations and implications. Since the beginning of the initiative, the Department has concentrated on one technology, repositories, and the building, population, maintenance, and promotion of these asset libraries. However, transitioning to reuse-based life-cycle processes has proven to be a far more complex issue, requiring a response of greater sophistication than "build it and they will come."

In particular, a domain-specific, architecture-centric approach to reuse is advocated. This approach establishes reuse among related families of systems, exploits the commonality of the systems and families, and maximizes the reusability of assets developed for reuse and the benefits of reuse. The SRI recommends a process-driven approach (i.e., the integration of reuse into disciplined software engineering). In addition, technology and tools will support the activities within disciplined software engineering. The goal of a domain-specific, architecture-centric, process-driven, and technology-supported approach is to provide the opportunity and infrastructure for systematic reuse to occur. Systematic reuse is manageable, repeatable, and improvable.

The SRI PMO has developed its first strategic plan, which leverages the extensive research and analysis available on reuse and software technology transfer from the Software Engineering Institute (SEI) (Carnegie-Mellon University, Pittsburgh, PA), the Software Productivity Consortium (SPC), and the experiences of Industry in change management. Elements of the plan exploit technology transfer models and mechanisms, such as addressing the supporting infrastructure for the current processes, that is, the people involved and the procedures (both documented and obvious standards, and those that are unwritten, hard wired, and default). Education, training, working groups, user interest groups, bulletin board systems for group communications, sharing lessons learned and successes are all mechanisms to reprogram the system and the people who have acquired, produced and maintained the most successful and reliable software to date. As the SRI PMO begins staffing, it will explore, produce, and distribute kits, guidelines, and other products and services designed to assist organizations and their transition to reuse.

WHAT ARE THE ISSUES?

fig -5 How to gain a return on investment (ROI)
How to get to systematic reuse
Organizational
Technical

The categories of issues that will be addressed in this section are the following:

Reuse Rationale: What are the upfront investments? How do I get a high payoff for the time, money, and effort that is spent building a reuse program? How do I avoid failure?

Reuse Management: How do I pick the right projects? What are the things I should consider before developing a reuse program? How do I bring together multiple projects into some kind of synergy? How do I get from no reuse to planned reuse?

Technology Transfer: How do I manage the change in my organization (jobs, job descriptions, new needed skills, evolving technology)? How do I tackle the attitude obstructions (e.g., "not invented here" syndrome) that will sink my project?

Support Technologies: From the perspective of system development, maintenance, and acquisition activities.

WHAT ARE THE UPFRONT INVESTMENTS?

Creating a separate group of domain engineers, performing domain analysis, and developing architectures.

Developing and maintaining asset management tools, such as repositories, for architectures, designs, documentation, and code.

Tools to aid in the integration of architecture, design, and software products to speed prototyping, full-scale development, modifications, and maintenance.

Redesigning and implementing the proposal evaluation criteria and process.

The payoff can be defined as the sum of the benefits minus the investment. The investment will be from one set of projects' funding and the benefits will be seen on future projects. This investment is excess cost to a project. It will be a rare circumstance when a single project can fund the acquisition or development and implementation of the tools and infrastructure needed to ensure success for an entire organization's transition to reuse. Costs need to be amortized over multiple projects. Mechanisms to share the cost of developing the tools and infrastructure across multiple projects should be planned for and established.

For an acquisition-oriented organization, the upfront investment will be in redesigning the current evaluation system for proposals and vendors, to incorporate criteria that will project percentage of reusability expected for a project, and to accurately capture the breadth and depth of the bidder's experience with reuse.

For development and maintenance organizations, the upfront investments will be the costs of domain engineering (which include domain analysis, architecture development and maintenance, and repository creation, population, and maintenance), tool acquisition, development, maintenance, and integration. Also, it has been reported that higher levels of testing and quality assurance are needed when reusing assets, as much as two to four times that required for fig -6 unique (in-house developed) assets. As such, the upfront investment required to accommodate this requirement would be additional tools and possibly staff to aid the testing and quality assurance phase, and appropriate schedule and budget adjustments.

Tools and technologies play an especially important role, and a necessary upfront investment, for development and maintenance organizations. For example, one of the most significant investments in technology and tools will be to support the development and maintenance of the domain analysis products, especially the architecture. This is not a widely commercialized field as yet, and what tools do exist, e.g., UNAS, are just being experimented with at this time in order to accommodate software system architectures. Another upfront investment for the development and maintenance of the domain architecture will be the establishment of procedures to execute the development and maintenance. This area is also a hot target of research, but relatively little guidance is available at this time.

Repositories are another upfront investment for development and maintenance organizations. An organization that has selected I-CASE tools to facilitate the transition to reuse may not need to create a repository, because many I-CASE tools have repositories incorporated into them. For organizations opting to develop and maintain their own repository for reusable assets, such as designs or code, automated browsing tools with sufficient sophistication must be acquired or developed to facilitate search and retrieval. After all, if the users cannot find the asset, they won't use it, and the investment in the repository has been wasted. Configuration management tools must be incorporated into asset repositories in order to trace an asset to the systems in which it was used. This type of information assists future users of an asset in deciding its appropriateness to their situation.

HOW DO I MEASURE THE RETURN ON INVESTMENT?

The benefits that will best justify an investment in a reuse program may be organization-unique (e.g., cost, productivity, quality, and reliability). Metrics, algorithms and processes must be developed and historical and current data collected to properly assess the the return on investment.

The implied requirement in the definition of payoff is the existence of measurements for the baseline (e.g., cost, productivity, reliability, quality), which must be defined, and values assigned for historical and current projects. These metrics should be chosen carefully, and the algorithms used to produce them should be examined to determine if they are able to represent the value of reuse. The metrics selected to measure the benefits of transitioning to reuse should address both process (e.g., the depth and breadth of the product-line life-cycle to which the reuse processes have been internalized within an organization) and product (e.g., the number of trouble reports (TRs) and engineering change proposals (ECPs)).

The benefits that will best justify the investment in the reuse program may be organization-unique. For example, reliability measures such as mean time between failures (MTBF), mean time to repair a defect (MTTR), and defect backlog would be especially appropriate for a system maintenance organization responsible for a weapon system. On the other hand, a system development organization would probably be better served by using cost and productivity measures. A word of caution is given for the cost and productivity metrics. Currently, cost models are not available that can treat reuse satisfactorily at the organization- rather than the project-level. In lieu of an appropriate cost model, the Ada-COCOMO should be used. This model incorporates costs for developing reusable assets and savings from reusing assets.

The measurement of high payoff, the benefit metrics, must not only provide justification for the investment but also help during a project. They should be functional enough to be used as gauges for project success. They must be economical to collect and report, and collection should be automated. Mechanisms must be established to accumulate an organizational database of historical financial data relative to software production and maintenance, including reuse activities. Compare the historical data with the newly gathered metrics data as reuse principles are incorporated into the organizations' methods and procedures. The ROI will conceptually be: (new benefit metrics data) - (investment in adopting and fig -7 internalizing the reuse procedures) - (historical benefit metrics data).

The internalization of reuse principles into an organizations' methods will evolve over time; it will proceed incrementally. Thus, the ROI seen at 12 months will be different and less than the ROI seen at 24 or 36 months. Often, the ROI is experienced on subsequent projects (further justification for the product-line approach). Several examples follow; note that as more software artifacts other than code are reused (e.g., architectures), greater benefits and returns on investment are available.

  1. Software from the Advanced Field Artillery Tactical Data System (AFATDS) Concept Evaluation Program (CEP) has been successfully reused in two AFATDS projects: the Elevated Target Acquisition System (ETAS), which experienced 68-77% code reuse; and the Forced Fusion System Prototype (FFSP), which saw 93.45% reuse. The upfront investment was the development of the initial reuse library and the purchase of some commercial, reusable components. The savings (return on investment) experienced on the FFSP project approximate $2.8 million.

  2. The Navy's Restructured Naval Tactical Data System (RNTDS) Project used two reuse economic models from the SPC to derive best and worst case results on their project. The best case was 99% reuse, with cost only 5-12% of building from scratch. The worst case was 89% reuse, with cost about 15-21% of building from scratch. Also, other benefits were observed. Error density decreased from just over 5 latent program TRs per element disclosed during Government acceptance testing in 1988 to less than 0.5 TRs in 1991. For every correction entered into their library on a specific program baseline, two other baselines have also incorporated the correction, resulting in a 3 to 1 payoff in program TR corrections. Test bed intensive activity costs (e.g., function tests) have been reduced by nearly 50%. This cost avoidance has offset the upfront investment costs of creating reusable components and a repository.

  3. TRW's UNAS project had an estimated $6 million upfront investment in performance optimization, design for reuse and portability. Using a second generation product, NAS (UNAS is the third and fourth generations), TRW saw a two-fold increase in productivity over typical C3 software developments, due to a decrease in the volume of latent software errors found in initial test configurations and a reduction in the average resolution time. Also using NAS with the COBRA DANE System Modernization (CDSM) project (an extremely responsive real-time control of a radar system), TRW experienced a 15-20% reduction in software development activity, saving 374 man-months. The software development was bid at 35% lower costs, and COBRA DANE was delivered five months early.

  4. CelsiusTech Systems AB, Scandinavia, integrates shipboard C3 and weapon control systems for ships ranging from patrol craft to frigates. The typical delivered system has a complexity of 10-30 nodes on a network, 300-800 Ada programs, and 0.8-1.5 MSLOCs. CelsiusTech required a massive upfront investment, resulting in sales figures for several years that were greater than all their competition combined.

  5. NASA Goddard Space Flight Center's Upper Atmosphere Research Satellite (UARS) Telemetry Simulator Project at the Computer Sciences Corporation found that traditionally, software reuse among telemetry simulators had been less than 20% and limited to only very low utilities. However, CSC has reused the UARS telemetry simulator in three other projects. The Extreme UltraViolet Explorer (EUVE) telemetry simulator reused 89% of UARS code as-is, and another 11% that required only minor modifications. A 67% reduction of effort was experienced in labor hours, while productivity was three times that on the original UARS telemetry simulator development project. An order of magnitude improvement in software quality was achieved with a final error rate of 0.14 errors per KSLOC. (The UARS telemetry simulator project had an error rate of 1.5 errors per KSLOC.) In the Solar, Anomalous, and Magnetospheric Particle Explorer (SAMPEX), 85% of the generic UARS telemetry simulator architecture was reused. Staff hours on the project (2,800) were even less than EUVE's (4,000), and the error rate was comparable. The WIND/POLAR telemetry simulator was very different than EUVE and SAMPEX, but still used 55% of the generic UARS telemetry simulator architecture. Schedule, effort, productivity, and quality estimates were similar to those of EUVE and SAMPEX.

WHAT ARE THE MOST COMMON FAILURES WHEN TRANSITIONING TO REUSE?

Inadequate investment.
No domain engineering group.
No reward for reuse.
No reward for architecture population.
Project-by-project reuse planning.
Any reuse is good reuse.
Technically inadequate metrics used to determine award fees.

 The most common failures are:

(1) Inadequate resources or investment. Reuse doesn't just happen. Resources must be allocated to acquire, build, maintain, manage, and upgrade domain knowledge, architectures, and support tools.

(2) Not creating support for domain engineering. Support in the form of resources, schedule, and infrastructure are needed to adequately perform domain analysis, architecture development, and to find, tailor, and develop reusable software components. And these activities are necessary while the organization is trying to get software delivered for a specific project: a separate group is recommended for domain engineering duties.

(3) Not rewarding software engineers for reusability, in both designing/developing for and designing/developing with reuse. Productivity metrics mostly address new source lines of code (SLOCs) produced, rather than delivered functionality, which deters designing/developing with reuse. For designing/developing for reuse, a good rule of thumb is that reusable assets will take twice the development effort of one-shot products. Hence, reusable products are initially more expensive, but result in cost avoidances for related products. Software reusability should be aimed at enterprise productivity across a product line of systems or families of related systems, rather than at individual or project-level productivity.

(4) No economic incentives for extra effort required for the population of architectures. Architectures represent candidate solutions for whole families of related systems within a domain. Populating these architectures entails design decisions to reflect the architecture, and developing the project's deliverables to populate the architecture. These activities incur time and costs that are not usually accounted for during the development of a project's definition and accompanying budget. In addition, legal issues, such as ownership rights, must be resolved so that contractors are incentivized to populate architectures.

(5) Project-by-project reuse planning. This is what has been typically referred to as opportunistic reuse. In order to reap the maximum benefits from reuse, consideration of reuse must be across related systems (vertical domain) and generic qualities of possibly unrelated systems (horizontal domain, perhaps across multiple vertical domains), with a hybrid approach (some vertical and some horizontal) promising the greatest rewards. The product-line approach to software acquisition, development and maintenance will provide the entre into a hybrid approach to reuse.

(6) Any reuse is good reuse. Directives to reuse any software available compete with, and eventually pummel, engineering and business objectives. Reuse must be quick, cheap, and reliable, and add value to the new project, not contaminate it. Establish reuse goals that not only complement, but actually aid the achievement of business and engineering goals.

(7) Technically inadequate metrics used to determine award fees. Contract award fees are most commonly based on the amount of software reused rather than the percentage of final delivered software that is composed of reusable software and software artifacts. This latter metric incentivizes contractors to populate both architectures and repositories.

HOW DO I AVOID FAILURE?

Reward reuse, not alternatives.
Provide leadership and resources.
Reorganize to facilitate reuse.

Management Must Do's

  1. Provide a reward mechanism to instill greater awareness of the desirability of reuse for development, maintenance, and acquisition activities.

  2. Provide proactive leadership and resources at the beginning of system development projects to encourage reuse.

  3. Change the organization to create a group whose sole job is to create reusable modules. The group will need a manager, parts producers, a configuration manager, a librarian, and a quality assurance/quality control manager.

  4. Adopt the product-line approach.

  5. Seek mechanisms for sharing reuse experiences and ideas (e.g., workshops, conferences, and working groups).

  6. To the extent feasible, provide cost-modeling tools in concert with organizational data for reuse/reusability decision assessments (including make vs. reuse vs. buy decisions). Cost models are needed to assess the ripple effects resulting from reuse at various stages of the software development process. Also, amortization schedules are needed to distribute costs over projects. This latter requirement is essential for acquisition organizations to measure and demonstrate the benefits of investing in contractor's reuse efforts.

WHAT ARE THE OBSTACLES TO SUCCESS AND HOW DO I OVERCOME THEM?

Upfront investment very high for a single project.
No defined, optimum approach to reuse.
High payoff and early success are usually mutually exclusive.
Attitudes.

There are many inhibitors to reuse. Chief among these is the upfront investment required to begin the transition to a reuse-based paradigm. The upfront investment is often too high for a single project to foster. At a glance, an acquisition-oriented organization has relatively little economic interest in making reusable the software assets of the product they are procuring. In addition, there are no incentive strategies for encouraging reuse investments. But the bottom line is this: a dollar saved on a software procurement is a dollar that can be spent on support for the warfighter. As illustrated earlier, there are organizations that adequately plan for reuse, select projects within the same domain or sub domain, and can show the returns on their investment in subsequent projects.

Another inhibitor to reuse is the fact that no strategy that defines the optimum approach to reusability is currently available. However, the product-line approach has been used in every single engineering field, and has proven successful. It promises to be the optimum approach for software reusability.

There are attitude inhibitors that can bedevil an organization. The "not invented here" syndrome is an example and can paralyze a reuse project. One of the most successful strategies to employ in tackling these attitude inhibitors is to create ownership of the change process within the ranks. Software engineers should participate in the development of policies and procedures for using assets that were not invented here. For example, they should be responsible for designing the test and verification procedures fig -8 to be used for each asset acquired from outside their organization. They should be involved in creating quality assessments of sources of reusable assets. In addition, the DOD SRI PMO is in the process of designing the technology transfer kits that will offer the PEO and PM options for addressing the issue of attitude obstructions.

Technically, there are additional inhibitors to reuse of assets other than code. For example, the reuse of design has been impeded by the lack of adequate representation technology and tools. Also, technology has not quite delivered automated aids for integrating and rippling changes throughout all the software artifacts, such as architecture, design, specifications, data models, etc. The task of systems engineering still remains very much manual in nature. However, nature abhors a vacuum, and as the software production industry evolves toward disciplined software engineering itself, this need for integrated domain and product engineering aids will be filled in the marketplace.

HOW DO I ENSURE A HIGH PAYOFF?

High payoff for the investment in transitioning to a disciplined software engineering approach incorporating reuse-based processes necessitates long-term investment.

There is great pressure for early high-payoff success stories. Undoubtedly, there exists some arena for which early high-payoff and success are not mutually exclusive. However, they are mutually exclusive for software reuse. Economic advantages will not be forthcoming for two to three years after the transition project has begun. The most important guidance within this primer might well be: Be realistic. Do not promise too much, too soon.

HOW DO I PICK THE RIGHT PROJECTS TO GET TO SYSTEMATIC REUSE?

Select projects within a distinct functional area.

Systematic reuse is planned reuse. Systematic reuse that is domain-specific, architecture-centric, process-driven, and technology-based is advocated by the SRI. Domain-specific reuse focuses reuse efforts within a distinct functional area that can be supported by a class of software systems (e.g., avionics, database management, or payroll). Domain specificity is at the heart of the DOD SRI. Projects within a domain will involve the same or similar development activities and will use similar development environments, technologies and tools.

Architecture-centric reuse prescribes that reuse efforts begin and end with the architecture (i.e., systems are developed from the architecture, and reusable assets that are developed, maintained, or acquired will populate architectures for that domain). The architectures provide the framework for solutions within a domain; that is, they can be adapted to create designs for systems within the domain, and they represent the structure of assets, their interrelationships, and the principles and guidelines governing the systems' design and evolution over time.

Process-driven reuse requires the incorporation of a disciplined software engineering approach, which will lead to systematic rather than opportunistic reuse. Technology-based reuse identifies technology as the support and facilitation mechanism to implement reuse. In addition, advances in software engineering practices and support tool evolution have more often than not complemented and catalyzed each other.

Selecting multiple projects within a particular domain is the right decision. The narrowness of the domain reduces the investment in the repository because the domain is well understood, the problem is well understood, and engineers can "get their minds around it". If a domain is too large to be managed, then it should be sectioned into subdomains. The type of domain is also important. The best type of domain is one in which the technology and the products are relatively stable, or evolving at a manageable pace. The worst domain type for reuse is one in which the underlying technology is rapidly changing (e.g., system software for PCs and workstations).

The domain serves as a minipilot project for the organizations reuse techniques. Experience is developed within a single domain. Metrics can be uniform throughout the projects and are easily compared. The domain architecture and model evolve into well-bounded, well-defined entities. As more assets are made available for reuse in the repository, the costs of development will begin to decrease for a development organization. For a maintenance organization, design rationales and implementation decisions for the systems within the domain can be evaluated and compared, and that analysis can provide the justifications for accepting or rejecting modification requests. For an acquisition organization, the proposal and vendor evaluation criteria have been tested and recalibrated, and their usefulness and veracity have been demonstrated repeatedly. They can be abstracted to provide candidate criteria for additional domains. For acquisition, development, and maintenance organizations, the domain-specific approach has a limiting effect on an organization's incorporation and internalization of reuse. It allows for an iterative, incremental adoption of reuse. This evolutionary approach has less risk associated with it than a revolutionary, "big bang" approach.

WHAT ARE THE THINGS I SHOULD CONSIDER BEFORE DEVELOPING A REUSE PROGRAM?

Size of organization and required infrastructure.
Investment to support needed infrastructure, and mechanisms to recoup investment.
Tools to facilitate the transition.

Strategic trade-off decisions need to be adequately resolved. For example, the size of the organization necessary to make the reuse transition effective needs to be decided. The organizational components that will be involved need to be identified and analyzed in terms of their ability to reorganize to achieve the necessary infrastructure. The investment to acquire, build and support the required infrastructure (e.g., architecture development and management tools, or a repository, or a process to assess reusability projections) needs to be defined, and effective mechanisms to recoup the investment should be developed. The tools that can facilitate the transition (e.g., configuration management and automated metrics collection and reporting mechanisms) should be acquired.

HOW DO I BRING TOGETHER MULTIPLE PROJECTS INTO SOME KIND OF SYNERGY?

Participate in your Agency/Service reuse planning.

Services and Agencies within the DOD are developing reuse plans which will establish the initial framework from which all reuse efforts within the organization will be coordinated. Priorities will be defined, which will dictate budgets. It is essential for PEOs and PMs to participate within this planning process.

Service and Agency reuse plans should address goals and objectives for individual reuse efforts within their organizations, and show how they relate and implement the vision, goals, and objectives of the DOD SRI. Service and Agency reuse representatives should create reporting mechanisms by which progress toward meeting the goals and objectives is measured by the results of individual reuse efforts. The coordination of multiple reuse projects within the purview of a PEO or PM should be addressed within the Service or Agency reuse plan as part of an integrated approach for transitioning to reuse.

HOW DO I GET FROM NO REUSE TO PLANNED REUSE?

Resources, enforced organizational standards, rewards for reuse and not alternatives.

The following seven steps outline the top-level strategies to create systematic reuse within an organization:

  1. Use a product-line approach to software acquisition, development and maintenance.

  2. Plan, implement, and analyze incremental efforts to adopt reuse.

  3. Treat technology transition as a project: manage it, resource it, schedule it, and measure progress.

  4. Provide fullest and best resources to developmental programmers.

  5. Establish organizational standards for design, reuse, and programming. Validate them.

  6. Enforce validated standards over whole developmental organizations.

  7. Reward reuse, not alternatives.

HOW DO I MANAGE CHANGE?

Organization knows reuse is here to stay.
Provide consistent resources.
Tailor education.

Techniques for change management have been developed and evaluated in the business community for decades (see Bibliography). The achievements in software technology transfer are based on these techniques. The following figure illustrates change as a process that organizations experience over time. Change management and technology transfer strategies can be used to manage this process and ensure successful change, that is, the adoption of new technology and, perhaps, a new organizational structure. An example of one technology transfer technique is the DOD SRI PMO plan to develop kits that will guide and assist an organization as it adopts reuse. A critical element to consider is that reuse is a multi-organization problem, and successful adoption of reuse within an organization may be intrinsically dependent on the command structure surrounding the organization, or on completely separate and autonomous organizations. This is the case of acquisition organizations dependent on contractors who will provide systems developed via newly (perhaps) transitioned reuse principles.

FIGURE 9: How People Commit To Change

Some strategies that have proven successful are: longevity, tailored education, and consistent resources. These strategies are geared to smoothing the management of the change and tackling the obstacles to change. Longevity of the program needs to be impressed on both software engineers and procurement specialists. They need to be convinced that this trend is geared toward institutionalization and not subject to sacrifice during the next budget crunch. The guarantee of longevity will provide engineers and procurement specialists with justification for generating their own ownership in the program. Different types of training should be provided for managers, developers, and domain reuse specialists. Personnel assignments should take reuse and reusability into account. Assign reuse facilitators to development groups. Be prepared to make full-time staff resources available for the start-up phase and for ongoing support of a reuse program.

WHAT ARE THE TECHNICAL ISSUES?

Associated with architectures:

Standards for representation.
Tools to assist modification of multiple structural views; automated change mechanisms.
Integration of formal and informal modeling and representation methodologies.
Associated with the reuse of assets of all types (architectures, designs, documentation, code, etc.)
Asset production and configuration management.
Asset locators.
Asset control.
Asset selectability.
Support for using assets.

Associated with acquisition:

Legal/contractual mechanisms to enforce the adoption of reuse.

Issues Associated with Architectures

The wide-spread use of architectures to guide software development is relatively new, and automated tools to assist in their development, maintenance, and modification are not commonly available. TRW's UNAS has been used successfully and is currently being investigated by the USC Center for Software Engineering for extensions to accommodate formal and non-formal architecture specifications. Research in the field of enterprise model integration may yield advances in techniques to integrate models representing varying structural views. More than likely, tools will precede standards, and organizations responsible for maintaining domain knowledge and products will be faced with the challenge of integration and translation. In addition, tools to automatically ripple changes throughout the life-cycle product line (e.g., architecture, domain model, data models, design documentation, etc.) will probably not be available for quite some time. The bottom line is that organizations attempting to develop and maintain architectures are faced with some technological support, and a good deal of manual efforts.

Issues Associated with the Reuse of Assets of All Types

System development and maintenance organizations have similar technical challenges: finding, understanding, modifying, integrating and composing assets; developing, populating, maintaining, and managing architectures; and creating and managing software artifacts such as designs and documentation. Automated tools should be selected to provide the greatest capabilities in location, selection, use, and control of the assets. Promising technologies should be identified and tools procured that give the most functionality. These tools speed development and help bring about a complete asset inventory with standardized style and structure, which facilitates maintainability, and, most of all, use of the assets. Organizations need to develop and maintain configuration management information (e.g., an automated index of all architectures and other assets released into production), and brief, precise, functional descriptions should be included. This will assist in the reuse of these assets and identify opportunities for reuse.

Issues Associated with Acquisition

A significant amount of investigation into the legal issues that surround the production, acquisition, and reuse of software products has preceded this Primer. The SRI PMO is currently developing a legal handbook, and has sponsored the development of software reuse business models to guide the acquisition process. CODSIA IRAG has developed acquisition scenarios to explore various contractual models. The CARDS program has also published informative and valuable papers on legal issues involving repositories. These sources will provide a more complete introduction and more substantial coverage of the legal issues than can this Primer. (See Bibliography.)

WHAT ARE COMMON TECHNICAL FAILURES AND HOW DO I AVOID THEM?

fig -10 (1)Inadequate configuration control of the versions of reuse assets: which assets are used in which systems? This process and associated data assists in the decision to use an asset, and in the development of data for estimating a return on the organization's investment. Establish appropriate configuration management mechanisms.

(2) Inadequate searching/browsing/lookup mechanisms. If you can't find it, you can't use it. Invest in support tools.

(3) Too little control over what is put in a library. Issues involved here are quality of assets, breadth of functionality, limiting repetition, and proper asset documentation.

(4) Including software assets that are too large and/or have too many side effects. Smaller assets are better. They have less side effects and are easier to categorize for searches. In addition, they require less overhead to maintain. However, smaller assets present their own problems. As noted by the AFATDS project, small assets create type incompatibilities requiring checks and conversions. The RNTDS project had to modify their compiler and executive systems.

(5) Undocumented interfaces. This requires that reusable asset customers break into the "black box" of the asset and determine its impacts on the project's design or its execution environment.

(6) no facility for exceptions and overrides. All or nothing reuse does not provide any cut and paste facilities. For software assets, the result is substantial amounts of "dead code" (i.e., unused source code that is compiled and bound into the executable form). This creates unnecessary overhead and deters reuse.

(7) Software overhead required to compile, link and execute the reusable module may be too great. If an asset cannot be integrated into the project attempting to use it, it won't be used.

(8) A domain cannot satisfy all of the requirements all of the time. If the scope of a domain is too broad, then all requirements cannot be captured and satisfied adequately for all systems within the domain. Hence, systems developed from too broad of a domain definition will find that requirements, such as performance, will most likely suffer.

(9) Neither top-down nor bottom-up design is adequate to capture the benefits of reuse. Domain engineering must be executed. It is often referred to as middle-out design.

(10) Support tools need to evolve. Support tools and the software acquisition, development and maintenance processes that they assist advance via complementary improvements.

CONCLUSIONS AND RECOMMENDATIONS

The Primer is just the starting point.

This Reuse Executive Primer has only scratched the surface of the subject of reuse. More study is recommended, of course, especially for legal issues that are not addressed in this paper. The SRI PMO is an excellent starting point. The SRI PMO can provide information on upcoming conferences and educational opportunities. In addition, points of contact for reuse working groups can be obtained from the SRI PMO. Products are developed by these groups that can provide invaluable help for organizations attempting to adopt reuse.

WHAT'S MY NEXT STEP?

Contact your Service/Agency reuse representative.
Develop a reuse plan.
Use the SRI PMO resources.

The next logical step is to contact your Service or Agency reuse representative (see below), determine if your organization is ready for the transition, and develop a plan for the transition using the strategies discussed in this Primer.