Введение

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

Причина, как показывает анализ, редко бывает технологической. Значительно чаще она кроется в разрыве между языком бизнеса и языком разработки. Требования собираются как перечень пожеланий, без исследования противоречий между ними. Архитектура выбирается по соображениям профессиональной моды или привычек команды. Связь между тем и другим существует лишь в индивидуальном опыте руководителя проекта и с его уходом утрачивается вместе с ним.

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

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

К постановке задачи привел и практический опыт наблюдения за проектами автоматизации в торговле и на производстве, где технологически состоятельные решения нередко обесценивались некорректно поставленными вопросами на ранних стадиях работ. Настоящая статья выросла из стремления установить, какая часть подобных неудач устранима инженерными средствами, а какая обусловлена организационной природой предприятий и потому требует инструментов иного рода.

Оговорюсь сразу о границах. Речь идет о предприятии среднего масштаба, преимущественно производственного профиля. Для банковского холдинга или маленькой торговой фирмы часть выводов пришлось бы пересматривать, и я не претендую на универсальность рецепта. Впрочем, сама логика рассуждения, как мне представляется, переносима.

Обзор литературы

Нормативным ядром современной системной инженерии остается стандарт ISO/IEC/IEEE 15288, определяющий процессы жизненного цикла систем от замысла до вывода из эксплуатации [1]. Его последняя редакция заметно усилила внимание к согласованию инженерных и организационных процессов, что для информационных систем управления особенно ценно. Развернутое методическое сопровождение стандарта дает руководство INCOSE, где процессы дополнены практиками и типовыми артефактами [2]. В отечественной литературе практики системной инженерии применительно к автоматизированным системам управления подробно разобраны в работе В. К. Батоврина и А. С. Королёва [3], и я во многом опираюсь на предложенную ими трактовку.

Второй опорной точкой служит стандарт архитектурного описания ISO/IEC/IEEE 42010 [4]. Его главная идея проста и, честно говоря, недооценена практиками: архитектура описывается не одной схемой, а набором представлений, каждое из которых отвечает на озабоченности конкретной группы заинтересованных сторон. Методология TOGAF в десятой редакции переработана в модульном ключе и связывает архитектурную работу с циклом развития предприятия [5].

Эмпирические исследования корпоративной архитектуры дают отрезвляющую картину. С. Котусев с соавторами показали, что реальную ценность имеют не всеобъемлющие описания, а компактные артефакты, выполняющие роль пограничных объектов между бизнесом и ИТ [6]. Применительно к российским производственным предприятиям архитектурный подход к цифровой трансформации рассмотрен в работе И. В. Ильина, А. И. Левиной и А. С. Дубгорн [7]. Вопросы зрелости архитектурной практики систематизированы в [8], и выводы там не слишком оптимистичны: большинство организаций застревает на уровне разрозненных схем.

Отдельное направление образует модельно-ориентированная системная инженерия. Обзор ее текущего состояния и исследовательской повестки дан А. Мадни и М. Сиверсом [9]. Интересно, что барьеры внедрения, выявленные в [10], оказались по большей части не инструментальными, а культурными: инженеры сопротивляются смене привычного документооборота сильнее, чем освоению новых нотаций. Это наблюдение перекликается с тем, что я видел в собственной практике.

По инженерии требований накоплен внушительный пласт эмпирики. Обследование практики, выполненное М. Кассабом и Ф. Лапланте, фиксирует устойчивый разрыв между рекомендациями учебных методик и реальными привычками команд [11]. Гибкие подходы на основе пользовательских историй, систематизированные в [12], хорошо работают для продуктовой разработки, но, как мне кажется, недостаточны для корпоративных систем, где требования живут дольше кода и дольше самих команд.

