Low Level Design Guidance
Tips to Push the Design Forward When Communicating with Teammates
Process Related Guidance to Remain on Track and Drive The Conversation Forward
It is often difficult to get everyone on the same page and share the correct knowledge. Oftentimes, the SMEs will assume you know certain things because "it's obvious" to them.
Use Specificity to Gain Incite
"User Models- Better wrong than vague. "Truth will sooner come out of error than from confusion." Sir Francis Bacon [1620]" (pg113, The Design of Design: Essays from a Computer Scientist) "The designer should guess or, if you prefer, postulate a complete set of attributes and values, with guessed frequency distributions, in order to develop complete, explicit, and shared user and use models. An articulated guess beats an unspoken assumption. Wrong ones will perhaps be questioned; vague ones won't" (pg116-117, The Design of Design: Essays from a Computer Scientist)
Record Keeping: Record Rational
"Keep a dated journal of your design questions, decisions, and reasons." (pg254, The Design of Design: Essays from a Computer Scientist) Do an assessment afterwards (aka lessons learned). A good way to record incites is to put rational within your model diagrams or the element documentation pane with the date of the decision and name of the person/group who made the decision.
When to Thread
Thread When It Makes Sense
Digital threads from Cameo to other softwares are often difficult to make but critical for the success of the model long term. Threads should be made because another software tool exists which executes some function well; this could be a simulation engine, a 3D modelling tool, a database, etc. Some (The academics selling Cameo and some leadership) believe that Cameo can and should "do everything" and over time threads will become less and less useful. We believe the opposite; we believe there will continue to be tool suites which can do their specific function better than Cameo would have performed that function. Just because Cameo can do the job, doesn’t mean it should be used to do the job.
For example: Matlab is a much more robust mathematical solver than cameo which is ran off of Javascript which has a lot of overhead computing. Therefore it makes since to farm out the computationally demanding tasks to softwares which were built to be efficient solvers.
Balance of Domain Content
Balance Attributes: Goldplating In One Design Aspect Will Set You Back on Another
"In characterizing the systems engineering viewpoint, two oft - stated maxims are “ the best is the enemy of the good enough ” and “ systems engineering is the art of the good enough. ” These statements may be misleading if they are interpreted to imply that systems engineering means settling for second best. On the contrary, systems engineering does seek the best possible system, which, however, is often not the one that provides the best performance. The seeming inconsistency comes from what is referred to by best. The popular maxims use the terms “ best ” and “ good enough ” to refer to system performance, whereas systems engineering views performance as only one of several critical attributes; equally important ones are affordability, timely availability to the user, ease of maintenance, and adherence to an agreed - upon development completion schedule. Thus, the systems engineer seeks the best balance of the critical system attributes from the standpoint of the success of the development program and of the value of the system to the user. " (Model Based Systems Architecture, pg28)
Adding Fidelity Appropriately
Concepts on expanding the model, how to grow in the right direction in a modular and scalable way. This will help you navigate the maze of content addition and avoid pinning yourself in a corner where a lot of rework may be required to proceed. See Phase II for more information.
Diagram Layout Guidelines
Diagram Layout Guidelines
Reading direction is from top to bottom, left to right. Layout diagrams to conform to this method.
A diagram should not contain more than 7+/-2 major elements
A diagram should have a printable layout
Rarely use colors in diagrams, because of color-blind people and monitors and printers which do not show colors appropriately
One diagram has one purpose. A new purpose requires a new diagram.
Look through the eyes of the model reader when you create a diagram and not the model builder.
Clearly separate diagram creation from model building.
(Model Based Systems Architecture, pg69)
Balance of Modularity & Complexity
Modularity
"In the case of complicated systems, modularity is the goal of good systems engineering because by creating a modular design, we make parts of the system easier to develop, maintain, and replace. By creating a poor design, we can make our systems immodular and harder to maintain and operate."
Complexity
"As systems gain in complexity, the interactions become nonlinear, and the behavior of the system becomes dynamic and harder to predict. Since the behavior of complex systems is hard to predict, they very often surprise us."
"Complex systems become difficult to model and simulate due to the interacting web of dependencies. At the far end of the complexity spectrum we even find chaotic behavior characterized by the “butterfly effect” where small changes in initial conditions lead to drastically different results."
Modularity & Complexity
"Complexity drives immodularity by increasing the interdependencies among the parts of a system. We also learn that as systems become more complex, we can eventually lose our ability to effectively engineer those systems. As systems engineers, we can no longer avoid immodularity, because complexity is forcing us away from easily predictable, elegant, modular designs. We will increasingly deal with systems that are not fully predicable and that may have messy designs. The key for systems engineers is to develop new techniques that will help deal with systems of greater complexity. As systems engineers developing complicated systems, we avoided immodularity to control variables and make our systems predictable."
Function and Location
Each piece of hardware for a system has a function and a location.
The way to read this diagram would be:
“IMU 34” is a type of “IMU”. “IMU 34” is a type of “AV Bay Payload”
Therefore, “IMU 34” inherits all of the value properties from “IMU” and from “AV Bay Payload”.
The “IMU” value properties would be all of the specs listed in a typical IMU spec sheet.
The “AV Bay Payload” could have compatibility constraints such as ensuring “IMU 34” would fit in the location properly.
The reason this method is used is so that you can easily scale to add more hardware and have the ability to tabulate both all IMUs and all AV Bay Payloads. From a coding perspective, “IMU” and “AV Bay Payload” can be thought of as classes.
A Quick Note Style Guides
"To Get a Consistent Style—Document It! A design style is defined by a set of microdecisions. A clear style reflects a consistent set. A clear style may not be a good style; a muddled one never is. The aspiring designer must therefore strive for consistency of style." (Model Based Systems Architecture, pg148)
In my experiences, the style guide is so in depth none of the designers which are supposed to follow it do not read it. For this reason, I would refer back to creating an "elegant" style guide. One that is only a few pages and can explain the intensions of the style and not the 900 pages of detail.
Additional Tidbits
Random Helpful Advice & Rules of Thumb
"The designer should avoid limiting a function by his own notions about its use. When you don’t know, grant freedom." (pg144, The Design of Design: Essays from a Computer Scientist)
"Be careful how you fix what you don't understand" (pg185, The Design of Design: Essays from a Computer Scientist)