(495) 925-0049, ITShop интернет-магазин 229-0436, Учебный Центр 925-0049
  Главная страница Карта сайта Контакты
Поиск
Вход
Регистрация
Рассылки сайта
 
 
 
 
 

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

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

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

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

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

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

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

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

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

Входная/Выходная информация

Шаг процесса

Участник

Бизнес
правила

01

Информация от заинтересованных лиц (заказчики, менеджер проекта)/

Этапы жизненного цикла системы

Определение этапов ЖЦ системы, на котором будет организована работа с требованиями

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

ГОСТ 34.601-90,

ГОСТ 19.102-77,

ГОСТ Р ИСО/МЭК 12207-99,

RUP [3]

02

Этапы ЖЦ/Шаблоны документов

Подготовка шаблонов документов для каждого этапа

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

ГОСТ 34.602-89,

ГОСТ 19.201-78,

РД 50-34.698-90,

RUP [3]

03

Шаблоны документов/Коды типов требований

Кодирование типов требований в документах

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

ГОСТ 34.602-89,

ГОСТ 19.201-78,

РД 50-34.698-90,

RUP [3]

04

Коды типов требований/Атрибуты типов требований

Определение атрибутов типов требований

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

Типовые атрибуты согласно RUP [3]

05

Коды типов требований/Зависимости между типами требований

Задание зависимостей между типами требований

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

Выполняется для каждого конкретного проекта. Шаг процесса может быть пропущен

06

Зависимости между типами требований, типы требований с атрибутами, шаблоны документов/ План управления требованиями

Разработка плана управления требованиями

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

ГОСТ 34.601-90,

ГОСТ 19.102-77,

ГОСТ 2.503-90,

RUP [3]

07

Информация от заинтересованных лиц по процедурам работы с требованиями/ Процедура выявления требований, анализа, верификации и утверждения

Разработка процедур выявления, верификации, утверждения, изменения требований

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

ГОСТ 34.602-89,

ГОСТ 19.201-78,

РД 50-34.698-90,

ГОСТ 2.503-90,

RUP [3]

08

ГОСТ 34.602-89, ГОСТ 19. 201 -78/Шаблон модели и его описание

Создание шаблона модели требований и его описание

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

ГОСТ 34.602-89,

ГОСТ 19. 201-78

Рис. 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. Стадии и этапы создания АС и оформляемые документы

№ стадии создания АС

Стадии создания АС

Этапы создания АС

Документы

01

Формирование требований к АС

1.1. Обследование объекта и обоснование необходимости создания АС.

1.2. Формирование требований пользователя к АС.

Интервью заказчиков и пользователей о проблемах

02

Разработка
концепции

2.1. Изучение объекта.

2.2. Проведение необходимых научно-исследовательских работ. 2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя.

2.4. Оформление отчёта о выполненной работе.

Концепция

03

Техническое
задание

3.1. Разработка и утверждение технического задания на создание АС.

ТЗ по ГОСТ 34.602 -89;

Описание автоматизируемых функций РД 50-34.698-90 п. 2.5;

Словарь терминов;

Модель требований;

Описание модели требований

08

Сопровождение АС

8.1. Выполнение работ в соответствии с гарантийными обязательствами.

8.2. Послегарантийное обслуживание

Интервью заказчиков и пользователей о проблемах;

ТЗ по ГОСТ 34.602 -89;

Запрос на изменение требований;

Описание автоматизируемых функций РД 50-34.698-90 п. 2.5;

Словарь терминов

Модель требований

Описание модели требований

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

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

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

Входная/Выходная информация

Шаг процесса

Участник

Бизнес
правила

01

Методы выявления требований, результаты обследования объекта автоматизации, план управления требованиями/Список выявленных требований

Выявление требований и их структурирование

Системный аналитик

Процедуры выявления требований

02

Список выявленных требований/Модель требований и ее описание

Моделирование требований

Системный аналитик

Шаблон модели требований и его описание

03

Список выявленных требований/Документы с требованиями

Документирование требований

Системный аналитик,
Специалист по требованиям

Шаблоны документов

04

Документы с требованиями, модель требований и ее описание/Документы и модели с требованиями верифицированные и утвержденные

Верификация и утверждение требований

Эксперт предметной области,

Рецензент

Процедура верификации и утверждения требований

05

Документы и модели с требованиями верифицированные и утвержденные /Базовая версия требований

Определение базовой версии требований

Архитектор

Процедура верификации и утверждения требований (раздел, посвященный определению базовой версии требований)

06

Базовая версия требований/ Измененные требования

Изменение требований

Все заинтересованные лица

Процедура управления изменениями

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

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

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

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

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

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

Бизнес-процесс

Подсистема

1

Зачисление студента

Зачисление студента

2

Перевод студента

Перевод студента

3

Отчисление студента

Отчисление студента

4

Подготовка отчётов

Подготовка отчётов

5

Проведение сессии

Проведение сессии

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

Шаг бизнес-процесса

Функциональное требование

1

Формирование списков групп

Формирование списков групп

2

Заполнение личной карточки студента

Ведение личных карточек студентов

3

Регистрация выдачи зачётной книжки

Ведение журнала регистрации выдачи зачетных книжек

На основе данных из таблиц 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 Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов

Ссылки по теме


 Распечатать »
 Правила публикации »
  Написать редактору 
 Рекомендовать » Дата публикации: 04.02.2008 
 

Магазин программного обеспечения   WWW.ITSHOP.RU
Rational ClearCase Multisite Floating User License
IBM Rational Functional Tester Floating User License
IBM RATIONAL Rose Enterprise Floating User License + Sw Subscription & Support 12 Months
IBM RATIONAL Clearcase Floating User License + Sw Subscription & Support 12 Months
IBM RATIONAL Quality Manager Quality Professional Authorized User Single Install License + Sw Subscription & Support 12 Months
 
Другие предложения...
 
Курсы обучения   WWW.ITSHOP.RU
 
Другие предложения...
 
Магазин сертификационных экзаменов   WWW.ITSHOP.RU
 
Другие предложения...
 
3D Принтеры | 3D Печать   WWW.ITSHOP.RU
 
Другие предложения...
 
Новости по теме
 
Рассылки Subscribe.ru
Информационные технологии: CASE, RAD, ERP, OLAP
Новости ITShop.ru - ПО, книги, документация, курсы обучения
CASE-технологии
Мир OLAP и Business Intelligence: новости, статьи, обзоры
Мастерская программиста
Adobe Photoshop: алхимия дизайна
ЕRP-Форум. Творческие дискуссии о системах автоматизации
 
Статьи по теме
 
Новинки каталога Download
 
Исходники
 
Документация
 
 



    
rambler's top100 Rambler's Top100