Архитектурные стили и связанные с ними компромиссы наиболее последовательно изложены во втором издании книги М. Ричардса и Н. Форда [13]. Авторы настойчиво повторяют мысль, которую стоит закрепить в качестве методологического принципа: в архитектуре не существует безусловно правильных решений, существуют лишь осознанные и документированные компромиссы. Систематический обзор микросервисного стиля, его паттернов и проблем миграции выполнен В. Велепучей и П. Флорес [14]. Подходы к декомпозиции монолитных приложений картированы в [15], и примечательно, что авторы прямо предостерегают от микросервисов ради микросервисов.

Для российского контекста существенны работы о цифровых платформах и сетевых формах организации предприятий, в частности исследование Ю. Ф. Тельнова с соавторами [16], где информационная система рассматривается как ядро экосистемы, а не как изолированный учетный инструмент.

Про трассируемость требований написано, казалось бы, все. И при этом эмпирических работ, где она доведена до денег, до стоимости переделок и до плотности дефектов, на удивление мало. В обследованиях практики [11] трассировка стабильно попадает в число самых декларируемых и самых редко выполняемых активностей. Причина понятна: пока связи между требованиями и решениями поддерживаются вручную, они устаревают быстрее, чем приносят пользу. Отсюда растущий интерес к легковесным формам фиксации решений, тем самым пограничным объектам, о которых пишет Котусев [6], только на уровне отдельного проекта, а не предприятия целиком.

Существует и еще один пласт исследований, без которого картина обзора была бы неполной. Речь о литературе про количественную оценку архитектурных характеристик. Ричардс и Форд предлагают оценивать альтернативы по звездным рейтингам характеристик [13], и этот прием часто критикуют за субъективность. Критика справедлива лишь отчасти: субъективность экспертных баллов никуда не девается, но она хотя бы становится явной, зафиксированной и обсуждаемой. Скрытая субъективность единоличного решения архитектора, по моим наблюдениям, обходится дороже.

Нельзя обойти и нормативный контекст создания автоматизированных систем в России. Обновленный комплекс стандартов на автоматизированные системы [17] сохранил стадийную логику предшественников, но стал заметно совместимее с международной рамкой жизненного цикла. Для практика это означает возможность вести проект в терминах, понятных и государственному заказчику, и команде, воспитанной на международных стандартах. На первый взгляд обстоятельство второстепенное, однако при согласовании технического задания с разнородными аудиториями оно приобретает вполне ощутимое практическое значение.

Наконец, обзор был бы неполон без констатации сближения двух дисциплин, о которых идет речь. Классическая модель, где требования полностью формулируются до начала архитектурной работы, в исследованиях последнего десятилетия последовательно вытесняется представлением о встречном движении: архитектурные решения проясняют и корректируют требования, а уточненные требования пересматривают архитектуру [12 ; 13]. Для информационных систем управления это встречное движение особенно заметно, поскольку значительная часть требований к таким системам вообще не может быть сформулирована до тех пор, пока заинтересованные стороны не увидят работающий фрагмент. Из этого наблюдения вырастает практический вывод, положенный в основу предлагаемой методики: контур проектирования должен быть итеративным по построению, а не по вынужденному отступлению от плана.

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

Материалы и методы

Объектом исследования является процесс проектирования информационной системы управления средним производственным предприятием численностью около четырехсот работающих. Предмет составляют методы связывания требований заинтересованных сторон с архитектурными решениями. Методологической рамкой выбраны процессы технического проектирования по ISO/IEC/IEEE 15288 [1], стадии создания автоматизированных систем по ГОСТ Р 59793 [17] и правила архитектурного описания по ISO/IEC/IEEE 42010 [4]. Элементы архитектурного метода TOGAF использовались как навигационная канва, без догматического следования всем его фазам [5].

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

На втором этапе требования классифицировались на функциональные, нефункциональные, интеграционные и нормативные, после чего приоритизировались по схеме MoSCoW с обязательной фиксацией источника каждого требования. Всего в реестр вошло 214 позиций. Конфликтующие пары требований разрешались на согласительных сессиях с участием владельцев процессов.

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

