Основы проектирования корпоративных систем

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

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

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

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