Распределение сбора артефактов по различным фазам унифицированного процесса.

Сдвиг важности каждого потока работ в течении итераций и фаз процесса разработки

Проверка команды с помощью итеративного подхода

· Тенденция переходить к написанию кода. Строки кода – то, что менеджеры способны сосчитать.

· Сопротивление изменениям. Изменения замедляют написание кода.

· Нет заинтересованности в многократном использовании анализа, проекта или кода. Возможно, потому что работу оценивают по написанию нового кода.

Изменение:

· Теперь основное:

o Уменьшение рисков

o Создание фундамента архитектуры

o Реализация функциональности

· Прогресс изменяется в рисках, прецедентах, и компонентах, реализующих прецедент.

Последствия итеративного подхода

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

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

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

Для избегания задержки разработки и роста цены разработки организация должна делать сначала сложные вещи.

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

Разбитый на фазы Итеративный подход позволяет вносить изменения в течение всего времени разработки системы.

Типовая итерация

· Исполнители и артефакты могут участвовать более чем в одном потоке работ.

Например, разработчик компонент (component engineer) участвует в потоках работ по анализу, проектированию и реализации.

· После завершения итерации

o Регрессионное тестирование

o Оценка изменений требований

o Оценка появления новых требований

 

4. Поток работ для получения требований к системе. Получение требований к разрабатываемой системе. Проблемы, возникающие при получении требований к системе. Цели потока работ на этапе получения требований. Роль требований в жизненном цикле программного обеспечения. Понимание контекста системы с использованием модели предметной области. Понимание контекста системы с использованием бизнес - модели. Дополнительные требования.

Сбор требований к системе, как построение модели прецедентов использования системы

Основная задача потока работ по определению требований – построение модели прецедентов использования системы.

Функциональные требования структурируются на прецеденты использования.

Нефункциональные требования привязываются к конкретным прецедентам использования системы.

Общие для нескольких прецедентов нефункциональные требования выделяются в отдельный документ, называемый дополнительные требования (supplementary requirements).

Построение модели прецедентов

Построение модели прецедентов требует от системного аналитика привязывать функциональность системы к конкретному пользователю системы – актеру (actor).

Требует от системного аналитика выявлять категории пользователей системы – актеров.

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

Затем построенная модель прецедентов управляет всей разработкой.

 

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

Артефакты: Модель сценариев использования; Актер; Сценарий использования; Описание архитектуры; Глоссарий; Прототип интерфейса пользователя.

Участники: Системный аналитик; Спецификатор сценариев использования; Проектировщик интерфейса пользователя; Архитектор

Деятельности: Поиск актеров и сценариев использования; Определение приоритетов для сценариев использования; Детализация сценариев использования; создание прототипа интерфейса пользователя; Структурирование модели сценариев использования;

Схема описания потока работ

· Описание артефакта: артефакт – общий термин для любого вида информации (создаваемой, изменяемой, используемой) исполнителями (workers) при работе по созданию системы.

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

· Описание деятельности (activity) – часть работы за выполнение которой отвечает исполнитель в потоке работ и имеет результат в виде набора артефактов.

Исполнители и артефакты

Модель прецедентов

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

Позволяет заключить соглашение (контракт) на разработку системы.

Структурировать требования на пакеты содержащие прецеденты и диаграммы прецедентов.

Модель прецедентов – исходная модель для построения моделей анализа, проектирования, реализации, тестирования.

Актер

Модель прецедентов описывает действия системы для каждой категории пользователей – актеров.

Актером может быть внешняя программная система.

Актером может быть внешнее устройство: часы, телефонная карта, …

Актерами могут быть сотрудники или клиенты фирмы, для которой разрабатывается система. И сотрудники, и клиенты могут быть взяты из бизнес-модели.

Примеры артефактов – актеров

Примеры артефактов – актеров и прецедентов

Примеры отношений прецедентов