Жизненный цикл ПО

TL;DR

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

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

1. Сбор и анализ требований (выявляем проблему, пользователей, границы системы, ограничения и ожидаемые результаты);
2. Проектирование (выбираем структуру решения: процессы, информационные объекты, классы, компоненты и т.п.);
3. Разработка (превращаем проектные решения в осязаемый код);
4. Тестирование (проверяем соответствие системы требованиям и сценариям);
5. Внедрение и сопровождение (выводим систему в реальную эксплуатацию и сопровождаем пользователей).

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

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

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

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