Распределение ответственности

Аналитик

Аналитик является ключевой ролью в составе рабочей группы.

Аналитик имеет право согласовывать требования перед их утверждением Руководством компании.

Для каждого проекта разработки программного обеспечения в рабочей группе выделяется специалист – Аналитик, который ведет управление требованиями. Управление требованиями выполняется Аналитиком на протяжении всего жизненного цикла проекта.

В обязанности Аналитика входит:

1. Разработка требований и/или координация работ по разработке требований.

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

3. Анализ требований, координация по процедурам проверки требований, сбор и учет замечаний к требованиям, идентификация и оценка рисков.

4. Согласование требований в компании, в рабочей группе проекта и у Заказчика.

5. Выпуск версий документов, содержащих требования, отчетов об анализе требований, предложений по управлению рисками, связанными с требованиями.

6. Обеспечение информированности членов рабочей группы о текущем статусе требований.

7. Организация сдачи разработанного продукта Заказчику.

8. Контроль над изменениями требований.

9. Контроль над соответствием разрабатываемых материалов проекта утвержденным требованиям.

Менеджер проекта

Менеджер проекта является ключевой ролью в составе рабочей группы.

Менеджер проекта имеет право согласовывать требования перед их утверждением Руководством.

Менеджер проекта имеет следующие обязанности в процессе управления требований:

1. Планирование ресурсов и контроль выполнения задач, связанных с управлением требованиями в проекте.

2. Проверка корректности требований.

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

4. Разработка плана компенсации рисков, связанных с требованиями к ПО.

5. Разработка и корректировка плана разработки ПО на основе утвержденных требований к ПО.

6. Контроль выполнения задач, утвержденных в плане проекта, в контексте удовлетворяемых требований к ПО.

7. Организация принятия решений по проблемам и рискам, связанным с управлением требованиями.

8. Вынос на уровень руководства проблем и рисков, связанных с требованиями, которые не могут быть разрешены внутри проекта.

Тестировщик

Тестировщик является ключевой ролью в составе рабочей группы.

Тестировщик имеет право согласовывать требования перед их утверждением Руководством компании.

Тестировщик проекта имеет следующие обязанности в процессе управления требованиями:

1. Проверка требований в отношении их тестируемости. Внесение предложений по изменению требований с целью обеспечения их тестируемости.

2. Подготовка и корректировка плана тестирования, включая программу-методику испытаний, на основе актуальной версии требований.

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

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

Проектировщик

Проектировщик является ключевой ролью в составе рабочей группы.

Проектировщик имеет право согласования требований.

Проектировщик проекта имеет следующие обязанности в процессе управления требованиями:

1. Проверка требований в отношении их реализуемости. Внесение предложений по изменению требований с целью обеспечения их реализуемости.

2. Оценка технических рисков, связанных с реализацией требований.

3. Разработка и корректировка технического проекта на основе актуальной версии требований.

Разработчик

Разработчик является ключевой ролью в составе рабочей группы.

Разработчик имеет право согласования требований.

Разработчик проекта имеет следующие обязанности в процессе управления требованиями:

1. Проверка требований в отношении трудоемкости их удовлетворения.

2. Внесение предложений по изменению требований с целью повышения эффективности работ по реализации требований.

3. Проверка соответствия между ТЗ и Техническим проектом, между ТЗ и Планом тестирования.

4. Оценка технических рисков, связанных с реализацией требований.

5. Кодирование и отладка в соответствии с Техническим проектом, с учетом Плана тестирования в контексте удовлетворяемых требований.

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

Требования к ПО должны быть документированы. Действующая версия требований должна быть оформлена и утверждена в соответствии с порядком утверждения официальных документов в организации Заказчика. Электронная копия действующей копии требований должна быть опубликована для информации членов рабочей группы и руководства компании.

Оформление требований для российских заказчиков выполняется в соответствии со стандартом ГОСТ 34.602, для иностранного заказчика - в соответствии со стандартом IEEEStd 830, если иное не оговорено в контракте.

Обеспечение ресурсами

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

Для небольших проектов роль Аналитика может быть совмещена с ролями Менеджера проекта, Проектировщика, Разработчика.

В плане проекта предусматривается затраты достаточные для выполнения работ по управлению требованиями.

Для проектов разработки программного обеспечения используется средство разработки требований RationalRequisitePro. Конфигурационный контроль требований осуществляется с помощью общего для всего проекта средства конфигурационного управления. Выбор средств поддержки процессов управления требований выполняется на этапе инициации проекта.

