As modern systems become increasingly complex, the need for Model-based Systems Engineering (MBSE) emerges rapidly from many organizations’ search to understand different design tools and methodologies. MBSE is now popular even outside of Aerospace and Department of Defense programs. At the same time, software development demands to be quick, agile, and cheap. Coupled with the need to address testing, delivery, fielding, and operations of the systems early in the design process, programs usually face an insurmountable task of integrating all of the best engineering practices. In this series of articles, I will walk you through how I adapted my modeling methodology to accommodate my former organization’s need to implement Agile DevOps.
To set the context, I was one of the lead systems engineers on a large military aircraft program. My responsibilities included architecting a thread of system features related to the aircraft’s control, guidance, and navigation. During program execution, the Software organization sometimes took over the role of systems engineering and management. And so, we started to get acquainted with agile and DevOps.
What is DevOps? According to Atlassian, “DevOps is an approach to software development that enables teams to build, test, and release software faster and more reliably. . . It replaces the old approach of development teams writing applications and then throwing them over the wall to an operations team who deploys and manages the software with minimal visibility into how it was developed. In a DevOps environment, developers and operations teams work side by side throughout the entire process of developing, deploying, and managing applications.” DevOps makes sense for a military program where the development and product lifecycle is long and complex. The operational elements of the program must be involved in software development to plan and execute validation and verification early. A late bug discovery is an expensive bug discovery.
What is agile? Also from Atlassian, “In an agile approach, some planning and design are done upfront, but the development proceeds in small batches and involves close collaboration with stakeholders. Changes are incorporated continuously, and a usable product version is often released quicker than products developed through the waterfall methodology.” My former organization wanted very rapid completions of very small-size features. This accomplished a few different things. One, features were completed and tested quickly. Any defects would be identified and fixed early and frequently. Defects were not allowed to propagate and cascade through the development lifecycle. Two, related and co-dependent features in different subsystems developed by different product teams could be planned and executed on a concurrent schedule. This eliminated wasted time when related features were waiting on one another for integration and test. Three, if there was unavoidable lead-time between feature completions, it was short enough that temporarily shuffling personnel among assignments would not cause any negative impact on the overall structure of the workforce.
The merits of an agile approach to a real-life military aircraft program with many moving parts (both literally and figuratively) are controversial. Implementing agile and DevOps is no easy feat. I will not address the practicality or the performance of this combination approach. I am only discussing how I adapted my modeling methodology to fit the program’s needs.
What were the needs?
- The “abilities” of the system must be understood, designed, and tested at different hierarchical levels
- System capabilities
- System features
- Subsystem features
- Each architecture level must be traced to the appropriate (existing) requirements.
- The work on subsystem features by each product team must be divided into
- User stories
- Epics
- Each subsystem feature must be designed, integrated with other subsystem features into the appropriate system feature, and tested.
- And do all of that to fit into a prescribed timeline across multiple subsystems.
- All of this will change at a moment’s notice.
My first task was understanding the program’s requirements for the hierarchical structure of the system’s abilities.
A system capability was something at the operational level that the system must be able to do. For example, “The aircraft shall do low-speed taxi” was a system capability. Another was “The aircraft shall do a holding pattern at XYZ altitude.”
A system feature was a unique behavior of the system when the collective subsystems work together to accomplish a part of or a whole system capability. For example, a system feature was “The aircraft shall fly with manual or autopilot control.” And “The aircraft shall enter and exit XYZ guidance mode upon command.”
Finally, a subsystem feature was a unique behavior of a subsystem working together with other subsystem feature(s) to create a unique behavior of a system feature. An example was “The vehicle management subsystem shall couple and decouple autopilot with the control loop upon command.” And “The data display subsystem shall indicate the guidance mode on a primary flight display.”
As stated in the examples above, the organization of the aircraft’s hierarchical “abilities” or behaviors made sense in hindsight. Initially, there was no concrete example of how they should be constructed vertically (decomposition) and horizontally (integration). What flowed down to the teams was merely, “these are the three terms, they are hierarchical, make it work.” I tried applying Vitech’s familiar System Definition Language (SDL) to the behavior hierarchy, and it worked:
A system capability is built from Operational Activities. Each activity is implemented by the appropriate system features (Functions). Each of the Functions is then decomposed by subsystem features (also Functions).
We were allowed to use either CORE or Rhapsody for the architecture tasks. That was not ideal when the whole point of Agile DevOps was to integrate all features quickly and seamlessly. I was not going to complain, however. The use of Rhapsody in the organization was, at best, barely able to draw the interfaces between components. At worst, it created disjoint diagrams that were impossible to trace and maintain. Besides, we were mandated to integrate various system features from different teams in Jira (another institutional shortcoming). I was successful and content using Vitech’s CORE and its Capability Architecture Development schema to develop my system features thread.
To be continued…
