Целевые программы

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

• Краткое описание;
• Участвующие субъекты;
• Предусловия, необходимые для инициирования прецедента;

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

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

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

Тестирование приводит к обнаружению дефектов. Дефекты необходимо исправлять. Чтобы исправить дефекты их необходимо отправить в виде запросов на изменение (change request) и адресовать разработчикам. Некоторые запросы на изменение связаны с усовершенствованием, а не исправлением дефектов. Как дефекты, так и усовершенствования изменяют свой статус, им могут быть присвоены различные приоритеты, за их сопровождение могут отвечать различные лица, их необходимо отслеживать в связи с их источниками в виде документации по прецедентам и тестированию.

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

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

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