Basics of Agile Systems Modeling

For the most part, this book is about systems modeling with SysML, but doing it in an agile way. Before we get into the detailed practices of systems modeling with that focus, however, we’re going to spend some time discussing important project-related agile practices that will serve as a backdrop for the modeling work.

Almost all of the agile literature focuses on the “three people in a garage developing a simple application” scope. The basic assumptions of such projects include:

• The end result is software that runs on a general-purpose computing platform (i.e., it is not embedded).
• Software is the only truly important work product. Others may be developed but they are of secondary concern. Working software is the measure of success.
• The software isn’t performance, safety, reliability, or security-critical.
• It isn’t necessary to meet regulatory standards.
• The development team is small and co-located.
• The development is time-and-effort, not fixed-price cost.
• The development is fundamentally code-based and not model- (or design)-based.
• Any developer can do any task (no specialized skills are necessary).
• Formalized requirements are not necessary.

Yes, of course, there is much made about extensions to agile practices to account for projects that don’t exactly meet these criteria. For example, some authors will talk about a “scrum of scrums” as a way to scale up to larger teams. That works to a point, but it fails when you get to much larger development teams and projects. I want to be clear – I’m not saying that agile methods aren’t application to projects that don’t fall within these basic guidelines – only that the literature doesn’t address how it will do so in a coherent, consistent fashion. The further away your project strays from these assumptions, the less you will find in the literature for agile ways to address your needs.

In this book, we’ll address a domain that is significantly different than the prototypical agile project. Our concerns will be projects that:

• Are systems-oriented, which may contain software but will typically also contain electronic and mechanical aspects. It’s about the system and not the software.
• Employ a Model-Based Systems Engineering (MBSE) approach using the SysML language.
• May range from small- to very large-scale.
• Must develop a number of different work products. These include, but are not limited to:
  • Requirements specification
  • Analysis of requirements, whether it is done with use case or user stories
  • System architectural specification
  • System interface specification
  • Trace relations between the elements of the different work products
  • Safety, reliability, and security (and resulting requirements) analyses
  • Architectural design trade studies
• Have a handoff to downstream engineering that includes interdisciplinary subsystem teams containing team members who specialize in software, electronics, mechanical, and other design aspects.

But at its core, the fundamental difference between this book and other agile books is that the outcome of systems engineering isn’t software, it’s system specification. Downstream engineering will ultimately do low-level design and implementation of those specifications. Systems engineering provides the road map that enables different engineers with different skill sets, working in different engineering disciplines, to collaborate together to create an integrated system, combining all their work into a cohesive whole.

The International Council of Systems Engineering (INCOSE) defines systems engineering as “a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods” (https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition). This book will not provide a big overarching process that ties all the workflows and work products together, although it is certainly based on one. That process – should you be interested in exploring it – is detailed in the author’s Agile Systems Engineering book; a detailed example is provided with the author’s Harmony aMBSE Deskbook, available at www.bruce-douglass.com. Of course, these recipes will work with any other reasonable MBSE process. It is important to remember that:

The outcome of software development is implementation;

The outcome of systems engineering is specification.