The Product Line Business Model

Abstract

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. The paper will compare and contract the government's and industry's business model for software acquisition and engineering.

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

1 Background

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 the 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 - processes, methods and tools - 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. 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 3 below). Furthermore, the qualities of products built from these models are well-understood and predictable before the products are produced.

The CARDS Tri-Lifecycle Software Engineering model [1,2,27] (illustrated in the next page), reflects three types of engineering activities during the acquisition and life cycle development and maintenance of software intensive systems: Enterprise Engineering (DoDD 8020.1 [7,8], and DoDD 8320.1 [8,9]), Domain Engineering (DoDD 3405.1 [23]), and Application Engineering (guided by MIL-STD 498) [13]. 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. There are numerous Domain Engineering methods and processes. The primary domain analysis methods (primary because of their validation/applications on various efforts and associated publications) include: Organization Domain Modeling (ODM) [17], a well defined and comprehensive method; Domain Analysis and Design Process (DADP) [DISA], a well defined object-oriented method; the SEI Feature Oriented Domain Analysis (FODA) [18] method, considered to be a mature methodology; SPC's Synthesis [24]; and the ARPA Domain Specific Software Architecture (DSSA, aka: the ADAGE ) [19]process, which is heavily tool supported.

2 Domain Engineering Business Models

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 paper will present and analyze a taxonomy of domain engineering approaches: Opportunitistic, Systematic and Product Lines (Optimized).

* 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)

* Systematic (is intentionally focussed on multiple applications for multiple customers, and seeks to leverage all software lifecycle artifacts)

* Product line (is likewise focussed on multiple customers and applications, but is guided by market analyses and associated business plans)

* Hybrid (reflects the practices closest to "real life." )

The figures below illustrating the TriLife Cycle for Product Lines, will be extended and described for the three categories described above.

References

[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 1996.

[3] Maymir-Ducharme, F.A., "Variant Domain Engineering Approaches," proceedings of the World International Software Reuse (WISR`95) Workshop, July 1995.

[4] Software Reuse Initiative (SRI), Reuse Methodology Fusion Framework (RMFF), Technical Report, 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] Department of Defense, Technical Architecture Framework for Information Management (TAFIM) Version 2.0, Defense Information Systems Agency, Center for Architecture, June 1994

[7] The DoD Enterprise Model, Volume I: Strategic Activity and Data Models, Office of the Secretary of Defense, ASD (C3I), January 1994.

[8] 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.

[9] Information Management Program, DoD Directive 8000.1, October 1992.

[10] DoD Data Administration, DoD Directive 8320.1, September 1991.

[11] Data Element Standardization Procedures, DoD 8320.1-M-1, January 1993.

[12] Federal Information Processing Standard (FIPS) Publication (PUB) 183, Integration Definition for Function Modeling, December 1993.

[13] FIPS 184, Integration Definition for Information Modeling, December 1993.

[14] The Reuse-Oriented Software Evaluation (ROSE) Process Model, Version 0.5, DRAFT, Electronic Systems Center, Air Force Systems Command, July 1993.

[15] Software Development and Documentation, MIL-STD 498, December 1994.

[16] Draft Guidebook for MIL-STD 498, January 1995.

[17] IEEE Standard for Developing Software Life Cycle Processes, IEEE Computer Society, IEEE STD 1074-1991, January 1992.

[18] Simos, M, ARPA STARS Organization Domain Modeling (ODM) Guidebook Version 1.0 March 1995

[19] SEI Feature Oriented Domain Analysis (FODA), see http://www.sei.cmu.edu/technology/mbse/

[20] ARPA Domain Specific Software Architectures (DSSA) Program, see http://www.isi.edu/software-sciences/dssa.html

[21] Software Reuse Business Model (SRBM) Technical Report, DoD Software Reuse Initiative, January 1995.

[22] Engineer's Handbook, Comprehensive Approach for Reusable Defense Software (CARDS), February 1994.

[23] Software Management, Informal Working Draft, DoD Directive 3405.1, November 1994.

[24] Glossary of Software Reuse Terms, Department of Commerce, National Institute of Standards and Technology (NIST), December 1994

[25] Synthesis, A Reuse-Based Software Development Methodology, Process Guide, Version 1.0, Software Productivity Consortium, October 1992.

[26] DoD Software Reuse Initiative (SRI) Vision and Strategy, Department of Defense, Defense Information Systems Agency, April 1995.

[27] Maymir-Ducharme, F, Svoboda, F "Translating Enterprise Models into Domain Engineering Workproducts," proceedings of Reuse'96, Morgantown, July 1996.

[28] Maymir-Ducharme, F, Krut, R "Varying Domain Engineering Approaches -- Business Case Perspectives," proceedings of Reuse'96, Morgantown, July 1996.

[29] Maymir-Ducharme, F, Svoboda, F, et al, "ACES, an Object Oriented application of the CARDS Tri-LifeCycle Engineering Paradigm," to be published at the Software Technology Conference (STC'97), April 1997.