Текст книги "Инновации от идеи до рынка"

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

3.7 Управление техническими данными и оценками

К данным проекта относят записанную информацию независимо от формы или метода записи. Этот термин включает технические данные, документацию по программному обеспечению, финансовую, управленческую, и любую другую информацию, требуемую контрактом. В том числе:

• Исследования, анализы, экспериментальные данные, подготовленные для контракта, где исследование, анализ, тест или аналогичная работа были указаны в качестве предметов исполнения.

• Модели разных уровней, сборки, цифровые двойники, используемые при разработке и эксплуатации системы.

• Данные о форме, посадках и функциях элементов продукта.

• Сведения, необходимые для установки, эксплуатации, технического обслуживания или обучения.

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

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

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

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

1. Физическое, математическое или иное логическое представление системы, сущности, явления или процесса.

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

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

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

Примеры включают: модель жизненного цикла, динамическое моделирование (во времени), модели на основе языка SysML, модель разработки, модель системы, цифровой двойник продукта, графические, математические, физические модели, модели операционного анализа, логические, функциональные, архитектурные модели, метамодели, модели затрат, процессов, проектов, модели данных, структурные, аналитические, бизнес-модели, вероятностные, параметрические, информационные модели. Каждый из этих типов моделей представлен данными и информацией, которые должны быть включены в интегрированные общие наборы данных проекта. Подробности изложены в главе 6 и книге [6].

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

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

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

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

Основными атрибутами данных являются:

• Тип данных, для классификации хранения.

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

• Источники данных (где данные генерируются), в том числе из Интернета, созданные машиной, человеком, и т. д. В части временной шкалы выделяют данные, полученные на основе заданных интервалов времени, непрерывной подачи в режиме реального времени (например, навигационная или метеорологическая информация), и по запросу.

• Потребители данных, включая список рассылки обрабатываемых данных (предприятия, пользователи, ключевые исполнители и роли), а также хранилища данных и программные приложения. К хранилищам относят корпоративные хранилища, операционные и транзакционные базы данных.

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

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

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

a) определить ресурсы и навыки персонала, необходимые для управления данными и информацией;

b) определить права, обязанности и обязательства сторон по генерации, управлению и доступу к информации;

c) определить инструменты и процессы управления данными и информацией, а также методологии, стандарты и процедуры, в соответствии с которыми будут создаваться, управляться и храниться данные и информация в проекте;

d) установить задачи, объем проектных данных и информации, которые необходимо поддерживать;

e) определить основную схему для интегрированных баз данных, которые будут использоваться для хранения данных во всех процессах жизненного цикла. Схема включает форматы и носители для сбора, хранения, передачи и поиска данных и информации;

f) создать и поддерживать словарь системных данных;

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

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

Некоторые распространенные причины, по которым организации не стремятся развивать возможности формирования исчерпывающего пакета информации и данных о проекте, включают:

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

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

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

• Нехватка средств на модернизацию ИТ-инфраструктуры, чтобы учесть дополнительный объем данных и требования к производительности новых инструментов.

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

Исходя из вышеизложенного, руководитель программ ОКР может убедить руководство в том, что необходим новый уровень возможностей по обработке и использованию технических данных, представив в качестве аргумента план возврата инвестиций. Например, в компании General Electric много лет собирали данные испытаний всего парка летающих авиадвигателей (несколько тысяч единиц) в старых Excel-форматах, опасаясь модернизировать процедуру из-за возможной потери части данных. Российский инженер из совместного инженерного центра, случайно узнавший о проблеме, предложил и реализовал за два месяца автоматическую программу конвертации всех записей в современную базу данных с расширенными возможностями последующей обработки.

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

1. Назначение и инструкции по требуемым данным и информации проекта.

2. Пакеты технических данных (ПТД).

3. Модели, цифровые двойники и связанные данные.

4. Матрицу соответствия требований.

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

6. Деревья спецификаций, цифровых моделей и чертежей.

7. Инженерные модели, чертежи, сборки и электронный макет системы.

