RSP gb toc Return Synthesis

OV.2. Fundamentals of Synthesis

Synthesis was conceived in recognition of past experience that suggested a need for a major reconception of the software process (Campbell, Faulk, and Weiss 1990) to produce improvements in software productivity, product quality, manageability, and customer responsiveness. Davis, Bersoff, and Comer (1988) present a comparison of several models of the software development life cycle, which is a good framework for understanding this need. As the foundation for an initial understanding of Synthesis, this section describes the key principles underlying the Synthesis approach, discusses the context in which Synthesis applies, and provides an overview of how Synthesis works, both in general and at the stages of reuse program implementation for which example Synthesis processes have been defined.

2.1 Key Principles

The Synthesis concept depends on four basic principles: program families, iterative processes, specifications, and abstraction-based reuse. An understanding of these principles will help you to understand Synthesis.

2.1.1 Program Families

A program family is a set of programs that are sufficiently similar that it is worthwhile to understand the common properties of the set before considering the special properties of individual instances. The concept of program families was first proposed by Dijkstra (1972) and later elaborated by Parnas (1976). Both papers argue that developers should construct software programs, not as unique artifacts, but as instances of a family of similar programs. A primary distinction of this view is in how the creation of program versions are viewed: not as successive modifications to previous versions, but as rederivations from a common abstraction. Each member of a family can be characterized entirely in terms of how it differs from the common abstraction (i.e., the variations in the family). In Synthesis, this concept of program families is generalized to a concept of product families that encompass all the work products of software development.

2.1.2 Iterative Processes

An iterative process is a process in which work products are considered complete only after repetition of producing and using activities. Each iteration is short with goals set to make progress toward an end product without unnecessary exposure to risk of failure if short-term goals are not met. In a noniterative process, an activity continues without interruption until its resulting work products are believed complete. Only after such proclaimed completion is there any attempt to use those work products in performing other activities. Although planning does not provide for rework of the results, feedback from using activities inevitably requires replanning to allow for corrections; schedule and quality are usually degraded as a result. Since many errors in software work products are difficult to discover without feedback from detailed use, an iterative process systematically produces better quality results than a process that depends on producing correct work products without such repetition. A strong discipline of work product versioning and configuration management is crucial to a successful iterative process (Humphrey 1989).

2.1.3 Specifications

A specification is a complete, precise description of the verifiable properties required of a work product or set of work products (e.g., a complete software product). For a system, a specification can serve as an abstract model that aids understanding and analysis. For expressive power, the notation in which a specification is written usually assumes an understanding of specialized terminology and constructs. Normally, a specification is either a description of requirements (i.e., the problem to be solved) or a description of a design (i.e., the form and/or content of a solution). Additionally in Synthesis, a specification may describe a product, or work product, (i.e., a problem and its solution) by resolving the variations that characterize a family of such (work) products.

This concept of specifications derives from work in both requirements specification and automatic programming. A key objective in both areas is the creation of a notation for describing a required system without unduly constraining the details of the solution. The Naval Research Laboratory Software Cost Reduction project developed an approach to precise, semi-formal specifications of software requirements for avionics systems (Heninger et al. 1978). Winograd (1979) argues the need for a new view of programming based on a descriptive (i.e., nonprescriptive) language. Balzer and Goldman (1979) describe criteria for designing and judging the quality of a specification language.

2.1.4 Abstraction-Based Reuse

The direct result of a software development project is a set of work products that describe and implement a software solution to a customer-defined problem. Abstraction-based reuse ( Campbell 1989) provides a means for representing a product family as a set of adaptable work products and for deriving instances of each work product to produce a particular system product. An adaptable work product concisely represents a family of similar work products that vary in well-defined ways. This supports the localizing of potential changes so that the cost of modification or reuse is minimized for likely changes.

The Ada generic package is a notation for representing a family of similar Ada code packages. Most word processing packages provide a "form letter" capability that can be used to represent a family of documents. Metaprogramming tools, such as TRF (TRF is a metaprogramming tool developed by Template Software, Inc.), provide a flexible notation for representing families of text-based work products. Each of these mechanisms provides a facility for producing work products from a representation of a work product family.

2.2 Context for Synthesis

