Friday, November 18, 2011
Academic engineering is a pretty new thing - once the engineers were educated by apprenticeships not by universities.
I think that in industry the SE is assigned rather specific task in the new product development process - in the defence setting the SE tasks are even mandated.
In academy the situation is different. What is Electronics Engineering Research if not the search of the new electronic technologies - sometimes the advances in physics are needed to advance the electronics but not always - so that's application of science not discovery.
The "hard engineering" disciplines are rooted in the exact sciences. That's not so for SE - the scientific component of the SE borders (some say lays in) social sciences domain - sore spot for academicians that thrive to belong to the Engineering part of the campus near the Physics, Chemistry etc buildings. The same challenge is faced by the Industrial Engineering practitioners and researchers.
So until we don't admit that SE science is inherently social we'll be stuck. Let's be true to ourselves - SE science is the science of social behavior of large groups of technical practitioners and managers (project teams) engaged in solving complex problems for other groups of people (stakeholders) by defining, developing, integrating and putting to use physical artefacts (systems).
Saturday, August 20, 2011
Thursday, July 28, 2011
- World 1 of physical object and events, accessible by all human beings given the right perceptions or equipment
- World 2 of mental objects and events, the inner world of human being accesible by only this human, and
- World 3 of objective knowledge that comprized the products of human thought - ideas, theories, stories, myths etc.
- Specialty Engineers (SpecIs) encode their mental models in executable information artefacts that allow production of physical objects by machines or skilled humans that don't have to share the engineers mental models. Examples - computer code is used by compiler/builder to encode physical computer file that may be run by a computer, mechanical drawing allows production of parts by workers/robots, electrical diagram allows to produce a circuit.
- Systems Engineers'/Integrators' mental models are encoded in information artefacts (or even communicated without physical encoding building the common understanding -the pure World 3 object) that are meant to create compatible mental models in the minds of other engineers. In that SE/SI are just like to architects, managers and leaders.
Saturday, June 18, 2011
When the managers say "Start Testing. When you'll find severe problems, investigate them and change the system. When the problems are not severe - proceed" they ask to start in the Evaluation Mode and change to Debugging Mode amidstream. Start as ST and change to SI if needed. No wonder that it's difficult for me to explain the difference between SI and ST - the managers frequently perceive the pair-wise encounters of some sub-systems that are done as part of sub-system testing combined with interface checking as the sufficient SI activity and try to drive the project into ST mode without conclusion of all SI activities such as E2E thread testing - they afterwards wonder why the ST phase takes as long as SI+ST phase that was proposed in the initial project plan and rejected as "too long ST".
I'd be delighted to forfeit talking about "System Testing" or "System Integration" and change to "System Debugging" (Subsystem Debugging, Interface Debugging, Whole System Debugging") and "System Evaluation" (or "System V&V").
Thursday, June 16, 2011
Tuesday, June 7, 2011
Monday, June 6, 2011
Monday, May 30, 2011
Once upon the time the giants walked the Earth. They built spacecraft, aircrafts, big ships, submarines, air defense systems. The gold was not a problem - any time when the Russian Bear growled in the woods, the Wise Councils opened their purse.
And then the Russian Bear have thrown the towel and the gold spring has gone dry (almost). Meanwhile the mean gnomes have overcome the world with their fancy software gadgets, and Eastern Dragons took over the commodities market. And then the Internet came - the wild beast that nobody could tame but everybody could ride.
And the giants retreated into these cave called NCOSE and then INCOSE. Meanwhile their legacy was forgotten and replaced by endless scrolls of SE standards and procedures.
Many young knights, peasants and serfs tried to seek their wisdom but they could not understand the language the giants spoke so they invented many languages of their own and the story of Babel tower repeated once again. But the giants laid silently in their cave speaking only once in a while and their voice has grown feebler and feebler until nothing was heard anymore.
I hope that I overreacted in the sadness of the fable - but this is the impression young SEs has of the SEs of old - there is a lot of wisdom but spoken in the obscure language.
Am I right or am I wrong or maybe I just dreaming?
mIt's possible that one of the major integration techniques with a psychological twist will be an ability to tell stories. Humans are wired for storytelling, are easily immersed in telling stories and enjoy listening to them. Storytelling may convey a point that is impossible to convey in any other way with the same effectiveness.
How does it connect with the integration? The ability to explain how the system reacts to some event is the hallmark of the Integration Engineer - one has to choose the important information from the wealth of the technical documentation, integrate the mental model and communicate it to the listeners in a simple way that hides the underlying complexityto be able to tell a compelling story.
Now - in order to be a genuine integration technique, the story has to use only available lower-level design information to describe the higher-level behavior without the right to use higher-level information and risk the tautologies.
The ability to tell the story of system's reaction to single event does not guarantee that the whole system story will be told but the trace of that specific event will be validated. Any missing information that prevents the story to flow may be tagged as a possible design anomaly to be resolved until the integrators will be able to tell the story, the whole story and nothing but the story so help them God. In this way the storytelling could be used as a design validation technique.
When the results of the tests on the hierarchy level of interest are combined with the design information on the lower level as the building blocks for the story, effective integration testing techniques may emerge.
And it's much more fun to tell and listen to stories than to read, write and execute endless test scrips so there is no harm will be done if the storytelling techniques will be added to the toolkit of the Integration Engineer.
So the First Secret of Integration may be formulated as "The Integration is the ability to tell a compelling, complete and accurate story about how the system works when used in a certain way".