The document discusses introducing model-based systems engineering (MBSE) into existing or legacy projects, known as "brown field" or "gray field" projects. It defines key terms like green field, brown field, and gray field projects. It acknowledges the challenges of applying MBSE to existing projects where architectures and components are already defined. The document proposes an iterative approach to MBSE for existing projects that focuses on new requirements and features, uses existing system components when possible, and aims handoffs to align with downstream development sprints. It provides examples from two organizations applying these MBSE techniques to their existing weapon system and vehicle projects.
2. When The Field Isn’t Green:
Introducing Model Based Systems Engineering
into an Existing/Legacy/Maintenance Projects
Jeffrey R. Cohen, P.E.
Sr. Solutions Consultant
321 Gang
jeff@321gang.com
https://www.linkedin.com/in/jeffreyrcohen/
Twitter: CohenJeffrey
The Continuous Engineering Experts TM
www.321gang.com
4. www.321gang.comThe Continuous Engineering Experts.
TM
Defining Some Terms
Green Field
New Project
Model Based Systems Engineering from Beginning
Major Components (Blocks) Not Defined
Interfaces Not Defined
Trade Studies Influence Design
Brown Field (Gray Field)
Built onto Existing Project
• Maintenance Project
• Sustainment Project
Document Intensive Systems Engineering
Major Components (Blocks) Defined and Often Cannot Change
Interfaces Defined
Trade Studies Done Long Ago, Existing Can’t Change
5. www.321gang.comThe Continuous Engineering Experts.
TM
We Know What to do for Green Fields
For Green Field, We Know What To Do
Harmony aMBSE (Bruce Douglass)
MBSE Consulting and Training Method (Frasier Chadburn)
Object Oriented Systems Engineering Method (OOSEM)
General Flow for New Projects
Requirements Analysis
Functional Analysis
Architectural Analysis (with trade studies)
Architectural Design/Design Synthesis
Interface Detailed Design
6. www.321gang.comThe Continuous Engineering Experts.
TM
But What About Gray Fields: Problem Statement
PROBLEMS for Gray Field Projects:
Architecture is Set
Functional Analysis Restricted (Can’t change existing subsystems)
No Money/Resources for Modeling Existing Systems
Reluctance to Change to MBSE because Documents are Deliverables
Downstream Groups Expectations
Common Objections:
• “Why Can’t You Just…”
• “That’s Not How We Did It Before”
• “This is fixed cost, even though <<manager>> wants SysML, I don’t think we can afford it”
• “You have to understand, we’ve been maintaining <<project>> for <<number of>> years. We
know what we are doing”
• “Well, the model is fine, but I have to deliver my <<document>> on schedule”
All about selling change that increases benefits while reducing disruption
7. www.321gang.comThe Continuous Engineering Experts.
TM
Approach
Start With Handoff Artifacts and Work Backwards
Generic Systems Engineering Approach
Iterative
Align Iterations with Downstream Sprint*
Key Differences to Green Field:
Only Import New Requirements
• Existing Requirements are in Requirements Database
• Trace as Needed
Only Modeling New Features
Use Existing Components (when possible)
• New Components = New Blocks
• Modified Components = New Blocks
• Existing Unmodified Components Modeled as ”Shell” Blocks Differentiated
with Stereotype
Import New
Requirements
Use Cases for
New Features
Refine Use
Cases
Allocate
Functionality
Update
Interfaces
8. www.321gang.comThe Continuous Engineering Experts.
TM
Identify Handoff Artifacts and Work Backwards
1. Meet with Downstream to Identify Wants and Needs
• Identify Key Symptoms
• Identify Big and Little Issues that Make Life Difficult
• Identify Current Handoff
• Identify Desired Handoff Elements
• Identify Development Process
2. New (or Expanded) Features Identify Use Cases
• Features Come from Agreements with Customer (often NOT formal SOW)
• Features Descriptions from Customer Often Documented as Main Flow Only
3. Refine Use Cases with Activity Diagrams or State Charts
• Systems Engineers Prefer Activity Diagrams
• Refined Use Cases Provided Source Material for ConOps (Deliverable)
4. Entire Use Case Allocated to Subsystem with Interfaces
9. www.321gang.comThe Continuous Engineering Experts.
TM
Hardly a Trend, but Similar Handoff Desires
Two organizations, Very Different Spaces, Similar Issues
Organization 1: Defense Contractor on Sustainment for Old Weapon System
Organization 2: Modifying a Manned Vehicle to an Unmanned Vehicle
Organization 1 Findings:
Exception Conditions Not Specified
Some Functionality Specified too Deep
Little Understanding of Cross-Functional Dependencies Leads to Errors During Integration
Test
Power Point and <<document>> were not maintained with latest requirement changes under
source control. The result was misaligned code going to build/test
Organization 2 Handoff Elements:
A Lot of Systems Engineering Already Done, but Model Desired to Explain Complexity
Activity diagrams, sequence diagrams. Indicate where changes will occur
Interfaces did not change for this project due to the messaging structure
10. www.321gang.comThe Continuous Engineering Experts.
TM
Example Findings: Key Symptoms (Org 1)
Frequent Interruptions by Downstream Teams
Unknown Rippled Failures
No Optimization Analysis Leading to Resource Constraints
Rework
oRework S/W due to missing requirements for non-normative conditions
oFailed both V&V
oRequirements Rework
Required Document Out of Sync with Code
11. www.321gang.comThe Continuous Engineering Experts.
TM
Example: Handoff Today
Org 1 Sustainment Projects
SRS (interim <<concept document>>) 4 x per year
PowerPoint diagrams from customer meetings
• Only sunny day scenarios, few exceptions
• Sometimes Markups from Meetings Not Delivered to Team
Org 1 New Development
Requirements from Customer
• Often incomplete
• Not fully analyzed for FMEA
PowerPoint
• Changes
• Interface
• Text and Pictures
Org 2 Development
Requirements in DOORS
Con Ops Documents
12. www.321gang.comThe Continuous Engineering Experts.
TM
Example: Handoff– What S/W Finds Useful (Org 1)
Interfaces
• Logical
Blocks/Ports/Interface Blocks
• Detailed Design
Enumerations
Interface Block with message structure
Behavior Model
• State Charts
• Activity Diagram
• Sunny day and non-normative paths (Sequence Diagrams)
Overall Behavior for the Changed Thread of Execution
Text Requirements with traces
13. www.321gang.comThe Continuous Engineering Experts.
TM
Example: Typical Desired Handoff Environment
System/Subsystem Model visible to Software Engineer
Systems Model included by Reference – Does not get
modified during a sprint
Systems Model “delivered” to CM at end of each
Systems sprint. Picked up by Software for their next
sprint.
Packages included by Reference to trace
*NOTE: Screenshot for reference only. Not a real screenshot from
Org 1 or Org 2
14. www.321gang.comThe Continuous Engineering Experts.
TM
So What’s a Systems Engineer to do?
Start with the handoff artifacts in mind
Deliver Use Cases refined with Activity Diagrams
Indicate Likely Regions for Change
Assume Interaction and Allocation Among New Components (or those funded to change)
Assume Interface Message Structures will ONLY Change if Necessary
Move to Iterative Development Aligned with Software Sprints (a la SAFe)
For Internal Model Elements
• Blocks to represent External Entities and Existing Entities
• Tried actors, but ended up creating blocks to show interfaces
• Interfaces and Interface Blocks for LOGICAL Interfaces
• New Functionality Allocated as Use Cases Refined with Activity Diagrams
• All Actions on an Activity Tend to be Allocated to One Subsystem (block or part)
• Some Actions were allocated to multiple subsystems including existing subsystems
• Required more modeling; Required new interfaces; Required new qualification tests
15. // Shameless Promotion
The Continuous Engineering Experts TM
www.321gang.com
See My New Modeling
Video Series:
https://ptdrv.linkedin.com/fg24i8v
I went to school in Pittsburgh and watched the destruction of the old J&L Steal Mill
Term Gray Field because you don’t get to tear down to the base and start anew
Process and Workflows for Green field projects are well known and well understood
No matter which specific methodology, all tend to have same general flow
Sell advantages:
Easier and Quicker Understanding
See inconsistencies earlier
Exception conditions earlier
* Two thoughts here. First is to align. Second is that the Systems Engineers belong at a higher level across multiple delivery teams. In this second case, Systems Engineers output is the backlog for the next Project Interval
Photo Credit: Patrick Bell from Haddonfield, NJ, USA
From Wikipedia under common use license
I’m not identifying the clients, just some generic