Дисклеймер: пост хоть и публичный, но пишу его в первую очередь для себя, ни на что не претендую, ничего не жду.
---------------------
Ну пост, так пост (тяжело вздохнул, мозг сопротивляется писать пост по этому заданию).
Итак, задание такое: Написан и опубликован пост с изложением ваших проблем при выполнении предыдущего задания в части подготовки инженерного обоснования. Особо в посте уделено внимание испытаниям как источникам свидетельств для аргументов в вашем обосновании. Сказано, как обоснование проверялось на отсутствие ошибок в аргументации. В посте также приведена оценка экономики: сколько было потрачено на обоснование, сколько было бы потратить оптимально, как принималось решение о необходимом объёме обоснования.
Мои проблемы в инженерных обоснованиях, что я последнее время играю роли менеджерские (причем организационного менеджера, а не операционного) и предпринимательские (визионера и чувака, который ходит бюджеты защищает). И с инженерными обоснованиями целевой системы я связан слабо.
Наверное, раз системная инженерия позиционируется как транс-дисциплина, то практика инженерных обоснований должна быть применима и к системам создания, то есть проектным командам.
Обоснования нам нужны, чтобы понять, будет успешна создаваемая система или нет. Что такое успешная проектная команда как система создания? Это проектная команда, которая создала успешную целевую систему.
Какие я могу привести обоснования успешности целевой системы, не погружаясь в инженерию целевой системы?
Я могу проверить нормативное выполнение практик системной инженерии проектной командой, могу проверить, что ничего не упущено (дальше идет переписка практик из учебника):
- По линии разработчиков: выявление потребностей внешних проектных ролей
разработка концепции использования
разработка концепции системы
нарезка работы на мелкие кусочки (ничего себе! Это же операционный менеджмент, что он делает в инженерии?)
инженерные обоснования
работы по безопасности и защите
проектирование с точностью, достаточной для изготовления - По линии архитекторов выбор важных архитектурных характеристик
принятие архитектурных решений
надзор за реализацией архитектурных решений - По линии изготовителей
- По линии конфигурационных надзирателей
У нас в проекте это, к сожалению, не поставлено. Я делаю подходы к тому, чтобы настроить регулярный учет альф, чтобы создать чеклисты по необходимым практикам системной инженерии и поставить работу команды по ним. Но каждый раз не удается довести дело до использования. То одно, то другое, то пожар, то еще что-то.
Надо сесть и пройти цепочку: системная схема в мета-мета-моделях → системная схема моего проекта → подальфы моего проекта (до нужной глубины) → состояния подальф → чеклисты перехода из состояния в состояние → практики для перехода. И все это многоуровнево по уровням целевой системы. И все это для разных воплощений (а у нас: и демонстрационный стенд в лаборатории, и испытательные стенды для ресурсных испытаний, и боевая инсталляция на складе центра снабжения, и далее инсталляции внешним клиентам).
Пока думал про инженерные обоснования, споткнулся об то, считать ли стенд для проведения ресурсных испытаний для подсистемы (например шасси шаттла) — воплощением (и воплощением чего?, подальфы воплощения целевой системы? подальфой воплощения системы создания?) Сам спросил, сам отвечаю: воплощением системы создания. Ресурсные испытания — это про подтверждение инженерных обоснований наблюдением, про время создания системы. Да, там будет задействована подальфа воплощения целевой системы, но сам стенд — это система создания, которая с целевой делает «испытания», станок для испытаний.
Что касается оценки стоимости, то стоимость инженерных обоснований и их проверки в нашем проекте всяко меньше стоимости исправлений ошибок в инженерных обоснованиях и уж тем более репутационного ущерба, которые они могут повлечь.
Я понимаю, что текст поста увел немного в сторону от задания, но потом постарался вернуться. Так что пусть будет так.
На этом все.
Спасибо мне за внимани-е :)
SVYATOSLAV
#познавательное
#система