In initiating a Synthesis practice, you should first consider the context in which you currently work. This context is determined by three concerns: business objectives, system engineering practices, and the objectives of a software engineering process. These concerns constrain the type of Synthesis process that an organization can adopt. Within this context, you can create a capacity for rapid, systematic delivery of similar, yet varied, systems.

2.2.1 Business Objectives

Synthesis is characterized by its focus on a family of systems for a business area rather than on individual systems. This focus arises from evidence that, within a class of systems, an understanding of similarities provides significant leverage for constructing a great variety of high-quality systems cheaply and reliably.

With Synthesis, you conceive a domain not on an objective basis, but as a realization of the declared business objectives of your specific organization. Your business objectives determine the types of systems you build and who your customers are. A primary consideration in setting these objectives is the expertise already available within your organization, particularly as a result of experience in building systems in the past. Other considerations are your expectations of future customer needs and changing technology.

The environment most conducive to the effective use of Synthesis is one in which you give emphasis to long-term business objectives. A positive climate for investment in the future, possibly at the cost of deferred-but potentially greater-total return is a major advantage for realizing success with Synthesis. It is important to consider these larger business concerns when addressing the needs of a particular customer to avoid arbitrarily sacrificing longer-term interests to short-term pressures. On the other hand, Synthesis lends itself to a management philosophy of incremental commitment, both for early pay-back after a minimum initial investment and for accommodating the changing needs of a single customer or the differing needs of many.

2.2.2 System Engineering Practices

Construction of modern, complex systems is a major undertaking that often requires the coordination of many large groups of engineers with expertise in diverse fields. Some of these groups may be organizations in separate companies, working jointly or as subcontractors, to deliver a required system. Engineers follow a discipline of system engineering, in part to partition the problem and apply appropriate expertise to solve each facet of the problem most effectively. This partitioning into subsystems often follows the lines of major hardware components, but it may also serve the purpose of decomposing the system into more manageable software assemblies.

Such partitioning is compatible with Synthesis, particularly when you are able to follow a systematic approach that results in similar partitionings of similar systems. Each software partition (or subsystem) then corresponds to a member of a family of similar subsystems (i.e., software systems) that can be the responsibility of a cohesive business organization.

2.2.3 Objectives of a Software Engineering Process

The broad purposes of a software engineering process may be stated simply:

A conventional approach to software development achieves these purposes, but not efficiently. Synthesis is motivated by the need for a systematic approach to tailoring the software engineering process to meet the specific needs of each organization. The key to achieving this end is to consider long-term business needs when developing software. Looking first at the similarities among systems that your organization builds provides a basis for you to become more productive by eliminating redundant effort. Your efforts to build a particular software system can be focused more efficiently on the aspects of that system that are distinctive. Synthesis prescribes the work that is necessary to achieve this potential.

2.3 An Overview of Synthesis

The purpose of a Synthesis process is to help you better utilize your expertise about a set of similar problems and associated solutions pertinent to your business area. By viewing similar problems as a family, common characteristics provide leverage in building any particular system. Similarities support a form of standardization that enables systematic adaptation to meet the specific needs of a particular customer. The results of standardized decision making by project engineers guide appropriate adaptations of standardized, reusable work products.

The primary distinguishing features of a Synthesis process are:

The degree to which a Synthesis process actually exhibits these features depends on the needs and abilities of the adopting organization. As a general rule, these are goals that guide the formulation of a Synthesis process but they may be moderated to formulate a process that suits each organization's circumstances.

Regardless of your specific circumstances, a Synthesis process is one which is designed to support two independent but interrelated objectives:

To address these separate concerns most effectively, a Synthesis process consists of two integrated subprocesses: Application Engineering and Domain Engineering. Figure OV.2-1 A Synthesis Process shows how these processes relate to each other.

Application Engineering (described further in Section AE of Parts OP and LV) is a standardized process by which projects produce and deliver applications to customers. In terms of objectives, this is the equivalent of conventional, "one-of-a-kind" software development. Both conventional and Synthesis approaches start with customer requirements and produce a set of software work products that are meant to satisfy those requirements. However, in a Synthesis approach, through a process of Domain Engineering (described further in Section DE of Parts OP and LV), you can institute a simpler, more efficient process of software development and support it with standardized, reusable work products.

