Процесс, управляемый примерами

Ориентация на архитектуру

Итеративность

Основные принципы RUP

RUP относится к итеративным методологиям. В соответствии с RUP процесс разработки разбивается на итерации, а однотипные итерации группируются в фазы.

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

Принципиальное отличие RUP от многих других итеративных подходов состоит в большом внимании к разработке архитектуры системы. Надо пояснить, что в RUP называется архитектурой. Даже знакомые с RUP специалисты иногда считают, что архитектура — это наиболее общее описание системы [5], и ее разработка сводится практически к выбору между тонким и толстым клиентом. В RUP понятие архитектуры не ограничивается этими принципиальными решениями, а включает, в частности, используемые в проекте типовые решения для доступа к СУБД, реализации параллельных процессов и т.д. Но и это не все. Архитектура в RUP — это еще и ключевая часть кода (обычно, до 20% общего объема), которая позволяет продемонстрировать соответствие системы основным функциональным и нефункциональным требованиям. Поэтому в RUP часто говорится об исполняемой архитектуре (executable architecture). Чтобы избежать этого не совсем привычного для русского языка сочетания, в дальнейшем будем использовать выражение «архитектурный каркас».

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

Из каких единиц функциональности состоит проект? Можно ли сказать, что любое, самое незначительное добавление функциональности повышает пользовательскую ценность системы? Как правило, существуют определенные наборы функциональности, которые либо должны поддерживаться системой целиком, либо их вообще не имеет смысла автоматизировать. Именно такой набор функциональности, позволяющий пользователю решить содержательную и действительно нужную ему задачу, и называется в UML примером использования. Соответственно, разработка программного обеспечения в RUP ориентируется именно на такие «кванты». Либо вы полностью реализуете пример использования в вашей системе, и пользователь получает реальную автоматизацию своих бизнес-процессов, либо нет. В последнем случае не важно, на сколько процентов вы реализовали пример использования: пользоваться им все равно нельзя. Скажем, либо вы реализуете возможность выписать счет для покупателя, либо нет — и тогда не важно, какие функции упорядочивания и фильтрации списков товаров вы уже реализовали.

Далее, в рамках объектно-ориентированного анализа и проектирования разработаны определенные методы и техники, направленные на реализацию именно одного примера использования. Дело в том, что реализация примера использования представляет собой, как правило, обозримую задачу, с которой справляется один разработчик. Но с другой стороны, пример использования представляет собой относительно независимую задачу, которую часто можно реализовать в виде отдельного компонента или подсистемы (или, по крайней мере, без необходимости непрерывно координировать каждое свое самое мелкое действие с коллегами, занятыми разработкой других частей).

Нельзя не отметить, что ориентация на примеры использования — это способ описать функциональность системы в форме и терминах, максимально понятных заказчику. В результате заказчик оказывается в большей мере привлечен к процессу разработки, чем при описании функциональности в терминах проектировщика, как это принято в стандартном ТЗ по ГОСТ 19 или 34.