Регистрация   E-Mail     Пароль   
  
Портал «Профессионал управления проектами»
!!!! Обращаем внимание регионов!
Первый курс по MS Project 2010 в он-лайн формате, 20-27 июля 2010 года.

Анализ требований и управление изменениями программных проектов

 
 
Дата публикации: 14.10.2014
Версия для печати (доступна только зарегистрированным пользователям)Версия для печати
 

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

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

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

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

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

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

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

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

Предыдущая страницапредыдущая 1. 2. 3. 4. 5. 6. следующаяСледующая страница
Страница 5 из 6
Обсуждение Обсуждение

Пожалуйста, авторизуйтесь или зарегистрируйтесь для участия в обсуждении.

Вызов консультанта