8. Запросы на изменение.

9. Формат обмена требованиями с подрядчиками.

10. Каталог и индексы основных записей хранилища данных.

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

Пакет технических данных (ПТД) включает техническое описание предмета, подходящего для использования в качестве основы для инженерной разработки, конкурентного приобретения, производства, установки, модификации, эксплуатации, технического обслуживания и логистической поддержки создаваемых продуктов или систем ОКР. Данные ПТД передаются в цифровую среду организации (электронный архив) и служат основой для исходного состояния продукта, как он поддерживается в эксплуатации. Этот набор может опираться на стандарт ISO 16792:2021 «Техническая документация на продукцию. Способы применения цифровых данных определения продукции» (или близкие к нему стандарты ASME Y14.41—2019, MIL-STD-31000), чтобы обеспечить поэтапные требования к поставляемым продуктам и связанными процессами управления данными ПТД. Различают типы наборов данных:

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

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

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

ПТД может содержать пункты из следующего перечня (MIL-STD-31000B). Это концептуальные чертежи и модели, чертежи и модели разработки, данные технического проектирования продукта, включая следующие позиции:

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

2. Параметры производительности продукта.

3. Данные о размерах и допусках.

4. Критические производственные процессы и последовательность сборки.

5. Допустимые входные и выходные характеристики.

6. Диаграммы потоков интерфейсов и данных (где приложимо).

7. Механические и электрические соединения.

8. Физические характеристики, включая форму, отделку и защитные покрытия.

9. Детали идентификации, состояния материала, виды обработки и покрытия.

10. Файлы исходных данных цифровых двойников в формате применяемого ПО.

11. Критерии верификации, испытаний и оценки.

12. Требования к калибровке оборудования.

13. Требования к обеспечению качества.

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

15. Данные по обоснованию выбора поставщика, если это требуется по контракту или заказу на поставку.

16. Требования к ПО для устройств или сборок, включая описание входных носителей и процедуры верификации правильности установки ПО.

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

Процесс технических оценок включает периодическое предоставление оценки технического и программного статуса программы или проекта в отношении основных вех жизненного цикла. Измерения в основном оцениваются в ходе технических обзоров программ и проектов (см. главу 2.7). Структура контрольных рубежей (КР) жизненного цикла предусматривает оценку прогресса и результатов действий на предыдущей стадии программы. Этот набор данных (критериев успеха) определяется заранее, в рамках плана проекта, для каждого КР индивидуально.

Цели проведения обзоров на КР:

• Фиксируют поставки и результаты завершенного этапа (вовлечены эксперты по компетенциям).

• Контролируется непропорциональное увеличение затрат на устранение ошибок при продвижении проекта «вниз по течению».

• Есть возможность корректировки планов, задержек на старте этапа, между фазами.

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

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

1) анализа реализации критических технических параметров системы в сочетании с оценкой прогресса в достижении системных требований и выявлением критических эксплуатационных проблем;

2) оценки выполнения пороговых значений параметров, как указано в требованиях;

3) описания функциональных возможностей системы и предоставления информации о производительности, стоимости, и графике работы;

4) документирования прогресса планируемого роста надежности, и достижения заданных показателей надежности и ремонтопригодности;

5) оценки безопасности системы;

6) официального документирования обоснований достижения договорных технических характеристик, усовершенствований и системных корректирующих действий.

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

Мерами эффективности (МЭ) называют качественные показатели того, насколько успешно достигнуты цели эксплуатации системы. МЭ являются независимыми от реализации, они оценивают «насколько хорошо», а не «как». Например, оценка текущего состояния программы, информирование о текущей готовности к переходу на следующий этап ЖЦ.

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

Можно выделить набор ключевых категорий ТПЭ, которые должны находиться в зоне внимания менеджера:

1. Характеристика производительности системы.

2. Управление производством.

3. Качество изготовления.

4. Управление графиком программы.

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

6. Управление требованиями.

7. Управление рисками.

