Опубликован: 16.02.2010 | Доступ: свободный | Студентов: 1483 / 172 | Оценка: 4.21 / 4.00 | Длительность: 06:28:00
Лекция 6:

Описатели

< Лекция 5 || Лекция 6: 1234 || Лекция 7 >

Сценарий

Сценарий (scenario) - это разновидность описателя, в котором записывается один из возможных вариантов взаимодействия пользователя с системой. Сценарий содержит запись последовательности действий пользователя, которые он выполняет для достижения некоторой цели. В одних сценариях фиксируются успешные попытки, в других - безуспешные. При записи сценария нужно указывать, какой конкретный путь достижения цели описывается, поскольку таких путей множество.

Состояния и переходы


Состояние: Новый: Сценарии добавляются в список, который находится в папке сценариев библиотеки документов.

  • Переход: От нового к активному
    • Основание: Новый: Сценарий считается новым, когда создается впервые.

Состояние: Активный: Начальное состояние сценария - активный. Бизнес-аналитик создает сценарий, указывая для него информативное название, и заполняет поле описания как можно более подробными сведениями о нем. После того как сценарий полностью описан, бизнес-аналитик назначает его ведущему разработчику. В поле "Specified" (Описан) устанавливается значение "Yes" (Да) и сценарий остается в активном состоянии на время его реализации. Ведущий разработчик координирует с другими разработчиками действия, необходимые для реализации данного сценария.

  • Переход: От активного к обработанному
    • Основание: Завершен: Сценарий переводится в состояние обработанного на основании "Completed" (Завершен), если команда разработчиков закончила написание кода, реализующего данный сценарий. Ведущий разработчик назначает сценарий тестировщику
    • Основание: Разделен: Сценарий переводится в состояние обработанного на основании "Split" (Разделен), если выяснилось, что он слишком объемный или что требуется описание дополнительных деталей. При разбиении сценария создайте новые сценарии и свяжите их с начальным сценарием.
    • Основание: Отложен: Основание "Deferred" (Отложен) устанавливается для сценария, который не будет реализован в данной итерации. Реализация сценария может быть отложена из-за нехватки времени у разработчиков или обнаружения проблем, блокирующих работу. В поле "Iteration" (Итерация) нужно указать правильный номер итерации, в которой сценарий будет реализован. Если реализация сценария откладывается до следующей версии продукта, поле "Iteration" (Итерация) нужно оставить пустым. Не забудьте предоставить подробное описание причин, по которым отложена реализация сценария, и укажите планируемые сроки работы над ним.
    • Основание: Удален: Сценарий удаляется ("Removed"), если его реализация больше не считается целесообразной. При удалении сценария проверьте поля "Issue" (Препятствие) и "Exit Criteria" (Условия завершения). Обычно для удаленных сценариев в этих полях содержится "No" (Нет).

Состояние: Обработанный: После реализации сценария ведущий разработчик устанавливает его состояние в "Resolved" (Обработанный). Ведущий разработчик также назначает этот сценарий тестировщику после чего можно начинать его проверку.

  • Переход: От обработанного к закрытому
    • Основание: Завершен: Сценарий закрывается как "Completed" (Завершен), когда тестировщик сообщает о прохождении тестов. При завершении работы со сценарием проверьте поля "Issue" (Препятствие) и "Exit Criteria" (Условия завершения). Обычно для завершенных сценариев в этих полях содержится "No" (Нет).
    • Основание: Разделен: Сценарий закрывается на основании "Split" (Разделен), если выяснилось, что он слишком объемный или требуется описание дополнительных деталей.
    • Основание: Отложен: Основание "Deferred" (Отложен) устанавливается для сценария, который не будет реализован в данной итерации.
    • Основание: Удален: Сценарий удаляется ("Removed"), если его реализация больше не считается целесообразной.
  • Переход: От обработанного к активному
    • Основание: Тест не проходит: Если какие-либо тесты сценария не проходят, тестировщик должен вернуть сценарий в активное состояние и снова назначить его ведущему разработчику, создавшему данный сценарий. Тестировщик также должен создать соответствующий описатель дефекта для сбоя теста.

