Введение в RUP (The Rational Unified Process. An Introduction) (Рубрика Management)
Эта книга Филиппа Крачтена (Philippe Kruchten) посвящена процессу разработки, который в конце девяностых и начале двухтысячных претендовал на то, чтобы стать стандартом де-факто в разработке софта. Это был уже не waterfall, который все трактуют упрощенно и предпочитают блеймить рассказывая про отсутствие итераций и обратной связи (что в общем виде неверно). В этой книге 2001 года выпуска автор дает следующие советы по организации производственных процессов (которые актуальны и сейчас) 1. Разрабатывайте итеративно - автор пинает waterfall, дальше вспоминает про спиральную модель Барри Боема, а потом предлагает итеративный процесс, в результате каждой итерации которого создается релизная версия. Внутри итерации по стандарту есть планирование, управление требованиями, анализ и проектирование, реализация, распространение, тестирование и оценка. 2. Управляйте требованиями - под требованием тут понимается условие или характеристика, которой должна соответствовать система. И автор предлагает активно работать с функциональными и нефункциональными требованиями, а также ограничениями системы. Нам надо уметь документировать требования и отслеживать их влияние на систему и принимаемые решения и компромиссы. 3. Пользуйтесь модульными архитектурами - автор рекомендует использовать модульную архитектуру, которая способствует эластичности, распределению ответственности, использованию стандартизированных компонентов и визуальному моделированию. 4. Используйте визуальное моделирование - здесь автор говорит про важность моделирования и вспоминает UML (unified model language) - унифицированный язык моделирования, на который было много надежд в те времена. Сейчас многие тоже хотят визуально моделировать, но уже используют для этого другие нотации и подходы (C4 Model, ArchiMate, SysML, 4+1, ...). Кстати, именно модель "4+1" и рекомендовалась внутри RUP как процесс, основанный на архитектуре. Суть в том, что у нас были 5 представлений: logical, process, development, physical, scenarios. Причем сценарное представление основанно на сценариях пользователей и объединяет остальные представления. 5. Не забывайте о проверке качества - про важность автоматизированного тестирования и поиск багов на ранних стадиях разработки софта. Сейчас это называется shift-left testing:) 6. Следите за изменениями - здесь автор говорит про повторяемость процесса изменений софта. Сейчас мы добиваемся этого при помощи выстроенного процесса CI/CD (continuous integration / continuous delivery). Интересно, что рекомендации не устарели за прошедшее время и даже стали гораздо четче + появилась крутая инструментализация:)
Дальше автор рассказывает про четыре функции разработки софта и показывает, что все эти функции реализуются внутри RUP и основаны на 6 советах, приведенных выше
- Обеспечивать руководство последовательностью действий команды
- Определять, какие артефакты должны создаваться и когда
- Указывать, чем должны заниматься отдельные разработчики и целые команды
- Предлагать критерии наблюдения и измерения продуктов и видов деятельности.
А дальше в книге автор подробно разбирает как устроен RUP и как его использовать для того, чтобы выстроить процесс разработки.
P.S. Филипп Крачтен, автор книги, - очень крутой специалист как по процессам, так и по software architecture. Он был директором по разработке процесса RUP внутри Rational до 2003 года, когда Rational был куплен IBM. В 2020 году получил Software Architecture Award от Carnegie Mellon University | Software Engineering Institute (вот его выступление про состояние software architecture, которое было приурочено к награждению)
P.P.S. Помню как лет 17 назад я знакомился с этим процессом поближе, проходя тренинги и обучения в Luxoft. Меня впечатлил подход, когда ты мог собрать себе кастомный процесс из кубиков, что предоставлял RUP. Правда, уже тогда мне казалось это довольно сложной конструкцией:)
#SoftwareArchitecture #Architecture #Software #Management #Leadership