Выбор технологии проектирования ИС. Критерии выбора

                        Extreme Programming (XP) – активно развивающаяся в последнее время технология, предназначенная для решения относительно небольших задач, относительно небольшими коллективами профессиональных разработчиков в условиях жестко ограниченного времени.

                        ICONIX разработал Дуг Розенберг в 1992 г., компания ICONIX Software Engineering  - процесс моделирования, который  представляет собой нечто среднее между довольно громоздким рациональным унифицированным процессом (Rational Unified Process - RUP) и весьма компактной методологией программирования еХtreme (XP). Процесс ICONIX основан на прецедентах (вариантах использования). В этом процессе тоже применяется язык моделирования UML (Unified Modeling Language), однако основное внимание уделяется анализу требований.

Модель Microsoft Solution Framework

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

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

Модель жизненного цикла MSF ориентирована на “вехи” (milestones) – ключевые точки проекта, характеризующие достижение какого-либо существенного результата. Этот результат может быть оценен и проанализирован, что подразумевает ответ на вопрос: “А достигли ли мы целей, поставленных на этом шаге?».

Основными фазами модели MSF являются:

                        Создание общей картины приложения (Envisioning):

o                          оценка существующей ситуации;

o                          определение состава команды,

o                          определение структуры проекта,

o                          определение бизнес-целей,

o                          определение требований и профилей пользователей;

o                          разработка концепции решения

o                          оценка риска.

o                          устанавливаются две промежуточные вехи: "Организован костяк команды" и "Создана общая картина решения".

                        Планирование (Planning). Разрабатывается проект и основные архитектурные решения, функциональные спецификации системы, планы и календарные графики, среды разработки, тестирования. Этап состоит из трех стадий:

o                          концептуальное проектирование - задача рассматривается с точки зрения пользовательских и бизнес-требований и заканчивается определением набора сценариев использования системы.

o                          логическое проектирование - задача рассматривается с точки зрения проектной команды, решение представляется в виде набора сервисов.

o                          физическое проектирование задача рассматривается с точки зрения программистов, уточняются используемые технологии и интерфейсы.

                        Разработка (Developing). Создается вариант решения проблемы, в виде кода и документации очередного прототипа, включая спецификации и сценарии тестирования. Основная веха этапа - "Окончательное утверждение области действия проекта". Продукт готов к внешнему тестированию и стабилизации. Кроме того, ключевые участники проекта могут предварительно оценить продукт и указать все недостатки, которые нужно устранить до его поставки.

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

                        Развертывание (Deploying). Выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Кроме того, анализируется проект в целом на предмет уровня удовлетворенности заказчика.

Rational Unified Process (RUP)

Одна из наиболее  совершенных технологий, претендующих на роль мирового корпоративного стандарта – Rational Unified Process (RUP). RUP представляет собой программный продукт, разработанный компанией Rational Software (www.rational.com), которая в настоящее время входит в состав IBM.

RUP в значительной степени соответствует стандартам и нормативным документам, связанным с процессами ЖЦ ПО и оценкой технологической зрелости организаций разработчиков (ISO 12207, ISO 9000, CMM и др.). Ее основными принципами являются:

1) Итерационный и инкрементный (наращиваемый) подход к созданию ПО.

2) Планирование и управление проектом на основе функциональных требований к системе – вариантов использования.

3) Построение системы на базе архитектуры ПО.

Первый принцип является определяющим. В соответствии с ним разработка системы выполняется в виде нескольких краткосрочных мини-проектов фиксированной длительности (от 2 до 6 недель), называемых итерациями.

Каждая итерация включает свои собственные этапы анализа требований, проектирования, реализации, тестирования, интеграции и завершается созданием работающей системы.

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

Согласно RUP, ЖЦ ПО разбивается на отдельные циклы, в каждом из которых создается новое поколение продукта. Каждый цикл, в свою очередь, разбивается на четыре последовательные стадии:

• начальная стадия (inception);

• стадия разработки (elaboration);

• стадия конструирования (construction);

• стадия ввода в действие (transition).

Каждая стадия завершается в четко определенной контрольной точке (milestone). В этот момент времени должны достигаться важные результаты и приниматься критически важные решения о дальнейшей разработке.

Начальная стадия

Начальная стадия может принимать множество разных форм. Для крупных проектов начальная стадия может вылиться во всестороннее изучение всех возможностей реализации проекта, которое займет месяцы. Во время начальной стадии вырабатывается бизнес_план проекта – определяется, сколько приблизительно он будет стоить и какой доход принесет. Определяются также границы проекта, и выполняется некоторый начальный анализ для оценки размеров проекта.