Whether Application Engineering is a series of analysis, design, implementation, and testing activities or creating and validating a model to generate a required application, it focuses on requirements and engineering decisions that are sufficient to describe a particular system, given a family of such systems. Work products, including code and documentation, are mechanically derived from these decisions using adaptable forms of those work products provided by Domain Engineering.

Domain Engineering supports Application Engineering in two ways. First, it creates a set of adaptable work products that correspond to the work products that an application engineering project must produce. By identifying key decisions that are deferred until a particular system is needed and parameterizing a work product to show how it varies as a result of those decisions, Domain Engineering creates work products that are adaptable to subsequent Application Engineering decisions. Second, Domain Engineering describes a standard Application Engineering process that supports the decision making and the work-product creation appropriate to projects in the business area. The process definition institutes standard procedures and practices which Domain Engineering may augment with appropriate automated support.

Domain Engineering and Application Engineering are iterative processes to attain quality products and to support evolving needs. Application Engineering must accommodate uncertain and changing customer requirements. Domain Engineering must accommodate changing markets, as well as the evolving product and process needs of client application engineering projects.

2.3.1 Defining a Tailored Process

To adopt a reuse process (such as a Synthesis process), you need to identify one that suits your organization's needs and abilities for reuse. A key element of reuse adoption is to understand the nature and extent of your organization's current needs and capacity for reuse and develop a plan for improvements in your reuse capability. The Consortium's Reuse Capability Model (RCM), described in the Reuse Adoption Guidebook (Software Productivity Consortium 1992c), is a mechanism for this purpose.

The RCM provides a framework for deriving a definition of a reuse process that matches your organization's circumstances. Every Synthesis process embodies the same basic principles. However, each can differ based on the degree to which the adopting organization chooses to commit to the various success factors for improved reuse capability that the RCM defines. Success factors are grouped into four categories, reflecting different perspectives on reuse that are important to an organization:

As noted in describing the distinguishing features of a Synthesis process (at the start of Section 2.3), the form of any specific process depends not just on those features but on the needs and abilities of the adopting organization as well. An organization with unlimited abilities could adopt a Synthesis process that exhibited those features clearly; a more limited organization would adopt a process that did not require all of the abilities that these features require. A Synthesis process as a whole is affected by management factors and process and technology factors of the RCM. The Application Engineering process is further affected by application development factors. The Domain Engineering process is further affected by asset development factors. By considering the needs and abilities of your organization with respect to each of the RCM success factors, you can design a process suited to that organization. As a guide to incrementally improving your organization's reuse capability and the implementing process, the RCM includes an implementation model consisting of four stages through which an organization's reuse practice can evolve from an initial, ad hoc reliance on the initiative of individual engineers:

An organization may progress incrementally through these stages of implementation for lower risk or it may commit directly to the adoption of a more advanced stage to get corresponding benefits sooner.

Part OP of this guidebook describes a Synthesis process that is oriented to the opportunistic stage of reuse implementation. Part LV describes a Synthesis process that is oriented to the leveraged stage. Other Synthesis processeses could be defined at the integrated or anticipating stage. Depending on your organization's circumstances concerning reuse, you are likely to prefer one of these processes over the others. Any such process definition, however, is best viewed as a prototype from which you should derive a process that is tailored to your specific circumstances. The remainder of this section characterizes the RCM and Synthesis processes in relation to each of the RCM's four implementation stages.

The two Synthesis processes described in this guidebook are appropriate to organizations that are targeting either the opportunistic or the leveraged stage of implementation. Each process has been designed to reflect the assumptions and limitations appropriate to the targeted stage of instituting a reuse program. For example, at the opportunistic stage, application engineers find and evaluate reusable components specifically for each work product. At the leveraged stage, reuse by application engineers is indirect in terms of requirements-level variations and leads implicitly to integrated reuse across the work products that constitute the product. This difference is traceable to success factors identified respectively with these stages in the RCM. Sections 1.3.2 through 1.3.5 describe the success factors that guide the design of a Synthesis process appropriate to a particular RCM stage of implementation.

2.3.2 An Opportunistic Synthesis Process

Your organization can adopt an opportunistic Synthesis process if it is targeting a new state of practice similar to the following:

