Reuse-driven Software Processes Guidebook
Reuse-driven Software Processes Guidebook
Synthesis is a methodology for constructing software systems as instances of a family of systems that have similar descriptions ( Campbell, Faulk, and Weiss 1990). This guidebook provides an introduction to the practice of the Synthesis methodology of software development. To the degree that you understand the essential similarities and variations in the systems you build, Synthesis enables you to exploit those similarities to eliminate redundant work. A mature organization will be able to satisfy the needs of its customers by answering the questions that are left open because of variations.
Synthesis focuses on your need both to deliver high quality products to customers and to accomplish this profitably. To this end, a Synthesis process consists of two subprocesses: Application Engineering and Domain Engineering. Application Engineering is how a group (or project) in your organization creates a product to meet customer requirements. Domain Engineering is how your organization improves productivity by creating a product family and a supporting Application Engineering process, tailored for projects in your business area. The details of these subprocesses will differ depending on the capabilities of your organization to practice reuse effectively.
Since projects in the same business area tend to build systems that satisfy similar needs, these systems can be thought of as instances of a family. A family of systems is a basis for a flexible approach to standardization that can accommodate diverse and changing needs. A business area whose objectives are fulfilled by a family is a domain. Both the mission of an organization and the changing needs of its customers determine the objectives of that business-area organization (i.e., product line). Synthesis is a comprehensive, business-area-level solution to problems of software productivity, product quality, manageability, and responsiveness in the building of systems to meet diverse and changing needs. Synthesis is a systematic approach to software development founded on the belief that the resources of a business-area organization should be managed not only to meet the immediate needs of customers, but also as an investment in future capability.
This guidebook describes two instances of a Synthesis family of processes, one that is opportunistic in character, the other that is leveraged. The opportunistic process is oriented toward organizations having modest reuse needs and capabilities. The leveraged process is oriented toward organizations that can make a greater commitment to reuse and that have more advanced needs and capabilities.
This guidebook defines Synthesis, a sound approach for effective family-oriented software development. It serves as a detailed guide to the practice of Synthesis and helps you begin to practice it. As you gain experience in practicing Synthesis, you will be able to refine and modify this guidance to meet the specific needs of your organization more effectively.
The scope of this guidebook includes all activities and work products related to production of software and support of the needs and objectives of a business-area organization and its customers. Synthesis activity is initiated, via a Reuse Adoption process ( Software Productivity Consortium 1992c), with the establishment of organizational business objectives for a domain. In addition, various Synthesis activities require you to standardize management, requirements, design, implementation, and verification and validation practices throughout your organization. Synthesis is an integrating framework for the methods you choose to standardize your practices. Detailed descriptions of particular methods are generally outside the scope of this guidebook. Such descriptions are available to you, often in other Consortium publications that are referenced, where appropriate, throughout this guidebook. Standardization of these activities in terms of purpose and technique, using methods of your choice, is essential to an effective Synthesis practice.
The audience for this guidebook includes business-area managers, project managers, and engineers of all disciplines who work together to accomplish the objectives of a business-area organization. Readers should be knowledgeable and experienced in the standard (or prevailing) software development methods used in their organization, but are assumed to have no experience with Synthesis. Practical use of this release of the guidebook requires the participation of knowledgeable technologists. Pilot projects are a requisite first step in transitioning to production use.
Release of this guidebook ends the third year of a multiyear effort to develop a guidebook for a family of Synthesis software processes for use by business-area organizations. This guidebook describes the family, in overview, and two representative processes, in detail. The first of these processes is opportunistic in character and assumes a low degree of organizational reuse capability and commitment; the second process is oriented to leveraged reuse and assumes a moderately high degree of reuse capability and commitment. Either process may be adopted as-is or tailored to fit the particular needs and capabilities of your organization.
This guidebook is a revision of the Synthesis Guidebook ( Software Productivity Consortium 1991a) and its successor, the Domain Engineering Guidebook ( Software Productivity Consortium 1992a). The current name was chosen because the guidebook covers the entire software life-cycle process for a domain, comprising Application Engineering as well as Domain Engineering. Major extensions in this version include an expanded characterization of the Synthesis process family, better integration with work on the Evolutionary Spiral Process (ESP) Model ( Software Productivity Consortium 1992b), additional and improved activity descriptions, and improved examples.
Publication of this guidebook follows 4 years of work (by 1993) on Synthesis at the Consortium. The Consortium has delivered a continuing series of other work products that describe various aspects of Synthesis. Information about Synthesis is evolving as experience accumulates from pilot projects. Recently delivered work products include:
Several recent publications are of interest, not only with respect to Synthesis but for reuse in general:
In this Web-based view, the information is organized into four parts. The first part is an overview of the Synthesis methodology and associated family of processes. It includes:
This introduction defines standard notations and conventions used throughout all parts.
The second and third parts represent adaptations of the Synthesis process for levels of reuse maturity. Opportunistic Reuse (OP) and Leveraged Reuse (LV) are each complete guidebooks for a particular Synthesis process. Part OP describes an opportunistic Synthesis process. Part LV describes a leveraged Synthesis process. Each of these parts presently consists of four sections with the fourth section, Advanced Topics, reserved for future use.
An Overview section provides a brief description of the applicable Synthesis process as a whole.
A Domain Engineering section defines the activities you follow to standardize the process, work products, and practices of Application Engineering for a business-area organization. The activities of Domain Engineering are organized and presented hierarchically:
This hierarchy reflects a grouping based on the knowledge and expertise needed to perform each activity, rather than the order in which activities may be performed. A description of an aggregate activity is primarily a summarization and roadmap to its subactivities. Each aggregate activity, as well as each of its subactivities, is described in its own section. Each activity is described according to the outline:
Activity Description Outline
- Getting Started. Describe when the activity is relevant and can be performed.
- Objectives: Explain the objectives that you should achieve in the performance of this activity.
- Required information: Describe baselined Synthesis work products or other information upon which some or all of the steps of this activity depend.
- Required knowledge and experience: Describe business-area, domain, and general software knowledge and experience you need to effectively accomplish the required tasks of this activity.
- Product Description. Describe the work product that results from completion of the activity.
- Purpose: Describe what is accomplished by producing this work product.
- Content: Describe the information content of this work product.
- Form and structure: Describe the structure of the work product and the form in which its content is to be presented.
- Verification criteria: Describe how the consistency/completeness, correctness, and quality of the work product will be judged. Provide review questions and metrics that support that evaluation.
- Process Description. Describe a process that achieves the objectives of the activity.
- Activities/Steps: Describe the actions, with associated inputs and results, that are required to accomplish the objectives of the activity. Suggest heuristics for performing each step more effectively.
- Risk management: Identify risks that may arise to prevent successful, timely completion of the activity, and describe strategies for mitigating those risks. Use checkpoints, reviews, and metrics to reveal flaws and misconceptions.
- Interactions With Other Activities. Describe interactions that may occur with other activities as a result of using a work product:
- Describe feedback to the activities that provide required information to this activity.
- Describe feedback from other activities concerning the adequacy to them of this activity's work product. Describe how those interactions stimulate product evolution. For each potential problem, describe:
- Contingency: The nature of the problem that may be found in the use of a work product.
- Source: The activity that provides/uses the work product of concern.
- Response: The appropriate, alternative responses within this activity to the contingency.
- Advanced Topics. (Reserved for future use only.) Provide guidance on complex aspects of this activity in short, topical discussions. More expansive papers appear in the Advanced Topics section. Discusses tailoring to particular needs and the use of alternative, immature, but potentially more robust approaches.
An Application Engineering section defines a prototypical process, activities, and work products for Application Engineering. A primary objective of Domain Engineering is to refine this definition to satisfy the needs and objectives of supported projects. Each activity of Application Engineering is described according to the outline shown above.
An Advanced Topics section is reserved for future use in presenting discussions of issues requiring advanced understanding of Synthesis. The emphasis of such discussions will be on the refinement of a Synthesis process and its guidebook description to meet particular needs.
The last part contains a collection of reference material including:
This version of the guidebook is intended as a reference for practicing managers and engineers. The guidance can also be tailored to reflect an organization's standard and prevailing software development methods. As a rule, detailed sections are meant to be sufficiently complete for full-scale use. For smaller, more exploratory pilot projects, you may decide to expend less effort on activities related to management, process definition, or opportunities for automation; however, no activities should be skipped entirely.
The guidebook is also organized for use as a graduated introduction to Synthesis. A reading of Section 2 in this Part and Sections DE and AE (in either Part OP or Part LV as appropriate) is sufficient to gain a basic understanding of the concepts of Synthesis. The activity hierarchy shown above serves as a guide to which sections you should read for a deeper understanding of particular aspects of Domain Engineering. You may choose to skip sections lower in the hierarchy when more detail is not of interest. This hierarchy is valid for both Part OP and Part LV.
Activity descriptions in the Domain Engineering and Application Engineering sections are not cookbook recipes on how to perform Synthesis. The Synthesis process family is a sophisticated approach to help solve a complex problem in partially understood domains where the experienced engineer must use judgement and intuition to properly interpret Synthesis for his or her given situation. The process diagrams found within this guidebook are intended to aid the reader's understanding of Synthesis. The process diagrams are not meant to be formal and complete process models. Instead, these diagrams depict only those entities and relationships important to the overall spirit of Synthesis. Other aspects of Synthesis have been suppressed where they were considered to be irrelevant to the point of the supported text. Hence, a process diagram's purpose is to depict:
Conversely, the process diagrams do not show:
Iteration within an activity and between other Synthesis activities is determined by the management method. Iteration is only indicated in the top-level process diagram A Synthesis Process (Described in Fundamentals of Synthesis) to suggest evolution of the domain as as whole.
Partial examples of work products are sometimes presented in the text to illustrate the form and content of individual Synthesis work products. These examples contain fragments of Domain Engineering work products drawn from the Traffic Light Control Software System (TLC) domain. A TLC system controls and coordinates the operation of traffic lights at a given intersection.
This guidebook uses the following typographic conventions (In the Web-based version, some of the typographic attributes are not universally available):
In this guidebook, figures that depict a process diagram use the following symbols:
Work product examples in this guidebook use a metaprogramming notation to represent variability in a product. Variability in a product means that a product will have different content, depending on certain critical decisions. A metaprogramming notation allows you to describe how a product's content is determined by those decisions. A simple example of this is the use of a macro processor to defer a decision about the size of a data structure. Instead of making the decision on the size of the structure when the code is written (by embedding a constant), you can defer the decision by setting parameters for (parameterizing) the code and supplying the required value at compile time. A metaprogramming notation is an extension of this idea.
Boldfaced, bracketed text is used for metaprogramming notation in this guidebook:
A body is any text that may be a part of some work product. A body may also contain nested metaprogramming constructs; if so, those constructs must be evaluated to determine the content of the body.
