СММ-АК-2024. Системные разбиения. WBS & FBS

Люблю находить артефакты деятельности о том как конкретно эти концепты, которые я встречаю в ШСМ, применялись, зачем и чего помогали достигать. Очень интересно

Читал главу учебника СМ про разбиения систем и разные виды отображений. А так же кодировки из главы про описание системы.
Вспомнил что когда-то читал про подход/фреймворк который использовался в НАСА: FBS(Functional breakdown Structure) - https://ntrs.nasa.gov/citations/20130012526. И вот сейчас до меня дошло что это, зачем и какие бонусы предоставляет.

FBS нужен для составления функциональной иерархии для их миссий. Представляет из себя function-oriented tree. Где любая функция так или иначе задействованная в миссии - отображается. И у функций могут быть подфункции. Такая структура нужна для быстрого понимания если чего-то не хватает, или что-то излишнее(например функция не нужна, а ее просто по памяти перенесли при разработке новой миссии). При чем это именно функциональное разбиение! Тут ничего не говорится про конструктивное или стоимостное.
Классный пример-скриншот с функциональным разбиением:

Если идти дальше, в глубь дерева то можно увидеть еще кучу более мелких функций

Прям как из упражнения на разбиение по системным уровням из учебника СМ. Есть мысль, что такое дерево может быть так же использовано в качестве чеклистов-проверок все ли функционирует или нет.

Используют такую структуру так же для выявления проблем с поставщиками. Когда нужно разрабатывать и утрясать требования для них, чтобы они не понаделали несовместимые друг с другом компоненты
Так же упоминают, что после того как архитектура определена - FBS служит направляющим для разработки остальных отображений/views. Например WBS(Work breakdown structure). Скорее всего и другие отображения

The SPST recommends that a Functional Breakdown Structure be generated at the beginning of architecture studies and comparisons, that the FBS be used to ensure the level comparison of architecture options, that the FBS be used to fully identify all needed functions, and that the FBS be used to identify and manage functional integration across elements within the architecture. The FBS can also be used to help generate the initial set of WBS’s. The space transportation system for the exploration mission can be addressed with the FBS already developed by the SPST.



Так же интересно упоминание WBS(Work breakdown structure). Это еще один способ разбиения/отображения который используется для разбиения уже работ на более мелкие модули, чтобы их можно было разрабатывать независимо. Так же важное упоминание, что WBS и FBS - не соотносятся друг с другом 1-1:

As has been discussed, since FBS’s and WBS’s are not the same, a single item in a WBS may address multiple items in a FBS while multiple items in a WBS may be needed to address a single item in a FBS.

И точно так-же как и FBS - WBS есть иерархическое представление

Или вот такое представление. Тут уже частично смешано с финансовым представлением

В pdf этого не упоминается, но вот нашел еще RBS(Resource Breakdown Structure). Еще один вид разбиения. И вид точно такой-же - иерархическое дерево. В этом разбиении уже назначаются конкретные ресурсы/исполнители необходимые для выполнения работ, которые были выделены в WBS

2 лайка

Забавно, что люди вперемешку с серверами)

1 лайк

Де-антропоцентричность!)

1 лайк

Классический инженерный процесс с поиском аффордансов отсюда и взят (это вообще говоря опыт классической системной инженерии), взятый из ранней системотехники радиоинженерных систем и распространившийся на все отрасли через создание INCOSE .

Но за функциональным разбиением нельзя пропускать PBS - продуктовое или физическое. Именно оно - база для WBS, потому что работы привязывают к физическим деталям. А вот тестирование - снова организуют по функциям.

А может такое быть чтобы один и тот же объект в PBS был в разных поддеревьях? Я так понимаю не может быть?

И еще, я же правильно понимаю, что в функциональном разбиении FBS. Мы только функцию указываем и не оставляем никакого намека на то сколько нам этого надо? Условно если мы проектируем завод который производит машины и в функциональном разбиении у нас поддерево выгляди так:

  • поверхностная обработка
    • грунтовка
    • покраска
    • лакировка
    • полировка

Тут мы ни в каком виде не указываем, что нам нужно условно 10 станций покраски, или что нам нужна пропускная способность в 100 машин/час?
Это все идет в другие разбиения

Скорее не может. Вот соответствовать разным функциям в FBS - может.

1 лайк

Почему? Как раз эти данные разумно фиксировать на этапе FBS, а потом на этапе выбора оборудования уже обеспечивать их достижение. Точнее говоря, они определяются где-то после окончания создания FBS и записываются как атрибуты FBS, до перехода к PBS.

1 лайк

Т.е. типа такого:

  • поверхностная обработка
    • грунтовка{200 машин/час}
    • покраска
      • покраска1
      • покраска2
    • лакировка
    • полировка

В этом случае пример с грунтовкой скорее правильный и допустимый(в виде атрибутов), а пример с покраской скорее нет?

С покраской неясен смысл разбиения. Если это два участка с одним функционалом имеются в виду - то да, это ошибка, в функциональном разбиении это не надо отражать.

Да, два участка с одним функционалом. Ну логично, да