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

Теперь нужно сказать об используемых программных технологиях. На слайдах приводится один из возможных примеров. Исходя из того что будет выбрана объектно-ориентированная модель, выбирается объектно-ориентированный инструментарий на основе того, что магазин нужен не очень большой, но расширяемый, нужно выбрать инструментарий Java. Тогда возникают основные компоненты: СУБД, язык (логика программной работы и графический интерфейс), серверная часть (ее для простоты можно опустить) и технология связи с базой данных (при данном инструментарии это JDBC). При использовании тех или иных технологий также необходимо рассматривать ограничения. Сразу нужно сказать, что хорошим тоном является упоминание не только названий, но и версий продуктов, которые будут применяться, потому что можно протестировать совместимость этой версии как со средствами, которые имеются у пользователя, так и с элементами программного комплекса, которые мы планируем реализовать.

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

Что включает в себя графический интерфейс, мы можем определить на основе рис. 4.1. Графический интерфейс позволяет просматривать каталог продукции, данные по каждой позиции отдельно (здесь можно прямо указать соответствующий раздел технических требований). Кроме того, пользователь должен при помощи графического интерфейса иметь возможность отслеживать хронологию заказов, работать с корзиной (например, просто перебрасывать элементы каталога в корзину с помощью механизма drag&drop и посредством мыши и клавиатуры изменять количество элементов продукции в своем заказе), удалять и добавлять элементы в корзину.

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

Следует отметить, что графический интерфейс, который является частью решения, должен быть реализован с использованием технологий и библиотек Swing (здесь тоже лучше указать версию). Кроме того, среда разработки и средства также должны быть указаны: используем ли мы NetBeans, Eclipse или что-то другое. Например, в данном случае будем использовать среду разработки Idea 7.0.1. Это нужно четко указать для возможности дальнейших модификаций продукта.

Еще ряд важных технологических требований касается других элементов магазина. Во-первых, требования к БД. Прежде всего необходимо явно описать способ хранения данных. Так как объем хранимых данных достаточно велик, следует использовать СУБД, а не файлы. Программная система хранит в БД всю статическую информацию: каталог продуктов, заказы, служебная информация (имена и пароли пользователей, их адреса, ФИО). Что касается единиц продукции, нужно перечислить все атрибуты таблицы, где хранится каталог продукции: наименование, цена, вес, описание, указатель (URL) на изображение данного товара, цена доставки (по земле и по воздуху). Можно сослаться здесь на структуру данных о товаре из списка требований. Естественно, впоследствии при детализации требований необходимо в документации описать ER-диаграммы, которые будут описывать все структуры данных, поля и их типы, включая индексируемые, ключевые и т. д. Еще очень важно оговорить тип СУБД, ее название и версию: мы будем использовать реляционную СУБД PostgreSQL версии 8.2.4, и тогда у нас не возникнет сложностей с сопровождением и дополнительных конфликтов с заказчиков. Естественно, нужно обсудить с заказчиком используемый спектр программного обеспечения.

Третьей составляющей программной системы является обеспечение связи с БД. В данном случае, поскольку мы работаем с технологией Java, будем использовать JDBC. Мы четко указываем, что будем разрабатывать модуль связи с базой данных (отдельный класс). Отдельно указываем версию JDBC – 1.4.2 (как и версия Java). Далее указываем тот самый драйвер JDBC, который мы будем использовать. Естественно, он связан с PostgreSQL. Впоследствии у нас возникнет ряд документации по установке баз данных, да и всей программной среды. Будут указаны все каталоги, переменные окружения и т. д.

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

Глава 5
Методологии разработки корпоративных систем

