Около полугода изучал теоретические основы системной инженерии. По постам Левенчука и ссылкам из них (бывало что из одного небольшого поста Левенчука в итоге порождалось 20+ вкладок в браузере и кучка скачанных PDF’ов 
). Еще конечно очень полезны видеозаписи заседаний русского INCOSE и лекций Левенчука (первая лекция тут: http://ailev.livejournal.com/757223.html , там же ссылки на вторую-шестую).
Мой предпринимательский опыт однако давно заставил меня понять, что теории мало, нужна и практика
Дальше начинаются проблемы. Вроде бы в целом всё ясно. Есть стандарты, в них практик описаны. Есть определенные виды жизненного цикла. А что конкретно делать-то? Непонятно.
Еще проблема с объектом, на котором практики системной инженерии применять. Хорошо конечно когда затевается большой проект типа проектирования новой АЭС, и можно влезть туда порулить процессом. Однако найти более-менее серьезный проект, где захотят внедрять системную инженерию, и тем более поставят меня оной порулить – это крайне сложно
Пробовал в некоторые небольшие проекты внедриться, объяснял отцам-командирам, что такое системная инженерия, что они с этого могут поиметь, как всё это выглядит. Понимания нет. В одном месте (софтовый проект) сказали «Да, всё круто, так и будем делать. Я передал то, что ты говорил, нашему системному аналитику, он напишет ТЗ на систему». Ага, супер Из моих рассказов об инженерии требований было понято, что надо написать ТЗ на систему, причём даже без сбора требований стэйкхолдеров
Еще в одном проекте (проектирование беспилотного ЛА + софта бортового и наземного) сказали, что всё это круто, но лучшее – враг хорошего, и они на коленке продолжат делать. При этом там даже нет и не планируется требований к софту и описания архитектуры софта – ни в виде моделей ни в виде документов.
В общем, есть большая проблема непонимания менеджментом необходимости системной инженерии.
Из известных мне предприятий радует разве что ОАО «Информационные спутниковые системы» (лидер российского спутникостроения, спутники связи и спутники ГЛОНАСС делает). Там 2 года назад внедрили Dassault (CATIA, ENOVIA), некоторые этапы жизненного цикла проходятся уже на этой платформе. Переходят на полностью электронный документооборот, включая обмен моделями с поставщиками. Осенью будем пытаться там делать автоматизацию общего проектирования. Тут и инженерия требований во всей красе (стэйкхолдеров с требованиями к системе автоматизации проектирования много насчитывается), и даже порождающее проектирование (будем порождать общий дизайн космического аппарата на основе требований к оному и базе знаний с знаниями, добытыми из проектантов, и набором предыдущих дизайнов).
А пока потренируемся на собственном проекте. Небольшой, софтовый. Но и на нём можно опробовать некоторые практики, изучить языки и нотации требований, софт для работы с ними.
Начну я с изучения моделеориентированной инженерии требований. Это, на мой взгляд, наиболее полезная вещь. Ибо есть у меня опыт в разработке софта, когда из-за неучёта требований каких-то сразу даже не выявленных заинтересованных сторон (вроде инвестора заказчика) проекты срывались, иногда на последних стадиях. Инженерия требований позволит снизить вероятность таких ситуаций.
–
