ТРПО-лекции

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

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

7.4.1. Итерация

Итерация (iteration) представляет собой определѐнный набор деятельностей, производимый в соответствии с планом и оценочными критериями, и приводящий к выпуску или версии программного обеспечения, или целевой системы.

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

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

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

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

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

7.4.2. Фазы итерации RUP

Каждая итерация делится на четыре фазы, показанные на рис. 7-3.

Рис. 7-3. Фазы

итерации RUP

Каждая фаза завершается контрольной точкой (milestone), предназначенной для обеспечения контроля путѐм постановки вопросов и анализа ответов на них.

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

Скачано с сайта 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

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

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

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

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

Унифицированный процесс рекомендует следующие ступени тестирования:

−Блочное тестирование. Тестируются минимальные части системы.

−Интегральное тестирование. Тестируются компоненты и/или подсистемы.

−Системное тестирование. Конечная система, состоящая из одного или нескольких приложений, тестируется тестерами.

−Приѐмочное тестирование. Конечная система тестируется пользователями.

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

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

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

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

7.6. Вспомогательные процессы RUP

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

1.Управление конфигурацией и изменениями (Configuration & Change management).

2.Управление проектом (Project Management).

3.Управление средой (Environment).

7.6.1. Технологический процесс управления конфигурацией и изменениями

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

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

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

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

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

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

7.6.3. Технологический процесс управления средой

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

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

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

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

7.7. Задачи ролей в технологических процессах жизненного цикла RUP

В ходе итеративной разработки программного продукта с использованием RUP предполагается повторение определѐнной последовательности действий для достижения результата.

Следует заметить, что круг задач начала итерации и внутри неѐ различен и по составу задач, и по составу ролей. Исключениями по составу ролей являются процесс управления проектом и процесс управления конфигурацией и изменениями.

Таблица 7-10. Роли и задачи проектной группы в начале итерации

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