This blog, and a subsequent blog entitled “Developing A Model-Based Systems Engineering Capability That Meets the Needs of Your Organization” are outgrowths from discussions concerning Model-Based Systems Engineering (MBSE) and requirements engineering that occurred within the Requirements Working Group (RWG) sessions during International Council of Systems Engineering (INCOSE) International Workshop (IW) 2016 in Torrance, CA.
The intent of these blogs is to remove some of the confusion that surrounds MBSE by presenting an alternative, data-centric view of MBSE, as opposed to the current model-centric view. A data-centric view provides a better framework within which to acquire a practical understanding of the Systems Engineering (SE) lifecycle development processes from the perspective of not only models, but all artifacts that are generated from activities conducted during each of the SE development lifecycle processes and the data used to represent these artifacts.
This blog series on MBSE is broken up into several parts:
- In this first part of the series, I discuss the need for MBSE and discuss the multitude of artifacts generated as part of the system engineering process as we progress through the various system development lifecycle stages.
- In the second part of this series, I go into what a model is, MBSE from the current model-based perspective, and the benefits of MBSE.
- In the third part of this series, I explore the need to transition to a data-centric perspective and propose an alternate definition for MBSE from a data-centric perspective vs the current model-based perspective.
The Need for MBSE: Meeting the challenges of increasingly complex systems
As stated in the INCOSE Vision 2025 (INCOSE 2007), a constant throughout the evolution of systems engineering “is an ever-increasing complexity of systems which can be observed in terms of the number of system functions, components, and interfaces and their non-linear interactions and emergent properties. Each of these indicators of complexity has increased dramatically over the last fifty years, and will continue to increase due to the capabilities that stakeholders are demanding and the advancement in technologies that enable these capabilities.”
An example of system complexity is the Boeing 787 (Malone et al 2016). For the 787, over 30 companies based in countries around the world built large portions of the airplane. To help manage this complex system, Boeing developed a model that had over 50,000,000 objects, with an average of three relationships per object! Furthermore, there are ~1,000 geographically dispersed users involved in this modeling effort.
ISO/IEC/IEEE 15288:2015, Systems and software engineering—System life cycle processes (ISO 15288 2015) defines the following lifecycle stages: conception, development, production, utilization, support and retirement. The International Council of Systems Engineering (INCOSE) SE Handbook, expands these six stages into thirty lifecycle processes grouped into four broad areas: technical process, technical management processes, agreement processes, and organizational project-enabling processes.
Each of these processes have inputs, activities, controls, enablers, and outputs. The inputs, controls, and enablers for any given process are outputs of the activities of other processes, some internal to a project/organization and some extremal. For purposes of this paper, the outputs of any process are referred to generically as “artifacts”. These artifacts may be represented in a “hard copy” printed form (documents, drawings, diagrams, etc.) or in an electronic form (documents, drawings, diagrams, databases, models, spreadsheets, etc.) The electronic forms of these artifacts are represented by “data” and stored in a data repository.
These processes are frequently executed by different disciplines and organizations across the various system development lifecycles, often resulting in “stovepipes” within the developing organization and especially between external organizations. For current and future systems with increasingly complexity, there are several major challenges that need to be addressed:
- The need to manage the large number of artifacts and datasets that represents these artifacts electronically, rather than in printed documents, diagrams, or drawings.
- The need to remove “stovepipes” and integrate artifacts, datasets across disciplines, organizations, and system development lifecycles.
- The need to capture, manage, and access all system and project/program management data and their associated interrelationships
- The need to identify and manage dependencies across not only disciplines and system development lifecycles, but dependencies across the system architecture.
- The need to identify, define, and manage interactions (interfaces) between parts of the system architecture, no matter the complexity of the system under development.
- The need to track progress, identify at risk activities, and take actions before these risks become problems that could impact cost, schedule, or being able to deliver a product that meets stakeholder needs in the operational environment.
- The need to transition from a “gut” decision-making culture to a data-driven decision culture that is more effective and appropriate for managing current and future complex systems. Data-driven decisions are not only driven by data but are recorded within the MBSE tool set, along with supporting information as to why the decision was made.
- The need to integrate SE activities with the project/program management activities and resulting artifacts to better manage cost and schedule.
SE is continuously evolving to meet the needs of organizations and to address the challenges described above for increasingly complex systems. Out of this evolution, the concept of MBSE has become the focus of the SE world, especially within INCOSE.
Systems Engineering Artifacts
As stated earlier, artifacts are generated as part of the activities conducted during each of the SE development lifecycle processes. Table 1 provides example artifacts generated during each of the lifecycle processes defined in ISO/IEC/IEEE 15288:2015, Systems and software engineering—System life cycle processes: conception, development, production, utilization, support and retirement. (Note: a similar list of artifacts can be generated from a program/project management perspective. Both sets of artifacts are dependent and need to be linked together for maximum management effectiveness.)
Table 1: Example SE Artifacts Generated During Each of the Lifecycle Processes.
The focus in the concept stage is to define the system of interest and investigate the extent of the effort and cost to provide that system of interest. Most of the work in the concept stage is conducted for three main purposes:
– facilitate a common understanding of the problem being solved and definition of the system of interest needed to address that problem;
– evaluate the risks associated with candidate concepts by performing feasibility analyses (cost, schedule, technical, political, environmental, ethical, etc.) and trade studies, and
– baseline a feasible concept and corresponding system level requirements.
The development stage starts with the results from the concept stage efforts. The artifacts shown in Table 1 representing the system under development have been defined. If the artifacts have been created using SE tools that support increasing granularity, artifacts developed during the concept stage can continue to be used in the development stage with added information. During development, the concept is transformed into a design, and in that transformation, design and technical issues are resolved as an integral part of the SE process.
As we progress from one lifecycle stage to the next, the number of artifacts and the amount of data required to develop those artifacts increases rapidly. The original artifacts from the concept stage serve as input to the later stages and help to identify areas where deeper analysis is necessary. Feedback from these analyses is used to update the various artifacts the concept, if needed. Traceability between artifacts from the previous stage and the subsequent stages are established and maintained as rationale for all changes.
In the next part of this series, I discuss what a model is, MBSE from the current model-based perspective, and the benefits of MBSE.
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.Tags: artifacts, data-centric, MBSE, Model Based Systems Engineering, model-centric, systems engineering