Сергей Зыков - Основы проектирования корпоративных систем

Еще одно важное замечание, которое нужно реализовать при внедрении методологии Rational Unified Process: необходимо использовать программно-инструментальные средства, предназначенные для визуального моделирования и проектирования. Визуального, потому что Rational Unified Process существенно связана с UML, и, конечно, поэтому сложные продукты и их документация содержат огромное количество UML-диаграмм и графических примитивов (классы, прецеденты, состоянии и т. д.), чтобы управлять проектом и проектировать продукт (если мы работаем итеративно, то у нас существует кроме большого количества диаграмм еще большое количество итераций). Грамотно отслеживать, говорить на одном и том же языке важно для упрощения рабочих навыков общения с кейс-средствами, которые поддерживают проектирование на языке UML и обеспечивают сопряжение со средствами тестирования, кодогенерации, создания баз данных и т. д. Кроме того, важными требованиями являются постоянный мониторинг качества программного продукта и управление изменениями (управление потоками работ, которые происходят при реализации программных продуктов по этой методологии).

Структура методологии RUP включает роли, это важно, так как используются прецеденты и задачи, связанные со сценариями использования, и артефакты – проектные документы, которые производятся на каждой стадии (рис. 5.2). При этом используется целый ряд руководств, шаблонов и инструкций, которые указывают, каким образом следует вести проектирование и реализацию корпоративных приложений в рамках подхода Rational Unified Process. Для всех продуктов Rational существуют инструкции, руководства по проектированию, где описаны шаблоны, на основе которых нужно разрабатывать сценарии использования, анализировать и проектировать.

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

По сути, идеология связана с лучшими практиками, которые были перечислены ранее. Основные из них сводятся к удовлетворению принципов итеративного подхода: архитектурная центричность, компонентное проектирование, управление изменениями и качеством. Rational Unified Process можно адаптировать для различных моделей жизненного цикла, т. е. применять как каскадный подход, так и как подход, связанный с итерациями (может быть эволюционная модель жизненного цикла или инкрементальные, спиральные модели), и, кроме того, RUP может включать более или менее широкий набор артефактов, активностей и ролей и быть более или менее формализованной (рис. 5.4). Поэтому можно говорить о том, что Rational Unified Process может быть легкой или тяжелой, большой, формализованной, более применимой к корпоративным приложениям. Тем не менее говорить о том, что RUP имеет смысл применять для небольших проектов или изготовления небольших продуктов, не совсем правильно, потому как это достаточно серьезная методология, которая предусматривает существенные трудозатраты и весомый инструментарий. И, конечно, пользоваться ею для создания небольших продуктов экономически нецелесообразно: слишком много дополнительных расходов, связанных с проектной документацией, обучением сотрудников, привлечением специалистов по рискам. Для небольших проектов это неоправданно, а вот для корпоративных проектов важно, что Rational Unified Process является достаточно формальным подходом, его артефакты достаточно четко определены, процессы формальны описаны, существует большое количество руководств, хороший опыт, накопленный в разных коллективах, по производству серьезных программных продуктов. Это свидетельствует о том, что этим подходом можно пользоваться для производства и сопровождения больших корпоративных приложений. При этом можно применять достаточно широкий спектр моделей жизненного цикла.

Рис. 5.2.Структура RUP: роли, задачи, артефакты

Рис. 5.3.Структура RUP: руководства, шаблоны, инструкции