Управление требованиями на базе стандартов

Авторы: Роман Алфимов ®, Светлана Красникова ®, Елена Золотухина ®.

Елена Золотухина является сертифицированным специалистом по решениям IBM Rational и преподает в Учебно-Консалтинговом центре компании "Интерфейс"

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

Проблемы при выполнении проектов создания автоматизированных систем (АС) могут возникать из-за неформального сбора информации, предполагаемой функциональности АС, ошибочных или несогласованных нефункциональных требований к системе, а также нерегламентированной процедуры их изменения. Организация управления требованиями, прежде всего, направлена на дезавуирование таких проблем за счет усовершенствования способов сбора, документирования, согласования и модификации требований к системе, отслеживания требований от заинтересованных лиц и из прочих источников, их порождающих. Регламентация процедур управления требованиями должна обеспечить высокое качество работы с ними в проектах, связанных с разработкой, сопровождением, созданием АС, разработкой их организационно методического обеспечения, а также внедрения готовых систем за счет уменьшения типичных ошибок при работе с требованиями. Существенный момент предлагаемой методики -- использование международных и отечественных стандартов в области управления жизненным циклом (ЖЦ) АС, позволяющее практически без адаптации применять методики в рамках уже существующих, хорошо зарекомендовавших себя на практике процессах разработки. В качестве инструментального средства, поддерживающего моделирование требований на основе UML 2.0., авторами используется продукт Enterprise Architect компании Sparx System.

Подготовка к управлению требованиями

Под управлением требованиями обычно понимается систематический подход к выявлению, документированию, планированию реализации требований и отслеживанию их изменений [1-3, 4]. Методика призвана регламентировать следующие процедуры работы с требованиями: выявление, документирование, верификация и утверждение требований, планирование реализации и отслеживание изменений требований.

Методика предусматривает две стадии: подготовку управления требованиями и непосредственно управление ими. Процесс подготовки управления требованиями представлен на рис. 1, а его описание в таблице 1.

Таблица 1. Описание процесса подготовки управления требованиями

Рис. 1. Процесс подготовки управления требованиями

Определение этапов ЖЦ системы, на которых будет организована работа с требованиями, зависит от выбора его модели. Далее в качестве примера мы будем ориентироваться на определение согласно ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания.", в котором работа с требованиями в рамках процедур, регламентируемых методикой, осуществляется на следующих стадиях: формирование требований к АС, разработка концепции, техническое задание и сопровождение АС.

Подготовка шаблонов документов выполняется для каждого этапа ЖЦ. Состав документов, оформляемых для выделенных этапов ЖЦ системы, приведен в таблице 2. Часть документов, создаваемых и сопровождаемых при управлении требованиями, определена в соответствии с ГОСТ, а часть готовится по специальным шаблонам, которые разработаны непосредственно авторами методики и созданы на основе обобщения работ [1-3, 5]. В документах, формируемых с использованием подготовленных шаблонов, будут фиксироваться различные типы требований.

Далее выполняется кодирование типов требований в документах. Назначенные коды типов требований используются при определении их атрибутов  и при задании зависимостей между ними.

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

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

Итогом работ, выполненных на предыдущих стадиях процесса подготовки управления требованиями, является разработка плана.

Следующим шагом процесса является разработка основных процедур управления требованиями: процедура выявления требований, процедура верификации требований, процедура изменения требований. При этом учитывается информация, поступившая от заинтересованных лиц по данным процедурам, и требования ГОСТ 34.602-89, ГОСТ 19. 201 -78.

В заключении создается шаблон модели требований и его описание. В качестве опорных документов используются ГОСТ 34.602-89, ГОСТ 19. 201 -78.

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

Часто для серии типовых проектов могут применяться сходные процедуры, шаблоны, роли, однако игнорирование подготовительного этапа в "нетиповом" проекте может привести к использованию неадекватных процедур управления требованиями, что часто сказывается на качестве конечного продукта, либо порождает другие проблемы в проекте, например, отсутствие или неактуальность проектной документации. Рассмотрим пример. Для типовых проектов, ограниченных по срокам реализации (обычно до 6 мес.), наличие подробной документации не обязательно. В случае краткосрочного проекта, не относящегося к типовому (например, в виду его значимости и перспектив развития), недостаточная документированность изменений требований недопустима, что должно найти свое отражение в соответствующих процедурах процесса управления требованиями.

Если ориентироваться на ГОСТ 34.601-90, то мы предлагаем использовать методику управления требованиями на следующих этапах ЖЦ (таблица 2). В таблице также перечислены документы, рекомендуемые для фиксирования требований. Часть документов, создаваемых и сопровождаемых при управлении требованиями, определена в соответствии с ГОСТ, а часть готовится по специальным шаблонам, ориентированным на применение для широкого класса проектов.

Таблица 2. Стадии и этапы создания АС и оформляемые документы

 Процесс управления требованиями

На основании регламентных процедур реализуется процесс управления требованиями (рис. 2, таблица 3).

Таблица 3. Описание процесса управления требованиями

 Рис. 2. Процесс управления требованиями

Пример управления требованиями: выявление

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

Как видно из рис. 3а, автоматизируемыми процессами являются: зачисление; перевод; отчисление; проведение сессии; подготовка отчетов. Как видно из рис. 3б, шагами бизнес-процесса зачисления, подлежащими автоматизации являются: формирование списков групп; заполнение личной карточки студента; регистрация выдачи зачётной книжки в журнале.

На основе состава  и шагов бизнес-процесса, подлежащих автоматизации, строится матрица трассировки (табл. 3, 4)¸ которая позволяет проследить связи бизнес-процессов с реализующими их подсистемами и конкретных шагов бизнес-процессов с функциональными требованиями, а также контролировать полноту и целостность реализации: каждому автоматизируемому бизнес-процессу должна быть поставлена в соответствие подсистема (подсистемы), а подсистема должна реализовывать какой-либо процесс, соответственно.

Таблица 3. Зависимость подсистем от бизнес-процессов

Таблица 4. Зависимость функциональных  требований подсистемы "Зачисление студента"  от шагов бизнес-процесса "Зачисление студента"

На основе данных из таблиц 3, 4 создается модель подсистем и функциональных требований, как представлено на рис. 4а, б.

 Рис. 3. Пример управления требованиями: выявление  a) Состав бизнес-процессов; б) Описание бизнес-процесса "Зачисление студентов в университет"

Рис. 4. Пример управления требованиями: выявление а) Состав подсистем; б) Состав функциональных требований подсистемы "Зачисление студентов"

Заключение

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

Литература

1.      Microsoft Solutions Framework 3.0 http://www.microsoft.com/rus/msdn/msf/default.mspx

2.      Oracle Custom Development Method (CDM)

3.      Rational Unified Process Version 2003.06.00

4.      Карл Вигерс, Разработка требований к программному обеспечению. М.: "Русская Редакция", 2004.

5.      Липаев В.В., Документирование сложных программных средств. М.: Синтег, 2005.

Стандарты

1.      ГОСТ 19.102-77 Единая система программной документации. Стадии разработки

2.      ГОСТ 19.201-78* Единая система программной документации. Техническое задание. Требования к содержанию и оформлению

3.      ГОСТ 2.503-90 ЕСКД. Правила внесения изменений

4.      ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания

5.      ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы

6.      ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств

7.      РД 50-34.698-90 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов