System Engineering & Design Architecture - Sander R.B.E. Beals (books to get back into reading txt) 📗

making it a 'cell phone' in more than one way: if you place it on the table with the screen down, the cells can charge the battery for you, thus leading to longer life....

OK, so we have some idea of what a System is in terms of its primary aspects. But how do we shape this into a clear and simple design strategy, that will be similar in approach for any hybrid system we could think of?

Keep It Simple Sir....

That IMHO is the best place to start with: since humans are reportedly only capable of juggling at most seven concepts at any one time, our approach should be to not exceed that limit, as Queen hinted with the cover of their album Innuendo. That subconsciously (behind our backs) we also handle way more things is also concealed in that image....

The SevenSphere also hints at that limit, since we can clearly see that adding more spheres will 'force' them to be added to the essentially flat form either behind, before, or outside the round symbol we call the SevenSphere. Now before and behind there are 6 extra spots, but only three of those may be filled on any side at the same time. Once we hit thirteen (7+3+3+1), expansion beyond the bigger Sphere in which the SevenSphere lives is inevitable. Is that why we call thirteen the number of bad luck, because it requires growth?

My Dad used to say: "Colt 45, seven dead: six you shoot, the seventh you throw it at!" And as a matter of keeping it simple, that is his tools approach: use it as intended as long as you can, even if that means having to improvise. My approach is different: I consider myself a problem solver, and as such I try to devise new tools to solve problems or new uses for existing tools. And as for my wildest personal dream: solving the conundrum of problem solving, wouldn't that be awesome? On the other hand, it seems more like a trip of discovery rather than a design approach. It is as if everything is already there... (and I'm just connecting the dots....)

A problem is only a problem if one is aware of it. And once you are aware of it, there are two ways of dealing with it: you either create a solution, or adapt to the problem, so it is not a problem anymore. And if you do choose an approach, you will need feedback in order to determine if you have reached your desired position of 'Problem Solved'. Now despite the fact that the title track of the movie 'Triple X' on my TV screen just had someone sing: "You're going to extremes, there's nothing in between", I figure there is: we could see the problem as an extreme opposite of our current position, and go all out to annihilate it, or see us and the problem as just two nearby specs in the infinity of possible approaches.

In that last case, there is always a solution, and it can be found quite easily, as long as we keep it simple. If we want to do that, what are our options? What are the most used and succesful mechanisms for getting to a simple and clean solution? Well, let's see (details in Appendix A):

K eep I t S imple S ir.... (or Sister, no gender issue intended)

80 / 20 % rule.

Divide and Conquer.

Stepwise Refinement.

Occam's Razor.

Thinking outside the Box.

The 7 item rule. (implied in the SevenSphere)

I'm not drawing that diagram, since you could see it coming a mile away. But keep these in mind, for they will come in handy. Going back to the discussion with my colleague, this mainly had to do with the amount of effort required to reach success in the various stages of development. I guess that is the next concept we have to look at closer, in order to get to our aim of a generic approach to Systems development.

Sofar it has all been pretty standard, right? It is generic enough to apply to either software or hardware design, or even something like fashion designing (even there the cutting patterns form the design). But in the rest of this document, we will be tackling all of these six stages in a new way, that also keeps in mind the 7 mechanisms mentioned above. And guess what? There is even some stuff to describe about this diagram on the right here, which may not have been obvious to everyone:

Analysis, Design and Implementation are creational aspects of the development, and thus form a stable triangle.

Requirements, Documentation & Systems Testing are also related because they are the phases that produce documentation, and consolidation of the design and product. These belong to the product, but aren't the essence of what we aim to produce. They show the limitations of the system, so you won't dry your cat in a microwave and then complain that the manual should have warned about that... Also, the testing part uses the other two to verify that the triangle of creation was executed correctly.

Apart from that, the six phases are all in sequence around the center, as they are passed on the road to Problem Solution.

 

What is also a new approach in this document, is that we'll be moving the responsibilities around a bit. Just like Object Oriented Software Design treated the Classes as responsible for their purpose, we will be treating the entire development effort like it is responsible for its own role in the process. And we'll start by combining some concepts from OO in order to show how we get things done:

Now from here on in, it is going to be a bit different, because we will be looking at the System Aspects as if they are based on the two most used mechanisms in Object-Oriented programming:

Model, View, Controller.

Object Action principle.

 

To make it an even six again, we will add to that a new aspect called Integrity, which basically turns Quality into an attribute of the System, rather than trying to apply it from outside like a band aid. If something requires testing before release, it requires testing even out there!

No doubt software for disciplines like hardware and building design has for several decades now included the calculations which determine whether the parts will endure the stresses on them so they are in fact source code that calculates the physical parts in terms of their actual minimal required dimensions given the material it's made of and its required strength.

In this case it is easy to see how the virtual world precedes the real one. So why not add Integrity to the System aspects in all types of Systems, hybrid or not? Based on what design discipline we are in, the concept of such integrity checking would be like polymorphism in Object Oriented programming: Even though the stuff needed to prove the system is working may be widely varying, it would in fact mean that the system has a 'standard' approach to determine its validity: SelfTest would mean "How do I feel?" to a human, but "Full Systems Check" to an android. It basically means the Three Laws of Robotics would be amended by a fourth directive, which would enable a system to determine if its behavior is still within the range of 'zero defects' for both humans and androids, which is actually required to be able to obey the three laws! Software for any system would actually have built in safeguards to determine stuff like:

Are my crucial methods still error free?

If I have redundant interfaces, is at least one of them active?

Is my Model still up-to-date?

Are my associates (other classes) of the correct version?

Can I reach all my partners through their respective interfaces?

Do I have error conditions for which help from the outside is needed?

(outside being other systems within its environment, or even outside it)

 

Now for software that seems like an extra load on the system at runtime, but for the hardware part of the system, it would be done in the design program, and not in the manufactured product. Likewise, such checks could be partially or totally switched off in production releases of the software, even though programmers could use it to figure out the real problems faster because of the extra checks where it matters. But should we ever switch off the integrity tests, given the performance of todays systems?

If we want to mimic Nature in Design and Engineering, we basically only have to look at ourselves with a bit of analytical effort:

"what exactly do I do when I am working?"

We've developed a simple mechanism for that, which is kind of like the two SevenSpheres on the right: the top one is usually where we find ourselves from moment to moment, while going through a certain routine that isn't routine enough to allow us to do it without thought and attention. Keeping your attention on the task at hand is something an average human is said to only be able to do for about for about five minutes if we talk about children, and up to 20 minutes for fully grown adults. Now any task is usually non-atomic, and prone to incoming higher-priority tasks. Kinda like the needle that punctures the egg, the new task invades our awareness, and demands we drop the Current Task. Our default action should then be to immediately go to the red sphere in the top diagram, and record whatever information we need to pick up the current task later on. The top diagram is cycled clockwise, from he start of the task to the end.

The second SevenSphere is a 2x3 configuration: normally, we attempt to keep a nice balance between our Priority Stack, QA Effort and Incoming other tasks, right until the moment the work runs out. In that case, we switch to the triangle of Cleanup, Reorganize and Current Task, the last one being whatever we deem most fun and/or useful, whatever the Environment you find yourself in. Mind you though: if chaos interferes with our normal way of working long enough, then the second triangle may become the Incoming projectile that requires we take time to Clean Up and Reorganize before preceeding with the task at hand. Currently, I'm in here writing this document because to me this is a Cleanup and Reorganize effort that can fit into the current wait for my colleague to help me fix a certain problem for which my talents and knowhow just aren't sufficient. In a similar way, I just spent a good ten minutes sorting out the mess of cables underneath my desk, because my feet were getting caught in it.....

Now that last one was an ad-hoc action, basically aimed at improving my working life. But like they say programmers are lazy, and I'm no exception. Even though I'm a tester now, I still keep my solutions as simple as possible:

If you find yourself in rest, try to figure out which action is needed next. Basically, that is the diagram on the previous page.

If you know the action to take, ask yourself if it is an action that needs to be repeated in the future maybe. Because if