8. Управление испытаниями.

9. Надежность, доступность и ремонтопригодность системы, и др.

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

При количественных оценках технических характеристик продукта программы следует выбрать небольшой набор сжатых критериев, которые точно отражают ключевые параметры или факторы риска, которые легко поддаются измерению, и на них может влиять изменение проектных решений. Метрики должны оценивать адекватность используемых ресурсов и инструментов (например, моделей, виртуальных ЦД), для поддержки своевременного исполнения графика работ. Стоимость процесса зависит от количества оцениваемых параметров.

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

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

С вопросами изучения результатов обзоров проекта и документированных уроков программ (часть процедуры закрытия программы) тесно соприкасается один из процессов жизненного цикла, система управления знаниями (СУЗ). Это комплекс организационно-технических мероприятий, охватывающих:

• поиск и извлечение знаний из отчетов по программам и ведущих носителей знаний;

• структурирование и систематизацию знаний для обеспечения их удобного хранения и поиска;

• анализ знаний (выявление зависимостей и аналогий), формирование компетенций (know-how) компании;

• обновление (актуализацию) и распространение знаний в компании в заданном порядке;

• генерацию новых знаний.

Каждый завершенный проект представляет возможность собрать и записать информацию о проекте и поделиться ею с заинтересованными сторонами. «Извлеченные уроки» включают обзор лучших практик, идей проекта и информации о клиентах, позволяют сохранить и использовать в новых проектах записи информации, собранной в ходе завершенного проекта.

3.8 Управление техническими рисками проекта

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

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

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

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

Риск характеризуют тремя основными компонентами:

1) воздействие или сценарий, приводящий к ухудшению эффективности в отношении одного или нескольких показателей проекта;

2) вероятность каждого из сценариев;

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

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

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

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

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

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

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

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

• Риск графика, который связан с невозможностью уложиться в сроки из-за задержек по ряду возможных причин (например, части, не доставленные поставщиками вовремя, поздние изменения, внесенные в конструкцию из-за сбоев, обнаруженных при испытании).

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

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

1. Угроза, или оценка чувствительности программы к неопределенности в описании угрозы, ее степень, изменения дизайна системы при изменении параметров угрозы.

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

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

4. Тестирование и оценка, где прослеживают адекватность и возможности программы.

5. Вопросы взаимодействия с поставщиками по срокам, качеству и др.

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

a) обзора процесса проектирования продукта;

b) анализа и ревизии производственных стандартов;

c) оценки методов контроля качества;

d) оценки процесса управления производством;

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

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

A. Выяснить причины, влияющие на людей.

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

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

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

1. Идентификация рисков для выявления негативного влияния на стоимость и график.

2. Анализ риска по причинам и эффектам отказов.

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

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

6. Отслеживание рисков: мониторинг показателей риска и действий, предпринимаемых против рисков.

7. Контроль рисков: выполнение запланированных корректирующих действий в соответствующих рабочих планах.

8. Информирование о рисках внутри и снаружи проекта по текущим и возникающим рискам.

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

Процесс оценки рисков и выявления проблем может включать:

• Ожидаемые природные трагедии (затопление, циклоны, бури, землетрясения, пожары, извержение вулкана, и т.д.).

• Технические угрозы (выбор неудачной технологии, разрыв интернет-соединения, отключение электричества, сбой ПО, и т.д.).

• Химические угрозы (попадание асбеста в атмосферу, смог от промышленных выбросов, и т.д.).

• Сбои в цепочке поставок.

• Биологические угрозы (эпидемические заболевания, массовые отравления, болезни пищевого происхождения, и т.д.).

• Несчастные случаи на производстве (травмы из-за скольжения на полу, падение предметов, транспортные аварии, поломки оборудования, и т.д.).

• Преднамеренные действия (забастовки рабочих, поджоги, акты терроризма, и т.д.).

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

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

На рис.6 представлена типовая диаграмма рисков для контроля.

Рис.6 Диаграмма рисков проекта.

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