Зачет был по стандартам. Точнее, по одному стандарту ГОСТ Р - ИСО\МЭК 15288, "Системная инженерия и процессы жизненного цикла". Процессов 25 штук. И все длинные и мутные. Когда вчера ночью я поняла, что запомнить больше уже не в состоянии, я стала рисовать в голове мультики. Глючные мультики.А кто-то еще говорит плохо про российское образование! Системную инженерию в нем изучают, хотя скептики скажут, что правильно рисовать мультики не в голове, а в Second Life, чтобы на розовые прыгающие по комнате фаллоимитаторы можно было и другим посмотреть. А то в Second Life летающие розовые фаллоимитаторы есть, а прыгающих по комнате -- нет.
Самым глючным был процесс анализа требований.
Мультик был про розовый фаллоимитатор, который может еще и прыгать по комнате... И у него были ушки. Заячьи. Соответственно, для него были требования заказчика, ограничения по технике безопасности, управление рисками и прочее. Кстати, в результате процесса реализации его пришлось сделать железным и покрасить зеленой заборной краской.
* * *
Две моих лучших догадки последнего времени:
1. Stakeholder из системной инженерии -- это совсем не роль. Это дальний родственник "позиции" из СМД -- у него есть собственные цели и проект по отношению к системе, он самоопределился. (В ISO 15288:2008 -- 4.29. stakeholder -- individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations. В ISO 42010: An individual, team or organization (or classes thereof) with interest in, or concerns relative to, a system. Concerns are those interests which pertain to the systems development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution and evolvability.).
2. Системой у организаторов системной инженерии является процесс системной инженерии (в смысле процесса из ISO 15288, определенного согласно правилам ISO TR 24744:2007). Цикл жизни процесса -- это уровни его зрелости (например, по ISO 15504-2, но можно и по CMM, тут уж неважно как, важен принцип). Суть работы организатора -- тащить процесс по уровням зрелости.
* * *
Эпицентр мировой активности по ISO 15926 переместился на http://trac.posccaesar.org/.
* * *
Теперь нужно бы
а) выбрать формализм организационного описания (например, DEMO. Или какой другой. Один из тестов: генерит ли этот формализм картинки или таблички, удобные и понятные начальникам. Пока было выяснено, что EIDEF0 в табличном виде начальникам удобны и понятны, а все остальное из обширного репертуара АРИС, БП-Вин и подобных начальству неудобоваримо). Ох, сколько раз я уже писал про это "выбрать формализм организационного описания"! Пора бы сосредоточиться, и выбрать.
б) выразить этот формализм на (EXPRESS, OWL, UML, ORM, Gellish -- нужное подчеркнуть, впрочем все эти варианты осмысленны) и далее сабмитить для включения в RDL WIP. Кстати, для формализма DEMO и Gellish эта работа вчерне была сделана, осталось только сабмитить (впрочем, и это будет сделано автоматом, нужно только выразить заинтересованность).
в) иметь софт, который из формального описания (representation) делает красивые и понятные картинки (presentation), и наоборот -- то бишь иметь WYSIWYG-редактор описаний организационных моделей. Еще этот софт должен уметь порождать всяческие таблицы отчетов, тексты корпоративных регламентов и прочих стандартов и т.д. -- функциональность легко подсмотреть у любого бизнес-моделера.
г) после чего разобраться (на примерах! конечно, на примерах!) по связям организационной модели с моделями продукта -- что легко будет сделать, если они будут выражены в одной и той же модели данных aka онтологии. И подтвердить, наконец, знаменитую фразу о том, что "система будет состоять из того же числа подсистем, сколько участвует организаций, ее создающих".
С таким подходом и в FIATECH сунуться не стыдно, вполне мейнстримно получается.