СММ-АК-2024. Как описывать системы

Вообще интересная глава про описания. В основном - довольно прикладная из которой пользу можно извлечь сразу. Т.к. описания используется для коммуникации между коллегами/командам.
Сделал несколько подходов к описанию “моей системы” через функциональное разбиение. Почему-то очень непривычно думать в чисто функциональном разбиении, очень хочется функцию сразу привязать к какому-то конструктивному элементу, очень непривычный тип мышления. То же самое и с чисто конструктивным описанием, когда пытаюсь только на конструктив внимание обращать - постоянно хочется функцию какую-то добавить.
Когда делал свои функциональные разбиения - просил GPT-o1 и GPT-4o проверить - очень хорошо справляются, Llama 3.1 8B хуже но вполне приемлимо для модели на лэптопе. Подсветили несколько моментов где я использовал конструктивные, а не функциональные объекты и объяснили почему.
Как таковой пользы в проекте я своими описаниями не принес, т.к. я делал “реверс-инжиниринг” “моей системы”, а функции эти уже и так достаточно хорошо известны всем, поэтому никаких открытий тут не было. Но что интересно было - иногда спрашивали почему эта функция в этом поддереве, а не в другом. Объяснял что это функциональное, а не конструктивное разбиение, про существование этой разницы.

В разделе про альфы упоминается, что обычно описания и состояния разносятся по разным документам и это даже хорошо, т.к. не создает ботлнеков. То что не создает ботлнеков - бесспорно, но самая большая проблема - как получить более-менее общее представление о системе из этих разных описаний? Т.к. обычно это превращается в какую-то дурацкую игру: “попробуй найди то описание, что тебе нужно, а еще угадай не устарело ли оно”.

Мое текущее понимание альф - это описание по которому можно отслеживать что-то в проекте. Описание хорошо, но оно должно иметь физическое воплощение, иначе забудется. Соответственно должна быть документация.
Концептуально вроде понятно, но как обычно - много вопросов как это в реальности применяется.
Немного сбивало/путало, что альфа сразу воспринимается как какой-то один объект(и это так и есть): одно слово, одна пиктограмма на схеме. И из-за этого сразу возникал образ единого документа на альфу, а это не обязательно так, надо помнить об этом.
Еще что меня сразу сбило - есть картинка где нарисовано 8 альф: по 3 из создатель и целевая система и 2 из надсистемы. Если я правильно понял это больше как рекомендуемые альфы, если видна потребность/польза в еще каких-то альфах то их тоже можно вводить и отслеживать.

2 лайка

Тоже есть такое, внезапно перескакиваю с функции на конструктив и обратно. По идее надо сразу писать и вторым проходом отслеживать такие косяки.

У меня поэтому и есть желание всё в один документ запихнуть, чтобы видеть картину в целом. Но при этом само описание становится дико неудобным для структуры. А если разносить в разные, то непонятно как актуальность поддерживать, особенно если во времени это продолжительно происходит

Описание - это может быть и одно из состояний альф. В этом и сложность с альфами, их тип/класс не зафиксирован

1 лайк