Обучение

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

· Процедуры и методики управления требованиями.

· Стандарты управления требованиями.

· Использование средства RationalRequisitePro в управлении требованиями.

Назначение специалистов на роль Аналитика осуществляется из числа специалистов, владеющих тематикой в требуемой предметной области проекта.

8.4 Действия по управлению требованиями

 

8.4.1 Анализ требований

Перед началом работ по проекту по разработке программного обеспечения требования проходят следующие проверки:

1. Менеджер проекта анализирует требования в отношении их корректности, соответствия контракту и другим исходным документам.

2. Аналитик анализирует требования в отношении их качества.

3. Проектировщик анализирует требования с точки зрения их технической реализуемости.

4. Тестировщик анализирует требования с точки зрения их тестируемости.

5. Разработчик анализирует требования с точки зрения трудоемкости их выполнения.

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

8.4.2 Разработка материалов проекта на основе требований

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

1. Менеджер проекта разрабатывает план проекта. Источниками для составления плана являются утвержденные требования, оценки трудоемкости, данные и рекомендации ГТР по выбору модели жизненного цикла, метрикам производительности, рискам.

2. Проектировщик разрабатывает Технический проект. Источникам для разработки Технического проекта являются утвержденные требования и данные ГТР по апробированным проектным решениям в указанном домене требований.

3. Тестировщик разрабатывает план тестирования, включая программу и методику испытаний, разрабатываемого программного продукта. Источником для разработки плана тестирования является утвержденное ТЗ и данные контракта по организации приемки.

4. Разработчик осуществляет кодирование и отладку программного обеспечения. Источником для работы являются утвержденное ТЗ, Технический проект, план тестирования.

8.4.3 Контроль изменений требований

При внесении изменений или конкретизации требований Аналитик проводит первичную оценку влияния изменений на проект и готовит предложения о целесообразности внесения изменений. В процессе работы он ведет согласование с Заказчиком и в рабочей группе проекта и координирует всю работу по подготовке решения об изменении.

Аналитик готовит или проверяет запрос об изменениях, в котором описываются причины изменений, приводится оценка влияния изменений на проект и проводится переоценка рисков.

Запрос на изменение проходит проверку у руководителя проекта, проектировщика, тестировщика и разработчика. Решение об изменении утверждается в порядке, предусмотренном для основного документа.

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

После утверждения изменений требований проводится каскадное приведение в соответствие всех зависящих материалов проекта:

1. Руководителем проекта выполняются необходимые изменения в плане проекта и плане рисков.

2. Проектировщик модифицирует Технический проект.

3. Тестировщик вносит изменения в План тестирования.

4. Разработчиком выполняются необходимые правки в разработанных модулях программного обеспечения.

Новые версии документов помещаются под конфигурационный контроль с описанием произведенных изменений.

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

 

Измерения

Численные измерения, используются в процессе управления требованиями для оценок состояния требований и контроля выполнения работ, связанных с управлением требованиями и их реализацией. Работа по выбору метрик и измерениям координирует ГТР. На основе статистической обработки накапливаемой в процессе выполнения проектов информации ГТР обеспечивает новые проекты все более точными рекомендациями по планированию, оптимизации рисков, выбору технологий.

Использование измерений и выбор метрик в проекте осуществляет Аналитик. Рекомендуются измерения требований по важности, статусу, степени выполнения, трудоемкости.

Показатель важности

Для требований вводится и отслеживается показатель важности требований, шкала показателя важности вводится при разработке требований Аналитиком и поддерживается на протяжении всего проекта. Минимально рекомендуемая шкала важности включает следующие значения: «обязательное», «рекомендованное», «опциональное».

Стабильность

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

 

8.5.3 Статус требований

Статус требования указывает текущее состояние требования. Информация о статусе требований важна для членов рабочей группы для эффективной организации работ. Рекомендованные значения статуса требования («получен запрос на изменение», «утверждено», «встроено в проект»).

 

8.5.4 Степень выполнения требований

Степень выполнения требований указывает этап, на котором находятся работы по реализации требований, например: «проектирование», «кодирование», «отладка», «тестирование», - или процент выполненных работ по реализации требований.

Трудоемкость

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

Верификация

Верификация процессов управления требованиями выполняется на нескольких уровнях для обеспечения гарантии исполнения всех необходимых действий по управлению требованиями.