• Abstract and Figures
• Public Full-text

Model-Based Systems Engineering Next Big Thing or a Fad? John M. Nicholson SAT THROUGH A SYSTEMS ENGINEERING (SE) TRAINING COURSE THE OTHER DAY TO UNDERSTAND THE SE philosophy of my organization. It was more of an audit of the course that covered only basic concepts in my field. As I struggled to maintain attention, the instructor advanced to the next slide in his presentation and posed the question: I True or False: All Projects at Company X Should Use Model-Based Systems Engineering? I chuckled to myself about the question, thinking it was a bit silly. However, to my dismay, the correct answer apparently was “True!” I nearly fell out of my chair! Counter-examples began popping into my head. For instance, if we are going to pave the sidewalk outside of Company X, should we build a System Model to get things going? Should I teach the pav- ing crew how to interpret the models? Or, more realistically, should a routine software bug fix of existing legacy software require development of a System Model of the code as part of the solution? My team just went into the Graphical User Interface (GUI) on one of our systems and changed the unit abbreviation for Milliseconds from “ms” to “msec.” Would Model-Based Systems Engineering (MBSE) have been a value-added activity? Nicholson is the Chief Engineer for a weapon system program in Colorado Springs and an instructor in Systems Engineering at University of Colorado in Colorado Springs. He holds a Ph.D. in Systems Engineering from the University of Alabama in Huntsville. DEFENSEACQUISITION | September-October 2019 | 19 After the training session ended, I politely asked the in- the expense of innovation. Despite this, all DoD contrac- structor about his true/false question. He enthusiastically tors have a process improvement policy based on the Six agreed with his previous conclusion that all projects should Sigma methodology. DoDAF became a requirement for all utilize MBSE. I challenged him with the sidewalk paving programs, but the Government Accountability Office still example. He retorted, “In the 20 or so projects at Company cites requirements volatility as the leading cause of project X where we used MBSE, not a single project failed because failure. In both cases, a tool or technique that works in we used too much MBSE.” Apparently, that was sufficient some cases is universally applied, even if it’s to the detri- proof that MBSE was justified on all projects. This is error ment of the project. of logic known as “Denying the Antecedent.” Focus on Value Added I replied, “On my program, we have donuts on Friday morn- Knowing when to apply a tool, technique or methodology is ing. In all of the projects we’ve executed, not a single one not easy. Many variables and considerations are involved. has failed due to Donut Friday. Using the same logic, we It is ambiguous. Every approach has advantages and dis- should mandate that all projects institute Donut Friday advantages. For complex engineering projects, the SE must into their engineering process.” He was not amused. We weigh these pros and cons of methods and determine if the continued to discuss the applicability and value of MBSE. pros outweigh the cons—if the method adds value or not. If We agreed to disagree. the method does not add value, it is a distraction. It is work your team does for no benefit. Meanwhile, there is needed Project Fads and Engineering Rituals work that is not getting done while the team works on In SE and project management, it seems we always are these distractions. The more we understand about the ap- looking for a silver bullet to solve our execution problems. plicability of our methods and their value added, the more Tools, techniques and processes work on one project and competitive we become because we focus our engineering are then mandated on all projects as globally applicable. teams on the most important tasks and minimize the dis- However, these so-called solutions often do more harm tracting busywork associated with misapplied techniques. than good. Part of the problem is the lack of rigor that un- The more we fail to minimize the tasks that don’t add derlies many of the SE tools and techniques. That is, there value, the more our engineering staff hates the SE process. really is no theoretical basis for much of what we do in SE. It also seems to be human nature to try and compartmen- When does MBSE add value? When doesn’t MBSE add talize situations and look for patterns. That way, we avoid value? If we can agree that MBSE wouldn’t be value added the critical thinking and ambiguity associated with plan- when we pave the sidewalk or change “ms” to “msec” on ning and executing complex engineering projects. People a GUI, then clearly it is not a universally applicable tech- don’t like ambiguity. People like to know the right answer. nique. And how far do we take the system model into the They tend to like the status quo. The status quo is comfort- architecture? Do we model down to the A-Spec? B-Spec? able—it makes us feel safe. They don’t like uncertainty. C-Spec? What value do we plan to get out of this model? Uncertainty makes us feel, well, uncertain. People need a At some point, are we modeling just to model or are we still universal answer. People need a silver bullet. Unfortunately, adding value? In some organizations, asking this question is Fredrick Brooks correctly concluded that the search for the blasphemy. My asking these questions has led to the label silver bullet is a futile quest—with the side effect of making that “Morgan doesn’t believe in MBSE.” Not true. In fact, I our SE culture ritualistic and susceptible to fads. am very enthusiastic about the benefits MBSE can bring to my program. However, I am also skeptical about anything In the SE profession, we constantly are bombarded with and anyone with a silver bullet. I raise an eyebrow every the next big thing. Often this is pushed down upon the time I hear something like, “I don’t know the problem, but technical staff from program managers with good inten- the answer is MBSE!” To me, this is a red flag signaling tions. Capability Maturity Model Integration (CMMI), Total that people don’t want the ambiguity of approaching every Quality Management (TQM), Six Sigma and Department complex engineering problem as if it has unique character- of Defense Architectural Framework (DoDAF) were all istics and challenges. They want a silver bullet. trends within the acquisition community. Many of them had some success. However, just like the MBSE argument, The Power of MBSE none of these techniques are universally applicable. In fact, MBSE is a powerful tool in the SE’s tool bag. It leverages they can be counterproductive. For example, Six Sigma the Object Oriented (OO) software concept of defin- has been highly successful at improving manufacturing ing each entity in one place and then uses it in multiple processes, but there is much debate over the long-term places within the design. For example, a communication impact of Six Sigma on development process. This is message may be defined in one place within the model because of the so-called “productivity dilemma.” Making but used by multiple subsystems within a design. In engineering development more efficient usually comes at traditional documentation-based SE, that message would 20 | September-October 2019 | DEFENSEACQUISITION At some point, are we modeling just to model or are we still adding value? In some organizations, asking this question is blasphemy. potentially be defined in multiple specifications and pos- system correctly. It also is complicated and potentially sibly interface specifications. If that message changes, confusing to learn and interpret, which can lead to ambigu- the MBSE project would need to change the definition ities and inconsistencies. Additionally, many of the issues one time, and that change would propagate throughout associated with requirements volatility are due to a lack the system model. In the specification-based approach, of mission understanding, which certainly is not cured by the engineering staff typically would be responsible for using MBSE. In my experience, applying MBSE can com- knowing where that message appeared in the docu- pound the problem by focusing the staff on satisfying the mentation and making the correct updates based on the model and not the needs of the user. design change. The specification-based approach is far more labor intensive and error prone. With Great Power Comes Great Responsibility One of the well documented problems with text-based re- In order to fully reap the benefits of MBSE, we must recog- quirements is that normal language is ambiguous. Many nize when it represents value added and when it does not. defects are introduced as a result of misunderstanding Simply declaring that “this organization shall use MBSE the meaning of a textual requirement. The customer or for every project” sounds like a fad and possibly will do the SE precisely understood the meaning of a require- more harm than good. How and when to apply MBSE and ment, but the design engineer interpreted the require- to what scale should be considered very carefully on each ment differently. MBSE offers a more precise syntax to program and project. The goal should be to maximize the specify requirements. The syntax, once learned, can de- benefits of MBSE without imposing additional unnecessary fine system functions and interfaces in a way that could work on the engineering staff to model system aspects be interpreted much more consistently by customers, SEs where the benefits are not applicable.

Load more

  3

Copy Link