Учебник. Московский финансовопромышленный университет Синергия Кафедра Системного программирования
 Скачать 3.83 Mb.
|
|
Операции: Определение продолжительности итерации. При планировании отталкивайтесь от даты окончания проекта. Оценка сценария. Определите подмножество из списка сценариев. Оценка требования к качеству. Определите подмножество из списка требований к качеству. Разбиение сценария на задачи. Соберите команду. Разбиение требования к качеству на задачи. Соберите команду. Планирование ресурсов на исправление дефектов. Зарезервируйте ресурсы на устранение дефектов. Планирование сценария (Составление графика сценария). Создайте набросок плана итерации. Планирование требования к качеству (Составление графика реализации требований к качеству). Создайте набросок плана итерации. Операция: Определение продолжительности итерации Итерация – это набор задач, которые должны быть выполнены в течение фиксированного промежутка времени. Общее время, необходимое для завершения задач, называется продолжительностью итерации. График проекта разбит на последовательность итераций и задач, которые, в свою очередь, имеют свой график. Определение продолжительности итерации включает в себя рассмотрение всех ключевых факторов, включая дату поставки продукта (если она определена), размер сценариев и их общее время. Обычно продолжительность итерации определяется в неделях, однако возможны и меньшие единицы времени. Продолжительность итераций определяется в начале проекта, а затем на основе этих данных определяется общая продолжительность проекта. Планирование от даты окончания. Если для проекта задана дата поставки конечного результата проекта, то она определяет продолжительность итераций. Создайте план проекта или с помощью 29 календаря выясните, сколько времени может быть отведено на разработку. Проверка размера сценария. После окончания планирования первой итерации проверьте, не разбиваются ли сценарии на более мелкие из-за ее продолжительности. Увеличьте продолжительность итерации, если это необходимо, для того чтобы она соответствовала размеру сценария. Проверка затрат на интеграцию. Интеграция выполняется на протяжении всей итерации по окончании каждой задачи разработки. Учитываются все особые требования или затраты на интеграцию. Анализ продолжительности итерации. Проводите анализ продолжительности итерации совместно с проектной группой. Оптимальная продолжительность позволяет выполнить небольшое количество сценариев или требований к качеству. Каждая итерация должна заканчиваться выпуском внутренней или внешней версии с новыми функциональными возможностями, исправленными ошибками, реализованными сценариями или требованиями к качеству. Операция: Оценка сценария Оценка сценария выполняется для создания общей картины, которая помогает понять, сколько усилий потребуется для реализации сценария. Подобные оценки позволяют бизнес-аналитику расставлять приоритеты и регулировать внешние ожидания. Менеджер проекта совместно с разработчиками выполняет оценки для наиболее приоритетных сценариев из списка. Определите подмножество из списка сценариев. Откройте список сценариев на портале проекта. Для каждого сценария с максимальным приоритетом назначьте разработчика или группу разработчиков, которые смогут выполнить оценку. Оценка реализации. Совместно с разработчиками оцените приблизительный порядок величины (rough order of magnitude, ROM) сложности каждого сценария. Для многих проектов может быть применено следующее правило. Если необходимо выполнить не более шести заданий, требующих 1–2 дня, в этом поле указывается значение 1. Если необходимо выполнить от 6 до 12 заданий, требующих 1–2 дня, в этом поле указывается значение 2. Если трудозатраты больше, в данном поле указывается значение 3 и рассматривается возможность разбиения сценария на части. Важно соблюдать примерные соотношения оценок, т. е. сценарий с порядком сложности 2 должен быть приблизительно в два раза больше сценария с оценкой сложности 1. Определение особых требований. Совместно с разработчиками определите риски, которые могут задержать или помешать успешному 30 завершению работ по реализации сценария, такие как недостаток знаний или зависимость от приложений сторонних поставщиков. Создайте описатель для каждого выявленного риска. Операция: Оценка требования к качеству Оценка требований к качеству служит для определения усилий, необходимых для их реализации. Подобные оценки позволяют бизнес- аналитику устанавливать приоритеты и регулировать внешние ожидания. Менеджер проекта совместно с разработчиками выбирает из списка наиболее приоритетные требования к качеству и выполняет для них оценки. Выбор требований к качеству из списка. Откройте список требований к качеству на портале проекта. Для каждого сценария с максимальным приоритетом назначьте разработчика или группу разработчиков, которые смогут выполнить оценку. Выполнение оценки реализации. Совместно с разработчиками оцените приблизительный порядок величины сложности каждого требования к качеству. Для многих проектов может быть применено следующее правило. Если необходимо выполнить не более шести заданий, требующих 1–2 дня, в этом поле указывается значение 1. Если необходимо выполнить от 6 до 12 заданий, требующих 1–2 дня, в этом поле указывается значение 2. Если трудозатраты больше, в данном поле указывается значение 3 и рассматривается возможность разбиения на части задачи реализации требования к качеству. Важно соблюдать примерные соотношения оценок, т. е. сценарий с порядком сложности 2 должен быть приблизительно в два раза больше сценария с оценкой сложности 1. Определение ограничений. Совместно с разработчиками определите риски, которые могут помешать успешному и своевременному завершению работ по реализации требования, такие как недостаток знаний или зависимость от ПО сторонних поставщиков. Создайте описатель риска и прикрепите его к соответствующему требованию к качеству для отображения зависимости. Операция: Разбиение сценария на задачи Сценарий перед реализацией нужно разбить на задачи. Такое разбиение позволяет точнее выполнить оценку сложности и распределить задачи между разработчиками. Некоторые сценарии могут затрагивать несколько подсистем приложения. В этом случае для каждой затрагиваемой области создается отдельная задача. Ключевым моментом в успешном разбиении сценария является подключение к этому процессу разработчиков и тестировщиков, а также поощрение их 31 выбирать себе задачи самостоятельно. Все задачи должны быть распределены. Соберите команду. Соберите архитекторов, разработчиков и тестировщиков, которые будут работать над сценарием либо как-то влиять на него. Менеджер проекта организует короткое собрание или дискуссию по электронной почте и фиксирует задачи. Определение архитектуры и задач разработки. Начиная с того места, где новый сценарий отличается от уже реализованных сценариев, проследите его до конца. Обращайте внимание на видимые пользователю элементы, изменения в инфраструктуре или структуре данных, а также на моменты, которые влияют на всю архитектуру. Определите изменения в компонентах системы, которые произойдут в результате реализации планируемого сценария. Выбор архитектуры и задач разработки. Пусть архитекторы и разработчики сами выберут себе задачи. Назначение ответственного разработчика сценария. Передайте сценарий одному из разработчиков, работающих над задачами сценария. Он будет отвечать за сквозное тестирование интеграции этих задач. Создание тестовых задач. Отредактируйте документ, описывающий тестирование для данной итерации, указав в нем тестовые данные и заполнив другие разделы. Создайте задачи для разработки необходимых тестов проверки сценария. Выбор тестовых задач. Пусть тестировщики сами выберут себе задачи. Операция: Разбиение требования к качеству на задачи Перед реализацией каждое требование к качеству должно быть разбито на задачи. Такое разбиение позволяет точнее выполнить оценку сложности и способствует лучшему пониманию разработчиками предстоящей работы. В рамках реализации требований к качеству обычно нужно выполнить несколько задач. Ключевым моментом в успешном разбиении требования к качеству является подключение к этому процессу разработчиков и тестировщиков, а также поощрение их выбирать себе задачи для себя самостоятельно. Все задачи должны быть распределены. Соберите команду. Соберите архитекторов, разработчиков и специалистов по тестированию, которые будут работать над требованием к качеству либо как-то влиять на него. Менеджер проекта организует короткое собрание или дискуссию по электронной почте и фиксирует задачи. Определение архитектуры и задач разработки. По ссылкам найдите сценарии, имеющие отношение к требованию к качеству, и проведите их обзор. Требования к качеству различаются по области 32 своего влияния. Часть из них влияет только на один сценарий, в то время как другие могут оказывать воздействие сразу на несколько сценариев. Если будут обнаружены сценарии, пропущенные бизнес-аналитиком, добавьте их к соответствующему требованию к качеству. Выбор архитектуры и задач разработки. Доверьте архитекторам и разработчикам самим выбрать себе задачи. Назначение ответственного разработчика требования к качеству. Передайте требование к качеству разработчику, которому принадлежат задачи по соответствующему сценарию. Он будет отвечать за сквозное тестирование интеграции этих задач. Создание тестовых задач. Отредактируйте документ, описывающий тестирование для данной итерации, указав в нем тестовые данные и заполнив другие разделы. Создайте набор задач для разработки необходимых тестов. Выбор тестовых задач. Пусть тестировщики сами выберут себе задачи. Операция: Планирование ресурсов на исправление дефектов Составление графика выделения ресурсов на исправление дефектов предполагает исправление дефектов в порядке, определяемом их важностью. Обычно ресурсы на исправление дефектов выделяются всей группе разработчиков, но могут ограничиваться одним или несколькими разработчиками из команды. Ассигнования на исправление дефектов берутся из общего бюджета разработки. Планирование ассигнований на исправление дефектов. Из общего бюджета разработки выделите часть, необходимую на исправление дефектов (единица измерения – абстрактный человеко- день). Если план итерации выполняется в Microsoft Excel, обозначьте эти ассигнования как резерв бюджета. Если план итерации выполняется в Microsoft Project, то ассигнования могут быть запланированы условно. Учет зависимостей и других факторов. Если сценарии или требования к качеству спланированы с учетом ассигнований на исправление дефектов, убедитесь, что ключевые разработчики, имеющие большое количество неисправленных ошибок, обладают достаточным резервом времени для исправления ошибок с самым высоким приоритетом. Проверьте еще раз предстоящие задачи, чтобы убедиться в наличии резерва. Переназначьте задачи или дефекты для обеспечения исправления дефектов. Проведение собрания, посвященного началу итерации. Завершите разработку плана итерации проведением собрания, на котором будет изложена информация о предстоящей итерации. На собрании должны присутствовать все участники команды, чтобы еще раз проверить задачи итерации. 33 Операция: Составление графика сценария Сценарий разрабатывается и проходит первоначальное тестирование в рамках определенной итерации. В плане итерации отражено текущее понимание того, что в ней должно быть выполнено. План должен быть завершен до начала итерации. Первоначальный план создается на основе оценок, а затем уточняется по мере того, как сценарии и требования к качеству разбиваются на задачи. С каждой задачей связаны оценка трудоемкости и ответственные разработчики. Если позволяет бюджет итерации, для завершения ее планирования может быть проведено посвященное этому собрание. Оно позволяет всем заинтересованным участникам команды собраться вместе для обсуждения возникших вопросов и завершения плана итерации. Создание плана начальной итерации. Совместно с бизнес- аналитиком разработайте план начальной итерации. Уточнение плана начальной итерации. Когда сценарий написан и задачи по разработке включены в план итерации, общее количество запланированных работ не должно превышать средние возможности команды разработчиков. Проведение совещания, посвященного началу итерации. Завершите разработку плана итерации проведением собрания, на котором будет изложена информация о предстоящей итерации. На собрании должны присутствовать все участники команды, чтобы еще раз проверить задачи итерации. Операция: Составление графика реализации требований к качеству Для реализации требований к качеству должен быть составлен график работ. Требования к качеству описывают нефункциональные требования, такие как, например, уровень производительности. С некоторыми требованиями не связаны задачи. Однако требования могут быть связаны со сценариями, в которых они реализуются. Таким образом, требования к качеству должны быть запланированы одновременно с соответствующими сценариями, чтобы обеспечить выполнение задач, связанных с их описателями. Создание плана начальной итерации. Совместно с бизнес- аналитиком разработайте план начальной итерации. Получите последнюю версию списка требований к качеству с расставленными приоритетами и оцененными трудозатратами. Совместно с бизнес- аналитиком выберите те из требований, которые укладываются в план итерации с учетом средней производительности команды, показанной в предыдущей итерации, и количества сценариев и ассигнований на исправление дефектов, запланированных на данную итерацию. 34 Уточнение плана начальной итерации. Когда задачи по разработке будут включены в план итерации, убедитесь, что общее количество запланированных работ не превышает средние возможности команды разработчиков. Проведение собрания, посвященного началу итерации. Завершите разработку плана итерации проведением собрания, на котором будет изложена информация о предстоящей итерации. На собрании должны присутствовать все участники команды, чтобы еще раз проверить задачи итерации. Вопрос 3. Разработка архитектуры решения. Хорошая архитектура – это ясная и простая внутренняя структура большинства элементов приложения. Простая архитектура понижает сложность приложения. Архитектура может определять такие структурные элементы, которые позволяют проще модифицировать приложение в случае изменения требований и благодаря которым участки приложения могут разрабатываться независимо. Кроме того, в хорошей архитектуре используются преимущества от разбиения по уровням для увеличения надежности и уменьшения времени вывода приложения на рынок. Если имеются технологические риски, для их уменьшения можно применять разработку архитектурных моделей, что помогает лучшему пониманию системы. И наконец, безопасность и производительность – это вопросы архитектуры. Работа над ними должна проводиться с учетом всей системы. Операции: Разделение системы на подсистемы. Выберите архитектурные шаблоны. Определение интерфейсов. Разработайте интерфейсы. Разработка модели угроз. Создайте обзор приложения. Разработка модели производительности. Проведите обзор требований к качеству. Создание архитектурной модели. Изучите риски. Создание архитектуры инфраструктуры. Разработайте архитектуру инфраструктуры. 35 Операция: Разделение системы на подсистемы Приложения, являющиеся частью распределенной системы, содержат логически связанные фрагменты кода и совместно реализуют поведение целой системы. Разделение системы на модули дает массу преимуществ. Оно позволяет снизить общую сложность, инкапсулировать функции, увеличить потенциальные возможности повторного использования подсистем и создать логические единицы для разработки. При этом отпадает необходимость реализовывать всю систему сразу. Для создания гибкой архитектуры в MSF применяется создание временного прототипа (shadowing). Приложение-прототип (shadow) позволяет применить принцип нисходящего проектирования в любой итерации. В начале итерации, когда существует лишь проект, прототип опережает рабочий программный код. В этот период проектные конструкции не синхронизованы с кодом. В рамках прототипа выполняются все изменения архитектуры или дизайна, которые необходимы для предохранения основного кода от превращения его в «дымоход», «спагетти-код» и прочих проблем, связанных с плохим проектированием. По мере реализации элементов начального предваряющего прототипа (leading shadow), архитектура все больше соответствует рабочему коду. Те части системы, которые были спроектированы, но не были реализованы, теперь становятся действительными. Когда архитектура соответствует рабочему коду, прототип называется завершающим (trailing shadow). Это сумма конструкций из всех предыдущих итераций. Чтобы избежать чрезмерной детализации архитектуры, рекомендуется сконцентрироваться на уровне компонентов и устанавливаемых элементов. Добавьте приложения, необходимые для поддержки функциональных возможностей, предусмотренных в запланированных сценариях, требованиях к качеству и в намеченных для исправления дефектах. В начале итерации добавьте задачи по переработке кода, чтобы он соответствовал измененной архитектуре. Если необходимо, проверьте новую структуру при помощи архитектурных моделей. Выбор шаблона архитектуры. Если предполагается развертывание системы в рамках существующей инфраструктуры, изучите логическую диаграмму центра обработки данных для того, чтобы понять технологию развертывания. Если такой диаграммы не существует, создайте ее. Создание приложений. В рамках диаграммы приложения создайте предваряющий прототип или его эквивалент для выбранной топологии системы. Создайте диаграмму системы на основе 36 приложений-прототипов и добавьте прокси для всех нереализованных точек входа. Проверка развертывания. После того как диаграмма приложения стала соответствовать архитектуре в данной итерации и определена целевая инфраструктура, пора проверить развертывание. На диаграмме приложений выберите определенный вариант установки и отобразите новые приложения на соответствующие им логические серверы. Создание задач, реализующих изменения в архитектуре. Создайте новые задачи, в рамках которых будет реализован предваряющий прототип и выполнены необходимые переработки существующих функциональных возможностей в новое приложение. Операция: Определение интерфейсов Разработку системы можно распараллелить, если до начала разработки определены все интерфейсы. Зачастую в начале итерации имеется еще недостаточно деталей, что мешает полному пониманию, необходимому для разработки элементов интерфейса. Поэтому разработку интерфейсов стоит откладывать до того момента, пока она не станет абсолютно необходимой: ведь даже после определения интерфейсов могут происходить изменения в проекте. Проработка интерфейсов помогает при интеграции систем, а также при изменении подходов в реализации задач разработки. В диаграмме приложений следует отображать внешние интерфейсы системы, а также внутренние интерфейсы высшего уровня. Проектирование интерфейса. Определите интерфейсы для сценария или требования к качеству. Проверьте требования по взаимодействию с внешними системами. Определение интерфейсов веб-сервисов. Выберите конечную точку веб-сервиса на диаграмме приложения. Определите операцию и снабдите ее необходимой информацией, такой как имя, возвращаемый тип и параметры. Убедитесь, что в свойствах правильно настроены язык и путь к генерируемым файлам. Сгенерируйте заглушку для нового веб- сервиса. Создание интерфейсов классов. Совместно с разработчиками определите методы классов, которые будут обеспечивать интерфейсы между разработчиками. Применяя диаграмму классов, проверьте согласованность классов и новых методов. Операция: Разработка модели угроз В модели угроз документируются известные угрозы безопасности и описывается, как на них следует реагировать. Моделирование угроз 37 является частью структурного подхода, позволяющего определить опасности, с которыми вероятнее всего столкнется система, а также степень их воздействия. В рамках целостной модели угрозы рассматриваются в порядке убывания представляемой опасности, а также рассматриваются необходимые меры противодействия им. Модель угроз следует создавать как можно раньше, а потом, по мере развития архитектуры, уточнять ее. Совместно с бизнес-аналитиком проведите обзор угроз и разработайте требования к безопасности. Создание обзора приложения. Определите сценарии, относящиеся к задачам обеспечения безопасности. Внимательно изучите каждый сценарий на предмет возможности отступления от бизнес- правил. Постарайтесь найти уязвимости в сценариях, относящиеся к задачам обеспечения безопасности. Разбиение приложения. Определите границы доверия в рамках вашего приложения. На логической диаграмме центра обработки данных создайте новую зону, которая будет отражать эти границы. Для каждой подсистемы определите, являются ли надежными входящие потоки данных и пользовательский ввод. Если нет, то решите, как они должны аутентифицироваться и авторизоваться. Определение угроз. Для каждого ресурса или функции определите затрагивающие их реализованные сценарии. На их примере обсудите, как система должна использоваться, а как – нет. Определение уязвимостей. Убедитесь, что все части системы были рассмотрены и что все известные типы угроз были проанализированы. Операция: Разработка модели производительности Моделирование производительности – это процесс, помогающий определить потенциальные проблемы с производительностью в приложении и найти решение для этих проблем. Моделирование производительности проводится на основе требования к качеству, которое, в свою очередь, разбито на задачи. Каждая задача имеет свой бюджет, предназначенный для решения вопросов производительности во время реализации. Обзор требований к качеству. Определите сценарии, связанные с требованиями к производительности. Определение объема работы. По списку требований к производительности определите объем работ для приложения. Определение необходимого уровня производительности. Используя оценки объема работ и список требований к качеству, определите необходимый уровень производительности для каждого ключевого сценария. Он включает такие характеристики, как время отклика, пропускную способность и используемые ресурсы. 38 Определение бюджета для решения вопросов производительности. Определите объем ресурсов, влияющих на производительность, который позволит добиться необходимой производительности. Примерами таких ресурсов являются время исполнения и пропускная способность сети. Распределение бюджета. Распределите ресурсы между технологическими операциями для каждого сценария. Оценка бюджета. Найдите бюджетные ассигнования, для которых существует риск нехватки для достижения необходимой производительности. Проверка модели. Выявите сценарии, на которые не выделены бюджетные ассигнования. Операция: Создание архитектурной модели Создание архитектурной модели может значительно снизить имеющиеся риски. Важно как можно раньше обратить внимание на риски в проекте и тем самым учесть их при принятии стратегических и архитектурных решений, пока изменения основных компонентов архитектуры еще не требуют больших затрат. Создание ранних прототипов снижает общие риски и неопределенности в проекте. Это, в свою очередь, позволяет более точно выполнять планирование и оценки в последующих итерациях. Модели могут быть временными и отбрасываться, как только они отвечают на поставленные вопросы, или могут быть основой для архитектуры приложения. Изучение рисков. Определите элементы, которые могут помочь в определении риска или принятии архитектурного решения. Планирование. Определите необходимый вид модели. Построение и работа модели. Постройте модель. Сосредоточьтесь на решаемой проблеме. Убедитесь, что модель должным образом описывает исследуемый вопрос. Операция: Создание архитектуры инфраструктуры Архитектура инфраструктуры определяет окружение, в котором будет работать приложение. Хорошо разработанная архитектура инфраструктуры гарантирует установку приложения в соответствии с требованиями к качеству. Начинайте разработку архитектуры инфраструктуры, как только появляется представление о будущем приложении. При необходимости изменяйте разработку по мере того, как улучшается понимание подсистем в рамках общей архитектуры. Для построения архитектуры инфраструктуры используйте логическую диаграмму центра обработки данных. 39 Создание архитектуры инфраструктуры. Создайте логическую диаграмму центра обработки данных. Работайте с операциями, если они применимы, для лучшего понимания рабочего окружения. В логическом центре обработки данных создайте логические серверы, отражающие физическое окружение. Проверьте получившуюся диаграмму. Сопоставление архитектуры решения. Отобразите участки диаграммы приложения на логическую диаграмму центра обработки данных. Проверьте правильность этого отображения. Проверьте диаграмму приложения при помощи логической диаграммы центра обработки данных. Корректировка архитектуры решения. По мере определения новых подсистем выявляйте необходимые изменения в архитектуре инфраструктуры. Вопрос 4. Формулирование концепции проекта. Перед запуском проекта необходимо четко сформулировать его концепцию. Формулирование и донесение центральной концепции является самым важным элементом в поддержании направленности проекта. В течение жизни проекта его концепция может меняться под воздействием внешних или внутренних факторов. Если подобные изменения произошли, то важно сразу изменить проект согласно новой концепции. Концепция дает представление о будущих пользователях. Способы использования и задачи этих пользователей должны быть выявлены при помощи собирательных образов (personas). Концепция дает понять, привязан ли проект ко времени или к реализуемому функционалу. Сама концепция и связанная с ней деятельность создают надежный фундамент, на котором будет строиться весь проект. Операции: Написание концепции. Обобщите всю известную о проекте информацию. Определение собирательных образов. Определите группы пользователей. Уточнение собирательных образов. Определите характер отличий между собирательным образом и пользователем. Операция: Написание концепции Концепция – это короткая и точная формулировка цели создания новой системы или улучшения существующей. Она дает команде 40 представление о проекте и его движущих факторах, а также содержит обоснование разработки системы. В концепции должно присутствовать высокоуровневое описание пользователей системы. Концепция должна также содержать описание потребностей пользователей и способов их удовлетворения разрабатываемым приложением. Наконец, концепция определяет, привязан ли выпуск системы к срокам или к функциональным возможностям. Концепция должна быть написана языком, понятным будущим пользователям. Написание сжатой и предметной концепции является сложной задачей. Обобщение исходных данных проекта. Напишите один-два абзаца о контексте проекта. В них должна быть описана предпосылка создания новой системы или улучшения существующей. Объяснение движущих факторов. Опишите основные требования или выделенный интервал времени, которые управляют выпуском продукта. Будьте кратки. Определение пользователей. Определите тех пользователей, которые получат наибольшую пользу от системы. Определение основных достоинств. Опишите предполагаемые достоинства новой или улучшенной системы. Операция: Определение собирательных образов Собирательный образ – это вымышленный персонаж, представляющий группу пользователей. Собирательные образы используются для изучения потребностей целого сегмента пользователей путем рассмотрения характеристик одного вымышленного персонажа. Для определения собирательного образа изучите сегмент пользователей, взаимодействующих с системой, соберите их опыт, умения и цели, которые они разделяют. На основе этих данных создайте вымышленный персонаж, представляющий данный сегмент. Собирательный образ является также инструментом, с помощью которого можно получить информацию о пользователях, упомянутых в концепции. Собирательные образы используются при создании сценариев и при проведении исследовательских тестирований. Определение ролей. Среди пользователей, определенных в концепции, выберите группу пользователей, взаимодействующих с системой. Создание собирательного образа. Для создания собирательного образа соберите реальные данные. Используйте данные, полученные в исследованиях удобства использования и при посещениях клиентов, в работе с фокус-группами и при маркетинговых исследованиях, чтобы убедиться, что собирательный образ представляет реальных пользователей. 41 Операция: Уточнение собирательных образов Собрания и обзоры часто помогают выявить новые детали о способах использования и уровне знаний. Используйте такие собрания для проверки собирательных образов. Периодически уточняйте их, чтобы они соответствовали текущей целевой аудитории системы. Если в собирательных образах происходят изменения, сообщайте об этом заказчику. Определение отличий. Выявляйте сходства и различия в уровне знаний, способах использования, взаимодействии и задачах, имеющиеся между собирательным образом и реальным пользователем. Если нашлись такие отличия, разберитесь, является ли пользователь тем, кого описывает собирательный образ. Обновление и передача изменений. Добавьте новые собирательные образы и измените существующие. Вопрос 5. Разработка требований к качеству. Требования к качеству используются для описания нефункциональных требований или ограничений на функциональные возможности системы. Требования к качеству должны быть точными и не быть субъективными. Они выявляются, им присваиваются приоритеты, и они – если запланированы на текущую итерацию – документируются. Операции: Определение требований к качеству путем «мозгового штурма». Определите цели требований к качеству. Создание моментальных снимков деятельности собирательного образа. Определите характерный промежуток времени действий собирательного образа. Определение приоритетов в списке требований к качеству. Определите важность каждого требования. Написание требований к качеству. Задокументируйте требования к качеству. Определение требований безопасности. Задокументируйте требования к системе безопасности. 42 Операция: Определение требований к качеству путем «мозгового штурма» Проведите коллективное обсуждение требований к качеству, проанализируйте каждый сценарий и определите, какие взаимодействия в них должны сопровождаться требованиями к качеству. Во время обсуждения выявите аспекты системы, для которых в сценариях были пропущены необходимые требования к качеству. Список требований к качеству содержит нефункциональные требования к приложению, он же является списком ограничений функциональных возможностей системы. Бизнес-аналитик каждый раз переоценивает и корректирует список требований к качеству, когда в процессе тестирования выявляются новые требования или когда появляются изменения в проекте. Определение необходимых уровней качества. В папке требований Проводника команды (Team Explorer) откройте список требований к качеству. Он связан с проектом. Если необходимо, импортируйте описатели требований к качеству, которые были созданы непосредственно в Проводнике команды. Определение требований к качеству. Проанализируйте сценарии на предмет соответствия желаемым стандартам качества всех моментов, связанных с взаимодействием пользователя и системы. Операция: Создание моментальных снимков деятельности собирательного образа Моментальные снимки деятельности – это необязательные средства, которые используются совместно с моделью собирательного образа. При написании сценариев моментальные снимки помогают конкретизировать некоторые детали. Моментальный снимок деятельности – это описание одного дня или короткого периода в жизни собирательного образа. При этом всегда описывается текущее состояние, без применения предлагаемой технологии, что помогает продемонстрировать, чем новая система или продукт будут полезны для пользователя. Работая с конкретными примерами деятельности, проще оценить пользу от каждого сценария и назначить им на основании этого приоритеты. Создание прототипа рабочего дня собирательного образа. Для каждого собирательного образа выделите один или несколько периодов времени в их жизни. Поиск технологических возможностей. Изучите каждый день собирательного образа и выявите места, где применение продукта оказывается полезным пользователю за счет решения каких-либо его задач или расширения возможностей. 43 Операция: Определение приоритетов в списке требований к качеству Приоритеты в списке требований к качеству определяются исходя из их важности и оказываемого влияния на пользователя. Требования, которые наиболее важны пользователю, должны реализовываться в первую очередь. Список требований к качеству, упорядоченных по приоритетам, включается в план итерации. Тот, в свою очередь, используется при планировании разработки для повышения эффективности использования ресурсов. При добавлении или удалении требований, а также при изменении потребностей пользователей следует заново определить приоритеты списка требований к качеству. Определение общего приоритета. Каждому сценарию в списке назначьте общий приоритет. В поле приоритета списка сценариев впишите соответствующее числовое значение. Описание приоритетных сценариев. Используя шаблон описания сценария, контурно обрисуйте наиболее приоритетные сценарии, снабдив их кратким описанием, но в то же время достаточно подробным, чтобы разработчики на его основании смогли сделать оценки. Передача запросов для выполнения оценок. Пошлите разработчикам запрос на выполнение общих оценок для самых приоритетных требований. Разбиение требований или изменение приоритетов. Если цена какого-либо требования к качеству превышает бюджет итерации, попробуйте разбить это требование. Операция: Написание требований к качеству Требования к качеству используются для описания нефункциональных требований или ограничений на функциональные возможности системы. Требования к качеству должны быть точными и не быть субъективными. Их описание должно предоставлять достаточно информации разработчикам, чтобы те могли спроектировать и запрограммировать функциональные возможности, удовлетворяющие этим требованиям. Документирование требования к качеству. Опишите требование к качеству в поле описания его описателя. При разработке требований к качеству используйте следующий языковой шаблон: «контекст», «воздействие», «ответ». Требование к качеству должно быть таким, чтобы его можно было протестировать. Проектирование оставьте архитекторам и разработчикам. Прикрепление вспомогательной информации. К требованию к качеству прикрепите связанные с ним сценарии, если таковые имеются. 44 Если требование к качеству затрагивает все сценарии или большинство из них, просто укажите это вместо того, чтобы прикреплять их все. Операция: Определение требований безопасности Требования к системе безопасности определяют уровень, до которого система будет защищать себя и ресурсы. Это могут быть конфиденциальные данные, требования закона или нематериальные активы, такие как репутация компании, торговые секреты или интеллектуальная собственность. Требования к системе безопасности должны быть конкретны, а для защищаемых ресурсов должна быть возможность проверки защиты. Способ защиты описывать не нужно. Требования к системе безопасности обычно формулируются предложениями, начинающимися с глагола, например: «Предотвратить доступ неавторизованных пользователей к учетным записям клиентов». Защищаемые ресурсы должны быть четко определены. Документирование требований к системе безопасности. Опишите требования к системе безопасности в поле описания описателя требования к качеству. Убедитесь, что требования к системе безопасности обращены на конкретные ресурсы и могут быть протестированы. Проектирование оставьте архитекторам и разработчикам. Прикрепление вспомогательной информации. Прикрепите ссылки на законодательные акты, если они имеются. Прикрепите все сценарии, относящиеся к задачам обеспечения безопасности. Если требование к системе безопасности затрагивает все сценарии или большинство из них, просто укажите это, вместо того чтобы прикреплять их все. |