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

Создание сценария

< Лекция 3 || Лекция 4: 1234 || Лекция 5 >
Аннотация: Продолжается рассмотрение действий и соответствующих им операций, таких как: cоздание сценария, ведение проекта, сборка продукта, выпуск продукта, устранение дефекта, закрытие дефекта.

В сценариях формулируются функциональные задачи системы. Для определения этих задач внимательно изучите все потребности собирательных образов системы. Эти задачи могут быть сначала просто выписаны в виде списка, а позднее описаны в виде сценариев. Старайтесь не допускать сценариев, описывающих неудачные или неоптимальные пути поставленных задач. Сценарии могут создаваться во время "мозгового штурма", при помощи моментальных снимков или пробных тестов. Все они добавляются в список сценариев. Когда сценарии назначаются на следующую итерацию, они документируются и им присваиваются приоритеты. Создание сценариев заканчивается, когда составлен график реализации всех сценариев в итерациях, либо после создания архитектурного прототипа.

Работа над сценариями методом "мозгового штурма" Определите задачи системы
Создание моментальных снимков деятельности Выясните типичные способы использования системы
Определение приоритетов в списке сценариев Определите приоритеты для каждого сценария
Создание описания сценария Выберите подходящий обобщенный образ
Раскадровка сценария Подберите инструмент для раскадровки

Операция: Работа над сценариями методом "мозгового штурма"

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

Определение задач системы В папке требований Проводника команды откройте список сценариев. Список сценариев связан с проектом. Импортируйте все сценарии, созданные при помощи Проводника команды
Формулировка сценариев Выберите цель и рассмотрите разные способы, которыми собирательный образ может достичь ее или потерпеть в этом неудачу. Для способа, которым собирательный образ пытается достичь цели, выберите описательное имя. Затем добавьте элемент сценария с этим именем в список сценариев. При определении концепции проекта следует убедиться, что представление о будущем приложения охватывает все сценарии. При изменении представления следует корректировать концепцию

Операция: Определение приоритетов в списке сценариев

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

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

Операция: Формулировка описания сценария

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

Выбор подходящего собирательного образа Из списка сценариев выберите сценарий, вошедший в ближайшую итерацию или важный с точки зрения архитектуры. Откройте шаблон описания сценария в Microsoft Word и сохраните документ, дав ему имя сценария, чтобы отличать его от остальных, уже написанных сценариев
Формулировка описания сценария Пишите сценарий в разделе описания соответствующего документа. С самого начала описывайте каждое действие, выполняемое собирательным образом в процессе достижения поставленной цели. Действия, уже описанные в других сценариях, записывайте схематично, а в тех местах, где сценарий отличается от остальных, будьте наиболее подробны
Разбиение сценариев Если детальная оценка (составленная как сумма задач разработки) превышает длину итерации, то такой сценарий является кандидатом на разбиение. Получившиеся в результате разбиения подсценарии в сумме должны соответствовать исходному сценарию. Для каждого нового сценария следует определить характерные отличия от других. На основе шаблона сценария создайте хотя бы два документа, описывающие сценарии

Операция: Раскадровка сценария

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

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

Ведение проекта

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

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

Операция: Оценка хода выполнения

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

Оценка списка обязательных работ Если есть предполагаемая дата реализации проекта, определите число необходимых итераций на основании длительности начальной итерации. Используйте данные из отчета об общем темпе проекта (velocity report) для вычисления количества человеко-дней для итерации. Произведение двух этих значений даст объем оставшихся трудозатрат, выраженный в человеко-днях
Проверка зависимостей Проверьте зависимости в графике и убедитесь, что они соблюдаются
Анализ осуществимости При необходимости оцените число итераций, необходимых для реализации планируемых функций, и определите, соответствует ли ход работ целям, определенным в концепции проекта

Операция: Оценка пороговых значений показателей тестов

В документе с описанием подходов к тестированию указаны пороговые значения для показателей тестов. Необходимо периодически анализировать продвижение проекта в соответствии с этими показателями и при необходимости их корректировать. Эффективность тестов, число неисправностей, охват кода, подробные отчеты о выполненных тестах - все это поможет контролировать выполнение проекта. Затем, при необходимости, можно скорректировать курс.

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

Операция: Определение риска

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

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

Операция: Обзор целей

После всех итераций, кроме нулевой, продукт должен быть в стабильном состоянии и готовым к поставке. Установите показатель минимального приемлемого уровня ( minimum acceptance level ), чтобы в дальнейшем сравнивать реализованные сценарии и требования к качеству с этим уровнем. Минимальный приемлемый уровень должен постоянно переоцениваться с учетом изменений потребностей заказчика, состояния рынка и т. д. Минимальный приемлемый уровень обновляется после каждой итерации.

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

Операция: Классификация дефектов

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

Создание отчета о дефектах Выдайте запрос системе отслеживания дефектов о вновь обнаруженных и заново обрабатываемых дефектах
Анализ дефектов Ознакомьтесь с каждым обнаруженным дефектом, привлекая разработчиков, тестировщиков и менеджера проекта. Определите важность исправления каждого из них до конца проекта и текущей итерации
Присвоение приоритета и привязка к итерации Каждому дефекту присвойте приоритет и определите, в какой итерации его необходимо исправить, чтобы его обработку можно было учесть в графике проекта
Воспроизведение непонятных дефектов Если отчет о дефекте невразумителен или нет уверенности в истинном действии дефекта, группа управления программой должна попробовать воссоздать дефект, чтобы лучше понять его реальное влияние и возможности повторного появления
< Лекция 3 || Лекция 4: 1234 || Лекция 5 >
Сергей Пономарев
Сергей Пономарев
Россия, Воронеж, Воронежский Государственный Университет
Руслан Шарипов
Руслан Шарипов
Казахстан