Результатами начальной стадии являются:

• общее описание системы: основные требования к проекту, его характеристики и ограничения;

• начальная модель вариантов использования (степень готовности – 10_20%);

• начальный проектный глоссарий (словарь терминов);

• начальный бизнес_план;

• план проекта, отражающий стадии и итерации;

• один или несколько прототипов.

Стадия разработки

На стадии разработки выявляются более детальные требования к системе, выполняется высокоуровневый анализ предметной области и проектирование для построения базовой архитектуры системы, создается план конструирования и устраняются наиболее рискованные элементы проекта.

Результатами стадии разработки являются:

• модель вариантов использования (завершенная по крайней мере на 80%), определяющая функциональные требования к системе;

• перечень дополнительных требований, включая требования нефункционального характера и требования, не связанные с конкретными вариантами использования;

• описание базовой архитектуры будущей системы;

• работающий прототип;

• уточненный бизнес_план;

• план разработки всего проекта, отражающий итерации и критерии оценки для каждой итерации.

Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы. Эта архитектура включает:

• модель предметной области, которая отражает понимание бизнеса и служит отправным пунктом для формирования основных классов предметной области;

• технологическую платформу, определяющую основные элементы технологии реализации системы и их взаимодействие.

Эта архитектура является основой всей дальнейшей разработки, она служит своего рода проектом для последующих стадий. В дальнейшем неизбежны незначительные изменения в деталях архитектуры, однако, серьезные изменения маловероятны.

Стадия разработки занимает около пятой части общей продолжительности проекта. Основными признаками завершения стадии разработки являются два события:

• разработчики в состоянии оценить с достаточно высокой точностью, сколько времени потребуется на реализацию каждого варианта использования;

• идентифицированы все наиболее серьезные риски, и степень понимания наиболее важных из них такова, что известно, как справиться с ними.

Стадия конструирования

Сущность планирования заключается в определении последовательности итераций конструирования и вариантов использования, реализуемых на каждой итерации. Итерации на стадии конструирования являются одновременно инкрементными и повторяющимися:

• итерации являются инкрементными в соответствии с той функцией, которую они выполняют. Каждая итерация добавляет очередные конструкции к вариантам использования, реализованным во время предыдущих итераций;

• итерации являются повторяющимися по отношению к разрабатываемому коду. На каждой итерации некоторая часть существующего кода переписывается с целью сделать его более гибким.

Результатом стадии конструирования является продукт, готовый к передаче конечным пользователям. Как минимум, он содержит следующее:

• ПО, интегрированное на требуемых платформах;

• руководства пользователя;

• описание текущей реализации.

Стадия ввода в действие

Назначением стадии ввода в действие является передача готового продукта в распоряжение пользователей. Данная стадия включает:

• тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователей;

• параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

• конвертирование баз данных;

• оптимизацию производительности;

• обучение пользователей и специалистов службы сопровождения.

Статический аспект RUP представлен четырьмя основными элементами:

• роли;

• виды деятельности;

• рабочие продукты;

• дисциплины.

Понятие «роль» (role) определяет поведение и ответственность личности или группы личностей, составляющих проектную команду. Одна личность может играть в проекте много различных ролей.

Под видом деятельности конкретного исполнителя понимается единица выполняемой им работы. Вид деятельности (activity) соответствует понятию технологической операции. Он имеет четко определенную цель, обычно выражаемую в терминах получения или модификации некоторых рабочих продуктов (artifacts), таких, как модель, элемент модели, документ, исходный код или план.

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

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

Дисциплина (discipline) соответствует понятию технологического процесса и представляет собой последовательность действий, приводящую к получению значимого результата.

В рамках RUP определены шесть основных дисциплин:

• построение бизнес_моделей;

• определение требований;

• анализ и проектирование;

• реализация;

• тестирование;

•развертывание;

и три вспомогательных:

• управление конфигурацией и изменениями;

• управление проектом;

• создание инфраструктуры.

RUP как продукт входит в состав комплекса Rational Suite, причем каждая из перечисленных выше дисциплин поддерживается определенным инструментальным средством комплекса. Физическая реализация RUP представляет собой Web_сайт, включающий следующие компоненты:

• описание всех элементов динамического и статического аспекта RUP;

• навигатор по всем элементам RUP, глоссарий и средство быстрого обучения технологии;