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

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

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

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

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

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