Методология-2024. Принципиальная схема нашей системы

Написан пост о принципиальной схеме вашей системы. Особо проверьте, что в принципиальной схеме показаны функциональные, а не конструктивные объекты. Отметьте, вы где-то нашли эту принципиальную схему, или вам пришлось её составить для этого задания самостоятельно?
Принципиальная схема составлена самостоятельно, дальше можно увидеть и вопросы (не стала их убирать), которые возникли при составлении.

Мы работаем над альфой описания целевой системы. На входе у нас есть ТЗ и исходные данные, на выходе части (минимально необходимые описания) проектной документации, в которых представленные решения соответствуют требованиям безопасности. Данные описания остаётся дополнить до комплекта проектной документации, достаточной для предоставления на экспертизу ПД и, по идее, достаточной для строительства::воплощение ОКС::“целевая система”.
То есть в схеме движется альфа описания, меняя свои состояния - описание становится всё более детализированным.
На “схеме” первом уровне функция, функциональный объект пока не указываю, потому что всё ещё продумывает, на втором уровне уточнения - не надо воспринимать это как чистую декомпозицию функций.

  • Проверка технического задания и исходных данных:
    • проверка на непротиворечивость информации
    • проверка на достаточность информации для начала работы
  • Анализ технического задания
    • месторасположение объекта и условия на территории
    • состав объекта
    • вид строительства
    • тип здания/сооружения
  • Нарезка описаний на информационные контейнеры (ИК) на основе анализа и определение порядка их предоставления
    • состав ИК достаточен, не избыточен для оценки безопасности проектного решения. Получается что ИК должен отражать связную единицу проектного решения
    • предварительный порядок предоставления ИК минимизирует количество переделок, которые возникнут в процессе проектирования (сначала разрабатываются наиболее критичные узлы)
  • Оценка проектных решений на безопасность при рассмотрении ИК
    • если решение не безопасно, то указывается почему с ссылкой на техрегламент
    • предлагаются альтернативные варианты (или нет?)
    • при наличии критичных замечаний (как определить что оно критично?) ИК отклоняется и отправляется на доработку/переделку проектировщику
  • Составление сводного заключения по “проектному сопровождению”
    • какие замечания были устранены, какие нет

Анализ ТЗ производится, чтобы решить как лучше нарезать описания на ИК, в зависимости от того, что мы знаем об объекте. Возможно анализ можно сделать частью нарезки на ИК.

Анализ всегда подчиняется какой-то цели, созданию чего-то. Туда и включайте – иначе совершенно непонятно, что вы в “анализе” будете делать. Например, лизать документы и определять, не горькие ли они )))

При этом в тексте помянуто довольно много всяких инженерных обоснований (все проверки ведь делаются в порядке обоснований, что приняли верные решения). На эту тему есть целый раздел в “Системной инженерии”.

Опять же – пропустили описание чего. А там и целевая система, и надсистема, и подсистемы. И вот что там происходит с описаниями надсистемы – непонятно, если всё это про целевую систему и рекурсивно с подсистемами.

1 лайк