Преимущества итеративной разработки

• Меньший риск неудачного завершения проекта или получения некачественного программного кода. Большая производительность

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

• Быстрый и заметный прогресс

• Ранняя обратная связь и возможность учета пожеланий пользователей

• Так называемая «управляемая сложность». Пример: команда разработчиков не перегружена лишней работой на этапе анализа и проектирования и не перегружена лишком долгими и сложными задачами

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

132. Прецеденты. Критерии выделения прецедентов при разработке по.

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

POS –система (Point-of system).

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

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

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

Прецеденты должны ориентироваться на цели и задачи пользователя. В процессе описания необходимо задавать вопросы:

1. Кто является пользователем системы?

2. Каковы типичные сценарии использования системы?

3. Каковы цели и задачи пользователей?

4. Какой ожидается результат?

Три типа исполнителей.

Все сущности включая разрабатываемою систему могут играть различные роли:

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

2. Вспомогательный исполнитель – обслуживает систему, предоставляет информацию (служба авторизации платежей).

3. Закулисный исполнитель – заинтересован в реализации прецедента, но не является не основным не вспомогательным исполнителем (Налоговая служба).

Основные форматы прецедентов.

Выделяют несколько уровней:

- сжатый -

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

- развернутый – наиболее подробный, детально описываются все шаги и варианты развития сценария, а так же предисловие и результаты.

В развернутом формате представляют примерно 10% наиболее важных для приложения прецедентов.

Существует другой формат описания прецедентов (2 столбца, действие исполнителя и реакция системы).

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

Для выделения прецедентов используется следующая процедура:

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

2. Определите основных исполнителей цели которых удовлетворяются с помощью системы.

3. Для каждого исполнителя определите его задачи

4. Определите прецеденты удовлетворяющие каждому исполнителю и присвойте имена в соответствие с задачей.

При определение исполнителей и задач часто возникают вопросы на которые нужно ответить:

1. Кто запускает и выключает систему

2. Кто является системным администратором

3. Кто осуществляет управление пользователем и безопасностью

4. Должна ли система выполнять какие либо действия в ответ на события времени (время – исполнитель?! Существует ли процесс мониторинга? В результате которого система перезапускается в случае сбоя или каких либо других событий ? Кто анализирует журналы регистрации? Могут ли в качестве исполнителей выступать внешняя программа или автоматическая система?!)

Выделение полезных прецедентов.

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

Существуют 3 критерия для выделения прецедента:

1. Критерий одобрения руководством – прецедент регистрация напрямую не связан, с функциональными обязанностями, это прецедент на более низком уровне, но не этапе анализа требования.

2. Критерий элементарного бизнес процесса (EBP)- это задача выполняемая одним человеком в одном месте в одно время в ответ на некоторое бизнес событие добавляющие изменения в бизнес значение и переводящие данные в некоторое устойчивое состояние.

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