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

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

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

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

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

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

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

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