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