Led by

David Dikel (Applied Expertise, ddikel@aecorp.com)

David Kane (Applied Expertise, dkane@aecorp.com)

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. The group selected a pair of principles to flesh out using the template from a number of candidate principles.

– Managing the Rhythms of Change

– Manage Cloning to Maintain Shared Code Base

Several practices were also described as part of the principle template:

The results for 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.

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 a degree on 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. [IEEE] 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. [RPG]

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 included that they:

• Are Doable: The principle should be actionable, not just true. e.g. Alan Davis suggests that software has increasing entropy [DAVIS], 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 apply the principle in a specific contexts.

• Address Motivation: The principles need to be attributed to success. In particular the principle must address motivation at several levels, for the organization as a whole, as well as 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. e.g. a principle would try to define a tradeoff between schedule, cost and quality.

Several of the participants in the group shared existing work in the subject (see references) We then created a list of candidate principles and prioritized them. Finally we selected and fleshed out two principles using a template to systematically describe the principle and some example practices to address the principle in a specific context.

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

Principle: Definition as revised during subgroup and working group discussions

Criteria: 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: What models does the principle map to, e.g., Malcolm Baldrige, SEI Capability Maturity Model?

For each principle, there may be one or more practices that apply the principles 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 may also be additional forces specific to the practice that are resolved as well.

• 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 the both the use and the life-cycle of assets expands. Further, these changes need to managed in some sort of coordinated fashion. [FOOTE] 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 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, it can have serious consequences for an organization if uncontrolled, 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>.

The results of the working group were presented to the Reuse Steering Committee at their April 1997 meeting. They have decided to go ahead to build on this approach to further 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.

[BALDRIGE] Malcolm Baldrige National Quality Award 1997 Criteria for Performance Excellence, National Institute of Standards and Technology, 1997. Available from oqp@nist.gov.

[DAVIS] Davis, A. M., "201 Principles of Software Development, "McGraw-Hill, New York, 1995, p209.

[DIKEL] Dikel, D., and Kane, D., et al Software Architecture: Organizational Success Factors. DARPA, 1995.

[DIKEL2] Dikel, D., and Kane, D., Workshop Preparatory Materials, WISR, 1997.

[FOOTE] Foote, B., Opdyke, W., "Lifecycle and Refactoring Patterns That Support Evolution and Reuse" Pattern Languages of Program Design, Coplien, J., Schmidt, D., eds. Addison-Wesley, Reading Massachusetts, 1995, pp 239-257.

[IEEE] IEEE Software Engineering Standards Committee, Underlying Principles for IEEE Software Engineering Standards, 21 August 1996. Available from the Chair, Leonard L. Tripp, leonard.l.tripp@boeing.com.

[JABIR] Jabir, A Search for Fundamental Principles of Software Engineering: Report of a Workshop conducted at the Forum on Software Engineering Standards Issues, MontrΘal, Quebec, Canada, 21-25 October 1996 (forthcoming).

[RPG] IEEE Software Engineering Standards Committee, Reuse Planning Group, Action Plan, 17 September 1996. Available at URL: "http://www.sesc-rpg.mews.org/".

[WILSON] Wilson, J. and Dikel, D., Software Reuse Benchmarking Study: Learning from Industry and Government Leaders. Software Reuse Initiative, 1996.

Practice Name: Configuration Management for Reuse

Problem and Context: The organization has Configuration Management in place, but with a standard development approach in which only a component owner has access to the component. Reusers don’t have an efficient way of making change requests. Users cannot get change histories of components that they are using or considering. Reusers can’t get status of theirs or other change requests. Reusers start to lose confidence that components will meet their needs.

Approach to Solve Problem: Change from a traditional configuration management approach to give reusers greater access to configuration management information such as change requests, version history, etc.

Results from Approach: User community is better informed about specific reusable components. This knowledge reduces their risk to reusing components. The flow of information helps develop relationships between the component owners and reusers.

How Are the Forces Resolved: Helps manage change, which is inevitable. The approach addresses the different configuration management needs of component users and owners. The practice also reduces surprises by providing information earlier about upcoming changes Relation to Existing Work: Configuration Management literature

Practice Name: Maintain Reuse Platform Identity

Problem and Context: Executives with corporate oversight want to achieve economies of scale through reuse. Application development groups are focused on near-term deliverables, but depending on another organization increases perceived risk. A platform is being used by an initial application, and the platform team is expecting others to use it in the future. Members of the platform team have expertise that is valuable to the application team. Further, the technical staff on the platform team may have an interest in a technical area of the application. If the application shifts direction, then the platform may get subsumed by the application as it shifts to adapt to the application. The platform gets so closely associated with the application, that other application teams stay away. Alternately, the platform may get dropped by the application if it does not move with the shift, which may also keep other applications from using the platform because of the stigma of getting dropped.

Approach to Solve Problem: Establish corporate commitment and a separate organization for the platform. Use stable corporate funding to get the platform started, and then ensure stable funding from the application organizations once the platform is established. There needs to be an advocate for the platform at the corporate level The platform organization should act like a product organization to engage customers and address customer needs.

Results from Approach: If you maintain the identity of the platform, then applications are better able to have their needs met, and the value of the platform is greater because it can be used by more applications. The platform has wider applicability. If the platform identity can be maintained, then staff can move between the platform team and the application groups that use the platform can strengthen them

Criteria:

Practice Name: White box reuse with frequent and regular merging

Problem: Rapid response requires that developers have access to and ability to change source; however, the longer merges are delayed the greater the chance that the size and difficulty of merging clones back into the source grows.

Context: In a critical system with many customers, it doesn’t take too long before developers build new and complex extensions on the clones making them incompatible with the code base. As a result, code grows rapidly in size and complexity. Internal customers of reuse supplier -- External customers need to make explicit statement of synchronization There must be enough trust in developers to let them have source White box access to source is necessary to respond rapidly to multiple quick response requests from end-customers

Solution: Provide access to source, let people fix bugs, and merge regularly

Resulting Context: Code base improves in robustness, reliability, and stays upward compatible Reuse suppliers build trust with users Uses can respond quickly to customers

Related work: “Stable Base” (CM Pattern)