Для сравнения альтернатив применялась аддитивная свертка частных критериев. Интегральная оценка k-й альтернативы вычисляется по формуле (1).

                                                 ,                                   (1)

где Jk – интегральная оценка k-й архитектурной альтернативы;

wi – весовой коэффициент i-го критерия, сумма весов равна единице;

xik – балльная оценка k-й альтернативы по i-му критерию;

n – число критериев.

Весовые коэффициенты определялись группой из семи экспертов, представлявших заказчика, интегратора и независимую консалтинговую практику. Согласованность мнений проверялась коэффициентом конкордации Кендалла, значение которого составило 0,74, что для задач подобного рода считается приемлемым. Сам выбор аддитивной свертки, конечно, дискуссионен: сравнительный анализ методов многокритериального выбора [18] напоминает, что каждый метод несет собственные искажения. Я сознательно предпочел простоту и прозрачность процедуры ее математической изощренности, поскольку результат предстояло защищать перед людьми, далекими от теории принятия решений.

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

Несколько слов об инструментарии, поскольку от него зависит воспроизводимость. Реестр требований велся в системе управления задачами с обязательными атрибутами: источник, тип, приоритет, статус, ссылки на архитектурные элементы и проверочные сценарии. Бизнес-процессы фиксировались в нотации BPMN, архитектурные представления строились с элементами нотации ArchiMate, хотя следует признать, что часть рабочих схем так и осталась на уровне аккуратных блок-схем: команда читала их охотнее, чем формально правильные модели. Считаю это не недостатком, а данными о реальной жизни нотаций.

Критерии для свертки отбирались в два шага. Сначала эксперты предложили пятнадцать кандидатов, затем попарным обсуждением список сокращался до шести: масштабируемость, совокупная стоимость владения за пять лет, скорость внедрения первой очереди, сопровождаемость, интеграционная гибкость и доступность кадров на региональном рынке труда. Порог в шесть критериев выбран сознательно: при большем числе веса размываются и итог перестает различать альтернативы. Балльная шкала пятиуровневая, оценки выставлялись индивидуально, затем обсуждались расхождения более чем в один балл.

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

Методические ограничения стоит назвать сразу, а не прятать в конец статьи. Одно предприятие, одна отрасль, одна команда. Экспертная группа из семи человек мала для статистических обобщений, ее хватает лишь для внутренней согласованности. Показатель плотности дефектов зависит от строгости приемки, которая сама менялась по мере зрелости проекта. Все количественные результаты ниже следует читать с этими оговорками.

Результаты исследования

Изложение результатов уместно начать с контекста, определяющего масштаб проблемы. По данным ежегодного обследования проектов внедрения корпоративных систем, около половины из них выходит за рамки бюджета, а типичной причиной называется недооценка организационной сложности [19]. Российская статистика цифровизации при этом фиксирует устойчивый рост затрат организаций на внедрение и использование цифровых технологий [20; 21], а обзоры отечественного рынка ERP-систем отмечают одновременно расширение спроса и дефицит зрелых методик внедрения [22]. Иначе говоря, рост финансирования отрасли опережает рост инженерной дисциплины, и это расхождение точно характеризует исходные условия большинства проектов.

Первым содержательным результатом стала процессная схема проектирования, построенная как V-образный контур и представленная на рис. 1. Левая ветвь ведет от потребностей заинтересованных сторон через системные требования к архитектурному и детальному проектированию. Правая ветвь поднимается от модульных испытаний к валидации системы в целом. Принципиальны горизонтальные связи: каждый уровень правой ветви проверяет артефакты симметричного уровня левой. Схема не нова по духу, она восходит к классике системной инженерии [1; 2], но ее адаптация к ИСУП потребовала уточнений: в контур явно введены согласительные сессии по конфликтам требований и архитектурные решения как отдельный класс артефактов.