В предыдущих главах были описаны модели жизненного цикла корпоративных систем, основные этапы их существования, начиная от концептуальной идеи, формализации требований, проектирования, реализации, передачи в эксплуатацию или на стадию сопровождения (собственно то, ради чего весь этот жизненный цикл строится) и вывод из эксплуатации. Было описано, каким образом перечисленные этапы отражаются в различных подходах или моделях жизненного цикла. Некоторые модели включают все стадии (объектно-ориентированная модель), другие – (Build-and-fix) не все стадии жизненного цикла. Существуют модели, которые основаны на линейной смене фаз (каскадная или водопадная), другие поддерживают определенную итеративность или цикличность (объектно-ориентированная или спиральная модели). Ряд моделей позволяет рассматривать некоторые этапы жизненного цикла параллельно или во взаимодействии, это прежде всего объектно-ориентированная модель, в которой сочетаются анализ и проектирование. Существуют несамостоятельные модели, такие как модель быстрого прототипирования. Отсюда следует вывод, что ряд моделей можно комбинировать. Комбинировать следует прежде всего некоторые из моделей полного жизненного цикла (спиральная, каскадная) с моделью быстрого прототипирования. Это дает возможность существенно экономить сроки и стоимость внедрения, избежать существенных проектных ошибок, так как позволяет проявить функциональность программного продукта уже на ранних стадиях (анализ и спецификация требований, начальный этап проектирования), а также благодаря быстрому прототипу вместе с заказчиком определить, в том ли направлении мы двигаемся и правильно ли понимаем друг друга.

Теперь рассмотрим параллельное направление, которое тоже связанно с подходами к разработке корпоративных информационных систем и называется методологией. Здесь возникает терминологическая нестыковка. Методология – набор приемов, методов и моделей, инструментальных средств. Здесь методология – это набор практических приемов. Тут нет математических моделей, экономического обоснования. В ряде подходов (методологии), особенно в гибких методологиях (Scrum, Agile), речь идет о гибко настраиваемой системе лучших практик или просто практических приемов разработки информационных систем. Поэтому в научном смысле о методологии здесь говорить не совсем верно. И в этой связи то, что было сказано о моделях жизненного цикла информационных систем, будет больше похоже на методологию, если к этому присовокупить еще и практические приемы. Также рассмотрим определенные классы инструментальных средств.

Методология – это параллельное направление (или ортогональное, еще одна ось, вдоль которой можно рассматривать жизненный цикл). Ранее уже упоминалось, что можно рассматривать программные проекты и программные продукты (их жизненный цикл отличается). В этой главе речь пойдет о программных продуктах, и акцент ставится больше на моделях, чем на методологиях. Но методологии полезны как набор практических приемов для достаточно эффективной реализации, в том числе и корпоративных приложений. Методологии, которые будут рассматриваться, могут включать различные модели. Например, методология Rational Unified Process может иметь в основе модель как каскадного жизненного цикла, так и спирального. То же можно сказать о методологии Microsoft Solution Framework (MSF). Методология с точки зрения жизненного цикла и точки зрения детализации этапов разработки информационных систем – это не столь формальный подход, как модели. В ряде случаев в зависимости от характера и масштаба проектов могут быть существенные коррективы. Rational Unified Process может становиться большим или малым (применяется более или менее развернутая схема разработки). В Microsoft Solution Framework также могут рассматриваться варианты более гибкого подхода (Agile) или подхода Formal (более полного). Желательно иметь в виду соотношение методологий и моделей.

Достаточно важно замечание по поводу характера и масштаба методологий. Существуют методологии, которые в полной мере подходят для проектирования корпоративных систем, и их можно назвать корпоративными (или тяжелыми). Они по аналогии с моделями описывают весь жизненный цикл, позволяют подготовить достаточно полную проектную документацию, хотя каждая из них является просто набором хороших приемов и в ряде случаев допускает упрощенный подход к проектированию и реализации информационных систем. И существуют более легкие (гибкие) методологии, которые не идеально подходят для больших корпоративных систем и могут использоваться при определенных условиях: при высоких рисках, высоких степенях неопределенности в проекте. Такие большие (тяжелые) методологии – это аналоги каскадной, спиральной моделей, не в том смысле, что эти модели там используются, а в том, что это достаточно полное представление жизненного цикла. Такими тяжелыми методологиями являются: Rational Unified Process и Microsoft Solution Framework. Rational Unified Process на сегодняшний день является методологией, которая представляется корпорацией IBM, Microsoft Solution Framework – корпорацией Microsoft. Интересно, что методология MSF возникла из модели синхронизации и стабилизации, и здесь имеются аналогии. Но если говорить о MSF как о методологии, речь пойдет скорее не о жизненном цикле программной системы, а о тех приемах и методах, которые нужны для поддержания этого цикла, для разработки, не только о программном продукте, но и о программном проекте (о ролях в проекте, их особенностях, взаимодействии персонала, проектной документации, которая поддерживает выполнение определенных видов деятельности).