At the opportunistic stage of implementation, the Application Engineering process is organized and managed in a conventional manner. The emphasis is still on the development of "one-of-a-kind" systems and the phased completion and review of corresponding deliverable work products. For example, DOD-STD-2167A ( Department of Defense 1988) has traditionally been interpreted as a "waterfall" model, leading through a series of phases, such as software requirements analysis, preliminary design, and detailed design. An opportunistic reuse process has the following implications for an organization:

An opportunistic reuse process is one in which reuse efforts are oriented entirely to supporting the current needs of a business group's active (and imminent) application engineering projects. An opportunistic Synthesis process is directed toward increasing the opportunities for effective reuse without causing significant changes in the application development process already familiar to managers and engineers.

In opportunistic Synthesis, a project follows its normal process (similar to that of Figure OV.2-2 A Simple Example of an Application Engineering Process for Opportunistic Reuse , which was derived following Evolutionary Spiral Process [ESP] guidance), changed only by the addition of general, low-level guidelines for individual engineers to find and exploit relevant reusable assets. Domain Engineering ( Figure OV.2-3 A Domain Engineering Process for Opportunistic Reuse ) is an attempt to identify, organize, and improve assets from previously built systems (a key element of domain knowledge) so that those assets will be useful in satisfying engineers' current needs. Because Application Engineering, at this stage of reuse program implementation, emphasizes the direct creation of documents and code, Domain Management focuses Domain Engineering efforts on opportunities for standardizing the form and content of particular work products. The domain engineer identifies sets of similar work products, defines each set's common and varying features, and uses those features to represent the set as a family from which application engineers can extract instances.

2.3.3 An Integrated Synthesis Process

Your organization can adopt an integrated Synthesis process if it is targeting a new state of practice similar to the following:

At the integrated stage of implementation, the advantages of leveraged effort compete with the immediate concerns of individual projects. Solution approaches that can build on existing assets are preferred over unique, single-use solutions. The long-term needs of the business organization influence decisions on the near-term use of resources. Although application projects may still have to perform one-of-a-kind effort, it is easier to distinguish essential from arbitrary product variations.

Application Engineering and Domain Engineering processes typical of an integrated Synthesis practice have not yet been defined.

2.3.4 A Leveraged Synthesis Process

Your organization can adopt a leveraged Synthesis process if it is targeting a new state of practice similar to the following:

At the leveraged stage of implementation, the Application Engineering process is organized and managed in a standardized way based on the nature of the business as determined by Domain Engineering. The emphasis is on producing and delivering systems that meet the needs of customers; however, only systems that fit the strategic charter of the organization are initiated. This process has the following implications for an organization:

A leveraged Synthesis process is one in which strategic business needs, tempered by past project experience and current project needs, define a domain that motivates reuse as a vehicle for achieving long-term organizational objectives. A separate application engineering project is instituted to serve each customer having a problem judged to be within the domain.

In a leveraged Synthesis process, projects follow a standardized, reuse-driven process (e.g., like the one shown in Figure OV.2-4 A Prototypical Application Engineering Process for Leveraged Reuse ) that results from an analysis by Domain Engineering of how projects can operate most effectively doing family-oriented reuse ( Figure OV.2-5 A Domain Engineering Process for Leveraged Reuse ). At the leveraged stage of implementation, Domain Management focuses Domain Engineering efforts on the adaptable standardization of the process and products of Application Engineering to improve the life-cycle productivity of the total software development enterprise. The deliverable work products of each Application Engineering project are mechanically derived from an Application Model and domain-specific adaptable specifications, designs, and implementations, resulting in a tailored, integrated software product. At this stage, the concept of a reuse library is subsumed into a broader framework of process support.

2.3.5 An Anticipating Synthesis Process

Your organization can adopt an anticipating Synthesis process if it is targeting a new state of practice similar to the following:

At the anticipating stage of implementation, the emphasis is on anticipating and creating a market for an organization's product line. The focus of investment is on predicting future market needs and creating assets that will serve those needs. Application projects are sought that not only exploit existing capabilities but also provide opportunities for enhancing those capabilities. Application projects are seen as a means to apply the knowledge and expertise embodied in a domain to problems that can benefit from this knowledge and expertise.

Application Engineering and Domain Engineering processes typical of an anticipating Synthesis practice have not yet been defined.