Рассуждения вокруг системотехники и комментарии к «Ричард Хэмминг: Глава 28. Системная Инженерия»
Попытался прокомментировать статью Ричард Хэмминг: Глава 28. Системная Инженерия» через свое понимание проблем «системной инженерии» и с учетом «современности», а также связанных или даже частично дублирующих ее EA \ BPM.
Выдержки из оригинала показаны цитатами, из других источников — курсивом. Плюс рассуждения вокруг системотехники.
Системная инженерия или Systems engineering (SE) — также давно известное направление, как и BPM (Business Process Management) и EA (Enterprise Architecture). Найти, где заканчивается SE и начинаются ЕА и ВРМ — сложно. Уж очень все эти три направления «по-развивались», особенно в маркетинговой плоскости.
Любое проектирование «большого и сложного» — должно базироваться на SE. Проектирование предприятия (а это и есть сложная система), описание архитектуры предприятия — это не SE? В стандартах SE часто употребляется и «предприятие» и «архитектура». Выделяют даже отдельное направление Enterprise Systems Engineering (ESE)
Есть рассказы (байки) КАК АРХИТЕКТУРА ПРЕДПРИЯТИЯ ДОПОЛНЯЕТ СИСТЕМНУЮ ИНЖЕНЕРИЮ
Для простых систем, как правило, ВРМ не используется, а это значит что «весь ВРМ» — это тоже про SE, а в стандартах SE — постоянно говорится о «моделировании» и «процессах».
Таким образом, сложно представить ЕА или BPM без «довеска» SE: итого получаем троицу ЕА-BPM- SE.
Так как SE — это проектирование всего «большого и сложного», то по «определению» оно пересекается практически со всем известным из «Best Practice» & ххBOK, включая «SE & PMBOK», «SE & ITSM», но ограничимся указанной «тройкой», причем с учетом изложенного в моих циклах с критикой ЕА и ВРМ:
Enterprise Architecture vs алхимия предприятия
Бизнес-процессы: Как все запущено и запутано (ВРМ)
Ключевой вывод: Если ЕА и ВРМ считаем алхимией, а SE не опровергает их подходы, а наоборот «дополняет», а зачастую «дублирует и повторяет», то можно поставить под сомнение утверждение, что SE — это инженерная дисциплина.
Проблема современных SE — такая же, как и для ЕА и ВРМ — нет детальных опубликованных примеров их апробации. Почти все проекты закрыты через NDA, ДСП и «военная тайна», нет пошаговых примеров по реализации проекта. Зато много зарабатывающих на SE ассоциаций, много маркетинга, курсов, продаж и т.п.
Немного про SE
Системная инженерия — междисциплинарный подход, определяющий полный набор технических и управленческих усилий, которые требуются для того, чтобы преобразовать совокупность потребностей и ожиданий заказчика и имеющихся ограничений в эффективные решения и поддержать эти решения в течение их жизненного цикла (ISO 24765).
sewiki.ru
Из книжки «Системная инженерия для чайников» от IBM
Системная инженерия — это междисциплинарный подход к созданию крупных комплексных систем, которые соответствуют определенному набору экономических и технических требований.
В аэрокосмической и оборонной промышленности системная инженерия используется уже давно, и многие из полученных опытным путем знаний применяются в других сферах.
Wiki Systems engineering
— совсем скупо.
Впрочем, как и Wiki Системотехника
При том, что Советская школа системной инженерии \ системотехники не уступала на тот момент западной.
Почему-то первенство SE отдают США (вопрос дискуссионный):
Согласно легенде системная инженерия впервые появилась как метод ведения работ в военной отрасли США, когда нужно было скрестить два сверхсложных инженерных проекта: атомный проект по созданию ядерного оружия и проект создания баллистических ракет, необходимых для доставки этого оружия. Не было никаких голов «генеральных конструкторов», которые могли были бы справиться с решением этой задачи, и пришлось изобретать методы совладания со сложностью подобного сверхпроекта.
Системноинженерное мышление
Сомневаюсь, что советские аналогичные проекты не использовали такие же SE-подходы.
SE — это про проектирование, внедрение и сопровождение систем, причем сложных систем. Процесс решения задач методами системной инженерии включает в себя постановку проблемы, нахождение принципиальных технических решений, моделирование системы, оптимизацию, архитектуру, изготовление и запуск, опытную эксплуатацию, а также анализ эффективности полученного продукта (изделия типа «система»).
Причем, что очень важно — этот подход стоит, прежде всего, на страже интересов потребителя разработки (заказчика), а не консалтера или разработчика. Во всяком случае, так изначально задумывалось.
Стандарты системной инженерии
Наглядным отражением задач SE можно считать (условно) картинку (впрочем, как и задач PMBOK): Проект «Тарзанка»
1. Начало
В первых трех абзацах «Глава 28. Системная Инженерия» через «Человек смотрел, как строят собор» говорится о простой истине: «За деревьями не видеть леса». Это типовая ситуация, когда люди концентрируются на частностях и не видят «целого». Об этом очень много написано. Кое-что есть у меня:
3.5 Леса, деревья, листья
можно разделить на две задачи (категории): задачу описания «леса» (процессы в «крупную клетку», взгляд с высоты «птичьего полета») и достаточно детальных «процессов — деревьев»
Они демонстрируют узость взглядов в своей работе и редко, если вообще когда-либо, связывают её с более общими целями системы.Такая узость взглядов является основной характеристикой бюрократа.
Скорее не «бюрократа», а узкоспециализированного специалиста. Действительно, попытки оптимизировать «отдельный участок» не всегда приводят к улучшению работы «системы в целом».
Системная инженерия — это попытка всегда держать основные цели в голове и понимать, для чего совершается каждое локальное действие, и как оно влияет на общий результат.
Т.е. умение видеть и «лес» и «деревья», понимать законы развития (жизнь) «леса» и совсем другие законы (жизнь) «деревьев», причем у каждого «дерева» — свои собственные законы.
Собственно это механизм перехода от крупного масштаба рассмотрения к мелкому и обратно.
Естественно, я очень скоро понял, что наибольшую ценность от новых машин могут извлечь только сами ученые при работе напрямую.
Я проецирую эту мысль на наше время, как необходимость привлечения самих бизнес-пользователей «напрямую» к описанию и оптимизации своих бизнес-процессов без использования ИТ-специалистов (BPM-специалистов, ЕА-архитекторов и прочих алхимиков) и программистов.
Об этом рассказывал в статье Бизнес-процессы: Как все запущено и запутано. Глава Третья. Общая классификация BPM и философия BPMS
На протяжении долгих лет не угасает стремление (мечта №2) — найти простой путь моделирования процессов непосредственно их участниками (задействованными в процессе) без привлечения BPM-специалистов «по отрисовке квадратиков и кружков», а также выполнение построенных таким образом процессов. Отсюда и сильная тяга (надежда) к формату BPMS
Обязательства в каждом случае были: (1) непосредственный вклад, (2) вклад в долгосрочной перспективе и (3) очень долгосрочный вклад. Также я понял, что под пунктами (2) и (3) одна из моих функций в исследовательском отделе была не столько решением существующих проблем, сколько разработкой методов решения проблем, расширением диапазона возможностей и обучением других тому, что мне удалось обнаружить, чтобы они смогли в дальнейшем применить, продолжить и улучшить результаты моих усилий.
Это же я пытаюсь донести в цикле ЕА «Enterprise Architecture vs алхимия предприятия», т.е. показать, что трансформация существующих подходов к ЕА и ВРМ должна быть направлена на:
не столько решением существующих проблем …
т.е. не разработка сиюминутного описания ЕА, к тому же закрытого по NDA и ДСП, т.е. чисто монетаризацией этого направления. Причем очень спорно, что проблемы действительно «решены», т.к. часто неудачный (провальный) проект ВРМ \ ЕА \ SE выдается за удачный, но узнать истину — нельзя.
сколько разработкой методов решения проблем, расширением диапазона возможностей и обучением других тому, …
это возможно только путем открытого обсуждения и не столько самих «методов решения проблем» — методологий и загадочных фреймворков, сколько демонстрации на конкретных примерах, апробации теоретических «Best Practice» и публикации практических «Best Practice». К сожалению, этого в современных ЕА и ВРМ и SE — нет.
… что мне удалось обнаружить, чтобы они смогли в дальнейшем применить, продолжить и улучшить результаты моих усилий.
Многих практиков ЕА и ВРМ и SE интересует только личная выгода, но вот развитие направления в целом, точнее переход от «алхимии» к «химии» — мало кого. Бизнес по ЕА и ВРМ и SE — процветающий: консалтинг, коучинг, инструменты и т.п., но что касательно практики и «теории по Ленину» — имеем ноль: «Нет ничего практичнее хорошей теории». Нет никаких доказательств в открытом доступе практичности, вообще ничего из практики по ЕА и ВРМ и SE — нет.
Всё «практическое», т.е. все примеры — или коммерческая или государственная тайна. Кто сказал, что методологии и выполненные по ним проекты — успешные? На основе чего? И с какой выгодой?
Тем не менее, позже я понял, что мне стоит обращать внимание не только на нужды Исследовательского Отдела, но и на все потребности Лабораторий.Потом это был AT&T, Страна за пределами AT&T, научные сообщества и сообщества инженеров, и, в итоге, весь мир. Таким образом, у меня появились обязательства перед самим собой, моим отделом, подразделением, компанией, родительской компанией, страной, миром ученых и инженеров и каждым жителем планеты.
Таких обязательств и побольше бы нашим согражданам. Особенно тем, кто или практикует SE или учит других методам SE. Особенно тем, кто отвечает за развитие отечественного SE.
Применительно к теории SE и к нашей стране: после развала ГОСТа, современные подобные организации (подобные гос-институты, включая Росстандарт, Роскачество и т.п.) ориентированы на монетизацию (путем сертификации, техрегламенты и прочее), регулирование и т.п., но никак не на развитие науки и инженерных практик, включая SE.
Это все — к вопросам: стандартизация, унификация, типизация, свободный обмен лучшими практиками. Отечественная SE — это ГОСТы серий 34.ххх и многие из 15.ххх и 2.ххх.
Обязательность их исполнения осталась в прошлом, но это обеспечило на то время мощный потенциал, прежде всего, при производстве военных систем (ГОСТ РВ 15.ххх и 2.ххх.).
Максимум, что сейчас делается — это переводы зарубежных ГОСТов.
Собственные (отечественные) методологические разработки в этих областях — нулевые.
Зачем нам это сегодня? Хотя, когда-то наша страна была пионером в этих отраслях, как минимум, в подходах к стандартизации и унификации к проектированию сложных систем.
Правильно — не нужно нам это, т.к. у нас:
а) полно западных наработок — пусть в массе своей и относящихся к алхимии, но для монетизации это не существенно;
б) есть и много «нефть и газ», что всем (во всяком случае, многим) дает достаточно «хлеба и зрелищ». Когда есть много «хлеба и зрелищ» стимул к развитию атрофируется.
Я убежден, что ЕА и ВРМ и SE могут быть также представлены и досконально формализованы как подходы к кодированию информации. И эти направления когда-нибудь станут настоящими научными и инженерными дисциплинами.
В системной инженерии очень просто говорить правильные слова, и многие люди научились говорить их, когда им задают вопросы в рамках этой темы, но как и во многих видах спорта, таких как теннис, гольф или плавание делать всё необходимое в целом оказывается сложно. Следовательно, системных инженеров стоит судить не по тому, что они говорят, а потому, что они в итоге делают и производят. Существует много людей, которые говорят о хорошей игре, но на деле не могут сыграть в неё.
Я бы развил мысль далее — «системных инженеров стоит судить не по тому, что они говорят, а» по результату.
И где отечественный авиа, авто — пром, где отечественный «SE-пром» (развитие 34.ххх), где хоть что-то отечественное из инженерии, системной инженерии? Умеем лишь переводить «западную алхимию», перепродавать западную «комплектуху» и из нее лепить системы (комплексировать), что в ИТ, что везде: 80% от суперджета и современных жигулей — импортные детали и технологии.
Конечно, по этому критерию нужно судить не только инженеров, но и вождей и всех граждан (с молчаливого согласия которых все это), но вот — инженеров, причем ответственных за «большие системы» и за отечественную «системную инженерию», — в первую очередь. Не хотел о политике, но это вытекает из цитат из Хэмминга: «судить, что они в итоге делают и производят». А что реально производят? Производят в основном их западные коллеги.
Первое правило системной инженерии
Если оптимизировать компоненты, то, вероятнее всего, производительность системы будет испорчена.
Проблема с заземлением дифференциального анализатора — как то не совсем мне очевидна. Это скорее технический дефект.
Я бы привел другой пример, не особо показательный, но в ином направлении: помним старую игрушку — Диггер. Играли — играли, все было хорошо.
Потом появились новые компьютеры и … на них играть стало невозможно, хотя их архитектура была совместимой. Из-за значительно прироста скорости — «бедного Диггера» мгновенно «съедали»: очень быстро работала новая система, т.к. уж очень «хорошо» оптимизировали вычислительную мощность компьютера.
Со временем для подобных игр появились программы — «замедлители», т.е., чтобы поиграть нужно было «повесить балласт» на производительность для ее сопоставления с производительностью старых машин. Вывод: иногда к таблетке «оптимизатор» нужно прилагать таблетку «анти-оптимизатор».
Еще пример оптимизации: некоторые умельцы форсировали движки на серийных автомобилях. После этого «рвало» полуоси (трансмиссию), особенно «гранаты» на переднеприводных автомобилях. Конечно, оптимизация должна быть комплексной с учетом «слабого звена» в общей системе (цепи).
Хотя в данном случае, мероприятия условно можно отнести к «оптимизационным», это просто увеличение мощностей, в первом случае — вычислений, во втором крутящего момента.
Это примеры когда не работает принцип: «кашу маслом не испортить»: в сложных системах он не всегда работает.
Зубрение перед экзаменом — пустая трата времени.
Не совсем понял критику. Вообще основная цель процесса обучения — это тренировка. Тренировка и развитие памяти человека (наращивание его ОЗУ), мыслительного процесса (вычислительная мощность CPU и DSP мозга). Примеры онтологий, понятийных аппаратов. Это просто позволит аналогию для практических задач. Задачи разные — подходы к решению одинаковые (общесистемные).
Очень мало (почти ничего) из изученного применяется на практике — это видимо норма любого обучения. Но это по принципу: «тяжело в ученье, легко в бою». В один миг может устареть кавалерия и быть заменена на танки, но элементы тактики (прорыв обороны, обход с фланга) останутся прежними.
Кстати к вопросу обучения в отечественных ВУЗах, часто наблюдается парадокс: двоечники добиваются блестящей карьеры (уходят в топы), а отличники «протирают штаны» инженерами (рядовыми сотрудниками).
Системная инженерия — это процесс, которому трудно следовать, так легко потеряться в деталях!
Да, верно, но только — пока эти направления: SE, ЕА, ВРМ — находятся на уровне развития «алхимия». Когда это станет реальной наукой и будут детальные и обоснованные (доказанные) и апробированные походы, то «следовать будет просто», даже начинающему.
По «букварю» — уж не знаю какому: букварю SE, ЕА или ВРМ (или все это схлопнется в одно направление) можно будет пошагово построить любую АСУ или предприятие. Сравнение с алхимией относится более явно к ЕА и ВРМ, чем к SE, SE — все-таки более продвинулась по сравнению с ними, в первую очередь, благодаря стандартизации.
Хотя и на SE уже наложена «лапа маркетинга». Ключевая проблема SE (повторюсь) — это отсутствие, также как и для ЕА и ВРМ, — публикуемых примеров реализации методик SE (проектов).
В итоге, если смотреть в целом, в обучении Математике появились большие пробелы. Мы практически не затрагиваем (1) важный метод Математической индукции, (2) после краткого упоминания в связи с квадратичными уравнениями в алгебре мы практически полностью игнорируем любое упоминание комплексных чисел до того рокового дня, когда появляются сложные собственные значения и собственные функции, и бедный студент знакомится с двумя новыми сложными концепциями одновременно и, естественно, это сбивает его с толку, (3) вкратце упоминается полезный метод неопределенных коэффициентов, (4) практически полностью игнорируются доказательства невозможности, (5) игнорируется дискретная математика, (6) не прилагаются усилия к тому, чтобы вывести размышления студентов из обучающих примеров к значимым концепциям, применимым в реальном мире.
Подобные проблемы, уверен, существовали и в СССР. С одной стороны советское образование славилось более «комплексным подходом» («широким взглядом») по сравнению с узкоспециализированным «западным». Но, с другой стороны, это же приводило к еще большему отдалению от «реального мира».
Про современное отечественное образование скажу так: как раз сейчас в стране сделан упор к «концепциям, применимым в реальном мире». Только «реальный мир» в стране — это не индустриальная эпоха, поэтому в моде концепции «бухгалтерско-маркетинговые».
В стране «экономистов и бухгалтеров — как собак нерезанных», школы и университеты маркетинга и т.п. В то время как наука и инженерия — оказалась на «обочине», поэтому наши спутники «падают как мухи», а про отечественные самолеты, автомобили, компьютеры и телефоны — уже никто даже не обсуждает (не верит).
Не обсуждает всерьез, т.е. только на уровне маркетинга, гос-пропаганды (чудовищный механизм), инвестиций в «правильные кормушки», пиара отдельных личностей и проектов, как правило, частно-государственных.
На инженерных специальностях вместо научных дисциплин часто преподается откровенная алхимия. Про преподавание алхимии:
«Со временем, на обложках подобных учебных пособий и книг внезапно проявится надпись «Пособие по алхимии», а некоторые уже сейчас способны разглядеть пока еще расплывчатые контуры такой надписи». habrahabr.ru/post/345948
Как раз поэтому:
… многие люди знают, что сказать, но не многие могут фактически применить это на практике, когда придет время действовать в реальном мире. Большинство из вас не может!
Не может, — потому что будущих инженеров учили маркетингу и алхимии. Системный подход, системный анализ — хоть и обязательный атрибут любой «Концепции и стратегии» в красочных буклетиках консалтеров, но в реальности это просто «управленческая уловка».
Упоминания про «У них была производственная линия, …» — это про промышленный конвейер и т.п. (Г. Форд), напрямую к SE отношения, видимо, не имеет. Хотя любое проектирование — это фактически такой же проектный конвейер.
Причем, если грамотно его организовать, то требования к компетенциям и «творчеству» работников на таком конвейере по выпуску «АСУ и предприятий» будут существенно снижены, при одновременном повышении качества и минимизации сроков проектирования.
Гибкость в проектировании дает не только возможность лучше справляться с изменениями, которые неизбежно возникнут после установки системы, но также вносит вклад в вашу собственную работу в виде небольших изменений, которые неизбежно возникают как на более поздних этапах проектирования, так и во время полевых испытаний системы. Я не понимал, насколько много может быть изменений в ходе испытаний, до того как принял участие в полевом тесте проекта Nike на островах Кваджалейн.
Большая ошибка в акте приемочных испытаний большой системы сделать запись: «Ошибок нет». Правильно указать: «на этапе испытаний ошибок не выявлено», потому что они обязательно есть, только их еще не нашли и не устранили.
Даже наличие литеры Э1 и последующих литер Оn (ГОСТ 2.103—2013) на опытные образцы системы не гарантирует отсутствие ошибок. Оперативное внесение изменений параллельно в конструкцию и документацию (Гибкость в проектировании) — это норма при каскадном проектировании (хотя это почему-то приписывают только «гибким» agile), что при строительстве, что при производстве.
Второе правило
Часть проектирования системной инженерии — подготовка к изменениям, чтобы пройти через них успешно и не снизить производительность других частей.
Этот тезис развился в отдельные современные направления «Управление изменениями», «Управление требованиями», в некоторых частных случаях, например, ITIL — «управлениями релизами» и т.п.
Как я писал ранее, период полураспада подходов к проектированию составляет 15 лет — половина идей, которые вы узнаете сейчас, будут бесполезны через 15 лет.
Сомнительный тезис. Проецируя на себя: мне намного больше дало изучение подходов к разработке военных систем (АСУ) и строительных ГОСТ и СНИП, которые я изучал 20 лет назад, чем современная литература примерно о том же, только в обертке «ЕА \ ВРМ» и с «маркетинговыми фишками», «цели бизнеса» и т.п.
Хорошей технической литературы со временем становится все меньше, но основная проблема — она (иголка) теряется в «стоге сена», образованным маркетинговым мусором и тиражируемым по всему интернету. Нарастающий «как снежный ком» вал маркетинга и алхимии, неподтвержденных практикой теорий и домыслов — современная реальность.
Вместо этого хотелось бы видеть такой же по объему архив (репозитарий) реальных примеров, проектов, апробаций и результатов детального анализа внедряемых систем по этим методологиям и фреймворкам.
Вообще, с трудом представляю, как человек, не читавший отечественные ГОСТы 34.ххх может понять содержание ISO/IEC по SE: уж очень написаны они «общо» и двусмысленно.
Если будет разработана качественная теория, то она будет «бессмертна» и востребована.
Хотя она может (должна) развиваться, но не со сменой курса на 180 градусов.
Кстати, тогда же я сравнивал стадии проектирования в ГОСТах на АСУ (24.ххх, 34.ххх) и в строительных (21.ххх) и других (ЕСКД-ЕСПД), стадии в методологии АРИС и еще в чем-то (не помню уже). И все сводилось к одному:
1) предпроект (аванпроект, концепция и т.п.)
2) эскизный проект, технический проект, рабочий проект
3) испытания, приемка, внедрение
В разных методологиях — разные термины, но суть на удивление — одинакова (классический каскад), в том числе и внутри указанных стадий. Причем независимо от масштабов: строим радиостанцию, танк, здание, АСУ, предприятие.
Этот «классический каскад» — фактически основа «системного подхода» к проектированию сложных систем.
Интересно, что эти самые «разные методологии», в которых указаны одни и те же SE-принципы, могут относиться как непосредственно к SE, так и ЕА и ВРМ. Например, стадии проектирования ТОГАФа обсуждаем в комментариях к Enterprise Architecture vs алхимия предприятия. Часть 2. Проще некуда: простой фреймворк и простое предприятие
Так зачем такой зоопарк методологий?
Мы говорим о «серьезных изделиях», полагаю, что использование agile (как альтернатива каскаду) и т.п. «как основы» при разработке что танка или самолета, что ядерного реактора или систем типа «мертвая рука» — никому в голову не придет.
Третье правило
Чем точнее вы отвечаете спецификациям, тем хуже будет производительность при перегрузке.
Это элемент «оптимизации». За отход от оптимизации — в сторону «повышения надежности», запаса прочности и производительности и т.п. — нужно «платить», платить «неоптимизацией». Если мы хотим иметь запас «прочности», включая запас производительности, то оптимизацию — лучше не ставить приоритетом.
Более тонкий корпус делает более дешевым и более легким изделие, но менее ударопрочным (при одном и том же материале) и защищенным. Поэтому дома и мосты должны строиться с запасом прочности.
Вся оптимизация — это управление компромиссом. Можно сэкономить «на спичках» и построить точно по заданным требованиям, но потерять главное качество.
… я верил, что маленькие задачи были относительно более важными, чем большие.
Это продолжение тезиса «За деревьями леса не видеть леса». Вообще, этот тезис — один из основных в SE и часто повторяется, см. в том числе, книжку «Системная инженерия для чайников» от IBM.
Оптимизируя «каждое дерево», можно загубить весь лес. Хотя бы потому, что одни деревья станут очень большими («локальной оптимизации отдельных лиц») и закроют тенью всех остальных, что их погубит, т.е. «достигнуть глобальной оптимизации всей системы» не получится.
Вестерман, как и я, полагает, в то время как клиент может знать о некоторых симптомах, он может не понимать реальных их причин. А это глупо, пытаться вылечить только симптомы. Таким образом, не смотря на то, что системные инженеры должны слушать клиента, они также должны попытаться выудить из него более глубокое понимание феномена. Поэтому работа системного инженера — определить в более глубоком смысле, какова проблема и как перейти от симптомов к реальным причинам
Это вылилось в различные ветки, например, в ITSM: «Управление обращениями», «Управление инцидентами», «Управление проблемами» и т.п. Это методы связывания разных следствий (инцидентов) к одной причине (проблеме).
Причинно-следственные связи и поведение элементов в сложной системе — не очевидны и для выявления этих связей выделяют целые направления, например, «Управление конфигурацией», когда через визуальное представление (картинку) связей элементов можно приблизиться к пониманию проблемы.
Вестерман полагает, что, по-видимому, искусство системной инженерии лучше изучать в команде, включающей как старые, так и новые лица. При этом он говорит о том, что более опытных коллег стоит постепенно убирать из процесса и вводить новых людей в команду. Я не знаю, как передать мой личный опыт «одинокого волка». Я могу только рассказать о том, что делал и как себя вел в определенных ситуациях.
И я про это же: достаточно опубликовать конкретные проекты по SE, ЕА, ВРМ и показать, откуда были взяты направляющие «что и как сделать» (стандарты, фремворки) и как были применены эти самые стандарты и фреймворки, какие проблемы возникли и как были решены. Всего лишь «только рассказать» и показать на конкретном подробном реальном или вымышленном примере.
Но позвольте уточнить еще раз. Системная инженерия должна строиться на прочной основе классического упрощения до конкретных проблем с определенным решением.
«Врага нужно бить поодиночке», а сложную задачу решать по частям (т.е. декомпозировать, упрощать) и т.п. — это все заповеди SE, такие же, как про «лес и деревья».
Какой на Ваш взгляд ключевой документ по SE? Не методология типа ГОСТ или ISO/IEC 15288
или даже Systems Engineering Body of Knowledge (SEBoK)
, а практический документ для конкретной системы (артефакт проекта).
Это не схема работы системы, показывающая принцип ее действия или детальная спецификация и даже не проектная «клюква» (набор проектных документов по каждому элементу системы) и география (территориальное размещение компонентов системы).
Это Схема деления изделия на составные части (ГОСТ 2.711–82). В этом и заключена детализация системы на элементы: изделия на отдельные под-изделия — составные части, которые в свою очередь являются изделиями (возможно даже изделиями типа «сложная система», некоторые покупные и т.п.).
Заходишь в кабинет главного конструктора, а у него почти во всю стену 6×3 весит всего одна «Схема деления» и с достаточно мелкими элементами (несколько сотен). Это к высказыванию Хэмминга:
Системная инженерия — это попытка всегда держать основные цели в голове и понимать, для чего совершается каждое локальное действие, и как оно влияет на общий результат. Тем не менее, здесь нет какой-то одной конкретной большой картинки.
Это и есть «одна конкретная большая картинка», да еще и с децимальными номерами и пояснениями типа «разрабатываемое» или «покупное» изделие.
Аналог «нашей» Схемы деления по ГОСТ — это «D.1.3 Структура системы» из «ихнего» ISO/IEC 15288, только «наша» оформлена в виде стандарта еще в 1982 и с более детальной нотацией. Вообще, при чтении «современных» западных стандартов на SE, вспоминается аналогии из ГОСТ 2.ххх, 34.ххх, а также из ГОСТ РВ 15.ххх.
С точки зрения ЕА, такая «одна конкретная большая картинка» — это заполненная табличка Захмана по конкретному предприятию (фреймворк Захмана показан в предыдущей моей статье). Видимо при декомпозиции большой системы на подсистемы потребуется составление под каждую — собственной (отдельной) таблички Захмана.
Я уже упоминал об этом, но позвольте заметить еще раз: решение, которое не дает более глубокого понимания — плохое решение, но, возможно, что это всё, что возможно сделать в текущем временном ограничении. Целью системной инженерии должно быть более глубокое и долгосрочное понимание сущности проблемы, в то время как клиент всегда хочет увидеть оперативное избавление от текущих симптомов. Опять же, конфликт, ведущий к мета-системной инженерии!
В идеале пользователь (клиент) всегда ждет от ERP, АСУ и т.п. режим: «пришел на работу, нажал Большую красную кнопку и ничего более делать не нужно: система сама поработает. Главное не забыть при завершении рабочей смены отжать Большую красную кнопку».
Видимо — это несбыточная мечта или порог, после которого последует SkyNet.
Как пример углубленного понимания системы и её проблем, я хочу рассмотреть проект управляемых ракет Nike.
У меня сложилась уверенность, что рассвет системной инженерии «там» (США) и системотехники «здесь» (СССР) пришелся на период холодной войны. После «потепления» у нас оно вообще оно погибло и исчезло как отечественная «Best Practice», а там трансформировалось в некий инструмент маркетинга (вообще, лидер в этой номинации ISO 9000). Видимо ничто так не мобилизует человека, как угроза его выживанию.
Системная инженерия — это безусловно увлекательная профессия, которую трудно практиковать.
Проектирование АСУ и предприятия, процессов организации — всегда подразумевают практику SE. Почитать по SE много чего есть, на мой взгляд, это еще не наука, но через фильтр «маркетинга» можно фильтровать полезность.
Поэтому читать книжки (тем более статьи) по ЕА и ВРМ и SE нужно прошептав: «Осторожно маркетинг», исключения составляют книжки (включая, западные) и отечественные ГОСТы советского периода. Отфильтрованное от маркетинга можно применять, но непонятно где: отечественная наука и промышленность «на коленях», вся идеология, методология и вся «комплектуха» — западные.
Неплохая практическая книжка по SE применительно к АСУТП: «Проектирование АСУТП», Нестеров.
Практиковать «по полной программе» системную инженерию можно видимо только в оборонке, но там совсем иной уровень используемых технологий, а недавний лозунг «импортозамещение» (читай элементарная индустриализация) — уже видимо похоронен. Следовательно, говорить о пост-индустриализации — просто смешно, мы еще (точнее уже) находимся (откатились) в «до-индустриализации».
Что такое SE
Systems engineering в понимании Хемминга — это то же самое, что «системная инженерия 2018» и системотехника сегодня? Скорее всего «да».
SE — это подходы к проектированию систем. Каких систем? Любых, но сложных. Точнее земных. Солнечную систему проектировать видимо нужно по другим методологиям. В идеале SE должны объясняить как строить не только технические системы, но и экономические, социальные (включая коммунизм, почему бы и нет? To be «светлое будущее», roadmap №2 на основе framework »1917»).
Простые системы также можно проектировать по SE, но это будет «не оптимально».
Универсальность SE обусловлена «взятием на вооружение» принципа «системного подхода», комплексного взгляда на разрабатываемое (модернизируемое) изделие — как на «сложную систему».
Как правило, «деталь» и «программа» — не включаются в категорию «система». В такую категорию выделяют нечто сложное, например, «самолет» или «большая программа» (ERP), тем более — объекты типа АСУ и «предприятие» — это настоящие «системы».
Точно также, как PMBOKу — все равно какие проекты по нему реализовывать, то и для SE — собственно не так важно какие изделия типа «система» по нему строить и внедрять.
Хотя системы типа «самолет», «АСУ» и «предприятие» — должны проектироваться по разным ответвлениям SE (принцип общий, но есть специфика).
Вследствие общности проектирования любых АСУ и произошло объединение в рамках одного ГОСТ 34.ххх подходов к проектированию АСУ разных классов и просто «автоматизированных систем».
Вообще, когда я читаю многие современные статьи и «открытия» по теме SE, ЕА, ВРМ, то часто возникает ощущение, что это уже ДАВНО читал, причем не в ГОСТах. Всп
