Методология 2025. Анатолий Левенчук

виде, а нижний ряд – это с конкретными расчётными функциями и указанными уже моделями конструктивов, самого Gielingh тут интересовала знаниевая работа над проектом, уточнение ролей с какими-то их методами работы и их поддержки со стороны конструктивов:

      Эта диаграмма характеризует важное для методолога, разработчика и архитектора:

      • Методологу надо рассмотреть альтернативы разложения метода для какой-то сигнатуры. Если у вас в системе предусмотрен метод «чистка зубов», то вам надо рассмотреть варианты еды на ночь семян кунжута (удивительно хорошая очистка!), использования зубной нити, зубочистки, зубной щётки или ультразвуковой щётки с выбором из многих видов зубной пасты и вариантами щёток (например, V-образная зубная щётка, если у вас брекеты), задействование ирригатора (чистка водой под давлением), и т.д.. Каждый метод обладает своими плюсами и минусами, а если это верхнеуровневый метод, то может быть реализован очень по-разному, его составляющие будут иметь в свою очередь, разные разбиения – и надо будет опять выбирать, и там, скорее всего, будут какие-то другие предметные области. Это и есть работа. По большому счёту, именно методолог делает «разузловку», разбиение системы на функциональные единицы. Понятно, что в силу разделения труда это очень плохо делать «сверху вниз», ибо ключевое понимание того, как же именно работает система, будет на нижних уровнях. Но это уже нюансы, о которых будет в курсе «Системная инженерия».

      • Архитектор будет следить, чтобы в конструктивах, реализующих функциональные объекты с предложенными функциями/методами работы, не было лишних зависимостей и соблюдались приемлемые значения важных общесистемных архитектурных характеристик. Так, если коммуникация в организации идёт «через верх» (каскадирование: CEO сказал что-то замам, те выдали начальникам дирекций, те выдали начальникам отделов, те выдали начальникам секторов, те уже не стали подключать сотрудников и сами что-то сделали, потом пошло согласование этих предложений снизу вверх), то это будет дико медленно – цикл стратегирования, бюджетирования и т. д. будет легко длиться больше года, и когда будет какой-нибудь валютный или кадровый кризис, организация банально не сможет быстро отреагировать. Архитектор вмешается, заставит разработчиков организовать потоки работ как-то другим способом, методологи должны будут предложить методы стратегирования и бюджетирования, которые не будут подразумевать каскадирования (подробней об этом в курсе «Системный менеджмент»).

      • Проектировщик/designer будет принимать решение по тому, что же из имеющегося в культуре разнообразия видов методов работы (и, соответственно, разнообразия ролей), предлагаемых методологом, должно войти в разрабатываемую систему, и какими видами конструктивов с их интерфейсами, удовлетворяющих ограничениям, полученным от архитектора, это может быть реализовано – и он также собирает и другие ограничения (технология