Жизненный цикл ПО и место моделирования

Жизненный цикл программного обеспечения описывает путь системы от идеи до эксплуатации и изменений. В простом виде его можно представить так:

Этапы жизненного цикла

Сбор и анализ требований;
Проектирование;
Разработка;
Тестирование;
Внедрение и сопровождение.

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

Роль моделирования на этапах

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

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

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

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

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

Итеративная работа

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

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

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

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