ГОСТ Р МЭК 62960—2022
4.3 Анализ состояния
Целью анализа состояния является представление руководителям организации, а иногда и заказ
чику, информации о том, как продвигается проект, и в некоторых случаях обоснования для продолжения
проекта с переходом на следующий этап плана проекта. В некоторых случаях анализ состояния про
водят на ключевых этапах проекта, его называют «анализом ключевых этапов». В некоторых случаях
анализ на ключевом этапе также включают в решение о продолжении проекта, такой анализ иногда
называют «вентильным анализом». В некоторых случаях оплата этапа зависит от результата анализа
состояния.
Анализ состояния надежности начинается с этапа, на котором собирают и структурируют инфор
мацию и свидетельства надежности. Структурированную информацию затем представляют руковод
ству для анализа и принятия решений.
В команду по анализу состояния должны входить специалисты, обладающие полномочиями по
выделению ресурсов на выполнение проекта и устранение возникающих трудностей. Участниками тех
нической части анализа состояния, как правило, являются председатель, секретарь, руководители про
екта и руководители различных групп проекта. Как только достигнут консенсус относительно состояния
технических проблем, анализ состояния может перейти к этапу управления, в котором обычно участву
ют руководитель программы, руководство и, возможно, заказчик. Следует позаботиться о том, чтобы
серьезные проблемы, отмеченные руководителями групп при анализе проекта, не были представлены
в качестве задач для следующего этапа проекта без сообщения об их возможном воздействии, если они
останутся нерешенными.
4.4 Обзор методов анализа надежности
4.4.1 Анализ
Анализ надежности может быть выполнен самостоятельно или как часть другого анализа. В лю
бом случае анализ надежности должен включать следующие этапы:
- определение заинтересованных сторон;
- определение требований;
- сбор информации о фактических показателях;
- оценку различий между установленными требованиями и фактическими показателями;
- идентификацию рисков и проблемных областей;
- разработку рекомендуемых действий.
При введении изменений, их результативность должна быть проверена, и должно быть сделано
обоснование необходимости каких-либо дополнительных действий.
4.4.2 Определение заинтересованных сторон
Лицам или организациям, разрабатывающим и эксплуатирующим системы, важно хорошо пони
мать, кто является их заинтересованными сторонами, поскольку их работа направлена на удовлетво
рение потребностей этих заинтересованных сторон. Поэтому необходимо идентифицировать заинте
ресованные стороны и установить способы обмена информацией с ними. Для некоторых систем можно
легко идентифицировать заинтересованные стороны, и они не изменяются в течение жизненного цикла
системы. Для других систем с самого начала может быть трудно идентифицировать заинтересован
ные стороны и полностью определить их потребности. Например, заинтересованные стороны могут
измениться, когда система вступает в стадию использования или когда разработанный объект продан
другому лицу или организации. Они также могут измениться, когда система вступает в стадию вывода
из эксплуатации.
При определении соответствующих заинтересованных сторон следует учитывать следующее:
a) к заинтересованным сторонам относятся те, на кого может повлиять система или отказ систе
мы, например, в результате неправомерного раскрытия информации или неисправности, вызванного
ошибкой человека или неправильным использованием;
b
) некоторые требования заинтересованных сторон, которые, например, могут привести к отка
зам и задержке поставки, могут быть известны в процессе разработки и должны быть определены и
рассмотрены при выполнении анализа;
c) как только соответствующие заинтересованные стороны определены, из этого перечня должны
быть выделены ключевые заинтересованные стороны. При определении ключевых заинтересованных
сторон следует применять подход, основанный на оценке рисков. Критерии для идентификации клю-
6