Рис. 1. Процессный контур системно-инженерного проектирования ИСУП

Источник: составлено автором на основе [1; 2; 17]

Работа контура начинается не с требований, а со стейкхолдеров, и это различие не терминологическая тонкость. Пока не составлена карта заинтересованных сторон с их целями и опасениями, любой список требований будет смещен в сторону тех, кто громче говорит на совещаниях. В нашем случае карта выявила две группы, которые при обычном подходе почти наверняка выпали бы из рассмотрения: внешних контрагентов, работающих с предприятием через обмен электронными документами, и службу качества, чьи потребности традиционно считались приложением к производственным. Обе группы в итоге дали требования, повлиявшие на архитектуру сильнее многих очевидных пожеланий.

Анализ требований дал результаты, часть которых оказалась для меня неожиданной. Распределение реестра по группам заинтересованных сторон приведено в таблице 1.

Таблица 1

Распределение требований к ИСУП по группам заинтересованных сторон

Источник: составлено автором по материалам обследования предприятия с учетом [11]

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

Типологический разрез реестра дополняет картину. Из 214 требований 128 отнесены к функциональным, 47 к нефункциональным, 23 к интеграционным и 16 к нормативным. Обращает на себя внимание вес двух последних категорий: почти пятая часть реестра описывает не то, что система делает для пользователей, а то, как она встроена во внешнюю среду. При традиционном сборе требований именно эти категории документируются хуже всего, поскольку у них нет очевидного заказчика внутри предприятия, и расплата наступает на стадии опытной эксплуатации, когда обнаруживаются несостыковки с контрагентами и регуляторами. Систематическая работа со стейкхолдерами позволила выявить их заранее, и это, возможно, наименее эффектный, но наиболее окупаемый результат первого этапа.

Далее выполнялась оценка архитектурных альтернатив по формуле (1). Весовые коэффициенты и балльные оценки экспертов сведены в таблицу 2, наглядное сопоставление профилей альтернатив дано на рис. 2.

Таблица 2

Весовые коэффициенты критериев и оценки архитектурных альтернатив

Источник: рассчитано автором по формуле (1) на основе экспертных оценок с учетом [13; 14; 18]

Рис. 2. Профили архитектурных альтернатив по частным критериям

Источник: построено автором по данным таблицы 2

Победа модульного монолита с оценкой 4,00 балла против 3,34 у классического монолита и 3,29 у микросервисов не выглядит сенсацией для тех, кто следит за архитектурной дискуссией последних лет [13; 15]. И все же результат стоит прокомментировать. Микросервисы взяли верх по масштабируемости и интеграционной гибкости, однако уступили по критериям, наиболее чувствительным для предприятия среднего масштаба: стоимости владения, скорости внедрения и доступности кадров [14]. Проверка чувствительности показала устойчивость вывода: лидер меняется лишь при увеличении веса масштабируемости более чем в полтора раза, что для рассматриваемого предприятия означало бы совсем другую бизнес-модель.

Экономическая сторона выбора заслуживает отдельного абзаца, потому что баллы в таблице легко воспринимаются как абстракция. За оценкой стоимости владения стоят расчеты на пятилетнем горизонте: лицензии и инфраструктура, штат сопровождения, стоимость типового изменения. Для микросервисного варианта расчет показал потребность в постоянной команде эксплуатации из четырех специалистов против двух у модульного монолита, а дефицит таких специалистов на региональном рынке означал бы конкуренцию зарплат с компаниями, для которых разработка является основным бизнесом [22]. Предприятие, чье конкурентное преимущество лежит в производстве, а не в информационных технологиях, в такой конкуренции почти обречено. Этот аргумент на защите архитектуры оказался решающим, хотя формально он спрятан всего в двух строках таблицы 2.

