Содержание проекта представляет собой описание всех работ, которые необходимо выполнить, чтобы получить программный продукт. Для описания всех работ необходимо:
- собрать и обработать требования;
- сформировать концепцию;
- создать иерархический список работ (ИСР) (Work Breakdown Structure -WBS).
Формирование реестра заинтересованных лиц
Требования, которые описаны в Уставе проекта, являются укрупненными. Их следует уточнить. Для этого нужно, прежде всего, выявить всех заинтересованных лиц. Заинтересованное лицо – это субъект, который прямо или косвенно имеет отношение к проекту. Даже на небольшом проекте реестр заинтересованных лиц должен содержать десятки (или более) фамилий:
1. Во-первых, это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).
2. Во-вторых, заинтересованным лицом всегда являются конечные пользователи продукта– актеры.
3. В-третьих, это члены проектной команды.
4. В-четвертых, это те, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.
Результатом выявления заинтересованных лиц является Реестр заинтересованных лиц. Наиболее широкое распространение получила форма реестра, приведенная на рис. 1.
Строки «Проект" и "PM" обязательны для заполнения (соответственно – вносится название проекта и фамилия и имя менеджера проекта).
Назначение атрибутов реестра и их назначение приведены в таблице 1.
Выявление требований и управление ими
Управление требованиями к ИС является важнейшим процессом при ее проектировании.
Управление требованиями к программному обеспечению — это процесс, который включает такие процедуры как выявление требований, их идентификацию, документирование, анализ, отслеживание выполнений, достижение соглашения по требованиям с заинтересованными лицами и управление изменениями.
Управление требованиями представляет собой непрерывный процесс, который выполняется в течение всего процесса разработки программного обеспечения.
Основная цель управления требованиями заключается в том, чтобы уменьшить риски и тем самым обеспечить гарантии качества разрабатываемого программного продукта для обеспечения потребности всех заинтересованных лиц.
Основными целями процесса управления требованиями являются:
- понять суть бизнес- процессов предметной области, для которой проектируется информационная система;
- определить проблемы предметной области, определить способы ее усовершенствования;
- создать условия для единого понимания особенностей предметной области как заказчиками и пользователями, а также разработчиками;
- выделить общесистемные требования, которые необходимы обеспечения функционирования разрабатываемой информационной системы;
- установить и поддержать соглашение с пользователями и другими заинтересованными лицами о том, какие функции система должна выполнять;
- обеспечить разработчиков системы лучшим пониманием того, как она должна функционировать и пониманием требований к ее созданию;
- определить границы разрабатываемой информационной системы;
- обеспечить основу для планирования содержания этапов проектирования и разработки;
- создать условия и информационный базис для оценки таких ресурсов, как стоимость и время, необходимых для разработки информационной системы;
- определить и утвердить графические интерфейсы пользователей отвечающих их потребностям и пожеланиям.
Управление требованиями является важнейшим фактором всего процесса разработки информационной системы. Поэтому эффективную работу с требованиями необходимо выполнять на протяжении всего жизненного цикла проекта. Первым шагом в этом направлении служит организация хранения всех выявленных требований.
Одним из основных инструментов, позволяющих организовать работу с требованиями в процессе проектирования, является программная система IBM Rational RequisitePro. Эта система позволяет проектной команде отслеживать требования – организовать их документирование и хранение, контролировать возможные изменения и выполнение.
Управление требованиями начинается с выявления и анализа целей и ограничений заинтересованного лица.
Заинтересованным лицом принято называть любого, кто имеет какое-либо отношение к системе как на этапе разработки, так и после ее завершения.
К категории заинтересованных лиц обычно относят:
- любого члена проектной команды, участвующего в разработке системы;
- любого, кто привносит свои знания в систему. Это могут быть эксперты предметной области, авторы документов, которые были использованы в процессе проектирования и т.п.;
- руководство компании заказчика;
- лиц, занятых настройкой и сопровождением системы;
- разработчиков и поставщиков стандартов и регламентов.
Требование представляет собой подробное описание того, что должно быть реализовано.
В зависимости от формата, источника и общих характеристик, требования могут быть разделены на различные типы. Наиболее часто в проектах используются следующие виды требований:
- потребности заинтересованного лица;
- предоставляемая системой функциональность, формулируемая бизнес-аналитиком;
- сценарий использования (Use Case), представляющие собой описание поведения системы;
- дополнительные требования – это такие требования, которые не могут быть охвачено сценариями использования, как правило это не функциональные требования;
- тестовые сценарии(Test Cases), которые представляют собой спецификации тестовых исходных данных, условий выполнения и ожидаемых результатов;
- сценарий – последовательность действий, определяющая путь по сценариям использования.
Работа по управлению требованиями осуществляется в соответствии с разрабатываемым для этой цели планом.
Перечисленные виды требований обычно представляют в виде пирамиды с иерархической структурой (рис. 2).
На верхнем уровне пирамиды располагаются потребности заинтересованного лица. На последующих уровнях находятся функциональные особенности, сценарии использования и дополнительные требования.
На разных уровнях пирамиды требований могут быть уточнены детали предыдущего уровня. Чем ниже уровень, тем более детально описывается требование. Например, потребность может быть следующей: «Данные должны быть неизменными». Функциональная особенность этого требования будет: «Система должна использовать реляционную базу данных».
На уровне дополнительных требований, требование еще более точное: «Система должна использовать базу данных Oracle 9i». Чем дальше вниз, тем более детальным становится требование.
Один из лучших способов управления требованиями – обобщать требования, по крайней мере, на двух различных уровнях. Например, документ Концепция («Vision») содержит высокоуровневые требования (особенности), а низшие уровни пирамиды представляют требования на более детальном уровне.
Какой будет степень детализации требований на каждом уровне, зависит от бизнес-аналитиков.
Главное отличие между потребностями и функциональными особенностями – в источнике требований. Потребности поступают от заинтересованных лиц, а функциональные особенности формулируются бизнес-аналитиками.
Роль тестовых сценариев заключается в том, чтобы проверить, корректно ли были реализованы сценарии использования и дополнительные требования. Алгоритмы помогают получить сценарии использования из тестовых сценариев, а также способствуют проектированию и реализации определенных путей через сценарии использования.
Свойства требований
Требование должно удовлетворять нескольким критериям. Хорошим требованием считается такое, которое имеет следующие характеристики:
- недвусмысленность;
- тестируемость (возможность проверки);
- ясность (краткость, сжатость, простота, точность);
- корректность;
- понятность;
- правдоподобность (реальность, выполнимость);
- независимость;
- элементарность;
- необходимость;
- независимость от реализации (абстрактность).
Кроме перечисленных характеристик для отдельных требований применяются еще три характеристики:
- постоянство;
- немногословность;
- завершенность.
Поясним приведенные критерии требований.
Недвусмысленность означает, что существует только один вариант интерпретации требования. Иногда двусмысленность проявляется в виде неопределенных акронимов.
Тестируемость (Возможность Проверки) означает, что тестеры должны иметь возможность проверить, было ли требование реализовано корректно. Тестирование должно быть либо пройдено, либо нет. Чтобы быть пригодным для тестирования, требование должно быть ясным, точным и недвусмысленным. Использование некоторых слов может сделать требование невозможным для тестирования:
- некоторые прилагательные– устойчивый, безопасный, точный, эффективный, целесообразный, гибкий, настраиваемый, надежный, дружелюбный, адекватный;
- некоторые наречия и фразы с ними: быстро, безопасно, своевременно;
- неспецифичные слова или акронимы: и т.д., и/или, TBD (to be determined).
Ясность (Краткость, Сжатость, Простота, Точность)
Требования не должны содержать ненужных выражений или информации.
Корректность
Если требование содержит факты, эти факты должны быть достоверны.
Понятность
Требования должны быть грамматически правильные, написаны в соответствующем стиле. Должны быть использованы стандартные соглашения. Слово «должен» должно быть использовано вместо «будет», «обязан» или «может».
Правдоподобность (Реальность, Выполнимость)
Требование должно быть выполнимо в рамках существующих ограничений, таких как время, деньги и доступные ресурсы.
Независимость
Чтобы понять требование, не нужно знать какое-либо другое требование.
Элементарность
Требование должно содержать отдельный трассируемый элемент (для которого возможно отслеживание связи).
Необходимость
В требовании нет необходимости, если:
- Ни одному заинтересованному лицу требование не нужно.
или
- Удаление требования не повлияет на систему.
Независимость от Реализации (Абстрактность)
Требования не должны содержать ненужной информации о дизайне и реализации системы.
Постоянство
Не должно существовать конфликтов между требованиями. Конфликты могут быть прямые и косвенные.
Прямые конфликты возникают, когда ожидается различное поведение системы в одной и той же ситуации.
Немногословность
Каждое требование должно быть обозначено только один раз, и не должно перекрываться другим требованием.
Завершенность
Требование должно быть описано для всех возможных условий:
Хорошее требование должно удовлетворять как можно большему количеству критериев. Однако они могут быть выражены в виде комбинации вышеперечисленных критериев.
Трассировка требований
Трассировка – это способ представления отношений между требованиями различного уровня в системе. Она помогает определить источник любого требования.
Каждая потребность обычно соответствует нескольким функциональным особенностям. Обычно это отношение «многие-ко-многим», так как одна потребность может трассироваться ко многим функциональным особенностям, но из нескольких потребностей может быть получена одна функциональная особенность. Одна потребность, соответствующая одной функциональной особенности – это также общий случай.
Функциональные особенности соответствуют сценариям использования в отношении «многие-ко-многим». Функциональные особенности также соответствуют дополнительным требованиям в отношении «многие-ко-многим».
Каждый сценарий использования соответствует одному или более сценарию (алгоритму), таким образом, их тип отношений – «один-ко-многим». Сценарии (алгоритмы) соответствуют тестовым сценариям в отношении «один-ко-многим».
Трассировка играет несколько важных ролей:
- подтверждение, что реализация удовлетворяет всем требованиям: все, что требовал заказчик, было реализовано;
- подтверждение, что приложение делает только то, что было заказано: не реализовывать то, что заказчик никогда не просил;
- анализ воздействия: Какие элементы будут затронуты при добавлении новых требований или изменении текущих?
- помощь в управлении изменениями: Когда некоторые требования изменяются, мы хотим знать, какие тестовые сценарии должны быть изменены, чтобы протестировать данное изменение.
Элемент трассировки – это элемент проекта, который должен быть получен (трассирован) из другого элемента.
Формирование Плана управления требованиями
Одна из самых первых задач в проекте – это разработка Плана Управления Требованиями (Requirements Management Plan – RMP). План управления требованиями содержит в себе общие подходы к управлению требованиями в проекте. В плане должно быть детально описано, каким образом создаются требования, как они упорядочиваются, изменяются и отслеживаются в течение жизненного цикла проекта.
Вопросы, на которые отвечает документ RMP:
- Будет использоваться инструмент для управления требованиями?
- Какие типы требований будут присутствовать в проекте?
- Каковы атрибуты этих требований?
- Где будут создаваться требования – в базе данных или в документах?
- Между какими требованиями должна осуществляться трассировка?
- Какие документы необходимы?
- Какие требования и документы будут использоваться как контракт с заказчиком?
- Если часть проекта разрабатывается сторонними исполнителями, какие требования и документы будут использоваться как контракт со сторонними разработчиками?
- Нужно следовать RUP или какой-либо другой методологии?
- Нужны заказчику особые документы для осуществления разработки?
- Как будет осуществляться управление изменениями?
- Предполагая использование специализированной программной системы для отслеживания и управления требованиями, будет ли система храниться в одном проекте, или будет разделена на несколько отдельных проектов?
- Какой процесс будет гарантировать, что все требования будут выполнены и протестированы?
- Какие требования или представления необходимы для генерации отчетов?
Описание процесса управления требованиями должно содержать следующие основные пункты:
- Формирование плана управления требованиями.
- Сбор требований.
- Разработка документа «Концепция» (Vision).
- Создание сценариев использования (Use Cases).
- Дополнительная спецификация.
- Создание тестовых сценариев (Test Cases) из сценариев использования (Use Cases).
- Создание тестовых сценариев (Test Cases) из дополнительной спецификации.
- Проектирование системы.
Первый шаг (план управления требованиями) определяет пирамиду требований. На каждом из последующих семи шагов строится один элемент пирамиды. Рабочий поток управления требованиями представлен таблицей 2.
Управление требованиями – это итеративный процесс. На типичной итерации предполагается полное прохождение по пирамиде. На любой итерации можно вернуться назад на несколько шагов и повторить действия. Например, в процессе создания тестовых сценариев, мы можем обнаружить, что отсутствует некоторая информация, и нам нужно получить ее от заинтересованного лица. Таким образом, мы возвращаемся на шаг сбора требований.
Для обеспечения целостности модели, важно обновлять все соответствующие требования.
На начальных итерациях акцент делается на первых нескольких шагах (в вершине пирамиды), а затем, на последующих итерациях, больше времени проводится на низших уровнях пирамиды.
В следующей статье рассмотрены рабочие потоки формирования требований.