Fred A. Maymir-Ducharme, PhD
USAF CARDS Program
Lockheed Martin
9255 Wellington Road
Manassas, VA 20110
Tel: (703) 367-1590
Fax: (703) 367-1076
Email:
fredmd@cards.com
The position represented in this paper is that there exist different business models for domain engineering. The paper distinguishes between opportunistic, systematic, and product line (optimized) domain engineering approaches and presents the associated business models through organizational economic profiles. This work is based on a number of CARDS Partnership efforts and workshop / working group meetings. The premise that there are economic justifications and rationales for opportunistic, as well as systematic domain engineering stems from lessons learned from the CARDS/SBIS Partnership and was represented at WISR'95 [3]. The CARDS Tri-LifeCycle model was developed as a result of the SRI RMFF [1] SBIS [24] and AMC-HQ [26]. And the subsequent taxonomy of domain engineering approaches was presented as a tutorial at Reuse'96 [2] and extended by the workshop working group [25].
Keywords: Reuse Technology (Concepts, Methods, Processes and Tools), Enterprise Modeling, Domain Engineering, Domain Analysis, Domain Design, Software Architectures, Application Engineering, Business Analysis, Tri-Lifecycle Software Engineering
The US Air Force (USAF) Comprehensive Approach to Reusable Defense Software (CARDS) Program is chartered to support the advancement of software reuse technology and its transition to US Department of Defense (DoD). In support of he DoD's efforts to reduce the spiraling cost of software development and maintenance, the CARDS Partnership program has demonstrated its skills in the use of the wide variety of software methods used by the DoD community to manage and engineer both the problem space (e.g., domain models capturing the requirements of similar/related systems) and the solution space (e.g., architecture/design models from which to develop designs exploiting the commonalities and engineered to support the variances across systems in the domain). The CARDS/SRI partnership was developed to capture and leverage CARDS' understanding of the varied software engineering paradigms [[arrowhorizex]] processes, methods and tools [[arrowhorizex]] and experience in making reuse work in practice.
The way we engineer our systems is continuously changing and improving. We can no longer treat each new project as a single, new and independent development effort and not build on previous engineering efforts and experience. Instead we need to view these systems within the context of similar systems built in the past, exploiting the commonalities and engineering the appropriate variances. Additionally, we must leverage off existing reusable assets and develop new ones with reuse in mind. Reuse is an integral part of a disciplined software engineering practice, which is continuously improving its technology/asset base and processes. In order to meet today's software challenge (e.g., increasing demand, complexity and size), we need new ways of fusing together information about what assets exist and need to be woven into the processes used to guide our engineering activities. Various software engineering methods, processes and tools exist to help take advantage of available information about data, process and software assets needed to make the engineering decisions governing the quality of the products that evolve as a consequence of their mechanization.
Disjoint engineering efforts (i.e., Information Engineering, Domain Engineering and Application Engineering) result in engineering process stovepipes. Each engineering level develops models representing the associated requirements. Each engineering practice designs a solution (sometimes captured by an architecture or design). And each engineering practice then implements/develops their products. The challenge is to fuse these engineering methods (and thereby their work products) to eliminate redundancies, inconsistencies and other anomalies. The goal is to define and implement a disciplined software engineering practice that assures that the workproducts and standards produced any phase of the lifecycle are consistent and coordinated with the workproducts and standards of all associated lifecycle phases. For example, data models developed during the enterprise modeling phases must feed into the appropriate domain engineering and application engineering phases; and reciprocally, provide feedback to the enterprise efforts when the data models need to be modified or extended. Applications developed individually without considering common and/or related systems in the domain result in stovepipe systems / applications. Likewise, domains engineered without considering the broader enterprise (e.g., common data elements, business functions, the need to interoperate, etc.), can result in stovepipe domains.
Mature engineering disciplines support clear separation of routine problem solving from R&D. These disciplines have publicly-held, experience based, and formally transmitted technology bases that include product models (e.g., designs, specifications, performance ranges) and practice models (tools and techniques to apply to the product models) (See figure below). Furthermore, the qualities of products built from these models are well-understood and predictable before the products are produced.
The state-of-the-practice of software engineering is not yet at this level of maturity. Instead of basing new development on a technology base of well-understood models, current software engineering practice tends to start each new application development from scratch with the specification of requirements, and moves directly into the design and implementation. By contrast, this effort's vision of a mature software engineering discipline, as illustrated in the figure above, relies on a technology base of reusable assets and clearly separates routine systems development (i.e., application engineering) from development of the domain-specific technology base (i.e., domain engineering). This separation highlights the need and significance of developing reusable corporate assets including requirements, models, architectures, processes, and components. The application engineering function can then focus on validating and using this technology base, instead of beginning with a blank sheet. In addition to creating the initial set of domain assets, domain engineering processes will continue to add and enhance the technology base according to the requirements associated with application engineering
The CARDS Tri-Lifecycle Software Engineering model [1,2,3,25,26] (illustrated in the following figure), reflects three types of engineering activities during the acquisition and life cycle development and maintenance of software intensive systems: Enterprise Engineering (DoDD 8020.1 [6,7], and DoDD 8320.1 [9]), Domain Engineering (DoDD 3405.1 [20]), and Application Engineering (guided by MIL-STD 498) [12]. Due to the complexity of engineering all of the systems within the enterprise, as well as the numerous methodologies available for each engineering area, it is likely that information will be lost, regenerated, or not seen as relevant to previous or succeeding activities -- thereby causing redundant work efforts, data and function anomalies, and higher development and maintenance costs. This lack of coordination and communication across processes has been coined "stovepipe processes" and is analogous to the systems stovepipes dilemma, where systems fail to leverage common data and the necessary interoperability. Approaching the problem with planning oversight of all three activities ensures that information flows from one activity to the next.
The CARDS team has investigated, tailored and applied various domain engineering approaches. In working with various DoD Services and Agencies to select and apply domain engineering technology (concepts, processes, methods and tools), the team has become aware of the economic drivers in selecting a domain engineering approach. After the approach is selected, the next steps include selecting and integrating the appropriate method(s) and tool(s). The following taxonomy reflects the different approaches to domain engineering that we have been exposed to and/or have worked on:
* Ad-Hoc (reflects an individual's personal efforts in considering prior or future related work)
* Opportunistic (is predominantly applied on single applications and typically solely developed for a single/specific customer)
*This approach leverages the commonality and availability of existing assets -- assets may be found commercially, within an internal repository, or within a public reuse repository/library
* Systematic (is intentionally focussed on multiple applications for multiple customers, and seeks to leverage all software lifecycle artifacts)
* This approach exploits the commonalities accross similar/common or related systems and engineers as needed tio support the variations accross applications and environments/platforms.
* Product line (is likewise focussed on multiple customers and applications, but is guided by market analyses and associated business plans)
* This approach is very market driven. Using economic techniques such as Pareto Analysis, product line analysts select the minimal set of requirements/capabilities needed to support the needs of the largest portion of consumers. The product line can be viewed as an Optimized systematic approach, guided/constrained by the orgainization's business model and market analyses.
* Hybrid (reflects the practices closest to "real life." )
The Opportunistic Domain Engineering approach is solely interested in the development of a single system; hence Enterprise Enginieering is not relevant -- nor economically rational. Similarly, if the organization is only contracted to develop a single application, the associated business model makes it unreasonable (and sometimes contractually illegal) to absorb the expense/cost (i.e., additional time and resources) to take additional systems or maintenance into consideration. The domain engineering emphasis is on domain analysis, which is used to identify common requirements from similar systems previously developed that may provide reuse opportunities. The resulting opportunity analysis report identifies potential components for consideration (an existing software architecture for a similar system is an extension of this analysis). The typical design approach is then to derive a design that maximizes the use of the most and/or largest components retrieved.
The Systematic Domain Engineering approach differs from the opportunistic in various ways. For one, reuseable software components are not considered until the domain design phase, in which the domain specific software architecture is complete. The architecture identifies the components, along with the associated connections/interfaces, constraints and rationales. The architecture is use to efficiently select (and qualify) components (e.g., COTS & GOTS) that meet both, the requirements and the design constraints. The architecture is also used to develop the components that are not otherwise available. As previously stated, the architecture is defined and engineered to exploit the commonalities as well as to support the variations across the common or related systems within the domain. The domain takes into consideration existing (past), current (present) and anticipated (future) systems. Maintenance is implicit within the systematic and product line models; this is further supported by the architecture.
The Product Line Domain Engineering approach is very similar to the systematic approach. The major difference is in the use of economic analyses and focus on specific market(s). The market analysis done concommitantly with the domain analysis is used to select the optimal domain requirements identified to meet the business needs / model of the organization. Instead of soliciting requirements, the product line application engineering phase elicits requirements from the list of those previously selected and supported. Individual products are configured from the architecture, which is then built from existing components (either generated from specifications or composed from existing software assets) instead of being implemented.
The Reuse'96 working group extended the domain engineering approaches taxonomy, adding ad-hoc and hybrid and identified various organizational and application/project - specific attributes that play a role in the selection and application of a specific domain engineering approaches. [28 ]. One of the more enlightening conclusions of the team can be summarized by the following bullets comparing the emphasis and results of the various domain engineering approaches:
* Domain Analysis: (Analyzes and captures requirements) : The Opportunistic approach uses the results as part of the Solution Space. The Systematic and Product Line approaches limit the results to represent the Problem Space.
* Domain Design: (Engineers the design components, connections, constraints and associated rationales) : The Opportunistic approach is "Best Fit" and Available; the Solution Space is limited to a Single System/App. The Systematic approach is very Theoretical; the Solution Space encompasses the Past, Present and Future Systems. The Product Lineapproach is very Practical; the Solution Space is strictly constrained by "the Now," which is very temporal and market-driven.
* Domain Implementation: (The resulting product(s)) : The Opportunistic approach Results in a single System/Application. The Systematic and Product Line approaches Result in Product Space.
[1] Maymir-Ducharme, F.A., Haddad, L., "A Framework for Integrating Reuse Methods" Software Technology Conference (STC '96) Proceedings, April 1996.
[2] Maymir-Ducharme, F.A., Webb, S.M., "Multiple Perspectives on Domain Engineering Tutorial," Reuse'96, Morgantown WV, July 96.
[3] Maymir-Ducharme, F.A., "Variant Domain Engineering Approaches," (WISR`95).
[4] Software Reuse Initiative (SRI), Reuse Methodology Fusion Framework (RMFF), TR, Comprehensive Approach to Reusable Defense Software (CARDS), Informal Technical Report, STARS-VC-U001/004/00, 1996.
[5] Software Reengineering Assessment Handbook, JLC-HDBK-SRAH, 1994.
[6] The DoD Enterprise Model, Volume I: Strategic Activity and Data Models, Office of the Secretary of Defense, ASD (C3I), January 1994.
[7] The DoD Enterprise Model, Volume II: Using the DoD Enterprise Model, A Strategic View of Change in DoD, A White Paper, Office of the Secretary of Defense, ASD (C3I), January 1994.
[8] Information Management Program, DoD Directive 8000.1, October 1992.
[9] DoD Data Administration, DoD Directive 8320.1, September 1991.
[10] Federal Information Processing Standard (FIPS) Publication (PUB) 183, Integration Definition for Function Modeling, December 1993.
[11] The Reuse-Oriented Software Evaluation (ROSE) Process Model, Version 0.5, DRAFT, Electronic Systems Center, Air Force Systems Command, July 1993.
[12] Software Development and Documentation, MIL-STD 498, December 1994.
[13] Draft Guidebook for MIL-STD 498, Jan. 1995.
[14] IEEE Standard for Developing Software Life Cycle Processes, IEEE Computer Society, IEEE STD 1074-1991, January 1992.
[15] Simos, M, ARPA STARS Organization Domain Modeling (ODM) Guidebook V1.0 March 1995
[16] SEI Feature Oriented Domain Analysis (FODA), http://www.sei.cmu.edu/technology/mbse/
[17] ARPA Domain Specific Software Architectures (DSSA) Program, see http://www.isi.edu/software-sciences/dssa.html
[18] Software Reuse Business Model (SRBM) Technical Report, DoD Software Reuse Initiative, January 1995.
[19] Engineer's Handbook, (CARDS), February 1994.
[20] Software Management, Informal Working Draft, DoD Directive 3405.1, November 1994.
[21] Glossary of Software Reuse Terms, Department of Commerce, National Institute of Standards and Technology (NIST), December 1994
[22] Synthesis,A Reuse-Based Software Development Methodology, Process Guide, V1.0, Software Productivity Consortium, Oct 1992.
[23] DoD Software Reuse Initiative (SRI) Vision and Strategy, Department of Defense, Defense Information Systems Agency, April 1995.
[24] Maymir-Ducharme, F, Svoboda, F "Translating Enterprise Models into Domain Engineering Workproducts," proceedings of Reuse'96, Morgantown, July 1996.
[25] Maymir-Ducharme, F, Krut, R "Varying Domain Engineering Approaches -- Business Case Perspectives," proceedings of Reuse'96, Morgantown, July 1996.
[26] Maymir-Ducharme, F, Svoboda, F, et al, "ACES, an Object Oriented application of the CARDS Tri-LifeCycle Engineering Paradigm," to be published (STC'97), April 1997.
[27] DISA, "Domain Engineering Process" V2.0, April 95