Оговорюсь, чтобы не создавать ложного впечатления: полученное ранжирование не является приговором микросервисам. При других весах, отражающих, скажем, приоритеты быстрорастущей цифровой платформы, порядок альтернатив сменился бы. Ценность процедуры не в конкретных цифрах, а в том, что спор об архитектуре переведен из плоскости вкусов в плоскость проверяемых предпосылок. Несогласный может оспорить вес или балл, и это будет продуктивный спор о фактах, а не соревнование авторитетов.

Архитектурная реализация выбранной альтернативы строилась в четыре слоя: представление, прикладные сервисы, доменная логика и данные. Доменные границы выделены по контурам управления: планирование, снабжение, производство, сбыт, финансы, качество. Каждый модуль владеет собственной схемой в общей базе данных, межмодульные обращения допускаются только через опубликованные интерфейсы, а асинхронные события проходят через легковесную интеграционную шину. Соблюдение границ контролировалось метриками связанности, подход к которым заимствован из исследований конформности микросервисных архитектур [24], что, кстати, лишний раз показывает: инструментарий микросервисного мира полезен и монолиту.

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

Интеграционный ландшафт спроектирован по принципу минимальной достаточности. Внешних систем оказалось семь: банковские сервисы, операторы электронного документооборота, государственные информационные системы, оборудование цехового уровня. Для каждой связи в архитектурном описании зафиксированы формат, направление, владелец и поведение при недоступности контрагента. Последний пункт выглядит избыточным ровно до первого сбоя. На четвертой итерации отказ внешнего сервиса подтвердил ценность заранее описанных сценариев деградации: производственный контур продолжил работу в автономном режиме, накопив документы для отложенной передачи.

Верификация нефункциональных требований велась не в конце, а с первой итерации. Для требований производительности определены измеримые пороги: время отклика типовых операций, длительность закрытия учетного периода, число одновременных пользователей. Каждая итерация завершалась прогоном нагрузочных сценариев, и дважды результаты заставляли пересматривать проектные решения, один раз довольно болезненно, с переносом части вычислений из синхронного вызова в фоновую обработку. Неприятно, но несопоставимо дешевле, чем обнаружить ту же проблему при промышленной эксплуатации.

Инженерная среда включала конвейер сборки и развертывания с автоматическим прогоном проверочных сценариев, что соответствует зрелым практикам DevOps [23]. Требования информационной безопасности закладывались на уровне архитектуры, а не навешивались после, в русле современных подходов к безопасной разработке [25]. Каждое значимое проектное решение фиксировалось короткой записью об архитектурном решении с указанием отвергнутых вариантов; о дисциплинирующей роли таких записей убедительно пишет И. Озкая [26]. Спустя полгода именно эти записи, а не диаграммы, оказались самым читаемым артефактом проекта.

С архитектурными решениями был связан и реестр проектных рисков. Каждому значимому риску сопоставлялись затронутые требования и архитектурные элементы, что превращало управление рисками из отдельного ритуала в естественное продолжение трассировки. Показателен пример: риск смены оператора электронного документооборота, оцененный на старте как маловероятный, реализовался на пятой итерации. Благодаря зафиксированной связи риска с интеграционным контуром замена заняла восемь рабочих дней вместо ожидавшихся по опыту аналогичных проектов четырех недель, поскольку зона изменений была известна заранее и ограничена одним адаптером.

Остановимся на устройстве самой трассировки, поскольку именно на этом этапе декларации о ее пользе чаще всего расходятся с практикой. Связи ведутся в трех разрезах: требование к архитектурному элементу, требование к проверочному сценарию, архитектурное решение к затронутым требованиям. Поддержание связей встроено в процесс, а не добавлено к нему: задача разработки не принимается в работу без ссылки на требование, проверочный сценарий не считается готовым без ссылки на то, что он проверяет. Трудозатраты на ведение связей измерялись и составили в среднем около трех процентов бюджета итерации. Полученная величина представляется весомым аргументом в дискуссии об экономической оправданности поддержания трассируемости.