Состояние: Закрытый: Тестировщик закрывает сценарий при прохождении всех тестов. Сценарий также закрывается, если он откладывается, удаляется или разбивается на более мелкие.

  • Переход: От закрытого к активному
    • Основание: Повторная активация: Сценарий может быть заново переведен в активное состояние при изменении функциональности.
Название Обязательное. Название должно отражать цель выполнения сценария. Название должно быть максимально информативным
Область Поле "Area" (Область) применяется для группировки сценариев по функциям или проектным группам. Область должна быть допустимым узлом в иерархии проекта
Итерация Итерация, в которой реализован сценарий
Кому назначено Ответственный за работу со сценарием
Состояниe Обязательное. В поле "State" (Состояние) указывается одно из возможных состояний сценария: "Active" (Активный), "Resolved" (Обработанный) или "Closed" (Закрытый)
Основание В поле "Reason" (Основание) указывается, на каком основании сценарий переведен в его текущее состояние. Например, "Completed" (Завершен) - одно из возможных оснований перевода сценария в состояние закрытого
Описание Описание сценария на достаточно общем уровне. Подробное описание сценария должно быть в одном из конечных продуктов
Архив По мере обработки сценария в поле "History" (Архив) накапливаются записи. При каждом изменении, связанном со сценарием, в это поле добавляется запись со сведениями о том, какие сделаны изменения, почему, а также другие подробности
Препятствие В поле "Issue" значения "Yes" (Да) или "No" (Нет) указывают на наличие или отсутствие проблем, каким-то образом препятствующих реализации сценария. Если в поле указано "Yes" (Да), в отчете о проблемах менеджера проекта будет присутствовать соответствующий сценари й
Условия завершения В поле "Exit Criteria" значения "Yes" (Да) или "No" (Нет) указывают, входит ли данный сценарий в список обязательных работ (backlog) для текущей итерации. Это поле применяется для синхронизации различных представлений списка обязательных работ (список сценариев, набор требований к качеству и план итерации). Если условия завершения установлены в "Yes" (Да), данный сценарий отображается в контрольном списке проекта и одном из конечных продуктов. Данное поле в следующей версии будет переименовано в "Iteration Backlog" (Список обязательных работ в итерации)
Ранг Значение в этом поле ("Rank") указывает важность данного сценария относительно всех прочих сценариев
Сборка с реализацией В поле "Integration Build" хранится номер сборки ("Build"), в которой содержится реализация данного сценария
Идентификатор В поле "ID" хранится уникальный идентификационный номер сценария
Приблизительный порядок величины Если требуется выполнить от 6 до 12 заданий, требую щих 1-2 дня, в этом поле указывается значение 2. Приблизительный порядок величины ("Rough order of mag-nitude") - это способ оценки трудозатрат на реализацию сценария или требования к качеству. Если трудозатраты больше, в данном поле указывается значение 3 и рассматривается возможность разбиения на части задачи реализации сценария или требования к качеству. Если требуется выполнить не более шести заданий, требующих 1-2 дня, в этом поле указывается значение 1.

Риск

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

Состояния и переходы


Состояние: Новый: Описатель нового риска создается в любой момент, когда определяется риск. Этот новый описатель должен содержать название и описание, которые четко определяют потенциальные последствия риска. Также должно быть указано возможное воздействие риска. Новый описатель риска может быть создан любым участником команды и должен быть назначен специалисту, который будет отслеживать этот риск до его закрытия или переназначения.

  • Переход: От нового к активному: Описатель нового риска создается в любой момент, когда определяется риск. Для его создания используется меню в Team Explorer.
    • Основание: Новый: Описатель нового риска создается в любой момент, когда потенциальный риск может повлиять на проект. Для его создания используется меню в Team Explorer.

