Opportunistic Synthesis
Opportunistic Synthesis
This part of the guidebook presents an opportunistic RSP process. This is a process suitable for an organization that has achieved the goals associated with the opportunistic stage of reuse capability, as defined by the RCM. To help you understand whether an opportunistic process suits your organization, this section discusses the assumptions that underlie the process and the nature of software development when using the process.
The RCM defines four stages of reuse capability implementation and characterizes each stage by a set of goals. The opportunistic RSP process described in this part of the guidebook was designed to fit the goals associated with the opportunistic stage as described in the Fundamentals section of the overview to this guidebook (Section OV.2). To adopt this process, an organization will have targeted those goals as a minimum, rather than the more ambitious goals associated with other stages. Your organization may choose to adopt the opportunistic process even if it has the potential to attain goals associated with more advanced stages of reuse capability implementation. However, this process does not depend upon nor require your organization to attain any of the more ambitious goals associated with more advanced stages.
The goals associated with the opportunistic stage introduce requirements for a process to be used by organizations targeting that stage. The RSP process described in this part of the guidebook is one example of a process that an organization targeting the opportunistic stage could adopt. It differs from other such processes because it reflects assumptions about an organization's circumstances that extend those implied by the RCM goals for the opportunistic stage. Section 2.3 in Part Syn of the guidebook describes characteristics common to all RSP processes, particularly that the process comprises iteratively cooperating Domain Engineering and Application Engineering subprocesses. Additional assumptions that distinguish the opportunistic RSP process are as follows:
In other words, domain and application engineers understand existing problems and solutions in the domain. Generally speaking, domain engineers do not have to create new ways to describe problems and solutions. They only need to document them, codifying their intuitions, common sense, and day-to-day practices. They can assume application engineers understand problems similarly and know how to make appropriate use of existing solutions.
This assumption improves the viability of a domain, independent of reuse stage. Domain engineers can rely entirely on their knowledge and experience, but detailed analyses of previously-developed work products can provide increased insight and ground the result in reality. Existing work products provide raw material from which a reuse library can be derived, with more confidence and less effort than original development provides.
Second, domain engineers sometimes reengineer existing work products to satisfy new needs. Strictly speaking, reengineering does not occur in a pure opportunistic process, where domain engineers only take advantage of existing opportunities-i.e., existing work products. The pure opportunistic process limits reuse to needs of past application engineering projects. This approach is undesirable if domain engineers perceive greater opportunity by satisfying new needs, they should provide a solution to those needs.
This assumption provides domain engineers with a strong focus. Their examination of existing material and the goals they set for reuse are tied to one project, not to an entire organization or to anticipated projects (a consideration at later stages of reuse capability). Also, this assumption helps justify having the current project directly fund Domain Engineering work in the early stages of reuse program implementation.
This section is a general overview of the opportunistic RSP process presented in this part of the guidebook. It gives an overall feel for software development and management as practiced by an organization with opportunistic reuse capabilities, without elaborating every activity or every possible variation or interpretation of the process. As Figure OV.2-1 in Part Syn depicts, Domain Engineering and Application Engineering activities, and the interactions between them, are defining aspects of any RSP process. This section describes this opportunistic RSP process from three perspectives:
This section concludes with a brief scenario of how Domain Engineering and an Application Engineering project interact.
In opportunistic reuse, an organization's strategy is to leverage reusable assets as best it can with minimal investment. Reuse at the opportunistic stage is not a key business-area strategy but rather an opportunity exploited on a project-by-project basis. The business organization may allocate limited initial funding, but in general would like to operate in a "pay-as-you-go" mode: each increment of investment in reuse, whether from organization or project funds, should result in a payoff for a specific project (against which direct costs are charged and justified).
This business/management orientation motivates how RSP is interpreted for the opportunistic context. As always with RSP, Domain Engineering exists to support Application Engineering. However, in the opportunistic process, Domain Engineering focuses on current needs. The current needs are defined by the application engineering project targeted for support by Domain Engineering. However, the organization can expect Domain Engineering products to be useful on other application engineering projects that are building applications in the same domain.
The first time an organization practices RSP, it may have to expend preliminary effort, beyond current project needs, to get up to speed. Once a domain exists, there are reusable assets that future projects can use as well. Each time an organization begins a new project, it considers focusing Domain Engineering on that project. The domain engineering project revises existing domain work products to reflect any differing needs of this new application engineering project. As the project proceeds, Domain Engineering adds and revises reusable assets to correspond to the current concept of the commonalities and variabilities among systems in the domain and their associated work products.
At the opportunistic stage of reuse program implementation, the current project shares a framework of process and work products with past projects. This framework links the reuse program's success to the individual application engineer's ability to take advantage of reuse opportunities as he builds each work product.
Application Engineering follows its organization's normal process, probably similar to the waterfall-like process depicted in Figure OV-1. (Figure OV-2 depicts a blowup of the activities of the Software Components Families Development box.) However, whenever Domain Engineering has provided reusable assets associated with a particular type of work product, the application engineer has the ability (and responsibility) to evaluate and exploit opportunities for reuse in creating that work product. Such reuse can leverage existing work products of the same type, either in their structure, in the content of portions, or in their entirety. In any case, the application engineer will likely have to tailor the resulting draft work product for it to meet fully the precise needs of the current project. Whenever the engineer is unable to create the entire work product through reuse, he still has the ability to work conventionally to create the appropriate final work product.
In opportunistic reuse, the goal of Domain Engineering is to support reuse by an application engineering project in a way that minimizes an application engineer's effort to discover whether reuse is feasible. Domain Engineering adopts a narrow focus on each work product that application engineers have to create. By analyzing the commonalities and variabilities of a work product type that has been produced by previous projects, domain engineers can focus the attention of the Application Engineering to those work products and aspects of each that are most likely to yield effective reuse.
To have sufficient context, Domain Engineering works on supporting reuse for a work product just prior to the planned Application Engineering activity for producing it. Domain Engineering uses work products and other information from preceding phases of Application Engineering to determine which reusable assets are most likely to fulfill the needs of the next phase. Ideally, the past is a perfect predictor of the future, and assets of past projects fit perfectly with the current project. In practice, application engineers will need assistance in making the correct match and adjustments between need and available reusable assets.
Where the predicted needs for the current project only partly match existing domain assets, domain management must decide whether original work is justified. When the current project has a need that is different from previous projects, the need may be unique to that project or it may indicate an important new need of all future projects. As a rule, until a need can be clearly characterized as a common need, it remains outside the scope of further Domain Engineering consideration. In opportunistic reuse, there must be an expectation of future recurring uses to justify a reuse-oriented investment. Application engineers must handle whatever custom development is necessary to address any needs perceived as unique to their project. However, when a similar need arises for a subsequent project, there is then a foundation of existing application work products from which Domain Engineering can create reusable assets and enhance the domain.
Even when common needs clearly exist, Domain Engineering is not obligated to provide reusable assets for every work product of Application Engineering. The domain's resources must be intelligently allocated to work products that offer the most potential benefit from reuse. Domain engineers work with particular work products based on the following criteria:
Consider the hypothetical process in Figure OV-1. Domain Engineering supports the reuse of three types of work products: requirements documents, design documents, and computer software units. Application Engineering begins with software systems engineering, establishing the system requirements and system design. During software systems engineering, Domain Engineering creates a Domain Definition, a general description of the domain scope, and Process Requirements, a description of the expected process and work products of Application Engineering. The Domain Definition identifies existing systems that are in the domain and available to Domain Engineering as sources of raw material. Normally, a new project continues a line of business that the organization has been pursuing; this presumption is the basis for intuitive expectations for reuse opportunities.
As the project progresses through the Application Engineering process producing work products, the application engineers look for opportunities to reuse existing work products, in whole or in part. In order to make reuse attempts for particular work products more effective, Domain Engineering attempts to organize, improve, combine, and document existing work products of that type. In this example, Domain Engineering has determined that software requirements documents, software design documents, and software components offer the best opportunities for reuse by the current project. As a result, domain engineers focus their efforts on enhancing the reusability of those work products and helping application engineers recognize and exploit them as opportunities arise.
Application Engineering benefits from opportunistic RSP because Domain Engineering identifies and provides potentially reusable existing assets based on perceived needs of the current project. This focus makes the likelihood of reuse greater than if Domain Engineering populated the library with arbitrary components. Because the organization expects more business in the domain, it anticipates that this effort will benefit future projects as well.