Отдельно отмечу организационный механизм, не предусмотренный исходной методикой, но повлиявший на результат, по-видимому, не меньше инструментальных средств. Раз в две недели собирался короткий архитектурный разбор: сорок минут, три вопроса. Какие решения приняты, какие требования они затронули, что мы отвергли и почему. Протокол разбора и превращался в записи об архитектурных решениях. Дисциплина держалась не на энтузиазме, а на календаре, и это, видимо, единственный надежный фундамент для любой инженерной практики.

Ключевой количественный результат пилота отражен на рис. 3. Покрытие требований трассировочными связями наращивалось от итерации к итерации: с 58 процентов на первой до 97 на шестой. Параллельно плотность дефектов по итогам приемочных испытаний снизилась с 4,8 до 1,1 на тысячу строк кода.

Рис. 3. Динамика покрытия требований трассировкой и плотности дефектов по итерациям пилотного проекта

Источник: составлено автором по данным пилотного проекта

На графике видна еще одна деталь, о которой стоит сказать. Прирост покрытия между итерациями неравномерен: с первой по третью он давался тяжело, по восемь пунктов, затем ускорился. Объяснение простое и поучительное. Первые итерации ушли на выстраивание привычки, команда сопротивлялась, связи проставлялись задним числом и неохотно. К четвертой итерации инструментальные проверки стали блокировать задачи без ссылок, и то, что было волевым усилием, превратилось в фон. Похожую динамику описывают исследования внедрения модельно-ориентированных практик [10]: техника осваивается за недели, культура за кварталы.

Разумеется, корреляция двух кривых сама по себе не доказывает причинность: одновременно с ростом трассируемости команда набирала опыт, стабилизировался состав требований, взрослела инженерная среда. Однако разбор дефектов по причинам говорит в пользу содержательной связи: доля дефектов, вызванных неверно понятым требованием, упала с 41 процента на первых двух итерациях до 12 на последних двух. Доля задач, возвращенных на доработку после приемки, за то же время сократилась с 23 до 9 процентов. Для экономики проекта это означало высвобождение примерно седьмой части бюджета разработки, и такой аргумент, по моему опыту, действует на руководство сильнее любых методологических манифестов.

Обсуждение и заключение

Главный вывод исследования звучит почти банально, однако банальности тоже нуждаются в проверке практикой: трассируемость требований является не бюрократической формальностью, а управляемым экономическим параметром проекта. Когда каждая строка реестра требований связана с элементом архитектуры и проверочным сценарием, разговор о готовности системы перестает быть спором мнений и становится чтением таблицы. Сам факт, что покрытие трассировкой можно наращивать планомерно, итерация за итерацией, снимает привычное возражение о неподъемной стоимости такой дисциплины.

Второй вывод касается выбора архитектуры. Модульный монолит для среднего предприятия оказался не компромиссом слабых, а рациональным оптимумом: он сохраняет большую часть эволюционного потенциала микросервисов, не взваливая на организацию их эксплуатационную цену. Не исключаю, что через несколько лет, при росте нагрузки и зрелости команды, отдельные модули будут выделены в самостоятельные сервисы. Ценно то, что архитектура заранее оставляет эту дверь открытой.

Третье соображение выходит за рамки конкретного проекта. Системно-инженерный подход часто воспринимается как тяжелая методология для больших программ, недоступная предприятию среднего масштаба. Опыт пилота говорит об обратном: почти все использованные практики масштабируются вниз. Карта заинтересованных сторон умещается на странице. Реестр требований ведется в той же системе, где живут задачи разработки. Записи об архитектурных решениях занимают полстраницы каждая. Дорогой оказывается не методология, а ее имитация, когда документы производятся для отчетности и не участвуют в ежедневной работе. Граница проходит не между большими и малыми предприятиями, а между работающими и декоративными артефактами.

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

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

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

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

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