Agile Model-Based Systems Engineering Cookbook

Improve system development by applying proven recipes for effective agile systems engineering

Dr. Bruce Powel Douglass

• Publisher: Packt Publishing
• Year: 2021
• ISBN:
  9781839218149
• Topic: Computer Science
• Subtopic: Systems Architecture
• Index: Computer Science

Worried about the growing complexity of systems in your organization? Manage it with recipes for applying agile methodologies and techniques in model-based systems engineering (MBSE)

Key Features

• Learn how Agile and MBSE can work iteratively and collaborate to overcome system complexity
• Develop essential systems engineering products and achieve crucial enterprise objectives with easy-to-follow recipes
• Build efficient system engineering models using tried and trusted best practices

Book Description

Agile MBSE can help organizations manage constant change and uncertainty while continuously ensuring system correctness and meeting customers' needs. But deploying it isn't easy.Agile Model-Based Systems Engineering Cookbook is a little different from other MBSE books out there. This book focuses on workflows – or recipes, as the author calls them – that will help MBSE practitioners and team leaders address practical situations that are part of deploying MBSE as part of an agile development process across the enterprise.Written by Dr. Bruce Powel Douglass, a world-renowned expert in MBSE, this book will take you through important systems engineering workflows and show you how they can be performed effectively with an agile and model-based approach. You'll start with the key concepts of agile methods for systems engineering, but we won't linger on the theory for too long. Each of the recipes will take you through initiating a project, defining stakeholder needs, defining and analyzing system requirements, designing system architecture, performing model-based engineering trade studies, all the way to handling systems specifications off to downstream engineering.By the end of this MBSE book, you'll have learned how to implement critical systems engineering workflows and create verifiably correct systems engineering models.

What you will learn

• Apply agile methods to develop systems engineering specifications
• Perform functional analysis with SysML
• Derive and model systems architectures from key requirements
• Model crucial engineering data to clarify systems requirements
• Communicate decisions with downstream subsystem implementation teams
• Verify specifications with model reviews and simulations
• Ensure the accuracy of systems models through model-based testing

Who this book is for

If you are a systems engineer who wants to pursue model-based systems engineering in an agile setting, this book will show you how you can do that without breaking a sweat. Fundamental knowledge of SysML is necessary; the book will teach you the rest.

]]>

Chapter 1: The 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 of the modeling work.

Almost all of the Agile literature focuses on the "3 people in a garage developing a simple application" scope. The basic assumptions of such projects include the following:

• The end result is software that runs on a general-purpose computing platform (in other words, it is not embedded software).
• 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 involves time and effort, not a 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 of scaling 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 cannot be applied 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 differs significantly from the prototypical Agile project. We will concern ourselves with the following:

• Projects that are systems-oriented, and that may contain software but will typically also contain electronic and mechanical aspects. It's about the system and not the software.
• Projects that employ a Model-Based Systems Engineering (MBSE) approach using the SysML language.
• Projects that may range from small to very large scale.
• Projects that have to develop a number of different work products. These include, but are not limited to, the following:
  a. Requirements specifications
  b. Analysis of requirements, whether this is done with use cases or user stories
  c. System architectural specifications
  d. System interface specifications
  e. Trace relations between the elements of the different work products
  f. Safety, reliability, and security (and resulting requirements) analyses
  g. Architectural design trade studies
• Projects that are handed off to downstream engineering, which includes interdisciplinary subsystem teams containing team members who specialize in software, electronics, mechanical, and other design aspects.

At its core, however, the fundamental difference between this book and other Agile books is that the outcome of systems engineering isn't software, it's specification. Downstream engineering will ultimately do the low-level design and implementation of those specifications. Systems engineering provides the roadmap 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.

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 his Harmony aMBSE Deskbook, available at www.bruce-douglass.com.

The outcome of software development is implementation.

The outcome of systems engineering is specification.

Note

Please refer to Agile Systems Engineering by Bruce Powel Douglass for more information: https://www.amazon.com/Agile-Systems-Engineering-Bruce-Douglass/dp/0128021209/ref=sr_1_3?dchild=1&keywords=agile+systems+engineering&qid=1603658530&sr=8-3.

What's Agile all about?

Agile methods are, first and foremost, a means of improving the quality of your engineering work products. This is achieved through the application of a number of practices meant to continuously identify quality issues and immediately address them. Secondly, Agile is about improving engineering efficiency and reducing rework. Let's talk about some basic concepts of agility.

Incremental development

This is a key aspect of Agile development. Take a big problem and develop it as a series of small increments, each of which is verified to be correct (even if incomplete).

Continuous verification

The best way to have high-quality work products is to continuously develop and verify their quality. In other books, such as Real-Time Agility or the aforementioned Agile Systems Engineering books, and here, I talk about verification taking place in three timeframes:

• Nanocycle: 30 minutes to 1 day
• Microcycle: 1–4 weeks
• Macrocycle: Project length

Furthermore, this verification is best done via execution and the testing of computable models. We will see in later chapters how this can be accomplished.

Continuous integration

Few complex systems are created by a single person. Integration is the task of putting together work prod...

Table of contents

• Agile Model-Based Systems Engineering Cookbook
• Contributors
• Preface
• Chapter 1: The Basics of Agile Systems Modeling
• Chapter 2: System Specification
• Chapter 3: Developing System Architectures
• Chapter 4: Handoff to Downstream Engineering
• Chapter 5: Demonstration of Meeting Needs: Verification and Validation
• Appendix A – The Pegasus Bike Trainer
• Other Books You May Enjoy