29,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Agile MBSE can help organizations manage change while ensuring system correctness and meeting customers’ needs. But deployment challenges have changed since our first edition.
The Agile Model-Based Systems Engineering Cookbook’s second edition focuses on workflows – or recipes – 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. In this 2nd edition, the Cameo MagicDraw Systems Modeler tool – the most popular tool for MBSE – is used in examples (models are downloadable by readers).
Written by a world-renowned expert in MBSE, this book will take you through systems engineering workflows in the Cameo Systems Modeler SysML modeling tool and show you how they can be used with an agile and model-based approach. You’ll start with the key concepts of agile methods for systems engineering. Next, each recipe will take you through initiating a project, outlining stakeholder needs, defining and analyzing system requirements, specifying 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 learn how to implement systems engineering workflows and create systems engineering models.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 593
Veröffentlichungsjahr: 2022
Ähnliche
Contents
Preface
Who this book is for
What this book covers
To get the most out of this book
Share your thoughts
Basics of Agile Systems Modeling
What’s agile all about?
Incremental development
Continuous verification
Continuous integration
Avoid big design up front
Working with stakeholders
Model-Based Systems Engineering (MBSE)
Managing your backlog
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Measuring your success
Purpose
How to do it
Example
Some considerations
Measuring the wrong thing
Managing risk
Purpose
Inputs and proconditions
Outputs and postconditions
How to do it
Example
Product roadmap
Purpose
Inputs and preconditions
How to do it
Example
Release plan
Purpose
Inputs and preconditons
Outputs and postconditions
How to do it
Example
Iteration plan
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Estimating Effort
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
How it works
Example
Work item prioritization
Purpose
Inputs and preconditions
How to do it
How it works
Example
Iteration 0
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Architecture 0
Subsystem and component view
Concurrency and resource view
Distribution view
Dependability view
Deployment view
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Additional note
Organizing your models
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
How it works
Example
Managing change
Purpose
Inputs and preconditions
How to do it
Example
System Specification
Recipes in this chapter
Why aren’t textual requirements enough?
Definitions
Functional Analysis with Scenarios
Functional analysis with activities
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Functional analysis with state machines
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Functional Analysis with User Stories
A little bit about user stories
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Model-Based Safety Analysis
A little bit about safety analysis
Some Profiles
Hazard analysis
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Model-Based Threat Analysis
Basics of Cyber-Physical Security
Modeling for Security Analysis
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Specifying Logical System Interfaces
A Note about SysML Ports and Interfaces
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Creating the Logical Data Schema
Definitions
Example
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Developing System Architectures
Recipes in this chapter
Five critical views of architecture
Architectural trade studies
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Architectural merge
Example
Pattern-driven architecture
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Subsystem and component architecture
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Architectural allocation
Creating subsystem interfaces from use case scenarios
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Specializing a reference architecture
What is a reference architecture?
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Handoff to Downstream Engineering
Recipes in this chapter
Activities for the handoff to downstream engineering
Starting point for the examples
Preparation for Handoff
Federating Models for Handoff
Logical to Physical Interfaces
Deployment Architecture I: Allocation to Engineering Facets
Deployment Architecture II: Interdisciplinary Interfaces
Demonstration of Meeting Needs: Verification and Validation
Recipes in this chapter
Verification and validation
Model simulation
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Model-based testing
Inputs and preconditions
Outputs and postconditions
How to do it
Computable constraint modeling
Purpose
Inputs and preconditions
How to do it
Example
Traceability
Some definitions
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Effective Reviews and walkthroughs
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Managing Model Work Items
Purpose
Inputs and preconditions
How to do it
Example
Test Driven Modeling
Purpose
Inputs and preconditions
Outputs and postconditions
How to do it
Example
Appendix A: The Pegasus Bike Trainer
Overview
Pegasus High-Level Features
Highly customizable bike fit
Monitor exercise metrics
Export/upload exercise metrics
Variable power output
Gearing emulation
Controllable power level
Incline control
User interface
Online training system compatible
Configuration and OTA firmware updates
Other Books You May Enjoy
Index
Landmarks
Cover
Index
Agile Model-Based Systems Engineering Cookbook
Second Edition
Improve system development by applying proven recipes for effective agile systems engineering
Dr. Bruce Powel Douglass
BIRMINGHAM—MUMBAI
Agile Model-Based Systems Engineering Cookbook
Second Edition
Copyright © 2022 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Senior Publishing Product Manager: Denim Pinto
Acquisition Editor – Peer Reviews: Saby Dsilva
Project Editor: Meenakshi Vijay
Content Development Editor: Rebecca Robinson
Copy Editor: Safis Editing
Technical Editor: Srishty Bhardwaj
Proofreader: Safis Editing
Indexer: Pratik Shirodkar
Presentation Designer: Rajesh Shirsath
First published: March 2021
Second edition: December 2022
Production reference: 3050123
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham
B3 2PB, UK.
ISBN 978-1-80323-582-0
www.packt.com
Foreword
As a systems engineer, you may know that viewpoints are important to understand context. When you read this foreword, you should be aware that I wrote it from my individual viewpoint. My own professional role involves the development of methods, templates, and training to make Systems engineering applicable for organizations, and also producing complex systems consisting of mechanical and electrical hardware, software, and the human beings operating it or interacting with it. Systems engineering is nowadays challenged with several constraints and boundary conditions requiring permanent change in the organization and its processes, methods, and tools. The need to work closely cross-domain (e. g. mechanical and hardware designers working together with software programmers, testers, and stakeholders), the need to quickly react to external (and internal) disruptions, and the need to bridge cross-cultural gaps require several significant changes in parallel. And this is difficult for bigger organizations and hard to realize. This is where this book helps significantly and contributes to mastering such challenges. The answer to those challenges lies in the introduction and application of Systems Engineering (SE) and in agile methods. The definition, deployment, implementation, maturation, and management of those two changes is a huge challenge to bigger companies and this book provides simple (not easy!) recipes to approach those changes.
This book perfectly fills a couple of gaps existing today in this area. Typically, there are two ways for companies to start their Systems Engineering journey: either they start first with training and educating Systems engineers theoretically or they start introducing a Model-Based Systems Engineering (MBSE) tool to provide a tool to “do Systems Engineering”. I’m not saying that the one or other method is better or worse, but I have observed this for years. Actually, both are necessary as, Systems Engineers need a good theoretical background on the methods and on tools. For re-use and communication, modern MBSE tools are optimally suited to implement SE formally in all development processes. However, to implement Systems Engineering broadly in a cross-domain development organization it is critical to follow strict modelling rules and to install syntactic and semantic guidelines.
In this area this book perfectly meets the needs of any SE practitioner and each company implementing or applying SE. The practical guidelines, the “step-by-step” descriptions, the cross-domain designed examples, and the provided downloads allow companies and individuals to get quickly and easily to the core of the method and mind set. With the provided references and additional sources, this book offers many further paths to go into more detail in many domains if needed or desired.
The second critical area covered by this book is the “agile” aspects of modern development organizations. The beauty of this book is that it holds “agile” at its core, the agile manifesto, and does not reduce or limit it to one of the many agile process implementations. The book provides excellent directions and practices to become more agile, independent of the development domain (not limited to software development), and also builds the bridge on how to use SE and MBSE in particular to foster an agile development process in general. Using the different SE artifacts as deliverables, prioritizing them accordingly to build a useful backlog, employing methods to track progress and risk, etc. are well described and practically applicable. As said before, practical examples and “step-by-step” guidelines are the core enablers for immediate practical application.
Last but not least, while the book follows the full development cycle and covers the aspects of functional analysis, architecting, trade studies, system design, verification, and validation, it also details the important aspects of system safety and security.
I highly recommend this book to all SE practitioners and to anyone considering how to implement SE in a company or how to become more agile. This second edition, with all of its enhancements and improvements in the step-by-step description and its additional areas covering things such as system security, is a must have in each SE’s library.
Thank you Bruce, and well done!
Christian von Holst
Global Tractor Systems Engineering Lead at John Deere
Contributors
About the author
Dr. Bruce Powel Douglass has received an MS in exercise physiology from the University of Oregon and a Ph.D. in neurocybernetics from the USD Medical School. He has worked as a software developer and systems engineer in safety-critical real-time embedded systems for almost 40 years and is a well-known speaker, author, and consultant in the area of real-time embedded systems, UML, and SysML. He is a coauthor of the UML and SysML standards, and teaches courses in real-time systems and software design and project management. Bruce has also authored articles for many journals and periodicals, especially in the real-time domain, and authored several other books on systems and software development. He has worked at I-Logix, Telelogic, and IBM on the Rhapsody modeling tool. He is currently a senior principal agile systems engineer at MITRE, and the principal at A-Priori Systems.
About the reviewers
Jaime Robles has more than a decade of experience in the development of complex engineered systems across the entire lifecycle. Currently, he is working as a Systems Engineer at the ALMA Observatory, the world’s most powerful telescope at millimeter and submillimeter wavelengths. Previously, he has worked in the development of small space systems for planetary surface exploration and as a consultant in systems engineering with MBSE focus at SPEX Systems.
He is an aerospace engineer, an OMG certified Systems Modeling Professional – Model Builder Advanced (OCSMP-MBA), an INCOSE associate Systems Engineering professional, and an active member of this professional organization participating in several groups (Space Systems WG, Requirements WG, LATAM Chapter). He also holds an MIT certificate in Architecture and Systems Engineering and has gained work experience in the United States, Switzerland, and Chile.
A word of acknowledgment to the author for sharing his vast knowledge with the MBSE community and for the opportunity to contribute with a grain of sand as a technical reviewer. Also, a special thanks to my family for their kind support and patience during the time invested in the review process.
Dr. Saulius Pavalkis is global MBSE Ecosystem Transformation Leader and MBSE R&D Cyber Portfolio Manager NAM at Dassault Systemes. He is also an INCOSE CAB Representative and on the CSE Board of Advisors at the University of Texas.
He has 20 years of MBSE solutions experience, and is a product owner and analyst with the Cameo core team, chief solution architect, consultant, and trainer. He is a world-leading expert in MBSE ecosystem, digital engineering, system architecture and simulation.
Throughout his career, he has been actively involved in building excellent MBSE ecosystem solutions in aerospace, defense, automotive and other areas as a former affiliate for JPL NASA for MBSE consulting and a contractor for Boeing's MBSE transformation.
Dr Saulius Pavalkis contributed to the MBSE SysML Based Method and Framework MagicGrid book and recently the Agile MBSE Cookbook by Dr. Bruce Douglass. He guides 2,000 subscribers—the largest SysML systems simulation community on YouTube (youtube.com/c/MBSEExecution). Saulius has INCOSE CSEP, OMG OCSMP, the No Magic lifetime modeling and simulation excellence award, a PhD in software engineering in the models query area, and a MS and BS in telecommunications and electronics from Kaunas University of Technology.
I would like to thank Dr. Bruce Douglass for amazing opportunity to review his latest book on Agile MBSE application. Dr. Bruce is a leading expert in effective and efficient MBSE application and has made this book is the best in class as an MBSE transformation guide. It is a must-have for any company or expert. Thank you, Dr. Bruce Douglass!
Join our community on Discord
Join our community’s Discord space for discussions with the author and other readers:
https://packt.link/cpVUC
Preface
Welcome to the Agile Model-Based Systems Engineering Cookbook! There is a plethora of published material for agile methods, provided that you want to create software. And the system is small. And the team is co-located. And it needn’t be certified. Or safety-critical or high-reliability.
MBSE is none of these things. The output of MBSE isn’t software implementation but system specification. It is usually applied to more complex and larger-scale systems. The teams are diverse and often spread out across departments and companies. Much of the time, the systems produced must be certified under various standards, including safety standards. So how do you apply agile methods to such an endeavor?
Most of the work in MBSE can be thought of as a set of workflows that produce a set of interrelated work products. Each of these workflows can be described with relatively simple recipes for creating the work products for MBSE including system requirements, systems architecture, system interfaces, and deployment architectures. That’s what this book brings to the table and what sets it apart.
In this second edition, some new recipes have been added and all the examples and figures have been done using the Cameo Systems Modeler SysML tool.
Who this book is for
The book is, first and foremost, for systems engineers who need to produce work products for the specification of systems that include combinations of engineering disciplines, such as software, electronics, and mechanical engineering. More specifically, this book is about model-based systems engineering using the SysML language to capture, render, and organize the engineering data. Further, the book is especially about how to do all that in a way that achieves the benefits of agile methods – verifiably correct, adaptable, and maintainable systems. We assume basic understanding of the Systems Modeling Language (SysML) and at least some experience as a systems engineer.
What this book covers
Chapter 1, Basics of Agile Systems Modeling, discusses some fundamental agile concepts, expressed as recipes, such as managing your backlog, using metrics effectively, managing project risk, agile planning, work effort estimation and prioritization, starting up projects, creating an initial systems architecture, and organizing your systems engineering models. The recipes all take a systems engineering slant and focus on the work products commonly developed in a systems engineering effort.
Chapter 2, System Specification, is about agile model-based systems requirements – capturing, managing, and analyzing the system specification. One of the powerful tools that MBSE brings to the table is the ability to analyze requirements by developing computable and executable models. This chapter provides recipes for several different ways of doing that, as well as recipes for model-based safety and cyber-physical security analysis, and specifying details of information held within the system.
Chapter 3, Developing Systems Architecture, has recipes focused on the development of systems architectures. It begins with a way of doing model-based trade-studies (sometimes known as “analysis of alternatives”). The chapter goes on to provide recipes for integrating use case analyses into a systems architecture, applying architectural patterns, allocation of requirements into a systems architecture, and creating subsystem-level interfaces.
Chapter 4, Handoff to Downstream Engineering, examines one of the most commonly asked questions about MBSE: how to hand the information developed in the models off to implementation engineers specializing in software, electronics, or mechanical engineering. This chapter provides detailed recipes for getting ready to do the hand off, creating a federation of models to support the collaborative engineering effort to follow, converting the logical systems engineering interfaces to physical interface schemas, and actually doing the allocation to the engineering disciplines involved.
Chapter 5, Demonstration of Meeting Needs Verification and Validation, considers a key concept in agile methods: that one should never be more than minutes away from being able to demonstrate that, while the system may be incomplete, what’s there is correct. This chapter has recipes for model simulation, model-based testing, computable constraint modeling, adding traceability, how to run effective walkthroughs and reviews, and – my favorite – Test-driven modeling.
Appendix, The Pegasus Bike Trainer, details a case study that will serve as the basis for most of the examples in the book. This is a “smart” stationary bike trainer that interacts with net-based athletic training systems to allow athletes to train in a variety of flexible ways.
It contains aspects that will be implemented in mechanical, electronic, and software disciplines in an ideal exemplar for the recipes in the book.
To get the most out of this book
To get the most out of this book, you will need a solid, but basic, understanding of the Systems Modeling Language (SysML). In addition, to create the models, you will need a modeling tool. The concepts here are expressed in SysML so any standards-compliant SysML modeling tool can be used.
All the example models in this book are developed using the Cameo Systems Modeler tool. To execute models and run simulations, you will need the Simulation Toolkit, included with the tool:
Software/hardware covered in the book
OS requirements
Cameo Systems Modeler
Windows, macOS, or Linux
Download the example models
You can download the example models for this book from the author’s website at www.bruce-douglass.com. Note that these models are all in Cameo-specific format and won’t generally be readable by other modeling tools.
We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!
Where to go from here
Visit the authors, website at www.bruce-douglass.com for papers, presentations, models, engineering forums, to download the models from this book, and more.
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://packt.link/av1n2.
Conventions used
There are a number of text conventions used throughout this book.
Bold: Indicates a new term, an important word, or words that you see on the screen. For instance, words in menus or dialog boxes appear in the text like this. For example: “Select System info from the Administration panel.
Warnings or important notes appear like this.
Tips and tricks appear like this.
Get in touch
Feedback from our readers is always welcome.
General feedback: Email [email protected] and mention the book’s title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you reported this to us. Please visit http://www.packtpub.com/submit-errata, click Submit Errata, and fill in the form.
Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit http://authors.packtpub.com.
Share your thoughts
Once you’ve read Agile Model-Based Systems Engineering Cookbook, Second Edition, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.
Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.
Download a free PDF copy of this book
Thanks for purchasing this book!
Do you like to read on the go but are unable to carry your print books everywhere?Is your eBook purchase not compatible with the device of your choice?
Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.
Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.
The perks don’t stop there- you can get exclusive access to discounts, newsletters, and great free content in your inbox daily.
Follow these simple steps to get the benefits:
Scan the QR code or visit the link below:https://packt.link/free-ebook/9781803235820
Submit your proof of purchase.That’s it! We’ll send your free PDF and other benefits to your email directly.1
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 storiesSystem architectural specificationSystem interface specificationTrace relations between the elements of the different work productsSafety, reliability, and security (and resulting requirements) analysesArchitectural design trade studiesHave 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.
What’s agile all about?
Agile methods are – first and foremost – a means for 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. Secondarily, 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, I talk about how verification takes place in three timeframes:
Nanocycle: 30 minutes to 1 dayMicrocycle: 1–4 weeksMacrocycle: Project lengthFurther, this verification is best done via the execution and testing of computable models. We will see in later chapters how this can be accomplished.
Continuous integration
Few non-trivial systems are created by a single person. Integration is the task of putting together work products from different engineers into a coherent whole and demonstrating that, as a unit, it achieves its desired purpose. This integration is often done daily, but some teams increment this truly continuously, absorbing work as engineers complete it and instantly verifying that it works in tandem with the other bits.
Avoid big design up front
The concept of incremental development means that one thing that we don’t do is develop big work products over long periods of time and only then try to demonstrate their correctness. Instead, we develop and verify the design work we need right now, and defer design work that we won’t need until later. This simplifies the verification work and also means much less rework later in a project.
Working with stakeholders
A key focus of the Agilista is the needs of the stakeholders. The Agilista understands that there is an “air gap” between what the requirements say and what the stakeholder actually needs. By working with the stakeholder, and frequently offering them versions of the running system to try, they are more likely to actually meet their needs. Additionally, user stories – a way to organize requirements into short usage stakeholder-system usage scenarios – are a way to work with the stakeholder to understand what they actually need.
Model-Based Systems Engineering (MBSE)
Systems engineering is an independent engineering discipline that focuses on system properties – including functionality, structure, performance, safety, reliability, and security. MBSE is a model-centric approach to performing systems engineering. Systems engineering is largely independent of the engineering disciplines used to implement these properties. Systems engineering is an interdisciplinary activity that focuses more on this integrated set of system properties than on the contributions of the individual engineering disciplines. It is an approach to developing complex and technologically diverse systems. Although normally thought of in a V-style process approach (see Figure 1.1), the “left side of the V” emphases the specification of the system properties (requirements, architecture, interfaces, and overall dependability), the “lower part of the V” has to do with the discipline-specific engineering and design work, and the “right side of the V” has to do with the verification of the system against the specifications developed on the left side:
Figure 1.1: Standard V model life cycle
Of course, we’ll be doing things in a more agile way (Figure 1.2). Mostly, we’ll focus on incrementally creating the specification work products and handing them off to downstream engineering in an agile way:
Figure 1.2: Basic Agile systems engineering workflow
The basis of most of the work products developed in MBSE is, naturally enough, the model. For the most part, this refers to the set of engineering data relevant to the system captured in a SysML model. The main model is likely to be supplemented with models in other languages, such as performance, safety, and reliability (although you can use SysML for that too – we’ll discuss that in Chapter 2, System Specification—Functional, Safety and Security Analysis). The other primary work product will be textual requirements. While they are imprecise, vague, ambiguous, and hard to verify, they have the advantage of being easy to communicate. Our models will cluster these requirements into usage chunks – epics, use cases, and user stories – but we’ll still need requirements. These may be managed either as text or in text-based requirements management tools, such as IBM DOORS™, or they can be managed as model elements within a SysML specification model.
Our models will consist of formal representations of our engineering data as model elements and the relationships among them. These elements may appear in one or more views, including diagrams, tables, or matrices. The model is, then, a coherent collection of model elements that represent the important engineering data around our system of interest.
In this book, we assume you already know SysML. If you don’t, there are many books around for that. This book is a collection of short, high-focused workflows that create one or a small set of engineering work products that contain relevant model elements.
Now, let’s talk about some basic agile recipes and how they can be done in a model-centric environment.
Managing your backlog
The backlog is a prioritized set of work items that identify work to be done. There are generally two such backlogs. The project backlog is a prioritized list of all work to be done in the current project. A subset of these is selected for the current increment, forming the iteration backlog. Since engineers usually work on the tasks relevant to the current iteration, that is where they will go to get their tasks. Figure 1.3 shows the basic idea of backlogs:
Figure 1.3: Backlogs
The work to be done, nominally referred to as work items, is identified. Work items can be application work items (producing work that will be directly delivered) or technical work items (doing work that enables technical aspects of the product or project). Work items identify work to do such as:
Analyzing, designing, or implementing an epic, use case, or user story, to ensure a solid understanding of the need and the adequacy of its requirementsCreating or modifying a work product, such as a requirements specification or a safety analysis Arranging for an outcome, such as certification approvalAddressing a risk, such as determining the adequacy of the bus bandwidth Removing an identified defect Supporting a target platform, such as an increment with hand-built mechanical parts, lab-constructed wire wrap boards, and partial softwareThe work items go through an acceptance process, and if approved, are put into the project backlog. Once there, they can be allocated to an iteration backlog.
Purpose
The purpose of managing your backlog is to provide clear direction for the engineering activities, to push the project forward in a coherent, collaborative way.
Inputs and preconditions
The inputs are the work items. The functionality-based work items originate with one or more stakeholders, but other work items might come from discovery, planning, or analysis.
Outputs and postconditions
The primary outputs are the managed project and iteration backlogs. Each backlog consists of a set of work items around a common purpose, or mission. The mission of an iteration is the set of work products and outcomes desired at the end of the iteration. An iteration mission is defined as shown in Figure 1.4:
Figure 1.4: Iteration mission
In a modeling tool, this information can be captured as metadata associated with tags.
The term “metadata” literally means “data about data”; in this context, we add metadata to elements using tags.
How to do it
There are two workflows to this recipe. The first, shown in Figure 1.5, adds a work item to the backlog. The second, shown in Figure 1.6, removes it:
Figure 1.5: Add work item
Figure 1.6: Resolve work item
Create a workflow item
From the work to be done, a work item is created to put into the backlog. The work item should include the properties shown in Figure 1.7:
Figure 1.7: Work item
Name.Description of the work to be done, the work product to be created, or the risk to be addressed.The acceptance criteria – how the adequacy of the work performed, the work product created, or the outcome produced will be determined.The work item classification identifies the kind of work item it is, as shown on the left side of Figure 1.3.The work item’s priority is an indication of how soon this work item should be addressed. This is discussed in the Prioritize work item step of this recipe. The estimated effort is how much effort it will take to perform the task. This can be stated in absolute terms (such as hours) or relative terms (such as user story points). This topic is addressed in the Estimating effort recipe later in this chapter. Links to important related information, such as standards that must be met, or sources of information that will be helpful for the performance of the work.Approve work item
Before a work item can be added, it should be approved by the team or the project leader, whoever is granted that responsibility.
Prioritize work item
The priority of a work item determines in what iteration the work will be performed. Priority is determined by a number of factors, including the work item’s criticality (how important it is), its urgency (when it is needed), the availability of specialized resources needed to perform it, usefulness to the mission of the iteration, and risk. The general rule is that high-priority tasks are performed before lower-priority tasks. This topic is covered in the Work item prioritization recipe later in this chapter.
Estimate effort
An initial estimate of the cost of addressing the work item is important because as work items are allocated to iterations, the overall effort budget must be balanced. If the effort to address a work item is too high, it may not be possible to complete it in the iteration with all of its other work items. The agile practice of work item estimation is covered in the Estimating effort recipe later in this chapter.
Place work item in project backlog
Once approved and characterized, the work item can then be put into the project backlog. The backlog is priority-ordered so that higher-priority work items are “on top” and lower-priority work items are “below”.
Allocate work item to iteration backlog
Initial planning includes the definition of a planned set of iterations, each of which has a mission, as defined above. Consistent with that mission, work items are then allocated to the planned iterations. Of course, this plan is volatile, and later work or information can cause replanning and a reallocation of work items to iterations. Iteration planning is the topic of the recIteration plan recipe later in this chapter.
In the second work flow of this recipe, the work is actually being done. Of relevance here is how the completion of the work affects the backlog (Figure 1.6).
Perform work item
This action is where the team member actually performs the work to address the work item, whether it is to analyze a use case, create a bit of architecture, or perform a safety analysis.
Review work performed
The output and/or outcome of the work item is evaluated with respect to its acceptance criteria and is accepted or rejected on that basis.
Reject work performed
If the output and/or outcome does not meet the acceptance criteria, the work is rejected and the work item remains on the backlog.
Remove resolved work item
If the output and/or outcome does meet the acceptance criteria, the work is accepted and the work item is removed from the project and iteration to-do backlog. This usually means that it is moved to a “to-done” backlog, so that there is a history of the work performed.
Review backlog
It is important that as work progresses, the backlog is maintained. Often, valuable information is discovered that affects work item effort, priority, or value during project work. When this occurs, other affected work items must be reassessed and their location within the backlogs may be adjusted.
Reorganize backlog
Based on the review of the work items in the backlog, the set of work items, and their prioritized positions within those backlogs, may require adjustment.
Example
Consider a couple of use cases for the sample problem, the Pegasus Bike Trainer summarized in Appendix A (see Figure 1.8):
Figure 1.8: Example user case work items in backlog
You can also show at least high-level backlog allocation to an iteration on a use case diagram, as shown in Figure 1.9. You may, of course, manage backlogs in generic agile tools such as Rational Team Concert, Jira, or even with Post-It notes:
Figure 1.9: Use case diagram for iteration backlog
Let’s apply the workflow shown in Figure 1.5 to add the use cases and user stories from Figure 1.8 and Figure 1.9.
Create work item
In Figure 1.8 and Figure 1.9, we see a total of seven use cases and eight user stories. For our purpose, we will just represent the use case data in tabular form and will concentrate only on the two use cases and their contained user stories from Figure 1.9. The description of the user stories is provided in the canonical form of a user story (see the chapter introduction in Chapter 2, System Specification: Functional, Safety, and Security Analysis for more details).
Figure 1.10: Initial work item list
For the work item list, I created a stereotype work item that has the tag definitions shown as columns in the table and then applied it to the use cases and user stories.
Approve work item
Figure 1.11: Working with the team and the stakeholders, we get approval for the work items in
As we get approval, we marked the Approved column in the table.
Prioritize work item
Using the techniques from the Work item prioritization recipe later in this chapter, we add the priorities to the work items.
Estimate effort
Using the techniques from the Estimating effort recipe later in this chapter, we add the estimated effort to the work items.
Our final set of work items from this effort is shown in Table 1.1:
Name
OK
Description
Acceptance
Classification
Priority
Effort
Iteration
Related
Setup bike fit
Enable rider to adjust bike fit prior to ride
Standard riders* can replicate their road bike fit on the Pegasus.
Use Case
4.38
13
*Standard riders include five riders of heights 60, 65, 70, 75, and 76 inches.
Adjust handlebar reach
As a rider, I want to replicate the handlebar reach on my fitted road bike.
Standard riders* can replicate their handlebar reach from their fitted road bikes.
User Story
3.33
3
Adjust handlebar height
As a rider, I want to replicate the handlebar height on my fitted road bike.
Standard riders* can replicate their handlebar height from their fitted road bikes.
User Story
4.33
3
Adjust seat reach
As a rider, I want to replicate the seat reach on my fitted road bike.
Standard riders* can replicate their seat reach from their fitted road bikes.
User Story
11.67
3
Adjust seat height
As a rider, I want to replicate the seat height on my fitted road bike.
Standard riders* can replicate their seat height from their fitted road bikes.
User Story
13.33
3
Select crank length
As a rider, I want to replicate the crank arm length on my road bike.
Support crank lengths of 165, 167.5, 170, 172.5, and 175 mm.
User Story
1.2
1
Control resistance
Control the resistance to pedaling in a steady and well-controlled fashion within the limits of normal terrain road riding.
Replicate pedal resistance to within 1% of measured pedal torque under the standard ride set*.
Use Case
2
115
*Standard ride set includes ride of all combination of rider weights (50, 75, and 100kg), inclines (-10, 0, 5, 10, and 20%) and cadences (50, 70, 80, 90, and 110).
Provide basic resistance
As a rider, I want basic resistance provided to the pedals so I can get a workout with an on-road feel in Resistance Mode.
Control resistance by setting the pedal resistance to 0–2000W in 50-watt increments for the standard ride set.*
User Story
1.42
55
Set resistance under user control
As a rider, I want to set the resistance level provided to the pedals to increase or decrease the effort for a given gearing, cadence, and incline.
Control resistance via user input by manually setting incline, gearing, and cadence for the standard ride set.*
User Story
1.00
21
Set resistance under external control
As a rider, I want the external training app to set the resistance to follow the app’s workout protocol to get the desired workout.
Control resistance via app control, manually setting incline, gearing, and allow the user to supply cadence for the standard ride set.*
User Story
0.30
39
Table 1.1: Final work item list
Place WI in project backlog
As we complete the effort, we put all the approved work items into the project backlog, along with other previously identified use cases, user stories, technical work items, and spikes. The backlog can be managed within the modeling tool, but usually external tools – such as Jira or Team Concert – are used.
Allocate WI to iteration backlog
Using the technique from the Iteration plan recipe later in this chapter, we put relevant work items from the project backlog into the backlog for the upcoming iteration. In Table 1.1, this would be done by filling in the Iteration column with the number of the iteration in which the work item is performed.
With regard to the second workflow from Figure 1.6, we can illustrate how the workflow might unfold as we perform the work in the current iteration.
Perform work item
As we work in the iterations, we detail the requirements, and create and implement the technical design. For example, we might perform the mechanical design of the handlebar reach adjust or the delivery of basic resistance to the pedals with an electric motor.
Review work performed
As the work on the use case and user stories completes, we apply the acceptance criteria via verification testing and validation. In the example we are considering, for the set of riders of heights 60, 65, 60, 75, and 76 inches, we would measure the handlebar height from their fitted road bikes and ensure that all these conditions can be replicated on the bike. For the Provide Basic Resistance user story, we would verify that we can create a pedal resistance of [0, 50, 100, 150, … 2000] watts of resistance at pedal cadences of 50, 70, 80, 90, and 110 RPM ± 1%.
Measuring your success
One of the core concepts of effective agile methods is to continuously improve how you perform your work. This can be done to improve quality or to get something done more quickly. In order to improve how you work, you need to know how well you’re doing now. That means applying metrics to identify opportunities for improvement and then changing what you do or how you do it. Metrics are a general measurement of success in either achieving business goals or compliance with a standard or process. A related concept – a Key Performance Indicator (KPI) – is a quantifiable measurement of accomplishment against a crucial goal or objective. The best KPIs measure achievement of goals rather than compliance with a plan. The problem with metrics is that they measure something that you believe correlates to your objective, but not the objective itself. Some examples from software development:
Objective
Metric
Issues
Software size
Lines of code
Lines of code for simple, linear software aren’t really the same as lines of code for complex algorithms
Productivity
Shipping velocity
Ignores the complexity of the shipped features, penalizing systems that address complex problems
Accurate planning
Compliance with schedule
This metric rewards people who comply with even a bad plan
Efficiency
Cost per defect
Penalizes quality and makes buggy software look cheap
Quality
Defect density
Treats all defects the same whether they are using the wrong-sized font or something that brings aircraft down
Table 1.2: Examples from software development
See The Mess of Metrics by Capers Jones (2017) at http://namcook.com/articles/The%20Mess%20of%20Software%20Metrics%202017.pdf
Consider a common metric for high-quality design, cyclomatic complexity. It has been observed that highly complex designs contain more defects than designs of low complexity. Cyclomatic complexity is a software metric that computes complexity by counting the number of linearly independent paths through some unit of software. Some companies have gone so far as to require all software to not exceed some arbitrary cyclomatic complexity value to be considered acceptable. This approach disregards the fact that some problems are harder than others and any design addressing such problems must be more complex. A better application of cyclomatic complexity is to use the metric as a guide. It can identify those portions of a design that are more complex so that they can be subjected to additional testing. Ultimately, the problem with this metric is that complexity correlates only loosely to quality. A better metric for the goal of improving quality might be the ability to successfully pass tests that traverse all possible paths of the software.
Good metrics are easy to measure, and, ideally, easy to automate. Creating test cases for all possible paths can be tedious, but it is possible to automate with appropriate tools. Metrics that require additional work by engineering staff will be resented and achieving compliance with the use of the metric may be difficult.
While coming up with good metrics may be difficult, the fact remains that you can’t improve what you don’t measure. Without measurements, you’re guessing where problems are and your solutions are likely to be ineffective or solve the wrong problem. By measuring how you’re doing against your goals, you can improve your team’s effectiveness and your product quality. However, it is important that metrics are used as indicators rather than as performance standards because, ultimately, the world is more complex than a single, easily computed measure.
Metrics should be used for guidance, not as goals for strict compliance.
Purpose
The purpose of metrics is to measure, rather than guess, how your work is proceeding with respect to important qualities so that you can improve.
Inputs and proconditions
The only preconditions for this workflow are the desire, ability, and authority to improve.
Outputs and postconditions
The primary output of this recipe is objective measurements of how well your work is proceeding or the quality of one or more work products. The primary outcome is the identification of some aspect of your project work to improve.
How to do it
Metrics can be applied to any work activity for which there is an important output or outcome (which should really be all work activities). The workflow is fairly straightforward, as shown in Figure 1.11:
Figure 1.12: Measuring success
Identify work or work product property important to success
One way to identify a property of interest is to look where your projects have problems or where the output work products fail. For engineering projects, work efficiency being too low is a common problem. For work products, the most common problem is the presence of defects.
Define how you will measure the property (success metric)
Just as important to identifying what you want to measure is coming up with a quantifiable measurement that is simultaneously easy to apply, easy to measure, easy to automate, and accurately captures the property of interest. It’s one thing to say “the system should be fast” but quite another to define a way to measure the speed in a fashion that can be compared to other work items and iterations.
Frequently measure the success metric
It is common to gather metrics for a review at the end of a project. This review is commonly called a project post-mortem. I prefer to do frequent retrospectives, at least one per iteration, which I refer to as a celebration of ongoing success. To be applied in a timely way, you must measure frequently. This means that the measurements must require low effort and be quick to compute. In the best case, the environment or tool can automate the gathering and analysis of the information without any ongoing effort by the engineering staff. For example, time spent on work items can be captured automatically by tools that check out and check in work products.
Update the success metric history
For long-term organizational success, recorded performance history is crucial. I’ve seen far too many organizations miss their project schedules by 100% or more, only to do the very same thing on the next project, and for exactly the same reasons. A metric history allows the identification of longer-term trends and improvements. That enables the reinforcement of positive aspects and the discarding of approaches that fail.
Determine how to improve performance against the success metric
If the metric result is unacceptable, then you must perform a root cause analysis to uncover what can be done to improve it. If you discover that you have too many defects in your requirements, for example, you may consider changing how requirements are identified, captured, represented, analyzed, or assessed.
Make timely adjustments to how the activity is performed
Just as important to measuring how you’re doing against your project and organizational goals is acting on that information. This may be changing a project schedule to be more accurate, performing more testing, creating some process automation, or even getting training on some technology.
Assess the effectiveness of the success metric application
Every so often, it is important to look at whether applying a metric is generating project value. A common place to do this is the project retrospective held at the end of each iteration. Metrics that are adding insufficient value may be dropped or replaced with other metrics that will add more value.
Some commonly applied metrics are shown in Figure 1.13:
Figure 1.13: Some common success metrics
It all comes back to you can’t improve what you don’t measure. First, you must understand how well you are achieving your goals now. Then you must decide how you can improve and make the adjustment. Repeat. It’s a simple idea.
Visualizing velocity is often done as a velocity or burn down chart. The former shows the planned velocity in work items per unit time, such as use cases or user stories per iteration. The latter shows the rate of progress of handling the work items over time. It is common to show both planned values in addition to actual values. A typical velocity chart is shown in Figure 1.14.
Velocity is the amount of work done per time unit, such as the number of user stories implemented per iteration. A burn down chart is a graph showing the decreasing number of work items during a project.
Figure 1.14: Velocity chart
Example
Let’s look at an example of the use of metrics in our project:
Identify work or work product property important to success
Let’s consider a common metric used in agile software development and apply them to systems engineering: velocity. Velocity underpins all schedules because it represents how much functionality is delivered per unit time. Velocity is generally measured as the number of completed user stories delivered per iteration. In our scope, we are not delivering implemented functionality, but we are incrementally delivering a hand-off to downstream engineering. Let’s call this SE Velocity, which is “specified use cases per iteration” and includes the requirements and all related SE work products.
This might not provide the granularity we desire, so let’s also define a second metric, SE Fine-Grained Velocity, which is the number of story points specified in the iteration:
Define how you will measure the property (success metric)
We will measure the number of use cases delivered, but have to have a “definition of done” to ensure consistency of measurement. SE Velocity will include:
Use case with:Full description identifying purpose, pre-conditions, post-conditions, and invariants.Normative behavioral specification in which all requirements traced to and from the use case are represented in the behavior. This is a “minimal spanning set” of scenarios in which all paths in the normative behavior are represented in at least one scenarioTrace links to all related functional requirements and quality of service (performance, safety, reliability, security, etc) requirements Architecture into which the implementation of the use cases and user stories will be placed System interfaces with a physical data schema to support the necessary interactions of the use cases and user storiesLogical test cases to verify the use cases and user storiesLogical validation cases to ensure the implementation of the use cases and user stories meets the stakeholder needsSE Velocity will be simply the number of such use cases delivered per iteration. SE Fine-Grained Velocity will be the estimated effort (as measured in story points; see the Estimating effort recipe).
Frequently measure the success metric
We will measure this metric each iteration. If our project has 35 use cases, our project heartbeat is 4 weeks, and the project is expected to take one year, then our SE Velocity should be 35/12 or about 3. If the average use case is 37 story points, then our SE Fine-Grained Velocity should be about 108 story points per iteration.
Update the success metric history
As we run the project, we will get measured SE Velocity and SE Fine-Grained Velocity. We can plot those values over time to get velocity charts:
Figure 1.15: SE velocity charts
Determine how to improve performance against the success metric
Our plan calls for 3 use cases and 108 story points per iteration; we can see that we are underperforming. This could be either because 1) we overestimated the planned velocity, or 2) we need to improve our work efficiency in some way. We can, therefore, simultaneously attack the problem on both fronts.
To start, we should replan based on our measured velocity, which is averaging 2.25 use cases and 81 story points per iteration, as compared to the planned 3 use cases and 108 story points. This will result in a longer but hopefully more realistic project plan and extend the planned project by an iteration or so.
In addition, we can analyze why the specification effort is taking too long and perhaps implement changes in process or tooling to improve.
Make timely adjustments to how the activity is performed
As we discover variance between our plan and our reality, we must adjust either the plan or how we work, or both. This should happen at least every iteration, as the metrics are gathered and analyzed. The iteration retrospective that takes place at the end of the iteration performs this service.
Assess the affectiveness of the success metric applicaiton
Lastly, are the metrics helping the project? It might be reasonable to conclude that the fine-grained metric provides more value than the more general SE Velocity metric, so we abandon the latter.
Some considerations
I have seen metrics fail in a number of organizations trying to improve. Broadly speaking, the reasons for failure are one of the following:
Measuring the wrong thing
Many qualities of interest are hard to identify precisely (think of “code smell”) or difficult to measure directly. Metrics are usually project qualities that are easy to measure but you can only imprecisely measure what you want. The classic measure of progress – lines of code per day – turns out to be a horrible measure because it doesn’t measure the quality of the code, so it cannot take into account the rework required when fast code production results in low code quality. Nor is refactoring code “negative work” because it results in fewer lines of code. A better measure would be velocity, which is a measure of tested and verified features released per unit of time.
Another often abused measure is “hours worked.” I have seen companies require detailed reporting on hours spent per project only to also levy the requirement that any hours worked over 40 hours per week should not be reported. This constrained metric does not actually measure the effort expended on project tasks.
Ignoring the metrics
I have seen many companies spend a lot of time gathering metric data (and yes, it does require some effort and does cost some time, even when mostly automated), only to make the very same mistake time after time. This is because while these companies capture the data, they never actually use the data to improve.
No authority to intiate change
Gathering and analyzing metrics is often seen as less valuable than “real work” and so personnel tasked with these activities have little or no authority.
Lack of willingness to follow through
I have seen companies pay for detailed, quantified project performance data only to ignore it because there was little willingness to follow through with needed changes. This lack of willingness can come from management being unwilling to pay for organizational improvement, or from technical staff being afraid of trying something different.
Metrics should always be attempting to measure an objective rather than a means. Rather than “lines of code per day,” it is better to measure “delivered functionality per day.”
Managing risk
In my experience, most unsuccessful projects fail because they don’t properly deal with project risk. Project risk refers to the potential for change that a team will fail to meet some or all of a project’s objectives. Risk is defined to be the product of an event’s likelihood of occurrence times its severity. Risk is always about the unknown. There are many different kinds of project risk. For example:
