(c) Bruce Powel Douglass, Ph.D. 2019

Dec 10, 2018

Question regarding Deployment View Pkg


I like the model organization structure that Harmony aMBSE is suggesting in Agile System Engineering, chapter 3.3 Organize Your Models Like It Matters.


I have one question though:

What is the reason that the Deployment View Pkg is in the subsystem models?


That means that there is no holistic Deployment View (sometimes also called "technical context"), because the information is split over different subsystem models, right?

I believe this view is especially important to integration and network guys. I also think that it is not a good idea to put a common Deployment View in the SE model as you do not want the dependencies to the physical interface packages there. I am wondering, does it make sense to keep a "complete" Deployment Package in the shared model?


Please let me know what you think.

Dec 10, 2018

The reason is that often, most of the interesting aspects of the deployment architecture take place at the subsystem level; a subsystem is an interdisciplinary coherent set of functionality that is then decomposed with deployment architecture. However, this does not mean that system-wide deployment architecture is useless or even inappropriate. You can create various views of the architecture at the system level (and in the system model).


I've done this using different approaches for different circumstances. I might identify, one one diagram different engineering facets (i.e. aspect of a single engineering discipline) using color coding and/or stereotypes. Or, if each facet is sufficiently complex, create multiple diagrams each of which show a single engineering facet. For example, for the ACES system in the Deskbook, I might create one showing all the electronics, another showing all the hydraulics, and a third showing all the CPUs and the software facets.


When I create a system-wide deployment architecture, I STILL must create deployment architectures for each of the subsystems because those detailed decisions aren't made until during the hand off to downstream engineering, and those decisions are largely local to a specific subsystem.


Does that help?

- b

It does help. :-) One more question: What is the best location for the system-wide deployment view? Is it the shared model?

Jan 7Edited: Jan 7

I'd say it depends on its intended use. If it is to drive systems engineering work, then I'd suggest putting it in the Design Synthesis > Architectural Design package of the SE model. If it is primarily intended to inform downstream engineering work, then I'd put it in the shared model in its own Deployment Architecture package. If it is BOTH, then I'd define the logical deployment model in the SE model, but refine the Shared model to represent physical architecture. The reason why is that the SE model tends to me more focused on logical perspective (logical interfaces for example) but the subsystems teams really need the physical perspective since they are designing actual physical subsystems.


BTW, will you be at the Embedded World conference next month in Nuremberg? I'm there, although I'm pretty busy since I'm teaching 11 sessions.

@Bruce Douglass, I would really like to catch up, but I am not sure if I can make it happen. I will definitely let you if I can make it happen.

New Posts
  • Is Agile methodology suitable for Firmware development? More generally, when Hardware and Software must be co-developed and manufactured, would Agile still be a good approach for the software development? Perhaps, Firmware can still be decomposed into an OTP (One Time Programmable) piece + a piece that can be updated "over the air", in which case the latter could still follow Agile. But what has been your experience with real Firmware projects? Thanks
  • Dear Bruce, in Harmony ESW process you added User Stories as an additional starting point to the Microcycle. I think User Stories are usually used to describe the "problem" or "expectation" of a stakeholder regarding the "product". It is maybe something like a high level requirements elicitation approach, which differs from Use Cases. What are your experiences and best practices to work with User Stories (e.g. high level approach) and Use Cases (e.g. detailed approach) regarding high-fidelity modelling and requirements refinement? Do you have a taxonomy regarding requirements, use cases, user stories and modelling? Thank you. Best regards, Matthias
  • This forum is intended for discussions about processes and methods, focusing on agile and lean methods for systems engineering and embedded software development.