Состояние: Активный: Когда с помощью Team Explorer создается новый описатель риска, его состояние автоматически устанавливается в "Active" (Активный). Активное состояние риска указывает, что может произойти некоторое событие, способное повлиять на проект. Каждый риск должен быть назначен некоторому владельцу.

  • Переход: От активного к закрытому
    • Основание: Снижен: Риск может быть закрыт с указанием основания "Mitigated" (Снижен), если были предприняты некоторые действия для предотвращения возникновения рискованного события и/или уменьшения воздействия риска до приемлемого уровня.
    • Основание: Неактивный: Риск может быть закрыт на основании "Inactive" (Неактивный), когда вероятность его возникновения можно игнорировать. Никаких действий предпринимать не требуется.
    • Основание: Переведен: Риск может быть закрыт на основании "Transferred", если его можно вынести за рамки проекта. При этом сам риск не исчезает. Он лишь не влияет на проект в его текущем состоянии. Примеры перевода рисков: перемещение риска на следующую версию, привлечение сторонних консультантов или покупка готового программного компонента вместо его разработки.
    • Основание: Принят: Некоторые события невозможно предотвратить или снизить их воздействие. В таких случаях члены команды принимают риск, осознавая его эффект. При этом указывается основание закрытия "Accepted" (Принят).
    • Основание: Аннулирован: Риска может больше не быть из-за изменений в проекте или изменений в самом риске. Отслеживать его в проекте больше нет оснований и он закрывается как "Avoided" (Аннулирован).

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

  • Переход: От закрытого к активному
    • Основание: Повторная активация: Риск может возникнуть снова и при этом повторно активируется. Его состояние при этом меняется с "Closed" (Закрытый) на "Active" (Активный).
Название Обязательное. В поле "Title" (Название) кратко описывается потенциальный риск. Название должно быть достаточно информативным, чтобы участникам команды было понятно, с чем связан риск
Область Поле "Area" (Область) применяется для группировки рисков по функциям или проектным группам. Область должна быть допустимым узлом в иерархии проекта
Кому назначено Ответственный за отслеживание риска. Обычно это менеджер проекта или архитектор, но ответственным может быть и любой другой член проектной группы
Серьезность Серьезность ("Severity") содержит оценку влияния неблагоприятного эффекта, уровень потерь или возможных затрат на устранение риска ("Low" - низкая, "Medium" - средняя, "High" - высокая или "Critical" - критическая)
Основание В поле "Reason" (Основание) указывается, на каком основании риск переведен в его текущее состояние. Например, "Avoided" (Аннулирован) - одно из возможных оснований перевода риска в состояние закрытого
Состояние Обязательное. В поле "State" (Состояние) указывается одно из возможных состояний риска: "Active" (Активный) или "Closed" (Закрытый)
Итерация Итерация, в которой может произойти рискованное событие
Приоритет Приоритет описывает важность риска по отношению к другим рискам; удобен для определения последовательности, в которой следует снижать риски
Ссылки Ссылки ("Links") на связанные с данным описателем другие описатели, гиперссылки, наборы изменений или файлы с исходным кодом
Вложения В этом поле ("File Attachments") указываются файлы, содержащие дополнительные сведения о риске
Препятствие В поле "Issue" значения "Yes" (Да) или "No" (Нет) указывают на наличие или отсутствие проблем, каким-то образом препятствующих обработке риска. Если в поле указано "Yes" (Да), в отчете о проблемах менеджера проекта будет присутствовать соответствующий сценарий
Условия завершения В поле "Exit Criteria" значения "Yes" (Да) или "No" (Нет) указывают, входит ли обработка данного риска в список обязательных работ (backlog) для текущей итерации. Это поле применяется для синхронизации различных представлений списка обязательных работ (список сценариев, набор требований к качеству и план итерации). Если условия завершения установлены в "Yes" (Да), данный риск отображается в контрольном списке проекта и одном из конечных продуктов. Данное поле в следующей версии будет переименовано в "Iteration Backlog" (Список обязательных работ в итерации)
Описание В данном поле содержится описание риска, его воздействие на проект и возможные варианты его уменьшения
Архив В данном поле фиксируются все изменения, происходящие с описателем
< Лекция 5 || Лекция 6: 1234 || Лекция 7 >
Илья Макаренко
Илья Макаренко

Добрый день.

Вопрос №1

Какова стоимость получения диплома о мини-МБА по данному курсу? Или ориентироваться на указанную на сайте?

Вопрос №2

Возможно ли начать обучение без потери результатов, не отправив документы на зачисление, а отправку выполнить позже?

Александр Медов
Александр Медов

Здравствуйте, какова полная сумма предоставленной услуги с печатью документа и отправкой по почте?