[ Up ] [ PISA ] [ Composition/Integration ] [ Domain Eng. ] [ Product Lines ] [ Certification ] [ Early Artifacts ] [ OO & DA ] [ Org. Principles ] [ Add. Info. ] [ References ]

Working Group Summary

The working group discussed organizational principles that can guide the adoption and management of reuse efforts, and used a template-based approach to describe the principles and associated exemplary practices. To better understand the scope of the subject, the group identified characteristics of principles. From a number of candidate principles, the group selected a pair to flesh out using the chosen template:

• Managing the Rhythms of Change
• Manage Cloning to Maintain Shared Code Base

Several practices were also described in conjunction with the principles:

• Configuration Management for Reuse
• Maintain Reuse Platform Identity
• White Box Reuse With Frequent and Regular Merging

The results of the working group were presented to the IEEE Reuse Steering Committee, which is chartered to define principles for software reuse. Participants also used the results within their own organizations, and the work may also be submitted to a patterns conference.

Introduction

The Organizational Principles for Software Reuse group was formed to take an initial cut at defining principles for software reuse to be submitted to the IEEE Reuse Steering Committee. The group focused on organizational principles because of the recognition that the primary obstacles to software reuse are organizational as opposed to technical. These concerns need to be addressed with insight and precision. The group adapted and used a template to do this. The group’s work in principles was intended to contribute to other efforts in the software engineering standards community that are identifying and articulating fundamental principles of software engineering as a means of unifying the corpus of software engineering practice standards [IEEE96]. Specifically, the Reuse Planning Group of the IEEE Computer Society Software Engineering Standards Committee (SESC) recommended initiating a standards effort to write a document providing principles of reuse [RPG96].

What Are Principles?

The group identified the boundaries of the discussion, i.e., what was and was not appropriate for a discussion of software reuse principles. The characteristics of the principles for our discussion were that they:

• Are Doable: The principle should be actionable, not just true. For example, Alan Davis suggests that software has increasing entropy [Davis95]. While this may be true, it is not actionable, and would not be a principle for the purposes of the working group’s discussion.
• Pertain to Reuse: The group recognized that there are many prerequisites to reuse. The group distinguished between those characteristics that are:
• Only needed if reuse is a goal.
• Desirable in general, but are more difficult to achieve when reuse is a goal.
• Desirable in general, and where the goal of achieving reuse does not necessarily add difficulty.
• Specify What Is To Be Done: The principle suggests what an organization is to do, but without specifying how the organization is to do it.
• Are Relatively Context Insensitive: The principles should be broadly applicable. Applying a principle requires a context, and so there may be practices that describe how to apply the principle in a specific context.
• Address Motivation: The principles need to promote success. In particular the principle must address motivation at several levels for the organization as a whole, as well as for individuals at several levels.
• Have Explanatory Power: The principles provide a model that makes sense of our experience. If the model does not match this experience, it will likely be rejected.
• Do Not Make Tradeoffs: The principles may describe priorities from which tradeoffs are made, but do not include the tradeoffs themselves, because that would rob the organization applying the tradeoff of making the choice. For example, a principle would try to define a tradeoff among schedule, cost and quality.

Approach

Several of the participants in the group shared existing work in the area (see references). We then created a list of candidate principles and prioritized them. Finally, we selected and fleshed out two principles. We used a template to systematically describe the principle together with some example practices illustrating it in specific contexts.

The following template was used to describe the principles. For each principle, the group identified:

Principle: The definition, as revised during subgroup and working group discussions.

Criteria: The top three ways to measure the extent to which the principle is practiced, rules of thumb, measures, etc.

Consequences: What happens when the principle is practiced or not practiced?

Warning Signs: What are the leading indicators that the principle is not being practiced?

Forces: What forces does the principle counteract?

Models: To what models does the principle map, e.g., Malcolm Baldrige, SEI Capability Maturity Model?

For each principle, there may be one or more practices that apply the principle in a specific context. For each practice the template includes:

Problem and context: What is the problem and its specific context?

Solution: What approach should be applied to address the problem?

Results from the approach: What positive results have been achieved from applying the solution?

How are the forces resolved: How are the forces that characterize the principle resolved? There also may be additional forces specific to the practice that are resolved as well.

Principle Overview

• Managing the Rhythms of Change: One of the constants of software engineering is the presence of change. When organizations undertake software reuse, the need to manage change grows because both the use and the life cycle of assets expands. Further, these changes need to be managed in a coordinated fashion [FO95]. The group identified example practices to implement this principle in specific situations:
• Configuration Management for Reuse
• Maintain Reuse Platform Identity
• Manage Cloning to Maintain Shared Code Base: Cloning is a process in which a component that provides a particular set of capabilities is duplicated and modified to provide a new capability, and maintained by the new owner. While cloning is a form of software reuse, if uncontrolled it can have serious consequences for an organization, because the cloned software results in additional code to maintain. The group identified an example practice to implement this principle in a specific situation:
• White Box Reuse With Frequent and Regular Merging

The complete templates of these principles and practices can be found at http://www.aecorp.com/ae/wisr.

Next Steps

The results of the working group were presented to the Reuse Steering Committee at its April 1997 meeting. The committee has decided to build on this approach to defining principles for software reuse. Project Authorization Request is being drafted to establish the principles document as an IEEE Recommended Practice. The next working group session is planned to occur at the Reuse ’97 workshop in July.

The results of the working group have also contributed to the work of the participants, including the development of a software reuse guide and a software architecture benchmark. A paper derived from this work may also be submitted to a patterns conference.

[ Up ] [ PISA ] [ Composition/Integration ] [ Domain Eng. ] [ Product Lines ] [ Certification ] [ Early Artifacts ] [ OO & DA ] [ Org. Principles ] [ Add. Info. ] [ References ]