March 10th, 2010

2019

Поколенческая инженерия

Дедушка, которому все верят, подписывает чертежи размещения кранов на большой стройке. Перед этим дедушка нанес стрелу крана на прозрачку, наложил прозрачку на план стройки и долго крутил эту прозрачку. Потом подписал все нужные бумаги, зная что за ошибку ему сидеть. И его подписи начальство верит.

Студенты перенесли план стройки в 3D-модель, нарисовали там же краны, покрутили их и даже сделали мультфильм, в котором видно, как заезжают крупногабаритные грузы, как их подхватывают краны и куда затем ставят. Заодно они исправили три-четыре коллизии, которые пропустили в чертежах дедушки.

Кто будет подписывать этот мультик про размещение кранов и последовательность монтажа? Дедушка не будет: он ему не верит, он просто не понимает, почему этот мультик может быть не менее точным, чем чертеж. Он не знает, сколько ошибок внесено при переносе 2D чертежей в этот трехмерный мир (а если бумажных 2D при этом не было, то ситуация для него еще хуже: он даже не будет уверен, что исходные чертежи безошибочны! Ибо "не чертежи"!). Подписи студентов у начальства не котируются, даже если студенты готовы свои подписи поставить (осознавая про "сидеть").

Что в этой ситуации делать?

1. Подождать, пока дедушка вымрет (немного уже осталось). После чего окажется, что студенты выросли до того возраста, когда их (электронным к тому времени) подписям будут верить. До тех пор работать, как работали.

2. Научить таки дедушку крутить кран на дисплее, а не на прозрачке. Использовать для этого боевое НЛП. Придать дедушке трех студентов, из которых все три -- девушки.

3. Выводить из мультика краны и 2D на прозрачку и бумагу, и давать дедушке. После чего получать подпись на этих копиях и класть в архив. Изменения же, улучшения и прочее продолжать делать в 3D, ибо это на порядок быстрее и удобнее. То, что при этом будет двойная работа (студентов и дедушки, плюс хлопоты по переведению в удобный для дедушки вид -- дедушка объявляется "стейкхолдером" и обслуживается по высшему разряду) окупается меньшим числом нервов и ошибок по совокупности.

4. Тяжело вздохнуть, и оставить все как есть (с ужасом понимая, что после того, как дедушка вымрет, все вообще остановится -- разве что один из студентов вдруг за это время научится крутить прозрачку по плану на просвет).

5. Ваши предложения? Кто что по какой технологии должен подписывать, кто в случае ошибок будет сидеть и за чьи ошибки он будет сидеть?
2019

Текущие планы по моделированию

Оказывается, про моделирование мало что понимают не только мейнстрим-экономисты, но и инженеры, прикладные математики и много других людей. Например, содержательно обсудить разницу между концептуальными моделями и имитационными моделями мало кто может -- а уж если нужно показать (а тем паче реализовать программно) их связь, то это вообще выходит за рамки текущего понимания "специалистами": в ВУЗах еще десяток лет назад этому не учили, а на производстве (отечественном) никому с этим раньше сталкиваться не приходилось.

Планы по моделированию:

0. Разборки с методологией моделирования
-- современные тренды моделеориентированной системной инженерии и моделирования(http://ailev.livejournal.com/769509.html, http://ailev.livejournal.com/747288.html)
-- учебник динамического моделирования (http://www.freebookspot.in/Books-Handbook%20of%20Dynamic%20System%20Modeling.htm)
-- работы Fontana по "алхимии" ("потокам конструирования", "исчислению конструкции") и почему он бросил эти заниматься (formalization and emergence of functional organization): http://fontana.med.harvard.edu/www/Documents/WF/Pages/earlier.research.wf.htm

1. эксперименты с (имитационными) моделями системной динамики, как одним из простейших видов динамических моделей (сегодня вечером, кстати, vvagr делает на заседании Русского отделения INCOSE доклад по модели АЭС в парадигме системной динамике, и будет показывать модель собственной разработки -- http://community.livejournal.com/incose_ru/12847.html).

Тут же -- разбирательство с моделями GORE (goal-oriented requirements engineering). Сюда можно отнести не только GRL (http://ailev.livejournal.com/800769.html), но и модели из FlyingLogic (для "деревьев из леса Голдратта) -- http://flyinglogic.com/.

Важно, что системная динамика -- это развертка во времени, поэтому можно пытаться как-то связать эти модели с жизненным циклом, увязав в них нужное разным заинтересованным сторонам:
-- речь идет о "потоках", следовательно можно моделировать и cashflow в зависимости от тех или иных проектных решений.
-- factory physics (логистика) -- это тоже про "потоки"! Поэтому мультифизичность моделирования мы понимаем как включение в том числе и factory physics. Но для этого нужно сделать...

2. Переход к более широкому классу мультифизических моделей , использование modelica (http://www.modelica.org/), в которой вся системная динамика -- лишь одна из многих имеющихся библиотек. Тут два основных направления развития:
-- переход к большей модульности (нужные нам библиотеки) и детальности моделирования
-- связь с другими моделями, использующимися в проекте, в частности...

3. Различение моделирования требований, функционального моделирования, архитектурного моделирования и т.д..
-- добавка к моделям системы modelica собственно "требовательной" информации (стейкхолдеров, их целей и т.д.). Артефакты инженерии требований, инструментарий для этой "требовательности" (http://ailev.livejournal.com/805721.html).
-- разбирательство с архитектурными артефактами и ролью в них моделей вообще и мультифизичных моделей в частности (http://www.freebookspot.in/Books-Method%20Framework%20for%20Engineering%20System%20Architectures.htm).
-- вспоминаем про DSL и language workbenches, "универсальный моделер" (http://ailev.livejournal.com/757999.html). Обратим внимание, как тесно связана тема программирования-моделирования "в большом" с работами Fontana по вышеприведенной ссылке, и с управлением конфигурацией/управлением изменениями в системной инженерии...

4. А чтобы не улетать слишком далеко в облака, нужен мэппинг всего вышеперечисленного в существующий программный инструментарий (ибо "программы всегда опаздывают", а "теория всегда опережает").