INCOSE MBSE Initiative Survey of Model-Based Systems Engineering (MBSE) Methodologies Jeff A. Estefan Jet Propulsion Laboratory California Institute of Technology Pasadena, California, U.S.A. [email protected] 1. Introduction 1.1 Purpose The purpose of this report is to provide a cursory description of some of the leading Model- Based Systems Engineering (MBSE) methodologies used in industry today. It is intended that the material described herein provides a direct response to the INCOSE MBSE Roadmap element for a “Catalog of MBSE lifecycle methodologies” [1]. In this report, a methodology is defined as a collection of related processes, methods, and tools [2]. A MBSE methodology can be characterized as the collection of related processes, methods, and tools used to support the discipline of systems engineering in a “model- based” or “model-driven” context. The intent of this survey is to educate the reader about the various candidate MBSE methodologies that are commercially available as well as the control- and state-based MBSE methodology that has been developed at NASA’s Jet Propulsion Laboratory (JPL), which has been published in the open literature. 1.2 Scope This memo describes the result of a MBSE methodology survey only; it is not a methodology assessment. The material contained herein is expected to be reviewed and shared by the INCOSE MBSE Initiative team and its governing leaders. It should be noted that this is a cursory survey and only the top-level synopses of each candidate methodology is described. Detailed descriptions of each can be found in the cited references. While it is recognized that modern day systems are not only gaining in overall complexity, they are also becoming more software intensive. Nevertheless, the scope of this survey report is on MBSE methodologies from the holistic, lifecycle wide systems engineering perspective and not specifically targeted toward embedded systems or software-intensive systems in general. There are some notable model-based methodologies that focus on embedded and software-intensive systems such as the Embedded Computer System Analysis and Modeling (ECSAM) methodology from Lavi and Kudish [3],[4] and Model-Based [System] Architecture and Software Engineering (MBASE) from Boehm and Port [5],[6]; however, these methodologies are not described herein. The interested reader can review the cited references at the end of this report for more information on these methodologies. In future revisions of this survey, the scope may expand to include model-based methodologies for embedded and software-intensive systems in addition to mainstream MBSE methodologies. As will be described, tools are an important element of any MBSE methodology; however, a survey of MBSE tools is beyond the scope of this report. It is expected that during an Survey of Candidate Model-Based Engineering (MBSE) Methodologies Page 1 of 70 Rev. B May 23, 2008 INCOSE MBSE Initiative INCOSE MBSE Initiative organization’s candidate MBSE methodology assessment process (including impact to native processes and procedures), a tool survey and assessment will occur concurrently or shortly thereafter, followed by selection and piloting of relevant tools. This latter effort requires participation from the organization’s systems engineering practitioner community because that is the community that will most heavily be using the tools. It is intended that this report be a living document and updated on a periodic basis based on feedback and input by not only members of the INCOSE MBSE Initiative team but also by members of the INCOSE community at large. 1.3 Overview This report is organized as follows: Section 2 characterizes the difference between methodologies and processes, methods, and lifecycle models (development, acquisition, and systems engineering). Also described is the role of models in the systems engineering process and the seminal work by Wymore on the mathematical foundation of MBSE. Section 3 documents the survey results of leading MBSE methodologies used in industry. Section 4 describes the role of the Object Management Group™ (OMG™) Unified Modeling Language™ (UML ®) and Systems Modeling Language™ (OMG SysML™), which are industry- standard, visual modeling languages used to support the disciplines of software and systems engineering, and how these modeling standards relate to MBSE methodologies. Section 5 discusses the role of OMG™ Model-Driven Architecture ® (MDA ®) to the discipline of systems engineering. In addition, the Executable UML Foundation is briefly introduced. Section 6 provides a list of references used in preparation of this survey report and for the benefit of the reader. Finally, Section 7 provides a list of acronyms and abbreviations used in this report. 2. Differentiating Methodologies from Processes, Methods, and Lifecycle Models In order to better understand key features of the various leading MBSE methodologies surveyed in this study, it is critically important to establish the terminology associated with processes, methods, and methodology, and to acknowledge the myriad lifecycle models used in the acquisition and development of large-scale, complex systems. Without such grounding, it will be extremely difficult to map any assessment and selection of candidate MBSE methodologies into the fabric of the systems engineering environment within a particular organization. 2.1 Process, Method, Tool, Methodology, and Environment Defined The word methodology is often erroneously considered synonymous with the word process . For purposes of this study, the following definitions from Martin [2] are used to distinguish methodology from process, methods, and tools: A Process (P) is a logical sequence of tasks performed to achieve a particular objective. A process defines “WHAT” is to be done, without specifying “HOW” each task is performed. The structure of a process provides several levels of aggregation to allow analysis and definition to be done at various levels of detail to support different decision-making needs. A Method (M) consists of techniques for performing a task, in other words, it defines the “HOW” of each task. (In this context, the words “method,” “technique,” “practice,” and “procedure” are often used interchangeably.) At any level, process Survey of Candidate Model-Based Engineering (MBSE) Methodologies Page 2 of 70 Rev. B May 23, 2008 INCOSE MBSE Initiative INCOSE MBSE Initiative tasks are performed using methods. However, each method is also a process itself, with a sequence of tasks to be performed for that particular method. In other words, the “HOW” at one level of abstraction becomes the “WHAT” at the next lower level. A Tool (T) is an instrument that, when applied to a particular method, can enhance the efficiency of the task; provided it is applied properly and by somebody with proper skills and training. The purpose of a tool should be to facilitate the accomplishment of the “HOWs.” In a broader sense, a tool enhances the “WHAT” and the “HOW.” Most tools used to support systems engineering are computer- or software-based, which also known as Computer Aided Engineering (CAE) tools. Based on these definitions, a methodology can be defined as a collection of related processes, methods, and tools. A methodology is essentially a “recipe” and can be thought of as the application of related processes, methods, and tools to a class of problems that all have something in common [7]. Associated with the above definitions for process, methods (and methodology), and tools is environment. An Environment (E) consists of the surroundings, the external objects, conditions, or factors that influence the actions of an object, individual person or group [2]. These conditions can be social, cultural, personal, physical, organizational, or functional. The purpose of a project environment should be to integrate and support the use of the tools and methods used on that project. An environment thus enables (or disables) the “WHAT” and the “HOW.” A visual graphic that depicts the relationship between the so-called “PMTE” elements (Process, Methods, Tools, and Environment) is illustrated in Figure 2-1 along with the effects of technology and people on the PMTE elements. Figure 2-1. The PMTE Elements and Effects of Technology and People. As stated by Martin [2], the capabilities and limitations of technology must be considered when developing a systems engineering development environment. This argument extends, of course, to an MBSE environment. Technology should not be used “just for the sake of technology.” Technology can either help or hinder systems engineering efforts. Similarly, when choosing the right mix of PMTE elements, one must consider the knowledge , skills and abilities (KSA) of the people involved [2]. When new PMTE elements are used, often the KSAs of the people must be enhanced through special training and special assignments. Survey of Candidate Model-Based Engineering (MBSE) Methodologies Page 3 of 70 Rev. B May 23, 2008 INCOSE MBSE Initiative INCOSE MBSE Initiative 2.2 Lifecycle Development Models A number of lifecycle development models have been created and applied to large-scale system and software development projects used in government, industry, and academia, but most are grounded in one of three seminal models. These are 1) Royce’s Waterfall Model [8], Boehm’s Spiral Model [9], and Forsberg and Moog’s “Vee” Model [10],[11]. A graphical depiction of each of these lifecycle development models is shown in Figure 2-2. There are large volumes of literature that describe each of these models; therefore, elaboration of each will not be provided here. Suffice it to say that variations of the waterfall and spiral models to support structured as well as iterative and incremental development have been used extensively in software development projects, while the “Vee” model and modified versions of the “Vee” have been applied extensively in the areas of systems engineering and systems development. In addition to recognizing that such major lifecycle development models exist, they can also serve as metamodels for lifecycle development. In other words, they provide the lifecycle development templates on which project- or domain-specific plans are built.