![]()
|
8. Organizational Principles For Software Reuse[The unabridged version of this report is also available.] Moderators:
Participants:
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:
Several practices were also described in conjunction with the principles:
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.
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 groups 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].
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:
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.
The complete templates of these principles and practices can be
found at
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.
|
![]() |