Leveraged Synthesis
Leveraged Synthesis
This part of the guidebook presents a leveraged RSP process. This is a process suitable for an organization that has targeted the goals associated with the leveraged stage of reuse capability, as defined by the RCM. To help you understand whether a leveraged 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 leveraged RSP process described in this part of the guidebook was designed to fit the goals associated with the leveraged stage as described in the Fundamentals section of the overview to this guidebook (Section OV.2). To adopt this process, an organization must have targeted those goals as a minimum. Your organization may choose to adopt the leveraged process even if it has the potential to attain goals associated with the more advanced anticipating stage 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 the anticipating stage.
The goals associated with the leveraged 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 leveraged 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 leveraged 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 leveraged RSP process are as follows:
This section is a general overview of the leveraged 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 leveraged 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 leveraged RSP process from three perspectives:
This section concludes with a brief scenario of how Domain Engineering and Application Engineering might typically work and interact.
In leveraged RSP, a business-area organization sets explicit, long-term objectives that direct capital investment in process and product standardization. The scope of this investment is a family of systems that represents the strategic focus of the organization. This scope indicates the organization's market, or customer base, where it expects to find its future business opportunities. Reuse at the leveraged stage is a key mechanism for attaining strategic business-area or organizational mission objectives.
Within this framework, a domain is the organizational vehicle for all domain-specific software development which includes both Domain Engineering and Application Engineering efforts (see Figure OV-1). Domain Engineering focuses on developing, instituting, and evolving effective process/product standardization suited to the needs of the business. Client application engineering projects are formed in the domain whenever appropriate opportunities arise to build systems that fall within the domain's scope. As the organization recognizes changing customer needs or technology, Domain Engineering evolves the domain to reflect those changes.
The benefit of this approach is higher application engineering productivity, accompanied by more predictable schedules and costs, more consistent quality in the product, and more rapid responses to diverse and changing customer needs. Domain Engineering funding will usually come from a combination of organizational capital and client project receipts. The guiding principle is systematic investment in process/product standardization as a means to leverage expertise and increase productivity in the delivery of systems to customers. Investments that promise long-term leverage are generally to be preferred over short-term profits.
Application Engineering under leveraged RSP is more similar to a prototyping process than to a conventional software development process, but is oriented nonetheless to producing production-quality products. Application engineers express customer requirements in the form of a unified model of a problem and its solution. This model allows application engineers to express the decisions that they must make, which correspond to supported variations in systems within the domain's scope. The resulting Application Model is a medium for evaluating the corresponding software product and for mechanically generating associated work products, including code and documentation, using reusable components. As requirements are better understood or change, the application engineers modify the Application Model, reevaluate it, and generate a revised product.
The goal of Domain Engineering under leveraged RSP is to provide application engineering projects with a capability both to create an accurate model of any product that is within the designated scope of the domain and to generate a valid software system product consisting of all required work products corresponding to the model. Domain Engineering accomplishes this goal through concurrent process and product family engineering for the domain in accordance with specified domain objectives. Additionally, this goal requires continual evolution of the domain as customer requirements and technology change. The challenge is to manage and accomplish this evolution in a timely and systematic fashion. Although existing systems are a valuable source of reusable components particularly when a domain is first being established or expanded, in leveraged RSP, the ability to evolve the domain rapidly as needs change is key to the long-term success of the business.
As an example, consider a hypothetical process where a business-area organization has established a domain for one of its business lines. The organization initiates Domain Engineering to formalize the domain in light of the organization's business objectives and its past experience building systems for this business. The organization chooses the domain engineering staff to include some of the most experienced managers and engineers in the organization so that the resulting, concurrently-engineered process and product family standardization will reflect the best available knowledge and expertise about the problems to be solved and how valid solutions are created. Domain Engineering rapidly proceeds through several iterations in which they achieve a consensus on the scope, commonalities, and variabilities of the domain, the decisions that application engineers must make to build any particular system, the requirements, design, and implementation of the supported product family, and the preferred Application Engineering process and its automated support. The resulting Application Engineering Process Support, including reusable assets, documentation, and automation, is baselined for subsequent use by client application engineering projects.
When a customer is found who needs a system that fits within the scope of the domain, the organization forms an application engineering project. The project manager and lead engineer have been assisting in Domain Engineering and understand the needed system in domain-specific terms. Domain Engineering dedicates some of its project support staff to assist the project in using the domain most effectively. From customer information and discussions, Application Engineering creates an Application Model that seems to correspond to what the customer needs. Application Engineering evaluates the model and explains it to the customer. Based on this interaction, Application Engineering discovers inaccuracies and revises the model. A software product is then generated. Based on reviews and exploratory use of the product, Application Engineering discovers additional shortcomings, leading to further revision of the model and generation of a modified product.
In evaluating the model or generated product, Application Engineering discovers a need that cannot be properly modeled. In consultation with Domain Engineering, they decide that the need is in fact within the proper scope of the domain and work starts on evolving the domain accordingly. In the meantime, Application Engineering completes the model and generates a product that approximates a solution to the understood need. Based on discussions with the customer, Application Engineering finds a workaround that achieves some of the unmet need and extends the model and product accordingly. When Domain Engineering has completed the agreed-upon domain evolution, Application Engineering again revises the model, using the added capability that is now available, to create an enhanced solution for the customer.
As the organization initiates new application engineering projects or as the needs of existing client projects change, Domain Engineering revises its consensus on the scope and substance of the domain. Each revision results in a new baseline of Application Engineering Process Support for use by application engineering projects. This evolution continues until the domain is no longer a viable business base.
