Контроль со стороны руководства — КиберПедия 

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

Поперечные профили набережных и береговой полосы: На городских территориях берегоукрепление проектируют с учетом технических и экономических требований, но особое значение придают эстетическим...

Контроль со стороны руководства

2017-11-22 266
Контроль со стороны руководства 0.00 из 5.00 0 оценок
Заказать работу

Руководство на периодической основе – один раз в месяц, проводит проверку выполнения процедур и правил выполнения управления требованиями. Проверке подлежит:

1. Наличие актуальной версии утвержденного ТЗ в проектах.

2. Наличие отчетов по анализу ТЗ.

3. Наличие решений по проблемам внутри проекта и сформированного плана управления рисками.

4. Своевременность выноса на уровень руководства проблем и рисков, которые не могут быть решены внутри проекта.

5. Отчеты ГОК по проверке процессов управления требований в проектах.

Контроль со стороны руководителя проекта

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

Проверке подлежат:

1. Корректность требований.

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

3. Состав и статус решаемых с заказчиком вопросов по управлению требованиями

4. Контроль завершенности встраивания измененных требований в проект.

5. Доступность материалов по управлению требованиями для членов рабочей группы

6. Выполнение решений принятых по рискам и проблемам.

Контроль со стороны ГОК

Группа обеспечения качества выполняет следующие проверки:

1. Контроль качества требований в соответствии с показателями качества.

2. Контроль соответствия Технического Задания - контракту и другим исходным материалам проекта.

3. Контроль соответствия Технического Задания – плану проекта.

4. Контроль обоснованности плана рисков.

5. Контроль соответствия Технического Задания – Техническому проекту.

6. Контроль соответствия Технического задания – Плану тестирования.

7. Контроль выполнения процедур по управлению требованиями.

 

8.7 Стандарт оформления требований

8.7.1 Шаблон для разработки требований

Для разработки требований для российского заказчика рекомендуется использовать шаблон, разработанный в ГОК на основе стандарта ГОСТ 34.602.

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

8.7.2 Правила оформления требований

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

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

1. Формулировка каждого требования должна быть четкой и по возможности состоять из одного предложения (как формула изобретения).

2. Формулировка требований должна быть по возможности самодостаточной, то есть смысл сформулированного требования должен быть в основном понятен без контекста.

3. Стиль записи сформулированного требования должен отличаться от стиля поясняющего текста. Рекомендуется выделять формулировку требования в тексте подчеркиванием.

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

 

8.7.3 Структурирование требований

В отдельные главы должны быть выделены технические и нетехнические требования.

Технические требования должны быть разделены внутри разделов на функциональные и нефункциональные требования.

Разделы могут быть структурированы в зависимости от особенностей проекта по режимам функционирования, классам/объектам, группам пользователей, опциям, функциональной иерархии, управляющим воздействиям и пр. Различные подходы могут быть использованы на различных уровнях структуры документа. Выбор различных способов структурирования требований целесообразно выполнять на основе стандарта IEEEStd 830. Обязательным является описание во введении способа структуризации документа.

8.8 Показатели качества требований

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

Корректность

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

Однозначность

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

Полнота

Совокупность требований является полной, если она включает:

· Все существенные требования, относящиеся к функциональности, производительности, ограничениям, атрибутам, внешним интерфейсам и пр.

· Определение всех реакций системы на все реализуемые классы входных данных во всех реализуемых ситуациях (включая ошибочные входные данные).

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

Совместимость

Требования являются совместимыми, если отсутствуют противоречия между любыми двумя подмножествами требований.

Возможные примеры несовместимостей:

· Различные требования описывают противоречивые характеристики одного объекта

· Различные требования описывают противоречивые действия одного и того же объекта

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


Поделиться с друзьями:

Своеобразие русской архитектуры: Основной материал – дерево – быстрота постройки, но недолговечность и необходимость деления...

История развития хранилищ для нефти: Первые склады нефти появились в XVII веке. Они представляли собой землянные ямы-амбара глубиной 4…5 м...

Индивидуальные очистные сооружения: К классу индивидуальных очистных сооружений относят сооружения, пропускная способность которых...

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



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.01 с.