1.7Процесс анализа требований
1.7.1Рабочий поток анализа требований
Анализ требований - один из основных рабочих потоков (workflow) программной инженерии, наряду, допустим, с такими, как проектирование интерфейса пользователя, либо программирование.
Для его обозначения в англоязычной литературе, как правило, используется понятие "Requirement Process". В отечественной практике, наряду с обобщающим термином "анализ требований", принятым, в частности, в ГОСТ Р ИСО/МЭК 12207-99, встречаются также такие термины, как "поток работ "требования", "работа с требованиями", "определение требований" и т.д., что вносит изрядную путаницу. Для того, чтобы внести некоторую ясность, рассмотрим декомпозицию рабочего потока Requirement Process на составляющие, принятую в SWEBOK, и введем терминологию, которой будем придерживаться на протяжении лекционного курса.
SWEBOK предлагает выделить в Requirement Process следующие основные составляющие:
Requirements Elicitation (Извлечение требований),
Requirements Analysis (Анализ требований в узком смысле),
Requirements Specification (Специфицирование требований),
Requirements Validation (Проверка требований).
В качестве примера альтернативной декомпозиции потока работ можно рассмотреть взгляд, предложенный в RUP [4.1]. RUP предлагает выделить в основном потоке анализа требований такие компоненты, как:
Analyze the Problem (Анализ проблемы),
Understand Stakeholder Needs (Понимание потребностей совладельцев),
Define the System (Определение системы),
Manage the Scope of the System (Управление контекстом системы),
Refine the System Definition (Уточнение определения системы).
Обобщая указанные выше декомпозиции, а также подходы, описанные в [4.4,4.5-4.7], далее будем придерживаться следующей, более удобной в методическом плане схемой декомпозиции потока работ "Работа с требованиями":
Формирование видения;
Выявление требований;
Классификация и спецификация требований;
Расширенный анализ требований (моделирование и прототипирование);
Документирование требований;
Проверка требований;
Управление требованиями;
Совершенствование процесса работы с требованиями.
Первые 6 работ в лекционном курсе рассматриваются, как компоненты процесса анализа требований.
Для того, чтобы успешно создать автоматизированную информационную систему (или шире, программную систему), необходимо, во-первых, определить компоненты потока работ, которые будут использоваться командой разработчиков и, во-вторых, правильно их организовать. В вопросы организации входит упорядочение работ во времени, интерфейсы между ними, параллелизм, работа с рисками и многое другое.
Найти ответ на первый вопрос может помочь общая классификация задач, работ и операций программной инженерии, представленная в ГОСТ Р ИСО/МЭК 12207-99. Другая, более поздняя по времени классификация, присутствует в SWEBOK. Однако нужно отметить, что данные руководящие документы рассматривают общий случай, а в частном проекте может быть задействован далеко не весь арсенал работ.
Сложнее - с решением второго вопроса. На сегодня существуют и имеют примеры успешного применения десятки и сотни различных методологий (процессов), среди наиболее известных - MSF, RUP, Oracle PJM, XP, FDD, SCRUM, PSP, Crystal, DSDM. Методологии подразделяются на 3 "волны": каскадные (исторически первые), прогнозирующие (например, RUP) и "быстрые" (agile), вошедшие в широкую практику на рубеже тысячелетий [4.3].
Описания методологий существенно разнятся объемом (от десятков до тысяч страниц текста), наборами базовых работ и рабочих квалификаций, акцентами (работа с моделями, управление рисками, построение команды и пр.). Но авторы их описаний обычно сходятся в одном: лучшая из методологий, которой нужно следовать, чтобы добиться успеха - именно та, которую предлагает (описывает, рекламирует) автор. Редким исключением являются работы А. Коберна, автора группы методологий Crystal (см., в частности, [4.3]), где он предлагает брать за основу не "самый лучший" из процессов, а тот, который, во-первых, наилучшим образом соответствует проектной задаче, а во вторых - команде, которая будет его реализовывать. В [4.3] вводится несколько метрик, позволяющих частично формализовать процесс подбора методологии.
1.7.2Почему нужно анализировать требования?
Из сказанного выше следует, что не все работы и операции, известные в программной инженерии, используются в той или иной методологии и, тем более, конкретном проекте. Возникает вопрос: является ли рабочий поток АТ необходимым в цепочке рабочих потоков создания информационной системы, стоит ли тратить на него время? Каков требуемый объем результатов, ожидаемых от АТ?
Со всей очевидностью можно утверждать: да, АТ, как этап разработки ИС, невозможно пропустить: этот этап закладывает фундамент всего процесса проектирования и реализации системы. Степень проработки АТ может быть различной: от совершенно неформальной записки, представленной на одной странице, до развернутой системы документов, моделей и прототипов, построенной в соответствии с принципами одной из прогнозирующих методологий, например, RUP. Она зависит от следующих основных факторов: размеров проекта, величины имеющихся ресурсов и степени рисков. Невысокая глубина проработки приемлема для небольших проектов, характеризующихся небольшим ресурсом и невысокими рисками. Хорошо проработанные требования позволяют:
выработать общее понимание между Заказчиком и Разработчиком;
определить рамки проекта;
более точно определить финансовые и временные характеристики проекта;
обезопасить Заказчика от риска получить продукт, в котором он не сможет работать,
обезопасить Разработчика от риска попасть в ситуацию "неконтролируемого размытия границ", которое может привести к непредвиденным затратам ресурсов сверх начальных ожиданий.
Анализ требований - это процесс (бизнес-процесс) и, следовательно, к нему подходят методы и средства процессного подхода к управлению (см., например, [1]).
Один из ключевых вопросов, позволяющих оценить результативность процесса - что является выходом (результатом) процесса. В чем результат АТ? Результатом рабочего потока "анализ требований" является набор артефактов. Это могут быть текстовые документы, модели UML, либо других языков моделирования, прототипы программного обеспечения.
Другой важный вопрос - какие цели преследует процесс.
RUP предлагает следующие цели для потока работ АТ:
добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система;
дать разработчикам наилучшее понимание требований к системе;
определить границы системы;
определить интерфейс пользователя и системы.
1.7.3Кто создает и использует требования
Как и кем используются требования?
Специалист по АТ - постановка задачи, определение рамок проекта;
Представитель заказчика - постановка задачи, определение рамок проекта, контроль работы исполнителя, приемка результатов работы;
Архитектор системы - разработка архитектуры, проектирование подсистем;
Программист - разработка программного кода;
Тестировщик - составление тест-плана, тестовых сценариев;
Менеджер проекта - планирование и контроль исполнения работ.
В рамках курса лекций для всех упомянутых выше лиц будем использовать обобщающий термин "Совладельцы (заинтересованные стороны)" (stakeholders). Совладельцами, вслед за разработчиками RUP и MSF (см., например, [4.4,4.8]), будем называть всех участников проекта создания программной системы, прямо или косвенно заинтересованных в его успехе. Авторы большинства современных методологий разработки программных систем сходятся в том, что в группе совладельцев ключевую роль играют две группы представителей Заказчика - те, кто ставит стратегические цели и выделяет финансирование и те, кто будет непосредственно использовать разработанный продукт. Причем, в отличие от каскадных методов, где Заказчик подключался в начальной фазе - составлении технического задания и конечной - приемке готовой работы, в современных методологиях Заказчик, действительно заинтересованный в успехе проекта автоматизации, должен участвовать в нем непрерывно.
1.7.4Организация работы с требованиями на примере MSF
В MSF для обозначения роли участников команды софтверного проекта используется понятие ролевых кластеров [4.9].
MSF основан на постулате о шести качественных целях, достижение которых определяет успешность проекта. Эти цели обуславливают модель проектной группы. В то время как за успех проекта ответственна вся команда, каждый из ее ролевых кластеров, определяемых моделью, ассоциирован с одной из упомянутых шести целей и работает над ее достижением.
Шесть ролевых кластеров модели проектной группы - это "Управление продуктом" (product management), "Управление программой" (program management), "Разработка" (development), "Тестирование" (test), "Удовлетворение потребителя" (user experience) и "Управление выпуском" (release management). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи.
MSF организован на базе комбинации каскадной и спиральной моделей. Отдельная стадия работы содержит в себе 5 фаз:
Envisioning (выработка концепции),
Planning (планирование),
Developing (разработка),
Stabilizing (стабилизация),
Deploying (внедрение).
В фазе выработки концепции работа с требованиями наиболее интенсивна (см. табл. 4.1).
Таблица 4.1.
|
Ролевой кластер
|
Фокус
|
Управление продуктом
|
Общие цели проекта; выявление нужд и требований заказчика; документ общего описания и рамок проекта.
|
Управление программой
|
Цели дизайна; концепция решения; структура проекта.
|
Разработка
|
Прототипирование; анализ технологических возможностей; анализ осуществимости.
|
Удовлетворение потребителя
|
Необходимые эксплуатационные характеристики решения и их влияние на его разработку.
|
Тестирование
|
Стратегии тестирования; критерии приемлемости, их влияние на разработку решения.
|
Управление выпуском
|
Требования внедрения и их влияние на разработку решения; требования сопровождения.
|
Как видно из таблицы, все 6 кластеров работают со своими группами требований.
Продолжается плотная работа с требованиями и на следующей фазе - фазе планирования, см. табл. 4.2.
Таблица 4.2.
|
Ролевой кластер
|
Фокус
|
Управление продуктом
|
Анализ бизнес-требований
|
Управление программой
|
Функциональная спецификация
|
Удовлетворение потребителя
|
Сценарии/примеры использования, пользовательские требования, требования локализации и общедоступности (accessibility).
|
Тестирование
|
Требования тестирования.
|
Управление выпуском
|
Эксплуатационные требования.
|
В фазах разработки и внедрения работа с требованиями сосредотачивается в кластерах управления продуктом и программой, см., соответственно, табл. 4.3,4.4.
Таблица 4.3.
|
|
Ролевой кластер
|
Фокус
|
|
Управление продуктом
|
Ожидания заказчика.
|
|
Управление программой
|
Управление функциональной спецификацией.
|
|
Таблица 4.4.
|
Ролевой кластер
|
Фокус
|
Управление продуктом
|
Получение отзывов и оценок заказчика; акт о приеме выполненной работы.
|
Управление программой
|
Сопоставление рамок проекта с поставленным решением; управление стабилизацией.
|
|