Что касается легких или гибких методологий, будут рассмотрены в разной степени детализации Scrum, Agile, eXtreme Programming. Они являются наборами лучших практик, т. е. наборами рекомендаций о том, каким образом при высоких проектных неопределенностях и рисках вести разработку программных систем для того, чтобы обеспечить определенные качества результирующего программного продукта, если это вообще возможно, или прекратить разработку, если это невозможно, при этом уложившись в определенный бюджет и сроки.

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

Поговорим о методологии Rational Unified Process, которую кратко называют RUP. Она была разработана компанией Rational, затем унаследована корпорацией IBM и сегодня поддерживается достаточно большим количеством инструментальных средств линейки Rational, которые закрывают весь жизненный цикл программного обеспечения. Это и средства проектирования, и средства управления проектами, и целый ряд средств, которые нацелены на фазы разработки, тестирования, внедрения и сопровождения. В линейке более 10 средств, которые взаимодействуют друг с другом, призваны вести проектирование на основе RUP и поддерживают практически весь жизненный цикл программного обеспечения. Самое главное, что нужно отметить о подходе Rational Unified Process, – это то, что есть несколько важных направлений, которых он придерживается. Это прежде всего итеративность (последовательная доработка, примерно, по спиральной или инкрементальной модели). Оценка рисков является важной составляющей RUP (на самом деле всех методологий, особенно гибких). Кроме того, подход имеет в своей основе архитектурную центричность (основан на том, что в центре всего проекта находится архитектура и этап архитектурного проектирования), также применяются сценарии использования. Тут нет ничего удивительного. Сценарии использования применяются широко в языке UML, который поддерживает большинство CASE-средств. Прецеденты – это один из первых видов диаграмм UML, которые встречаются по пути жизненного цикла программных систем. На стадии первичного проектирования возникают прецеденты, и диаграммы прецедентов детализируются в ходе проектирования на сценарии использования. Сценарий использования, по сути, являет собой конкретизацию прецедента. То есть если имеется прецедент, который объединяет такие роли, как пользователь и система, и представляет собой вход в систему (регистрацию), то сценариев использования здесь может быть, как минимум, два – это успешная и неудачная регистрация. То есть сценарий использования детализирует возможные варианты прецедентов.

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

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

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

Поскольку речь идет об итерации, каждая стадия может повторяться большое количество раз (как минимум, три – четыре раза для серьезных программных продуктов). Эти стадии называются: начало, проектирование, построение, внедрение (рис. 5.1). Информация не является закрытой, она доступна на соответствующих интернет-ресурсах, т. е. это открытая, общедоступная методология. Более того, корпорации IBM и Microsoft стараются их популяризировать, давать возможность и сторонним разработчикам, и другим компаниям разрабатывать информационные системы.

Рис. 5.1. RUP: основные вехи

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

Очень важно подчеркнуть, что если первичное проектирование отвечает на вопрос «Что мы делаем?», то вторая фаза – на вопрос «Как?». Здесь речь идет об архитектурной составляющей проекта, из каких компонентов он будет состоять, как они будут взаимодействовать. С точки зрения программной архитектуры принимаем решение: будет ли это двух– или трехзвенная система, будут ли использоваться базы данных и т. д. Кроме того, происходит детализация требований. В моделях жизненного цикла, например объектно-ориентированной, очевидно, что детализация требований представляет собой полный перечень всех классов с описанием их сигнатур (имен, типов) атрибутов и методов, локальных и глобальных переменных, методов, которые будут взаимодействовать с соседними классами, и детализацией алгоритмов и структур данных, которые будут использоваться.

После того как детальное проектирование осуществлено, начинается третья фаза – фаза построения. Она соответствует реализации и модульному тестированию, интеграции и сборочному тестированию, тестированию. После этого осуществляется приемка и передачи продукта заказчику. Завершает стадию построения ревизия проекта, которая показывает, что продукт отвечает заявленным требованиям и способен пройти все приемочные тесты на реальном программном обеспечение заказчика.

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

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

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

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

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

Еще одно важное замечание, которое нужно реализовать при внедрении методологии 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 является достаточно формальным подходом, его артефакты достаточно четко определены, процессы формальны описаны, существует большое количество руководств, хороший опыт, накопленный в разных коллективах, по производству серьезных программных продуктов. Это свидетельствует о том, что этим подходом можно пользоваться для производства и сопровождения больших корпоративных приложений. При этом можно применять достаточно широкий спектр моделей жизненного цикла.