![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rHere are my notes and ideas from 4th Systems Engineering Roundtable, Zürich.
This are people lured by the term "Systems Engineering" and the main question this Thursday was "What could we do together?"
The first suggestion was to speak about Systems Engineering problems. Unfortunately this approach will relatively quick burn all questions people could ask. After this such group will be lost without purpose.
The second suggestion was to produce something. And this is really "something" because the purpose and the goal audience of the prospective results were not defined.
We had discussed A Model-Based Engineering (MBE) Manifesto (PDF) from Model-Based Systems Engineering (MBSE) Wiki.
If you would like to read something boring, obscure and ambiguous, this is a good choice.
There are two new links: International Federation for Systems Research from Austria and Augmented Intelligence in Systems Engineering Challenge Team.
I have strong suspicion that there is a demand to find an international term for "Levenchukism".
Below are some thoughts from my notebook.
Modeling is a way to make complex systems and the knowledge about them visible.
I mean not the graphical representation but the way to imagine and to understand the system or its parts. A mathematical model could be described with formulas. Some simple models would be clear even when described in text without other representations. A source code or a pseudo-code could be a good model in some cases.
It is difficult to discuss model-based approaches because people speak in different contexts. Consequently the same word may mean for them different things. This produces misunderstandings and disagreements.
The main problem by attempts to implement model-based approaches in IT and other areas is
The Inverted Knowledge Pyramid:
Models must be easily verified by tools and validated by people. Simply speaking, the software could easily check that models are consistent and experts could easily check that this models are realistic.
These goals are also missed in most cases. Model-based approaches depend from modelling tools and the vendors of this tools try to create processes that support their understanding and make easier the tools development not the work with these tools.
There also is an interesting trick that could predict acceptance of new tools, methods and processes. I'll describe it in my next post.
This are people lured by the term "Systems Engineering" and the main question this Thursday was "What could we do together?"
The first suggestion was to speak about Systems Engineering problems. Unfortunately this approach will relatively quick burn all questions people could ask. After this such group will be lost without purpose.
The second suggestion was to produce something. And this is really "something" because the purpose and the goal audience of the prospective results were not defined.
We had discussed A Model-Based Engineering (MBE) Manifesto (PDF) from Model-Based Systems Engineering (MBSE) Wiki.
If you would like to read something boring, obscure and ambiguous, this is a good choice.
There are two new links: International Federation for Systems Research from Austria and Augmented Intelligence in Systems Engineering Challenge Team.
I have strong suspicion that there is a demand to find an international term for "Levenchukism".
Below are some thoughts from my notebook.
Modeling is a way to make complex systems and the knowledge about them visible.
I mean not the graphical representation but the way to imagine and to understand the system or its parts. A mathematical model could be described with formulas. Some simple models would be clear even when described in text without other representations. A source code or a pseudo-code could be a good model in some cases.
It is difficult to discuss model-based approaches because people speak in different contexts. Consequently the same word may mean for them different things. This produces misunderstandings and disagreements.
The main problem by attempts to implement model-based approaches in IT and other areas is
The Inverted Knowledge Pyramid:
- Requirements are written by marketing people.
- Architecture is defined by youngsters from universities with PhDs but without practical experience.
- Models are drawn in graphical tools by inexperienced interns.
- People who have enough understanding and experience to manage complex problems are pressed down to the base level where they must implement wrong models that depend on unrealistic architecture based on unreasonable requirements.
Models must be easily verified by tools and validated by people. Simply speaking, the software could easily check that models are consistent and experts could easily check that this models are realistic.
These goals are also missed in most cases. Model-based approaches depend from modelling tools and the vendors of this tools try to create processes that support their understanding and make easier the tools development not the work with these tools.
There also is an interesting trick that could predict acceptance of new tools, methods and processes. I'll describe it in my next post.
no subject
Date: 2018-09-17 08:30 am (UTC)В этом блоге в любом месте можно писать на русском (а также английском и немецком). Рабочие обсуждения на английском у меня в другом месте.
А тег попал просто случайно, обычно он обозначает языки поста без учёта комментариев даже в том случае, если они что-то дополняют.
в среднем она устроена не совсем неправильно -- требования *собирать* действительно лучше маркетингу,
Требования должны собирать специалисты по сбору требований и уних должно быть очень хорошее понимание технических возможностей. Потому что requirements specification - это не набор благих пожеланий, а описание способов удовлетворения конкретных потребностей. И тут просто согласование с заказчиками их желаний с доступными технологиями может и существенно сократить цену разработки, и существенно улучшить конечный продукт.
Если не продавать летающих лошадей, потом не придётся объяснять заказчикам, почему пегас на костылях и зачем ему в заднице неучтённый в техзадании пропеллер.
модели рисовать дело неблагодарное (их всё равно никто не смотрит после первого показа -- иногда и его не бывает)
Я видел проекты, где генерация из моделей была от 80% до 100%. В механике или электротехнике всё идёт от моделей к рабочим чертежам, правда процесс коучеры и консультанты модными словами не описывают.
я думаю, что виновата не пирамида, а процесс, при котором сигналы снизу встречаются немецким молчанием "я не знаю, что мне с вашим мнением делать"
У меня есть старый текст про немецкую подковёрную борьбу. Но тут просто схема из главы про организацию процесса. Там задумано много, и причины, и следствия, и пути решений.
с требованиями иногда получается конфликт, когда по отдельности модели (прототипы для требования А, для Б и Ц) верифицируются, но... они несовместимы
Об этом будет пост через один. Фиг знает, когда будет написано всё, так что я немного бескорычтно улучшу хотя бы кусочек мира.