Файл: ТРПО-лекции.pdf

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 112

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

7.4.2.1. Вопросы в контрольных точках

Фаза анализа и планирования требований (Inception). Согласованы ли границы и задачи проекта? Следует ли продолжить работу над проектом?

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

Фаза построения (Construction). Получено ли достаточно близкое к завершению приложение? Можно ли переключить внимание проектной группы на обеспечение гарантии успешного развѐртывания?

Фаза внедрения (Transition). Готово ли приложение к выпуску?

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

7.4.2.2. Фаза анализа и планирования требований

В течение этой фазы идеи преобразуются в концепцию ПС, и создаѐтся план работ. Задачи фазы анализа и планирования требований:

−Построить упрощѐнную модель прецедентов, содержащую наиболее критичные варианты использования.

−Создать пробный вариант системной архитектуры с указанием наиболее важных подсистем.

−Выявить и расставить по приоритетам наиболее важные риски.

−Составить детальный план фазы проектирования.

−Выполнить грубую оценку всего проекта.

Результаты фазы анализа и планирования требований:

−Общее описание ПС: основные требования к проекту, его характеристики и ограничения.

−Начальная модель вариантов использования (степень готовности 10-20%).

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

−Начальный бизнес-план.

−План проекта, отражающий этапы и итерации.

−Один или несколько прототипов приложения.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Задачи проектирования:

−Составить детальное описание большинства вариантов использования.

−Разработать базовую архитектуру системы в виде представлений всех моделей (прецедентов, анализа, проектирования, реализации и развѐртывания).

−Определить наиболее критичные варианты использования.

−Спланировать действия и подсчитать ресурсы для завершения проекта.

Результаты фазы проектирования:

−Модель прецедентов (степень готовности 80%), определяющая функциональные требования к ПС.

−Перечень требований нефункционального характера.

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

−Работающий прототип.

−Уточнѐнный бизнес-план.

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

7.4.2.4. Фаза построения

В ходе ключевой фазы построения происходит создание ПС. Задачи фазы:

−Добавить к базовой архитектуре законченные программы.

−Расширить базовый уровень архитектуры до полного развитого уровня.

−Создать систему, готовую к передаче пользователям.

−При необходимости сформулировать предложения о внесении в архитектуру незначительных изменений.

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

−Приложение, интегрированное на требуемых платформах.

−Руководство пользователя.

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

7.4.2.5. Фаза внедрения

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

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

Задачи пользователей на фазе внедрения:

− Убедиться в соответствии новой системы функциональным требованиям.

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

− Исправить обнаруженные ошибки.

− Внести улучшения в главный выпуск, и оптимизировать производительность. − Подготовить тираж.

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

− Определить дефекты, исправление которых откладывается.

7.5. Основные технологические процессы RUP

Унифицированный процесс определяет шесть основных процессов:

1.Моделирование бизнес-процессов (Business modeling).

2.Управление требованиями (Requirements).

3.Анализ и проектирование (Analysis & Design).

4.Реализация (Implementation).

5.Тестирование (Test).

6.Развѐртывание (Deployment).

7.5.1. Технологический процесс бизнес-моделирования

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

7.5.2. Технологический процесс управления требованиями

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

Таблица 7-2. Роли и артефакты процесса управления требованиями

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

7.5.3. Технологический процесс анализа и проектирования

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

Таблица 7-3. Роли и артефакты процесса анализа и проектирования

7.5.4. Технологический процесс реализации

Этот процесс осуществляется для выявления порядка организации программного кода в терминах отдельных подсистем и преобразования исходного кода в исполняемые компоненты. Кроме того, процесс определяет порядок тестирования компонентов, а также интеграции отдельных компонентов в подсистемы и систему.

Таблица 7-4. Роли и артефакты процесса реализации

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011