При необходимости вы можете перейти на сайт нашего партнера в любом из представленных регионов:
?
по сайту по документам

Все работы по промышленной безопасности, по линии Ростехнадзора в Калуге и Калужской области

Приказ Росстандарта от 06.08.2020 №472-ст

«ГОСТ Р 27.016-2020 (МЭК 62853:2018). Национальный стандарт Российской Федерации. Надежность в технике. Надежность открытых систем»

Первое официальное опубликование: М.: Стандартинформ, 2020
Действует с 01.07.2021
Скачать файл:
Скачать документ PDF (2.44МБ)
Запросить документ MS Word
Войдите для запроса:


Дата изменения: 12.02.2022

страниц: 77; таблиц: 3; иллюстраций или формул: 20; абзацев: 1319; строк: 2983; слов: 24990; символов: 175433; терминов: 37;


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

В настоящем стандарте детализированы требования ГОСТ Р МЭК 60300-1 по отношению к открытым системам. В настоящем стандарте определены виды анализа процесса на основании требований [1], где идентифицирован набор процессов жизненного цикла системы.

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

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

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

Разделы сайта, связанные с этим документом:


Связи отсутствуют



    Отсутствуют статьи или новости, содержащие этот документ

Ваш комментарий


Упоминания в вопросах и комментариях в других разделах сайта


Нет комментариев, вопросов или ответов с этим документом




  • Термины

  • Аккомодация изменений - change accommodation
    Набор действий, которые модифицируют и адаптируют систему в соответствии с изменениями ее целей, задач, окружающей среды или фактической работы, которые требуют в отношении системы установления нового перечня заинтересованных сторон
    см. страницу термина
  • Анализ причин отказа
    это действия по определению причин отключения электроснабжения (см. [22]). Некоторые типичные причины описаны выше. Предотвращение отказа включает, например, переход от линий электропередач на опорах к кабелям, профилактическому обслуживанию трансформаторных станций. Предотвращению отказа также помогает создание карт соединений кабелей для учета при земляных работах и запрет на постановку судов на якорь около подводных кабелей
    см. страницу термина
  • Анализ процесса - process view
    Набор процессов, действий и задач, который обеспечивает ориентацию на конкретную озабоченность заинтересованных сторон в отношении системы таким способом, что охватывает весь жизненный цикл системы или его части
    см. страницу термина
  • Гарантийный случай, случай гарантии - assurance case
    Создаваемый обоснованный проверяемый артефакт, подтверждающий, что удовлетворяется претензия верхнего уровня (или совокупность претензий), включая поддерживающие претензию систематическую аргументацию и ее явные предположения
    см. страницу термина
  • Заинтересованная сторона - stakeholder
    Лицо или организация, которые могут воздействовать на осуществление деятельности или принятие решения, быть подверженными их воздействию или воспринимать себя в качестве последних
    см. страницу термина
  • Ключевые решения
    К ... относят решения, принимаемые на стадиях жизненного цикла системы, а также решения, оказывающие большое влияние на дальнейшее развитие жизненного цикла системы.
    см. страницу термина
  • Коды
    модули программного обеспечения, которое необходимо для поддержки постоянных напряжения и частоты в сети, контроля нагрузок и реакции на отказы, а также программного обеспечения для эксплуатации "системы защиты" потребителей, дистрибьюторов, поставщиков и контроля необычных действий в сети (чрезмерные вариации потребления, необычные платежи, необычный поток данных и возможные вредоносные программы)
    см. страницу термина
  • Консенсус - consensus
    Общее согласие, характеризующееся отсутствием серьезных возражений по существенным вопросам у большинства заинтересованных сторон и достигаемое в результате процедуры, направленной на учет мнений всех сторон и сближение несовпадающих точек зрения
    см. страницу термина
  • Мониторинг - monitoring
    Определение состояния системы, процесса или деятельности
    см. страницу термина
  • Надежность открытых систем - open system dependability
    Способность системы адаптироваться к изменениям в целях, задачах, среде, фактическом функционировании и непрерывно обеспечивать ответственность за выполнение ожидаемых функций, как и когда это требуется
    см. страницу термина
  • Обмен информацией о надежности - dependability communication
    Непрерывный итеративный процесс, который выполняет заинтересованная сторона для обеспечения, выделения или получения информации и участия в диалоге с другими заинтересованными сторонами в отношении менеджмента надежности
    см. страницу термина
  • Окружающая среда (системы) - environment
    Условия, определяющие окружающую обстановку и детали всех воздействий на систему
    см. страницу термина
  • Ответственность
    это общая ответственность за принимаемые решения и действия в процессе жизненного цикла системы. Ответственность включает обязанность представления информации пользователям и другим заинтересованным сторонам, а также мониторинга и поддержания средств контроля идентифицированного риска. Так как у открытых систем не существует централизованного управления, трудно идентифицировать сторону, ответственную за конкретное решение, действие или особое управление
    см. страницу термина
  • Ответственность (подотчетность) - accountability
    Состояние ответственности за решения и деятельность перед руководящими органами организации, правовыми органами и заинтересованными сторонами организации
    см. страницу термина
  • Открытая система - open system
    Система, границы, функции и структура которой изменяются во времени, по-разному распознаваемая и описываемая с различных точек зрения
    см. страницу термина
    является система, границы, функции и структура которой изменяются в процессе жизненного цикла, которую распознают и описывают по-разному в зависимости от точки зрения. Надежность открытой системы является ключевым понятием жизненного цикла системы, которая находится в эксплуатации в реальных условиях продолжительный период времени. Надежность открытых систем позволяет учесть способность открытых систем адаптироваться к изменениям в целях, задачах, окружающей среде, фактическом функционировании и непрерывно поддерживать ответственность заинтересованных сторон за представление ожидаемых услуг в соответствии с установленными требованиями. Свойства надежности (готовность, безотказность, ремонтопригодность) и обеспечение технического обслуживания одинаковы для открытых и обычных систем, но необходимо учитывать, что ни одна заинтересованная сторона не имеет полного понимания системы и соответствующего ей риска
  • Ошибка взаимодействия - interaction error
    Ошибка, которая происходит при взаимодействии объектов, несмотря на то что функционирование каждого объекта соответствует установленным требованиям
    см. страницу термина
  • Процесс - process
    Совокупность взаимосвязанных и (или) взаимодействующих видов деятельности, использующих входы для получения намеченного результата
    см. страницу термина
  • Разрушающие изменения
    являются изменения, для которых существенная адаптация системы, по мнению существующих заинтересованных сторон, невозможна или невыполнима. Такая ситуация включает случаи, когда стоимость необходимой адаптации превышает устойчивость работы ответственных заинтересованных сторон в действующем соглашении. Менеджмент в таком случае может быть заранее запланирован в максимально возможной степени, например в отношении введения новых заинтересованных сторон, удаления неработающих заинтересованных сторон, восстановления консенсуса или раннего вывода системы из эксплуатации
    см. страницу термина
  • Реагирование на отказ - failure response
    Совокупность действий, незамедлительно осуществляемых при прогнозировании или обнаружении отказа, с целью предотвращения отказа или снижения его воздействия, а также для анализа причин отказа, предотвращения их повторного появления и подготовки необходимых отчетов
    см. страницу термина
  • Свидетельства надежности - dependability case
    Основанные на фактах аргументированные, прослеживаемые доводы в поддержку утверждения о том, что система удовлетворяет или будет удовлетворять требованиям к надежности
    см. страницу термина
  • Свойства надежности
    готовность, безотказность, ремонтопригодность
    см. страницу термина
  • Структура исходных сведений - frame of reference
    Набор правил для формирования, интерпретации и использования документов, описывающих общее понимание и четкие соглашения о системе, ее цели, задачах, окружающей среде, фактической работе, жизненном цикле и их изменениях
    см. страницу термина
  • Устойчивость организации - resilience
    Способность организации к адаптации в сложной и изменяющейся окружающей среде
    см. страницу термина
  • Цель анализа процесса аккомодации изменений
    состоит в том, чтобы поддерживать статус "пригодности использования" системы, несмотря на изменения в требованиях, окружающей среде, задачах и/или целях
    см. страницу термина
  • Цель анализа процесса достижения консенсуса
    является установление и поддержание общего понимания с четкими соглашениями о системе, ее назначении, цели, задачах, окружающей среде, фактическом изготовлении, жизненном цикле и их изменениях
    см. страницу термина
  • Цель анализа процесса обеспечения ответственности
    состоит в установлении взаимосвязи между нарушением четкого соглашения и его значением для заинтересованных сторон и общества в целом. Это относится к обязательствам ответственных заинтересованных сторон обеспечивать средства реализации консенсуса относительно системы, чтобы поддерживать доверие к системе и обеспечивать готовность средств устранения возможного вреда
    см. страницу термина
  • Цель анализа процесса реагирования на отказ
    состоит в том, чтобы обеспечить непрерывную работу системы с выполнением максимально возможного количества функций с наименьшим разрушением и ущербом самым целесообразным способом в условиях эксплуатации
    см. страницу термина
  • Цель высшего уровня
    "обеспечение непрерывности и ответственности функционирования постоянно изменяющейся системы" разделяют согласно четырем видам анализа процессов, представленным в настоящем стандарте. Декомпозиция цели означает идентификацию подцелей, достижение которых подразумевает достижение основной цели (см. рисунок B.1)
    см. страницу термина
  • Цель действий реакции на отказ
    состоит в том, чтобы восстановить электроснабжение всех потребителей за самое короткое время
    см. страницу термина
  • Цель надежности открытых систем
    состоит в поддержании непрерывного функционирования системы в условиях наличия окружающих систем, заинтересованных сторон и среды до тех пор, пока это практически осуществимо при наличии непредвиденных событий и изменений, неполноты и неопределенности знаний о системе у заинтересованных сторон
    см. страницу термина

  • Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru) ...
  • Настоящий стандарт может быть использован для повышения надежности открытых систем и обеспечения уверенности в том, что анализ процесса открытой системы соответствует ожидаемым результатам. Настоящий стандарт может помочь организации определить деятельность и задачи, которые ДОЛЖНЫ быть выполнены для достижения целей в области надежности открытой системы, включая обмен информацией о надежности, оценку и сопоставление показателей надежности на всех стадиях жизненного цикла системы. ...
  • - МЭК Electropedia: доступна на electropedia.org; ...
  • - ИСО, Интернет-онлайн-платформа: доступна на iso.org/obp. ...
  • Примечание 1 - Консенсус НЕ ОБЯЗАТЕЛЬНО подразумевает полное единодушие. ...
  • 2 Границы, функции и структура открытой системы не только изменяются во времени, но могут быть неопределенными в любой момент времени, их по-разному распознают различные заинтересованные стороны. Это уточняет определение системы в [2] для данного уровня абстракции и данной точки зрения. Границы могут быть четко определены на одном уровне абстракции, но они могут стать более неопределенными на более детальном уровне. Уровень детализации, необходимый для данной цели или заинтересованной стороны, может быть заранее не предопределен и НЕ ОБЯЗАТЕЛЬНО достижим. ...
  • 5 Тот факт, что программное обеспечение системы может быть "открытым", не важен для признания системы открытой, за исключением того, что общедоступное программное обеспечение ОБЯЗАТЕЛЬНО включает аспекты открытых систем, так же как и отсутствие централизованного управления. ...
  • - Возможность отказов из-за неполного понимания системы, непредвиденных событий и изменений НЕ МОЖЕТ быть устранена или спрогнозирована. Система ДОЛЖНА быть гибкой, обеспечена средствами контроля риска, включая выявление ошибок, ДОЛЖНА быть восстанавливаемой после отказов и адаптируемой для предупреждения их повторного появления. ...
  • Система ОБЯЗАТЕЛЬНО обменивается различными функциями с другими связанными, независимо управляемыми системами. Управление этими окружающими системами подчиняется принципам и требованиям заинтересованных сторон, и взаимодействия с ними подвержены изменениям по различным причинам. Система ДОЛЖНА служить разнообразным заинтересованным сторонам. У каждой заинтересованной стороны есть свои цели, единого органа управления системой может не быть; кроме того, цели основной системы и окружающих систем изменяются во времени. Условия работы системы, такие как требования и ограничения, изменяются часто и непредсказуемо. Таким образом, этим системам присущи неопределенность и неполнота этих условий, в каждый момент времени они не могут быть полностью поняты. ...
  • Истинные, предполагаемые ожидания для системы всегда относительны при наличии других окружающих систем и заинтересованных сторон. Цели различных уровней систем, окружающих базовую систему, ДОЛЖНЫ быть учтены. Поскольку условия меняются, а неполнота и неопределенность так или иначе снижаются, система ДОЛЖНА адаптироваться к соответствующим изменениям в требованиях и предположениях. Данные изменения невозможно ожидать или определить заранее. ...
  • Все это подчеркивает важность процесса, который постоянно анализирует, пересматривает область применения менеджмента надежности, а также обеспечивает ее четкое документирование и согласование. Согласование заинтересованными сторонами области применения менеджмента надежности ДОЛЖНО быть установлено соответствующими соглашениями о распределении ответственности и подотчетности. ...
  • Область применения менеджмента надежности открытой системы нельзя назвать простой из-за особенностей, описанных в 4.1. Недостаточно простого соответствия требованиям, установленным в соглашениях, поскольку соглашения не могут охватить все аспекты рассматриваемой системы, так как открытые системы не могут быть полностью определены. Заинтересованные стороны ДОЛЖНЫ быть готовы действовать вне соглашений на основе общего понимания системы и ее окружающей среды. Обеспечение надежности открытых систем стремится к уверенности в соответствии системы даже при нарушении предположений и требований, ставших недействительными в результате изменений в системе и возможных отказов системы. ...
  • Для обеспечения надежности открытой системы ее жизненный цикл ДОЛЖЕН допускать выполнение заинтересованными сторонами следующих действий: ...
  • Систему не считают определенной, а рассматривают как открытую, если знания о ней не могут быть полными и определенными. Система, к которой применяют подход надежности открытых систем, ДОЛЖНА быть способна: ...
  • Для подтверждения надежности открытых систем на стадиях жизненного цикла системы необходимо представить свидетельства надежности, которые ДОЛЖНЫ обеспечить демонстрацию следующего [8], [9]: ...
  • Примечание 1 - В отличие от четких соглашений, общее понимание системы НЕ ОБЯЗАТЕЛЬНО четко документировано и включает подход, убеждения, восприятие и ценности, которые разделяют заинтересованные стороны. ...
  • ДОЛЖНО быть обеспечено одинаковое понимание у всех заинтересованных сторон, при котором расхождения в интерпретациях являются приемлемыми. Четкие соглашения включают в себя преимущества и ответственность заинтересованных сторон в разработке и эксплуатации системы, а также в сделанных предположениях. ...
  • Содержание 6.i.3 "Процессы, действия и задачи" представляет собой основную часть настоящего стандарта. Представлен перечень процессов, действий и задач (d), установленных в [1], которые осуществляют анализ процесса вместе с рекомендациями по реализации надежности открытых систем. Для каждого процесса, указанного в [1], приведен дополнительный абзац, в котором описана его связь с анализом процесса, а также приведено более подробное описание соответствующих действий и задач с признаками результатов анализа процесса. Описания в 6.i.3 ДОЛЖНЫ быть использованы вместе с описаниями в [1], которые обеспечивают определение и условия применения связанных процессов, действий и задач. ...
  • 4) Предварительно согласован арбитражный процесс для ситуаций, когда консенсус НЕ МОЖЕТ быть достигнут с целью разрешения конфликта интересов. ...
  • <6.1.1> Процесс приобретения устанавливает и поддерживает соглашение между покупателем и поставщиком, что является частью четких соглашений, упомянутых в [a), b)]. Покупатели ДОЛЖНЫ учитывать также интересы других сторон (не только покупателей и поставщиков), таких как конечные пользователи, местное сообщество и контролирующие органы [a)]. ...
  • <6.1.2> Процесс поставки устанавливает и поддерживает соглашение между покупателем и поставщиком, которое является частью четких соглашений в соответствии с [a), b)]. Поставщики ДОЛЖНЫ учитывать также интересы других сторон (не только покупателей и поставщиков), таких как конечные пользователи, местное сообщество и контролирующие органы [a)]. ...
  • - : Согласование соглашения и его выполнение ДОЛЖНЫ быть реализованы справедливо и беспристрастно [a)7)]. ...
  • Анализ процесса достижения консенсуса ДОЛЖЕН быть выполнен с использованием действий и задач следующих процессов (см. [1]). ...
  • - : Стратегия приобретения ДОЛЖНА быть направлена на достижение общего понимания и четких соглашений в соответствии с [a)]. ...
  • - : Оценка выполнения соглашения ДОЛЖНА включать оценку его справедливости и беспристрастности [a)7)]. ...
  • - : Стратегия поставки ДОЛЖНА разъяснять способы ее выполнения [a)]. ...
  • - : Общее понимание менеджмента качества ДОЛЖНО признавать, что определение обязанностей и критериев оценки несовершенно и может быть изменено, а заинтересованные стороны ДОЛЖНЫ быть готовы действовать, когда необходимо, вне определенной для них ответственности ради всеобщего качества [b)]. ...
  • - : Политика, цели и процедуры менеджмента качества ДОЛЖНЫ быть направлены на уровень общего понимания и согласия по отношению к точным соглашениям [a), b)]. Заинтересованные стороны ДОЛЖНЫ выработать общее понимание и четкие соглашения относительно менеджмента качества, учитывая, что не существует одной организации, которая осуществляет менеджмент качества системы в целом [a), b)]. ...
  • - : Критерии оценки ДОЛЖНЫ быть справедливыми и беспристрастными [a)7)]. ...
  • - : Стратегия менеджмента знаний, классификация разделения и систематизации знаний в организации ДОЛЖНЫ обеспечить структуру базового понимания всех заинтересованных сторон [a)2)]. ...
  • - : Определение и планирование проекта (цели, ограничения, область применения, модель жизненного цикла, структура распределения работ, график, критерии выполнения стадий жизненного цикла, затраты и бюджет, функции, обязанности, ответственность персонала и т.д.) ДОЛЖНЫ отражать общее понимание и четкие соглашения и, в свою очередь, углублять и разъяснять их, формируя основу их поддержки [a)2), a)3), a)5), a)6), b)1), b)2), b)3)]. ...
  • <6.2.1> Процесс управления моделью жизненного цикла ДОЛЖЕН установить связи между процессами жизненного цикла, что позволяет получить все результаты анализа процесса [a), b)]. ...
  • - : Планы обмена информацией и выполнения анализа ДОЛЖНЫ быть частью разработки и поддержки четких соглашений; анализ ДОЛЖЕН обеспечивать и документировать обоснование положений соглашений [a)5), b)2), b)5)]. ...
  • - : Оценка выполнения соглашения ДОЛЖНА включать оценку его справедливости и беспристрастности [a)7)]. ...
  • - : Поддержка знаний ДОЛЖНА быть интегрирована в поддержку общего понимания и четких соглашений [b)]. ...
  • - : Ответственность за свидетельства надежности ДОЛЖНА быть определена в планах проекта [b)4)]. ...
  • - : Стратегия менеджмента принимаемых решений ДОЛЖНА включать предварительно согласованный арбитражный процесс [a)4)]. ...
  • - : Форматы и структура элементов информации являются частью структуры в соответствии с [a)2)], их содержание ДОЛЖНО отражать общее понимание [a)3), a)5)]. ...
  • - : Изъятие информации с учетом разработки четких соглашений и их обоснования [b)5)] ДОЛЖНО быть выполнено только после внимательного рассмотрения значения информации для изменения договоренностей и обеспечения ответственности на более позднее время, включая случаи, когда они появляются в результате реагирования на отказ. ...
  • - : Помимо заинтересованных сторон с конфликтом интересов те стороны, интересы которых затрагивают решения, ДОЛЖНЫ быть идентифицированы и вовлечены [a)1), a)7)]. ...
  • - : Желаемый результат и критерии выбора ДОЛЖНЫ быть определены справедливым и беспристрастным способом при помощи рекурсивного применения анализа процесса достижения консенсуса [a)6), a)7)]. ...
  • - : Записи резолюций, обоснования решений и предположений, прослеживания и оценки ДОЛЖНЫ обеспечить учет формирования консенсуса и доказательства его справедливости и беспристрастности [a)7), b)5)]. ...
  • - : Управляемые элементы информации ДОЛЖНЫ включать перечень идентифицированных заинтересованных сторон [a)1)], структуру ссылок [a)2)], понимание цели системы и т.д. [a)3)], согласованный арбитражный процесс [a)4)], четкие соглашения [a)5)], свидетельства надежности [b)4)], учет разработок и обоснование консенсуса [b)5)]. ...
  • - Стратегия управления информацией и действиями по поддержке информации ДОЛЖНА включать политику управления изменениями соглашений [b)1)], поддержку консенсуса заинтересованных сторон [b)2)], анализ процесса достижения консенсуса [b)3)]. Эти действия ДОЛЖНЫ сократить различие интерпретаций [a)6)] и поддерживать справедливость и беспристрастность для всех заинтересованных сторон [a)7)]. ...
  • - : Разработка информации о четких соглашениях ДОЛЖНА признавать согласованный арбитражный процесс разрешения конфликта интересов [a)4)]. Структура в соответствии с установленной в [a)2)] ДОЛЖНА быть использована для преобразования информации в информацию, полезную для заинтересованных сторон. ...
  • - : Оценка продукции или услуги и процесса ДОЛЖНА быть частью поддержки общего понимания и четких соглашений [b)1), b)2)]. ...
  • - : Запись действий по обеспечению качества ДОЛЖНА обеспечивать отчет о достижении консенсуса [b)5)]. ...
  • - : Обработка проблем ДОЛЖНА включать анализ необходимости модификации общего понимания и четких соглашений и их процессов [b)1), b)2), b)3)]. ...
  • <6.4.1> Процесс анализа деятельности или назначения обеспечивает структуру базового понимания и начинает создание общего понимания окружающей среды и т.д. в этой структуре. Применение этого процесса ДОЛЖНО учитывать, что системе может недоставать организации, охватывающей все заинтересованные стороны. ...
  • - : После анализа проблемы ДОЛЖНО быть получено подтверждение, что все заинтересованные стороны разделяют одно и то же понимание области применения, основ или причин проблем и возможностей, указанных в [a)2), a)3), a)6)]. ...
  • - : Определение условий использования системы ДОЛЖНО устранить разногласия в предположениях заинтересованных сторон справедливым и беспристрастным образом [a)2), a)3), a)7)]. ...
  • - : Стратегия анализа и определение проблем области применения ДОЛЖНЫ разъяснить структуру базового и общего понимания, они также ДОЛЖНЫ быть справедливыми и беспристрастными [a)2), a)3), a)7)]. ...
  • - : Выполняющий оценку и метод оценки ДОЛЖНЫ быть идентифицированы и согласованы всеми заинтересованными сторонами [a)7)]. ...
  • - : При определении явных и неявных потребностей следует обратить особое внимание на ; потребности заинтересованных сторон ДОЛЖНЫ быть выявлены вместе с их предположениями о системе и ее среде; следует учесть, что различия в предположениях могут стать очевидными только после некоторого периода эксплуатации; различия, препятствующие обмену информацией о надежности среди заинтересованных сторон, могут быть препятствием в достижении консенсуса и могут привести к нерациональным решениям [a)2), a)3)]; сбор информации, идентификация, выбор и определение потребностей заинтересованной стороны ДОЛЖНЫ быть справедливыми и беспристрастными [a)7)]. ...
  • - : Идентификация основных групп заинтересованных сторон ДОЛЖНА учитывать, что заинтересованные стороны могут изменяться во времени, и каждая заинтересованная сторона может по своему понимать, какие субъекты являются основными группами заинтересованных сторон системы; каждая заинтересованная сторона ДОЛЖНА быть идентифицирована вместе с ее функциями [a)1)]; предварительные концепции эксплуатации ДОЛЖНЫ включать политику относительно функций системы, которая выражает общее понимание [a)2)]. ...
  • - : Идентифицированные классы решений ДОЛЖНЫ быть распределены среди всех заинтересованных сторон, и каждая заинтересованная сторона ДОЛЖНА быть в состоянии рассмотреть решения со своей точки зрения для обеспечения справедливости и беспристрастности [a)3), a)7)]. ...
  • - : Прослеживаемость результатов анализа до и после изменений ДОЛЖНА быть поддержана в дополнение к прослеживаемости результатов анализа и других артефактов в одной итерации жизненного цикла [b)2), b)5)] (см. <6.4.1.1, примечание 2>). ...
  • - : Идентификация заинтересованных сторон ДОЛЖНА учитывать, что заинтересованные стороны могут изменяться во времени и каждая заинтересованная сторона может по-своему понимать, какие субъекты являются заинтересованными сторонами системы; каждая заинтересованная сторона ДОЛЖНА быть идентифицирована вместе с ее функциями [a)1)]. ...
  • - : Стратегия определения потребностей и требований заинтересованных сторон ДОЛЖНА обеспечивать справедливое и беспристрастное разрешение различных мнений и конфликтов, что помогает обеспечивать гарантию и целостность системы [a)4), a)7)] (см. <6.4.2.3 a)2) примечание>); стратегия ДОЛЖНА быть направлена на достижение общего понимания политики в отношении функций системы [a)3)]. ...
  • - : Концепция эксплуатации ДОЛЖНА включать политику относительно функций системы, которая ДОЛЖНА отражать общее понимание [a)2)]. ...
  • - : Четкое принятие структуры ДОЛЖНО формировать часть соглашений [a)5)]. ...
  • - : До того как выбран особый набор технических требований, заинтересованные стороны ДОЛЖНЫ достигнуть консенсуса относительно ожидаемых последствий и рисков, соответствующих этому набору для каждой заинтересованной стороны [a)5), a)6), a)7)]. ...
  • 2 Соглашения ДОЛЖНЫ быть четкими, разъяснять причины, по которым каждая заинтересованная сторона ДОЛЖНА обеспечивать свою ответственность (подотчетность). Четкие соглашения при необходимости могут ссылаться на негласные соглашения, например на промышленные своды правил. ...
  • Анализ процесса обеспечения ответственности ДОЛЖЕН быть выполнен с использованием действий и задач процессов, приведенных в [1]. ...
  • Примечание 11 - Существуют некоторые ситуации, когда информация о сложных процессах жизненного цикла ДОЛЖНА быть объединена. ...
  • - : Установление функций и т.д. ДОЛЖНО включать идентификацию физического или юридического лица, ответственного за каждое ключевое решение [b)]. ...
  • - : Определение ответственности и полномочий является частью достижения [a), b)] и ДОЛЖНО рассматриваться [c), d), e)] совместно. ...
  • - : Установление соглашения между покупателем и поставщиком (включая критерии приемки и обязанности покупателя) включает ключевые решения, управляющие жизненным циклом системы [a)]; их невыполнение является нарушением соглашения; ключевые решения, приводящие к нарушению и т.д., ДОЛЖНЫ быть идентифицированы в соответствии с [b), c), d), e)]. ...
  • - : Определение бизнес-критериев и способов управления стадиями жизненного цикла включает ключевые решения [a), b)]. Отчеты об этих разработках ДОЛЖНЫ быть документированы [i)]. ...
  • - : Отмена и приостановка проекта ДОЛЖНЫ быть учтены своевременно [i)]. ...
  • <6.3.1> Процесс планирования проекта: все определения и идентификации, осуществленные в этом процессе, включают ключевые решения [a)] и ДОЛЖНЫ быть рассмотрены вместе с [b), c), d), e), h)]. ...
  • - : Установленный стандарт моделей жизненного цикла ДОЛЖЕН определить связи между процессами жизненного цикла, которые дают возможность получения всех результатов анализа процесса обеспечения ответственности [от a) до i)]. ...
  • <6.2.3> Процесс управления портфолио ДОЛЖЕН идентифицировать ключевые решения относительно управления взаимодействием между жизненными циклами системы и других систем [a)]. ...
  • <6.2.6> В условиях, когда знания ДОЛЖНЫ быть разделены между несколькими организациями, ДОЛЖЕН быть внедрен процесс менеджмента знаний [f), g), i)]. Достоверная информация в [i)] ДОЛЖНА включать "уроки" прошлого опыта, который ответственные заинтересованные стороны использовали в своих решениях. ...
  • - : Установление соглашения между покупателем и поставщиком, включая критерии приемки и обязательности покупателя, включает ключевые решения, управляющие жизненным циклом системы [a)]; его невыполнение является нарушением соглашения, ключевые решения, приводящие к нарушению и т.д., ДОЛЖНЫ быть идентифицированы [b), c), d), e)]. Поддержка соглашения также ДОЛЖНА обеспечивать результаты [f), g)]. ...
  • - : Ответственность за продукцию или услугу ДОЛЖНА быть преобразована таким образом, чтобы гарантировать непрерывное достижение результатов [f), g), h), i)]. ...
  • - : Установление политики менеджмента качества и другого и определение критериев и методов оценки качества включают ключевые решения [a)] и результаты [b), c), d), e), h)], которые ДОЛЖНЫ быть рассмотрены совместно. Для идентификации и определения ДОЛЖНА быть установлена ответственность. ...
  • : Стратегия управления информацией ДОЛЖНА поддерживать обратные связи о результатах решений при принятии новых решений [g)]. ...
  • - : Планирование приобретения включает ключевые решения [a)] и ДОЛЖНО быть рассмотрено вместе с [b), c), d), e), h)]. ...
  • - : Определение стратегии оценки и управления проектом включает ключевые решения [a)] и ДОЛЖНО быть рассмотрено вместе с [b), c), d), e), h)]. ...
  • <6.3.4> Процесс менеджмента риска: ответственность за менеджмент идентифицированного риска, т.е. мониторинг и обеспечение контроля риска особенно важны. Это ДОЛЖНО быть четко определено даже для риска, который не полностью понят [b), e), f), h)]. ...
  • - : Определение стратегии менеджмента риска и решений по обработке риска включает ключевые решения [a)] и ДОЛЖНО быть рассмотрено вместе с [b), c), d), e), h)]. ...
  • - : Средства управления проектом ДОЛЖНЫ включать обратные связи, упомянутые в [g)], инициирование корректирующих действий [h)] и представление отчетной информации [i)]. ...
  • - : Записи о принимаемых решениях ДОЛЖНЫ включать свидетельства того, что ответственность за принятие и контроль решений достигнута [i)]. ...
  • - : Статус конфигурации, отчетность и оценка конфигурации ДОЛЖНЫ обеспечивать часть достоверной информации в соответствии с [i)], которая помогает приобрести уверенность и доверие заинтересованных сторон к информации о системе [i)2)]. ...
  • - : Оценка проекта ДОЛЖНА включать оценку в соответствии с [d)]. Результат ДОЛЖЕН быть обеспечен в информации об ответственности [i)]. ...
  • <6.3.6> Процесс управления информацией ДОЛЖЕН обеспечивать достоверной информацией в соответствии с [i)]. В частности, ДОЛЖНЫ быть достигнуты достаточная уверенность и доверие заинтересованных сторон [i)2)]. При обеспечении информацией необходимо учитывать совместную работу нескольких процессов жизненного цикла. ...
  • - : Четкая структура распределения работ ДОЛЖНА сопровождаться назначением ответственности и идентификацией уместной информации для распространения [b), i)]. ...
  • - : Установленная ответственность ДОЛЖНА включать идентификацию информации для распространения в случае отказа системы [i)]. ...
  • - : Стратегия менеджмента принимаемых решений ДОЛЖНА обеспечивать хорошие обратные связи [g)]. ...
  • - : Идентификация конфигурации технических объектов и изменений в процессе управления конфигурацией включает ключевые решения [a)] и ДОЛЖНА быть рассмотрена вместе с [b), c), d), e), h)]. ...
  • - : Оценка конфигурации ДОЛЖНА быть выполнена как часть мониторинга нарушения соглашений [f)] и обратных связей, о которых информируют лиц, принимающих решения, [g)]. ...
  • - : Назначение ответственности ДОЛЖНО быть прослеживаемым [b)]. Прослеживаемость ДОЛЖНА быть обеспечена соответствующим образом [c), d), e), i)]. Требования заинтересованной стороны ДОЛЖНЫ быть прослежены до требований к мониторингу системы [f), g)]. ...
  • - : Все процессы ДОЛЖНЫ инициировать процесс управления информацией для сбора и управления данными о регистрации и другими свидетельствами, которые позволяют установить и обосновать адекватность и достоверность информации об ответственности; ДОЛЖНО быть обеспечено объективное представление обоснований [i)2)]. ...
  • - : Определение стратегии обеспечения качества включает ключевые решения [a)] и ДОЛЖНО быть рассмотрено вместе с [b), c), d), e), h)]. ...
  • - : Описание области применения решений ДОЛЖНО включать описание ответственности каждой идентифицированной основной заинтересованной стороны [b)]. ...
  • - : Четкое соглашение по требованиям заинтересованных сторон ДОЛЖНО идентифицировать ответственность по каждому элементу соглашения [c), d), e), h)]. ...
  • - : Элементы информации ДОЛЖНЫ быть собраны и использованы вместе с доказательствами их подлинности в форме, допускающей проверку пользователями информации [i)2)]. ...
  • - : Публикация, распределение или предоставление доступа к информации ДОЛЖНЫ быть выполнены в соответствии с [i)]. ...
  • - : Идентификация заинтересованных сторон, определение потребностей заинтересованных сторон, определение концепции эксплуатации и других концепций жизненного цикла и определение требований заинтересованных сторон включают ключевые решения [a)] и ДОЛЖНЫ быть рассмотрены вместе с [b), c), d), e), h)]. ...
  • - : Потребности заинтересованных сторон ДОЛЖНЫ быть идентифицированы вместе с их ответственностью [b), c), d), e), h)]. ...
  • - : Записи о выборе ключевых элементов информации для исходных состояний ДОЛЖНЫ быть зафиксированы в отчете для использования в достижении [i)]. ...
  • <6.3.7> Процесс измерений ДОЛЖЕН формировать часть обратных связей [g)]. ...
  • - : Концепция эксплуатации и другие концепции жизненного цикла ДОЛЖНЫ включать определение ответственности основных групп заинтересованных сторон, идентифицированных в <6.4.1>. Анализ сценариев ДОЛЖЕН идентифицировать ключевые решения, принятые заинтересованными сторонами в соответствии со сценариями, и анализировать возможные воздействия и последствия этих решений [a), b), c), d), e), h)]. ...
  • - : Назначение ответственности ДОЛЖНО быть прослеживаемым [b)]. Прослеживаемость ДОЛЖНА быть обеспечена соответствующим образом [c), d), e), i)]. ...
  • - : Взаимосвязь структуры и проекта ДОЛЖНА определять матрицу ответственности. ...
  • - : Назначение ответственности ДОЛЖНО быть прослеживаемым [b)]. Прослеживаемость ДОЛЖНА быть обеспечена соответствующим образом [c), d), e), i)]. ...
  • - : Определение функциональных границ, ограничений выполнения требований к системе и выбора ключевой информации для исходных состояний включает ключевые решения [a)] и ДОЛЖНО быть рассмотрено вместе с [b), c), d), e), h)]. ...
  • - : Функциональные границы ДОЛЖНЫ быть определены вместе с границами ответственности [a), b), c), d), e), h)]. ...
  • - : Функции ДОЛЖНЫ быть определены вместе с ответственностью за их выполнение [a), b), c), d), e), h)]. ...
  • - : Требования, относящиеся к риску и критичности системы, ДОЛЖНЫ быть идентифицированы вместе с ответственностью за них [c), d), e)]. ...
  • - : Определение требований заинтересованных сторон и их обоснование ДОЛЖНЫ разъяснять ключевые решения, которые влияют на определение требований, и ответственность за них [a), b), c), d), e), h)]. ...
  • - : Ниже указаны ключевые решения [a)], которые ДОЛЖНЫ быть рассмотрены вместе с [b), c), d), e), h)]: идентификация ключевых причинных факторов, идентификация озабоченностей заинтересованных сторон, определение критериев оценки, определение точки зрения на структуру, идентификация элементов системы, определение интерфейсов и взаимодействий между элементами системы и внешними юридическими лицами, выбор и принятие структуры. ...
  • - : Критерии оценки структуры ДОЛЖНЫ включать критерии ответственности, описанные в вариантах структуры. ...
  • - : ДОЛЖНЫ быть разработаны модели и виды анализа, которые разъясняют способ достижения результатов [a), b), c), d), e), h)]. ...
  • - : Записи о выборе ключевых элементов информации для исходных состояний ДОЛЖНЫ быть зарегистрированы в отчете для использования в достижении [i)]. ...
  • - : Ниже указаны ключевые решения [a)], которые ДОЛЖНЫ быть рассмотрены вместе с [b), c), d), e), h)]: ...
  • - : Если характеристики структуры преобразовывают в характеристики проекта, ответственность за них также ДОЛЖНА быть назначена [b), c), d), e), h)]. ...
  • - : Ответственность за неразрабатываемые элементы ДОЛЖНА быть разъяснена [b), c), d), e), h)]. ...
  • - : Прослеживаемость подотчетности также ДОЛЖНА быть поддержана [b), c), d), e), h), i)]. ...
  • - : Прослеживаемость ответственности при изготовлении элементов системы ДОЛЖНА также быть поддержана [b), c), d), e), h), i)]. ...
  • - : Распределение требований к системе по элементам системы ДОЛЖНО также включать распределение ответственности [b), c), d), e), h)]. ...
  • - : Интерфейсы элементов системы ДОЛЖНЫ быть определены вместе с областью ответственности за них [b), c), d), e), h)]. ...
  • - : Записи о выборе ключевых элементов информации для исходных состояний ДОЛЖНЫ быть зафиксированы в отчете для использования в достижении [i)]. ...
  • <6.4.6> Процесс анализа системы: записи о следующих действиях ДОЛЖНЫ быть зафиксированы в отчете для использования в качестве достоверной информации в [i)]: ...
  • - : Определение стратегии изготовления, идентификация ограничений и технологии изготовления включают ключевые решения [a)] и ДОЛЖНЫ быть рассмотрены вместе с [b), c), d), e), h)]. ...
  • - : Записи установления критериев, используемых для выявления аномалий, и выбор ключевых элементов информации об исходных состояниях ДОЛЖНЫ быть зафиксированы в отчете для использования в достижении [i)]. ...
  • - : Ограничения системы, связанные с интеграцией, ДОЛЖНЫ быть включены в требования к системе, структуру или проект как часть обратной связи [g)]. ...
  • - : Записи об использовании критериев для выявления аномалий и выбор ключевых элементов информации об исходных состояниях ДОЛЖНЫ быть зафиксированы в отчете для использования в соответствии с [i)]. ...
  • - : Приемка изготовленных элементов системы и оценка, которая следует из проверки интерфейсов и т.д., являются ключевыми решениями [a)] и ДОЛЖНЫ быть рассмотрены вместе с [b), c), d), e), h)]. ...
  • - : Прослеживаемость ответственности за верификацию системы элементов также ДОЛЖНА поддерживаться [b), c), d), e), h), i)]. ...
  • - : Стратегия перемещения ДОЛЖНА включать назначение ответственности [b), c), d), e), h)]. ...
  • - : Идентификация необходимого обучения операторов и т.д. ДОЛЖНА включать идентификацию их ответственности [b), c), d), e), h)]. ...
  • - : Утверждение о том, что система или элемент системы соответствуют установленному требованию, является ключевым решением [a)] и ДОЛЖНО быть рассмотрено вместе с [b), c), d), e), h)]. ...
  • - : Обучение операторов и т.д. ДОЛЖНО включать обмен информацией об их ответственности [b), c), d), e), h)]. ...
  • - Записи следующих действий ДОЛЖНЫ быть зафиксированы в отчете для использования в качестве достоверной информации в [i)]: ...
  • - : Ограничения системы для обеспечения верификации ДОЛЖНЫ быть включены в требования к системе, структуру или проект как часть обратной связи [g)]. ...
  • - Следующие действия включают ключевые решения [a)] и ДОЛЖНЫ быть рассмотрены вместе с [b), c), d), e), h)]: ...
  • - Записи следующих действий ДОЛЖНЫ быть зафиксированы в отчете для ...
  • - : Ограничения системы для обеспечения перемещения ДОЛЖНЫ быть включены в требованиях к системе, структуру или проект как часть обратной связи [g)]. ...
  • - : Анализ готовности к эксплуатации ДОЛЖЕН рассматривать перспективу обеспечения ответственности в установленной среде [b), c), d), e), h)]. ...
  • - : Стратегия эксплуатации ДОЛЖНА разъяснять назначение ответственности за мониторинг и поддержку потребителей [b), c), d), e), f), g), h), i)]. ...
  • - : Идентификация систем, обеспечивающих доступ при эксплуатации, ДОЛЖНА включать идентификацию границ ответственности между системой и системами, обеспечивающими доступ [b), c), d), e), h)]. ...
  • - Записи о следующих действиях ДОЛЖНЫ быть зафиксированы в отчете для использования в качестве достоверной информации в [i)]: ...
  • ДОЛЖНЫ быть включены в требования к системе, структуру или проект; ...
  • - Записи о следующих действиях ДОЛЖНЫ быть зафиксированы в отчете для ...
  • - : Подтверждение того, что система или элемент системы соответствует потребностям заинтересованной стороны, является ключевым решением [a)] и ДОЛЖЕН быть рассмотрен вместе с [b), c), d), e), h)]; ...
  • - : Анализ результатов валидации ДОЛЖЕН рассматривать перспективу обеспечения ответственности [b), c), d), e), h)]. ...
  • - Процесс эксплуатации включает следующие ключевые решения [a)] и ДОЛЖЕН быть рассмотрен вместе с [b), c), d), e), h)]: ...
  • - : Мониторинг эксплуатации системы ДОЛЖЕН охватывать ожидаемые и непредвиденные результаты решений во всей системе [f)]. Мониторинг ДОЛЖЕН формировать часть обратных связей [g)]. Мониторинг ДОЛЖЕН допускать быструю идентификацию ответственных заинтересованных сторон и предоставление информации об отчетности по отношению к аномалиям и отказам [h), i)]. Прослеживаемость между действиями мониторинга и нарушением соглашения в [6.3.2] ДОЛЖНА быть установлена через цепь ответственности, поддерживаемую в соответствии с <6.4.5 d)3), 6.4.7 c)2), 6.4.8 c)2), 6.4.9 c)4), 6.4.10 c)3), 6.4.13 d)4)>. ...
  • - : Эксплуатация в непредвиденных обстоятельствах ДОЛЖНА включать инициирование корректирующих действий ответственными заинтересованными сторонами [h)] и своевременное представление информации об ответственности [i)3)]. ...
  • - : Поддержка потребителя ДОЛЖНА быстро представить достоверную информацию относительно запроса [i)1), i)2)], во время отказов [i)3)], во время изменений [i)4)] и когда выявлено нарушение при функционировании [i)5)]. ...
  • - : Разрешение инцидентов и проблем в эксплуатации ДОЛЖНО быть прослежено до ответственных заинтересованных сторон и действий, которые они предприняли [h), i)]. ...
  • - : Определение степени удовлетворенности потребителя ДОЛЖНО быть выполнено как часть обратных связей. Удовлетворенность заинтересованных сторон необходимо контролировать вместе со степенью их ответственности [f), g)]. ...
  • - : Решение о техническом обслуживании и инцидентах в эксплуатации ДОЛЖНО быть прослеживаемым до ответственных заинтересованных сторон и их действий [h), i)]. ...
  • - : Аномалии эксплуатации по отношению к соглашениям, требованиям заинтересованных сторон и ограничениям организации ДОЛЖНЫ быть идентифицированы, проанализированы и зарегистрированы с помощью процесса анализа системы [h), i)]. ...
  • требования к обеспеченности технического обслуживания, которые ДОЛЖНЫ ...
  • - Записи следующих действий ДОЛЖНЫ быть зафиксированы в отчете для ...
  • - : Ограничения системы для адаптации технического обслуживания ДОЛЖНЫ быть включены в требования к системе, структуру или проект как часть обратной связи [g)]. ...
  • - Процесс технического обслуживания включает следующие ключевые решения [a)] и ДОЛЖЕН быть рассмотрен вместе с [b), c), d), e), h)]: ...
  • - : Анализ инцидентов и проблем для идентификации будущих потребностей технического обслуживания ДОЛЖЕН исследовать полученную степень достижения [b), c), d), e), h)]. ...
  • критериям контроля и периодам хранения (если система ДОЛЖНА быть ...
  • - : Определение степени удовлетворенности потребителя ДОЛЖНО быть выполнено как часть обратных связей; удовлетворение заинтересованных сторон следует контролировать вместе со степенью их ответственности [f), g)]. ...
  • - : Завершение вывода из эксплуатации ДОЛЖНО подтвердить, что у системы не осталось вопросов в области отчетности и ответственности [i)]. ...
  • Участие человека играет ключевую роль, так как не все отказы могут быть предупреждены или смягчены при помощи предварительно спланированных действий. Для быстрой и соответствующей реакции участие человека ДОЛЖНО быть обеспечено поддержкой программных и аппаратных средств с целью оптимизации принятия решений и выполнения установленных действий. ...
  • - Следующие действия включают ключевые решения [a)] и ДОЛЖНЫ быть рассмотрены вместе с [b), c), d), e), h)]: ...
  • эксплуатации, которые ДОЛЖНЫ быть включены в требования к системе, ...
  • элементов и материалов, которые не ДОЛЖНЫ быть использованы повторно, ...
  • - : Записи о выборе информации для архивирования ДОЛЖНЫ быть зафиксированы в отчете для использования в качестве достоверной информации в [i)]. ...
  • Примечание 6 - Установленные действия реагирования ДОЛЖНЫ быть основаны на результатах анализа последствий и вероятности неблагоприятных событий. Эти действия ДОЛЖНЫ быть выполнены системой, а также персоналом, связанным с жизненным циклом системы. ...
  • - : Оценка выполнения соглашения ДОЛЖНА подтверждать, что цели защиты в соответствии с и результаты [b), c)] достигнуты и обеспечены. ...
  • - : Соглашение между покупателем и поставщиком ДОЛЖНО идентифицировать ключевые функции, которые ДОЛЖНЫ быть защищены от отказов, и цели защиты [a)1), a)2), a)5)]. ...
  • Анализ процесса реагирования на отказ ДОЛЖЕН быть выполнен при использовании действий и задач следующих процессов, установленных в [1]. ...
  • - : Оценка выполнения соглашения ДОЛЖНА подтверждать, что цели защиты в соответствии с и результаты [b), c)] достигнуты и обеспечены. ...
  • - : Оценка менеджмента качества ДОЛЖНА анализировать обнаружение и обработку неисправностей, ошибок, отказов и предшествующих им признаков, идентифицированных в соответствии с [a)3)], как предполагается в [b), c)]. ...
  • - : Соглашение между покупателем и поставщиком ДОЛЖНО идентифицировать ключевые функции, которые ДОЛЖНЫ быть защищены от отказов, и цели защиты [a)1), a)2), a)5)]. ...
  • - : Управление проектом ДОЛЖНО включать в себя анализ процесса аккомодации изменений, связанных с адаптацией системы для предотвращения повторных отказов [d)]. ...
  • - : Установленные модели жизненного цикла ДОЛЖНЫ определять взаимосвязь процессов жизненного цикла, что обеспечивает получение всех результатов анализа процесса реагирования на отказ [a), b), c), d)]. ...
  • - : Навыки, которые ДОЛЖНЫ быть идентифицированы, включают навыки, необходимые для понимания цели системы, и навыки, необходимые для применения понимания цели системы к разработке с участием человека, что обеспечивает результаты [a)7), a)8), b)]. ...
  • - : Оценка проекта и стратегия управления проектом ДОЛЖНЫ отражать общее понимание, установленное в [6.2.2 a)], чтобы поддерживать: ...
  • - : Процессы и процедуры менеджмента риска приведены в ГОСТ Р ИСО 31000 и ГОСТ Р ИСО/МЭК 31010. Кроме того, ДОЛЖНЫ быть идентифицированы в соответствии с [a), b)8)]: ...
  • - : Идентификация требований к системе, связанных с риском и т.д., ДОЛЖНА допускать идентификацию ключевых функций, которые ДОЛЖНЫ быть защищены от отказов [a)1)]. Необходимо идентифицировать: ...
  • - : Соглашение по требованиям заинтересованных сторон ДОЛЖНО включать перечень ключевых функций, требующих защиты [a)1)], цели защиты ключевых функций [a)2)], цели обработки отказов, воздействующих на ключевые функции [a)5)]. ...
  • - : Определение ключевых функций ДОЛЖНО включать: ...
  • - : Анализ представительных сценариев ДОЛЖЕН помочь идентифицировать ключевые функции, требующие защиты [a)1)]. Этот анализ включает в себя анализ риска отказов для определения потребности в защите от отказов [a)2)] и анализ вреда, который исследуемая система может нанести связанным с ней системам [b)7)]. ...
  • - : Анализ полного набора требований заинтересованных сторон ДОЛЖЕН включать анализ риска отказов ключевых функций для определения цели их защиты [a)2)], рассмотрение общих мер противодействия отказам с невыявленными причинами [a)8)] и рассмотрение ущерба, который исследуемая система может нанести всем связанным с ней системам [b)7)]. Анализ ДОЛЖЕН идентифицировать неисправности, ошибки, отказы и предшествующие им признаки, которые воздействуют на ключевые функции, и их последствия [a)4), a)5)]. ...
  • - : Потребности заинтересованных сторон ДОЛЖНЫ быть идентифицированы вместе с потребностями в защите от отказов [a)1), a)2)]. Потребности заинтересованных сторон ДОЛЖНЫ включать потребность в непричинении вреда исследуемой системе и связанным с ней системам [a)8), b)7)]. ...
  • - : Идентификация требований и функций заинтересованных сторон включает обозначение ключевых функций, требующих защиты от отказов [a)1)], и цели защиты [a)2)]. Требования заинтересованных сторон ДОЛЖНЫ включать требования непричинения вреда исследуемой системе и связанным с ней системам [b)7)]. ...
  • - : Критические показатели работы ДОЛЖНЫ включать меры степеней защиты ключевых функций [a)2)], обработки отказов и т.д. [a)5)]. ...
  • - : Прослеживаемость от требований к мониторингу до требований к ключевым функциям ДОЛЖНА поддерживаться с целью обеспечения ответственности за реакцию на отказ [b)1), c)]. ...
  • - : Определение требований к системе и их обоснование ДОЛЖНО включать следующее: ...
  • - : Соглашение о требованиях к системе ДОЛЖНО включать перечень ключевых функций, требующих защиты [a)1)], цели защиты ключевых функций [a)2)], цели обработки неисправностей и т.д., которые воздействуют на ключевые функции [a)5)]. ...
  • - : Принятие структуры заинтересованными сторонами ДОЛЖНО включать принятие структуры обработки неисправностей и т.д. [a)6)], конкретных реакций на отказ [a)7)], общих реакций на отказ [a)8)], обнаружения неисправностей и т.д. [b)1)]. ...
  • - : Анализ полного набора требований к системе ДОЛЖЕН включать анализ последствий возможных отказов ключевых функций [a)4)], который допускает: ...
  • - : Критические показатели деятельности ДОЛЖНЫ включать показатели степени защиты ключевых функций [a)2)] и обработки неисправностей и т.д. [a)5)]. ...
  • - : Идентифицированные озабоченности заинтересованных сторон ДОЛЖНЫ быть отражены в целях защиты ключевых функций [a)2)] и целях обработки неисправностей и т.д. [a)5)] в итерациях процесса определения структуры вместе с процессом определения требований и потребностей заинтересованных сторон и процессом определения требований к системе. Озабоченности заинтересованных сторон относительно вреда системам, связанным с исследуемой системой, ДОЛЖНЫ быть идентифицированы [b)7)]. ...
  • - : ДОЛЖНЫ быть разработаны модели и виды анализа, направленные на обработку неисправностей и т.д. [a)5), a)6)], их обнаружение [b)1)], частные и общие реакции на отказ [a)7), a)8)]. Взаимодействия между действиями реакции на отказ и другими функциями системы ДОЛЖНЫ быть направлены на то, чтобы избежать увеличения вреда от действий реакции на отказ [b)7)]. ...
  • - : ДОЛЖНЫ быть идентифицированы ключевые объекты структуры, связанные с ключевыми функциями и их защитой [a)1), a)7)]. ...
  • - : ДОЛЖНЫ быть идентифицированы ключевые элементы системы, связанные с ключевыми объектами структуры, для защиты ключевых функций [a)1), a)7)]. ...
  • - : Ошибки взаимодействия, их обнаружение и конкретные общие реакции на них ДОЛЖНЫ быть учтены при определении интерфейсов между элементами системы и внешними объектами и при разделении требований по элементам системы [a)3), b)1), a)7), a)8)]. Взаимодействия между реакциями на отказы и другими функциями системы ДОЛЖНЫ быть учтены во избежание увеличения вреда от действий реакции на отказ [b)6)]. ...
  • - : Прослеживаемость от целей обработки неисправностей и т.д. [a)5)], структуры обработки неисправностей и т.д. [a)6)], конкретных реакций на отказ [a)7)], общих реакций на отказ [a)8)] и обнаружения неисправностей и т.д. [b)1)] до целей защиты [a)2)] ДОЛЖНА поддерживаться для отчетности о реакции на отказ [c)]. ...
  • - : Прослеживаемость от характеристик проекта для обработки неисправностей и т.д. [a)6)], конкретной реакции на отказ [a)7)], общих реакций [a)8)] и обнаружения [b)1)] до объектов структуры для защиты ключевых функций [a)2)] и целей обработки ошибок [a)5)] ДОЛЖНА поддерживаться для целей отчетности [c)]. ...
  • - : Прослеживаемость результатов анализа системы ДОЛЖНА поддерживаться для обеспечения своевременного отчета о реакции на отказ [c)]. ...
  • - : Прослеживаемость от перечисленного ниже до характеристик проекта ДОЛЖНА поддерживаться для отчета о реакции на отказ [c)]: ...
  • - : ДОЛЖНЫ быть определены характеристики проекта, связанные с общими мерами защиты от отказов с невыявленными причинами [a)8)]. ...
  • - : Принципы разработки проекта ДОЛЖНЫ обеспечивать руководство по анализу процесса аккомодации изменений после реагирования на отказ [d)]. ...
  • - : Требования защиты ключевых функций [a)2)] и обработки неисправностей и т.д. [a)5)] ДОЛЖНЫ быть распределены по элементам системы. ...
  • - : Прослеживаемость интегрированных элементов системы ДОЛЖНА поддерживаться способом, допускающим быстрое реагирование на отказ [b)] и своевременный отчет о реакции на отказ [c)]. ...
  • - : Прослеживаемость результатов верификации ДОЛЖНА поддерживаться способом, допускающим быструю реакцию на отказ [b)] и своевременный отчет о реакции на отказ [c)]. ...
  • - : Прослеживаемость перемещенных элементов системы ДОЛЖНА поддерживаться способом, допускающим быструю реакцию на отказ [b)] и своевременный отчет о реакции на отказ [c)]. ...
  • - : Прослеживаемость валидированных элементов системы ДОЛЖНА быть поддержана способом, допускающим быструю реакцию на отказ [b)] и своевременный отчет о реакции на отказ [c)]. ...
  • - : Стратегия эксплуатации ДОЛЖНА включать следующие процедуры [b)]: ...
  • - : Соглашение между заинтересованными сторонами о том, что установленные требования выполнены, ДОЛЖНО включать соглашение о том, что цели обработки неисправностей и т.д. выполнены [a)5)]. ...
  • - : Обучение операторов и т.д. ДОЛЖНО быть запланировано как часть общего реагирования на отказ и мер защиты от отказов [a)7), a)8)]. Обучение ДОЛЖНО выработать у заинтересованных сторон навыки достижения [b)] посредством участия человека. ...
  • - : Анализ готовности к эксплуатации ДОЛЖЕН подтвердить, что достижение целей в соответствии с [a)2), a)5), a)8), от b)1) до b)7)] продемонстрирован. ...
  • - : Область применения и действия верификации ДОЛЖНЫ включать верификацию достижения целей защиты ключевых функций [a)2)] и обработки неисправностей и т.д. [a)5)]. ...
  • - : Инциденты в эксплуатации ДОЛЖНЫ быть зарегистрированы и прослежены до разрешения проблемы способом, допускающим своевременный отчет о реакции на отказ [c)]. ...
  • - : Инциденты в эксплуатации ДОЛЖНЫ быть зарегистрированы и прослежены до разрешения проблем способом, допускающим своевременный отчет о реакции на отказ [c)]. ...
  • - : Область применения и действия валидации ДОЛЖНЫ включать следующее: ...
  • - : Инциденты в эксплуатации ДОЛЖНЫ быть зарегистрированы и прослежены до разрешения проблем способом, допускающим своевременный отчет о реакции на отказ [c)]. ...
  • - : Идентификация неприемлемых результатов ДОЛЖНА включать оценку реакции на отказ [b)8)] и инициировать анализ процесса согласования изменений для улучшения системы [d)]. ...
  • - : Прослеживаемость эксплуатационных элементов ДОЛЖНА поддерживаться способом, допускающим быструю реакцию на отказ [b)] и своевременный отчет о реакции на отказ [c)]. ...
  • - : Поддержка потребителей ДОЛЖНА активно обеспечивать отчет о реакции на отказ [c)]. ...
  • - : Стратегия технического обслуживания ДОЛЖНА отражать цели защиты ключевых функций [a)2)] и цели обработки отказов и т.д. [a)5), b)]. ...
  • - : Идентификация будущих потребностей технического обслуживания ДОЛЖНА быть объединена с идентификацией и обнаружением неисправностей и т.д. [a)3), b)1)]. ...
  • - : Обработка случайных ошибок ДОЛЖНА быть объединена с анализом процесса реагирования на отказ [a), b), c), d)]. ...
  • - : Логистическая поддержка ДОЛЖНА быть включена в реакции на предшествующие отказу признаки [a)7), b)4)]. ...
  • - : Обучение персонала ДОЛЖНО быть запланировано как часть общих мер в соответствии с [a)8)] и ДОЛЖНО подготовить у заинтересованных сторон способность достигать [b)] посредством участия человека в соответствии с пониманием целей системы. Требования квалификации ДОЛЖНЫ включать требования к упомянутой выше способности. ...
  • - : Мониторинг эксплуатации системы ДОЛЖЕН включать мониторинг неисправностей, ошибок, отказов и предшествующих им причин в классах I) и II) [a)6)] для возможности их обнаружения в соответствии с [b)1)]. При обнаружении неисправностей и т.д. ДОЛЖНЫ быть выполнены процедуры стратегии эксплуатации, обеспечивающие получение результатов [от b)2) до b)7)], а их результаты ДОЛЖНЫ быть оценены [b)8)]. ...
  • - : Цели эксплуатации системы в непредвиденных обстоятельствах, необходимых для непрерывного выполнения функций, и условия, вызывающие эксплуатацию в непредвиденных обстоятельствах, ДОЛЖНЫ быть включены в цели защиты ключевых функций в [a)2)] и цели обработки неисправностей и т.д. в [a)5)]. ...
  • - : Результаты эксплуатации и аномалий ДОЛЖНЫ быть зарегистрированы способом, допускающим отчет о реакции на отказ [c)] и улучшение системы [d)]. ...
  • - : Инциденты и проблемы в эксплуатации ДОЛЖНЫ быть зарегистрированы и прослеживаться способом, допускающим отчет о реакции на отказ [c)] и улучшение системы [d)]. ...
  • - : Инциденты при техническом обслуживании ДОЛЖНЫ быть зарегистрированы и прослеживаться способом, допускающим отчет о реакции на отказ [c)] и улучшение системы [d)]. ...
  • - : Результаты технического обслуживания, результаты логистики и аномалии ДОЛЖНЫ быть зарегистрированы способом, допускающим отчет о реакции на отказ и улучшение системы [c), d)]. ...
  • - : Идентификация тенденций инцидентов и проблем ДОЛЖНА быть выполнена для улучшения жизненного цикла системы [d)]. ...
  • - : Прослеживаемость элементов технического обслуживания ДОЛЖНА поддерживаться способом, допускающим быструю реакцию на отказ [b)] и своевременный отчет о реакции на отказ [c)]. ...
  • - : ДОЛЖНА быть определена стратегия вывода из эксплуатации для выполнения [b)7)]. ...
  • - : Контроль удовлетворенности потребителя ДОЛЖЕН быть объединен с оценкой реакции на отказ [b)8)] и улучшения жизненного цикла системы [d)]. ...
  • Существует много видов изменений, которые требуют адаптации. Изменения возникают в других системах, связанных с данной системой. Из-за быстрого темпа нововведений достаточно часто происходят изменения в технологической, деловой и социальной средах. Обнаружение непредвиденных событий указывает на изменения в предположениях, которые всегда являются неполными и неточными. Изменения могут быть неочевидными; часто их необходимо выявлять с помощью, например, периодического анализа. Необходимая адаптация НЕ ОБЯЗАТЕЛЬНО ДОЛЖНА проходить непосредственно в исследуемой системе. При необходимости ДОЛЖЕН быть рассмотрен и приспособлен весь набор процессов жизненного цикла. Даже влияние и изменение окружающей среды могут быть адаптацией. ...
  • - : Инциденты и проблемы в эксплуатации ДОЛЖНЫ быть зарегистрированы и прослежены способом, допускающим отчет о реакции на отказ и улучшение системы [c), d)]. ...
  • Примечание 8 - Адаптация может быть технической или нетехнической. Весь набор процессов жизненного цикла проанализирован и адаптирован при необходимости. Адаптация НЕ ОБЯЗАТЕЛЬНО связана непосредственно с системой. Даже влияние и изменение окружающей среды может быть адаптацией. ...
  • - : Заинтересованным сторонам ДОЛЖНА быть обеспечена необходимая поддержка при обеспечении соглашения между покупателем и поставщиком с учетом измененного содержания [b)2)II)]. ...
  • - : Для адаптации изменений ДОЛЖНЫ быть идентифицированы необходимые изменения соглашения. Цель адаптации ДОЛЖНА быть представлена как модификация соглашения [b)3)]. ...
  • - : Заинтересованным сторонам ДОЛЖНА быть обеспечена необходимая поддержка при обсуждении соглашения между покупателем и поставщиком с учетом измененного содержания [b)2)II)]. ...
  • - : Для адаптации изменений ДОЛЖНЫ быть идентифицированы необходимые изменения соглашения. Цель адаптации ДОЛЖНА быть представлена как модификация соглашения [b)3)]. ...
  • - : Большое отклонение фактического продвижения в выполнении соглашения от запланированного ДОЛЖНО быть идентифицировано как изменение, которое также может требовать адаптации [a)1)]. ...
  • - : Большое отклонение фактического продвижения в выполнении соглашения от запланированного ДОЛЖНО быть идентифицировано как изменение, которое также может потребовать адаптации [a)1)]. ...
  • Анализ процесса аккомодации изменений ДОЛЖЕН быть выполнен с использованием действий и задач следующих процессов [1]. ...
  • - : Идентификация потенциально новых или измененных возможностей или назначения ДОЛЖНА быть выполнена как часть идентификации изменений и оценки их воздействия [a)1), b)1)]. ...
  • - : Оценка жизнеспособности проекта ДОЛЖНА быть выполнена как часть изменения идентификации и оценки статуса "пригодности использования" системы [a)1), b)1)]. ...
  • - : Оценка удовлетворенности потребителя ДОЛЖНА быть использована при оценке статуса "пригодности использования" системы [b)1)]. ...
  • - : Определение проекта в отношении системы, ответственностей и полномочий ДОЛЖНО быть совместимо с целью адаптации системы [b)2), b)3)]. ...
  • - : ДОЛЖНО быть получено разрешение на начало адаптации системы с определенной целью с учетом воздействия адаптации на другие проекты из портфолио организации [b)3), c)]. ...
  • - : Планирование корректирующих и предупреждающих действий в менеджменте качества ДОЛЖНО быть объединено с определением цели адаптации [b)2)]. ...
  • - : "Извлеченный урок" в одной итерации адаптации изменений ДОЛЖЕН быть включен в улучшение процесса для применения по отношению к будущим изменениям [e)]. ...
  • - : Менеджмент качества ДОЛЖЕН быть запланирован с учетом того, что цели менеджмента качества изменяются, когда цель системы и т.д. также изменяются [от a) до d)]. ...
  • - : Мониторинг статуса улучшения качества ДОЛЖЕН быть выполнен как часть признания и идентификации соответствующих изменений [a)] и оценки адаптированной системы [d)]. ...
  • - : Мониторинг корректирующих и предупреждающих действий ДОЛЖЕН быть использован при оценке адаптированной системы по отношению к цели адаптации [d)]. ...
  • - : Установленные модели жизненного цикла ДОЛЖНЫ устанавливать связи между процессами жизненного цикла, которые позволяют получить результаты анализа процесса аккомодации изменений [от a) до f)]. ...
  • <6.2.2> Процесс управления инфраструктурой: изменения в инфраструктуре проекта и требованиях к инфраструктуре ДОЛЖНЫ быть идентифицированы как изменения, которые могут потребовать адаптации системы [a)]. ...
  • - : Ожидаемые цели, задачи и результаты выполнения проекта ДОЛЖНЫ обеспечивать основу для оценки статуса "пригодности использования" системы и определения цели адаптации в отношении других проектов в портфолио [b)1), b)2)]. ...
  • - : Сбор и анализ результатов оценки обеспечения качества ДОЛЖНЫ быть выполнены как часть признания и идентификации соответствующих изменений [a)]. ...
  • - : Область применения проекта ДОЛЖНА включать действия по получению всех результатов анализа данного процесса [от a) до f)]. Планирование действий по управлению проектом (см. ) ДОЛЖНО предусматривать ситуацию изменения цели проекта [a)]. Изменения действий в пределах области применения проекта ДОЛЖНЫ быть признаны и идентифицированы [a)]. ...
  • - : Модель жизненного цикла данного проекта ДОЛЖНА определять связи процессов жизненного цикла, позволяющие получить все результаты анализа процесса аккомодации изменений [от a) до f)]. ...
  • - : Большое отклонение фактических результатов от плана ДОЛЖНО быть идентифицировано как изменение, которое, в свою очередь, может потребовать адаптации [a)1)]. ...
  • <6.2.6> Процесс менеджмента знаний ДОЛЖЕН поддерживать информацию об "извлеченных уроках" из каждой итерации адаптации изменений, чтобы обеспечить ее применение по отношению к будущим изменениям [c)2), e)]. ...
  • - : Обмен информацией о плане адаптации изменений ДОЛЖЕН позволять разработку соглашения о цели адаптации [b)3)] и ДОЛЖЕН быть использован при выполнении адаптации [f)]. ...
  • <6.3.2> Процесс оценки и управления проектом ДОЛЖЕН допускать получение всех результатов анализа процесса аккомодации изменений [от a) до f)]. В частности, этот процесс ДОЛЖЕН быть направлен на изменение технических целей, требований и бизнес-задач в целом. Это включает поддержку разработчиков вариантов адаптации, идентификации изменений проекта, предположений, рисков и других изменений, которые требуют адаптации системы и идентификации соответствующих технических или нетехнических средств. ...
  • : Оценка проекта ДОЛЖНА включать признание и идентификацию изменений [a)]. Проект ДОЛЖЕН быть исследован в отношении возможных изменений содержания, целей и планов проекта для оценки статуса "пригодности использования" системы [b)1)] и определять цель адаптации [b)2)]. ...
  • - : Анализ результатов измерений ДОЛЖЕН обеспечить идентификацию изменений и разработку рекомендаций по выполнению адаптации [a), b)2)]. ...
  • - : План проекта ДОЛЖЕН быть переработан в соответствии с согласованными целями адаптации и обновленным соглашением [b)3)]. ...
  • - : Задачи проекта ДОЛЖНЫ быть идентифицированы и обоснованы, что составляет основу оценки статуса "пригодности использования" при изменении [b)1)] и определении цели адаптации [b)2)]. ...
  • - : Критерии достижения в точке принятия решения на стадии жизненного цикла ДОЛЖНЫ включать критерий решения о выходе из стадии использования, которое инициирует анализ процесса аккомодации изменений [a)]. ...
  • - : Функции, обязанности, ответственность и полномочия для выполнения анализа процесса аккомодации изменений ДОЛЖНЫ быть определены способом, допускающим отчет об аккомодации изменений [f)]. ...
  • - : Изменения инфраструктуры и услуг, необходимых для выполнения проекта, ДОЛЖНЫ быть признаны и идентифицированы [a)]. ...
  • - : Менеджмент проекта, технический анализ, аудит и контроль ДОЛЖНЫ определить потребность и готовность к выполнению адаптации системы [a), b)]. ...
  • - : Стратегия менеджмента риска ДОЛЖНА быть направлена на изменения в менеджменте риска и включать процедуры анализа применяемых средств контроля риска, когда изменения признаны и идентифицированы [a), b)1), b)2)]. ...
  • - : Идентификация риска, связанного с изменениями, ДОЛЖНА быть выполнена как часть признания и идентификации изменений [a)1)]. ...
  • - : Представление данных о риске заинтересованным сторонам ДОЛЖНО быть выполнено как часть согласования целей адаптации и действий по адаптации [b)2), f)2)]. ...
  • - : Определение заинтересованными сторонами необходимости воздействия на риск, связанный с изменениями, ДОЛЖНО быть зафиксировано в обновленном соглашении заинтересованных сторон [b)3)]. Выполнение обработки риска, связанного с изменениями, является частью выполняемой адаптации [c)3)], [c)4)]. ...
  • - : Проект ДОЛЖЕН иметь разрешение на выполнение адаптации системы в соответствии с определенными целями [b)3), c)]. ...
  • - : Стратегия менеджмента принимаемых решений ДОЛЖНА быть направлена на изменения критериев решений в соответствии с изменениями содержания, предположений, рисков и т.д. проекта. Менеджмент принимаемых решений ДОЛЖЕН включать анализ прошлых решений, если они признаны и идентифицированы [b)1), b)2)]. ...
  • - : Условия применения менеджмента риска и процесс идентификации риска ДОЛЖНЫ учитывать риск, связанный с изменениями [a)]: ...
  • - : Пороги и критерии принятия риска, связанного с изменениями, ДОЛЖНЫ отражать воздействие изменений на статус "пригодности использования" системы [b)1)]. ...
  • - : Оценка последствий риска, связанного с изменениями, и ее сопоставление с пороговым риском ДОЛЖНЫ быть выполнены как часть оценки статуса "пригодности использования" системы [b)1)]. ...
  • - : Меры оценки результативности обработки риска ДОЛЖНЫ допускать оценку адаптированной системы [d)]. Мониторинг этих мер является частью признания и идентификации изменений [a)]. ...
  • - : Идентификация структуры информации о системе ДОЛЖНА учитывать вероятность того, что сама структура системы может быть непреднамеренно изменена вследствие неопределенности и неполноты системы или сознательно в процессе адаптации [a), f)]. ...
  • - : Верификация конечной конфигурации ДОЛЖНА поддерживать признание и идентификацию случайных изменений в системе вследствие неопределенности и неполноты системы [a)]. ...
  • - : Установление идентификаторов элементов конфигурации ДОЛЖНО обеспечивать прослеживаемость между введенными или измененными в процессе адаптации элементами конфигурации и изменениями, которых требует адаптация [f)]. ...
  • - : Исходное состояние ДОЛЖНО допускать признание и идентификацию изменений в системе в течение всего жизненного цикла системы [a)]. ...
  • - b)5)>: Соглашение между покупателем и поставщиком, которое устанавливает исходное состояние, ДОЛЖНО быть использовано для определения цели адаптации будущих изменений как обновлений исходного состояния [b)3)]. ...
  • - : Управление изменениями конфигурации ДОЛЖНО включать следующее: ...
  • - : Прослеживание и управление утвержденными изменениями следует выполнять с учетом адаптации [f)]. Обоснование адаптации ДОЛЖНО быть зарегистрировано как "извлеченные уроки" для применения по отношению к будущим изменениям [c)2)]. ...
  • - : Одобрение внедрения системы ДОЛЖНО соответствовать тому, что внедрение системы обеспечит минимальные нарушения в существующем обслуживании системы и в других связанных системах [c)5)]. ...
  • - : Отчет о статусе конфигурации ДОЛЖЕН обеспечивать поддержку прослеживаемости элементов конфигурации, а также обоснование изменений этих элементов [f)]. ...
  • <6.3.6> Процесс управления информацией ДОЛЖЕН обеспечивать: ...
  • - : Идентификация элементов конфигурации крайне важна для признания и идентификации изменений в системе [a)]. Элементы системы, изменение которых может потребовать адаптации системы, ДОЛЖНЫ быть идентифицированы как элементы конфигурации. Элементы конфигурации могут быть компонентами, представляемыми в виде черного ящика. ...
  • - : Потребности в информации ДОЛЖНЫ быть идентифицированы для признания и идентификации изменений [a)] и оценки статуса "пригодности использования" системы [b)1)]. ...
  • - : Оценка продукции и услуг ДОЛЖНА быть выполнена как часть оценки адаптированной системы по отношению к цели адаптации [d)]. ...
  • - : Сравнительная оценка процессов жизненного цикла проекта ДОЛЖНА допускать непрерывное усовершенствование жизненного цикла системы [e)]. ...
  • - : Стратегия организации ДОЛЖНА определять стартовые механизмы для периодического анализа проблем и возможности признания изменений, особенно в случае соответствующих событий [a)]. ...
  • - : сравнительная оценка вариантов альтернативных решений ДОЛЖНА дать информацию для принятия решения о начале адаптации системы [b)3)] и для определения возможных целей адаптации, как предпочтительных вариантов альтернативных решений [b)2)]. ...
  • - : Прослеживаемость результатов анализа деятельности или назначения до и после изменений ДОЛЖНА поддерживаться в дополнение к прослеживаемости между результатами анализа деятельности или назначения и артефактами в последующих стадиях жизненного цикла [d), e), f)]. ...
  • - : Идентификация заинтересованных сторон ДОЛЖНА поддержать менеджмент деструктивных изменений, в которых существующий список заинтересованных сторон может быть изменен [a),3)]. ...
  • Результат процесса анализа деятельности или назначения ДОЛЖЕН включать четкие соглашения между заинтересованными сторонами относительно возможности начала адаптации системы и целях адаптации в соответствии с [b)3), b)2)]. ...
  • - : Процесс определения требований и потребностей заинтересованных сторон ДОЛЖЕН быть утвержден всякий раз, когда это необходимо. Условия утверждения процесса такие же, как у процесса анализа деятельности или назначения. ...
  • - : Определение проблемы, пространства возможностей и пространства характеристик решения ДОЛЖНЫ сформировать основу для анализа воздействия изменений на статус "пригодности использования" системы и ДОЛЖНЫ быть частью возможных целей адаптации [b)1), b)2)]. ...
  • - : Стратегия определения требований и потребностей заинтересованных сторон ДОЛЖНА включать план проведения анализа, который признает изменения у идентифицированных заинтересованных сторон и определенные требования и потребности заинтересованных сторон. Такой анализ следует проводить периодически и всякий раз при необходимости [a)]. ...
  • - : Прослеживаемость между требованиями к системе до и после адаптации ДОЛЖНА поддерживаться [f)1)]. ...
  • - : Цель адаптации ДОЛЖНА быть представлена как обновление определения требований к системе и обоснования, отражающего изменения окружающей среды, включая системы, связанные с исследуемой системой [b)2)]. Обоснование ДОЛЖНО быть зарегистрировано, поддерживать оценку статуса "пригодности использования" системы [b)1)]; это помогает будущим адаптациям в качестве "извлеченных уроков" [c)2)]. ...
  • - <от a) до d)>: При необходимости ДОЛЖЕН быть выбран процесс определения требований к системе. Условия выбора такие же, как у процесса анализа деятельности или назначения. ...
  • - : Определение потребностей заинтересованных сторон, обоснование () и разработка концепций эксплуатации и других концепций жизненного цикла () ДОЛЖНЫ учитывать, что выходы формируют основу следующих действий, если изменения произойдут в будущем: ...
  • Потребности заинтересованной стороны и их обоснование ДОЛЖНЫ быть зарегистрированы способом, который помогает в будущей адаптации как "извлеченные уроки" [c)2)]. ...
  • - : Критические показатели работы, которые поддерживают оценку адаптации, ДОЛЖНЫ быть определены [d)]. ...
  • - : Цели адаптации и соглашение по ним ДОЛЖНЫ быть представлены как обновление определения требований заинтересованных сторон и четкого соглашения по требованиям заинтересованных сторон [b)3)]. ...
  • - : Определение функциональной границы (), стратегии определения требований к системе (), требований к системе () и анализ требований к системе () ДОЛЖНЫ быть выполнены, чтобы их выходные данные поддерживали анализ воздействия будущих изменений на статус "пригодности использования" системы [b)1)] и определение цели адаптации [b)2)]. ...
  • - : ДОЛЖНЫ быть идентифицированы требования к системе, которые относятся к риску, связанному с изменениями [a), b)1)]. ...
  • - : ДОЛЖНЫ быть определены критические показатели работы, допускающие оценку адаптированной системы по отношению к цели [d)]. ...
  • - : Обратная связь с компетентными заинтересованными сторонами относительно проанализированных требований ДОЛЖНА допускать обмен информацией с заинтересованными сторонами, поддержку заинтересованных сторон при переговорах и отчет об адаптации [b)2)I), b)2)II), f)]. ...
  • - : Соответствие цели адаптации ДОЛЖНО быть отражено при обновлении четкого соглашения относительно требований к системе [b)3)]. ...
  • - <от a) до f)>: При необходимости процесс определения структуры ДОЛЖЕН быть утвержден. Условия утверждения такие же, как и для процесса анализа деятельности или назначения. ...
  • - <от a) до d)>: При необходимости ДОЛЖЕН быть утвержден процесс определения проекта. Условия утверждения выбора такие же, как и для процесса анализа деятельности или назначения. ...
  • <6.4.6> Для оценки статуса "пригодности использования" системы ДОЛЖЕН быть использован процесс анализа системы [b)1)] и статус системы, адаптированной относительно цели адаптации [d)]. ...
  • - : Идентификация ключевых факторов структуры и озабоченностей заинтересованных сторон (), разработка точек зрения на структуру и модели рассматриваемых структур () ДОЛЖНЫ быть выполнены таким образом, чтобы выходные данные поддерживали анализ воздействия будущих изменений на статус "пригодности использования" системы [b)1)]. ...
  • - : Определенные критерии оценки структур, разработанных точек зрения на структуру, моделей рассматриваемых структур, результаты оценки рассматриваемых структур ДОЛЖНЫ допускать определение цели адаптации и согласование ее [b)2), b)3)]. ...
  • - : Определение необходимых технологий и типов необходимых характеристик проекта () и оценка альтернатив получения элементов системы () ДОЛЖНЫ быть выполнены так, чтобы их выходные данные поддерживали анализ воздействия будущих изменений на статус "пригодности использования" системы [b)1)]. ...
  • - : Установленные характеристики проекта, возможности проекта и результат оценки альтернатив получения элементов системы ДОЛЖНЫ допускать определение цели адаптации и ее согласование [b)2)]. ...
  • - : Для адаптации изменений в будущем и улучшения жизненного цикла системы [e)] ДОЛЖНА быть использована регистрация знаний об эксплуатации [c)2)]. ...
  • - : Подтверждение того, что вредные для здоровья факторы и т.д. после утилизации элементов системы отсутствуют, ДОЛЖНО быть учтено при адаптации [f)]. ...
  • <6.4.9> Процесс верификации ДОЛЖЕН использоваться для оценки адаптированной системы по отношению к цели адаптации [d)] и для признания и идентификации изменений [a)] при выполнении различных видов анализа или оценки проекта и процесса управления, проводимых периодически. ...
  • <6.4.11> Процесс валидации ДОЛЖЕН быть использован для оценки адаптированной системы относительно цели адаптации [d)] и для признания и идентификации изменений [a)] в различных видах анализа, проводимых периодически или при оценке проекта и процесса управления. ...
  • - Следующие действия ДОЛЖНЫ быть выполнены как часть признания и идентификации изменений [a)]: ...
  • - Следующие действия ДОЛЖНЫ быть выполнены как часть подготовки к ...
  • - : Проблемы технического обслуживания и эксплуатации ДОЛЖНЫ быть решены при помощи выбора соответствующих процессов [b), c), d), e)]. ...
  • - : Архивированная информация, собранная за весь период функционирования системы, ДОЛЖНА быть учтена при адаптации [f)] и зарегистрирована для использования в будущем при изменениях [c)2)]. ...
  • a) Цикл адаптации изменений начинают, если система ДОЛЖНА быть модифицирована в соответствии с изменением ее целей, задач, окружающей среды или фактического изготовления, цикл охватывает стадию достижения консенсуса, стадию разработки и стадию обеспечения ответственности. ...
  • Примечание 1 - Процессы жизненного цикла [1] применены одновременно, итеративно и рекурсивно к системе и на определенных этапах к ее элементам (см. <1.3> и <5.7>). Это особенно характерно для открытых систем. Так как открытая система непрерывно обновляется и изменяется, процессы, упомянутые выше, ДОЛЖНЫ быть повторены несколько раз после того, как система была введена в эксплуатацию. ...
  • Примечание - В приложении B цели, приведенные в рамочках с пунктирными границами, ДОЛЖНЫ быть проработаны далее в отдельных диаграммах. ...
  • Конкретный пример доказательства для данного жизненного цикла системы получен при помощи дальнейшей разработки и конкретизации целей и обеспечения свидетельств (решений) выполнения неделимых целей. Описания целей и стратегий ДОЛЖНЫ быть исследованы на соответствие и достаточность в данной ситуации, структуру доказательств необходимо изменить и увеличивать при необходимости. Данный пример не содержит образцы текста и доказательств, которые также ДОЛЖНЫ быть добавлены при необходимости. ...
  • Эта цель обоснована с точки зрения подготовки, которая происходит до возникновения событий, которые нужно учитывать, и фактического выполнения при возникновении событий, включая мониторинг (см. рисунок B.5). Подготовка, которая определяет, какой ДОЛЖНА быть взаимосвязь, включает идентификацию и определение необходимых элементов [6.3.2 от a) до e)] (см. рисунок B.6). Цели выполнения разделены на две группы: цели, которые в пределах системы [от f) до h)] (см. рисунок B.7), и цели, которые ДОЛЖНЫ быть получены за пределами системы [i), i)1), i)2), i)3), i)4), i)5)] (см. рисунок B.8). ...
  • Эту цель разделяют на цель адаптации системы к изменениям и на цель долгосрочной поддержки постоянного улучшения жизненного цикла системы, уверенности и доверия общества к системе. Доказательством первой цели являются идентификация изменений [6.5.2 a)], подготовка к адаптации [b)], выполнение адаптации [c)] и оценка [d)] (см. рисунок B.15). Цель идентификации изменений разделяют на цели идентификации типов изменений для наблюдений [a)1) - a)3)] (см. рисунок B.16). Доказательством выполнения цели подготовки к адаптации являются выполнение необходимых действий [b)1) - b)3)] (см. рисунок B.17). Цель выполнения адаптации рассмотрена с двух точек зрения: доступности необходимой поддержки [c)1), c)2)] и выполнения необходимых действий адаптации [c)3) - c)5)] (см. рисунок B.18). Первая часть цели постоянного улучшения оставлена неразработанной, но она ДОЛЖНА быть разработана в условиях конкретной модели жизненного цикла, включая подробное описание, каким образом одна итерация анализа процесса адаптации изменений достигает длительных воздействий на будущие улучшения. Другая часть цели поддержка уверенности и доверия общества к системе является примером обеспечения ответственности для адаптации [f)], доказательством является доступность выполнения входных данных для анализа процесса обеспечения ответственности и то, что эти данные фиксируют в отчете об адаптации [f)1), f)2)] (см. рисунок B.15). ...
  • Электроэнергию очень трудно хранить. Это означает, что цена может быть отрицательной в периоды чрезмерной поставки, то есть поставщик ДОЛЖЕН заплатить, чтобы поставлять электроэнергию. ...
  • Для жизненного цикла интеллектуальной электросети ДОЛЖНЫ быть созданы и поддерживаться свидетельства надежности, соответствующие 5. В C.3 показан возможный набор этапов этой работы, а также вопросы, которые ДОЛЖНЫ быть рассмотрены на каждом этапе в случае интеллектуальной электросети. Ниже приведены девять этапов из описания свидетельств надежности в [5]. ...
  • У оператора сети ДОЛЖНЫ быть контракты со многими поставщиками и дистрибьюторами электроэнергии. Это могут быть крупные электростанции (угольные, атомные или гидроэлектрические) в их собственной стране или за рубежом. У них также могут быть контракты с операторами сети в разных странах. Оператор сети может покупать электроэнергию через дистрибьюторов у частных владельцев ветряных двигателей и парков солнечных батарей. Поставщик может быть потребителем или консорциумом. Все эти контракты содержат требования, которым ДОЛЖНО соответствовать программное обеспечение. Например, требования о том, кто может поставлять электроэнергию, когда и по какой цене. Эта цена может быть различной для дня, ночи, времени года. ...
  • Оператор сети также имеет контракт с дистрибьюторами, покупающими электроэнергию на рынке (по постоянной или по переменной цене) и продающими электроэнергию потребителям. Это также ДОЛЖНО быть отражено в программном обеспечении интеллектуальной электросети. ...
  • После подготовки этапов 1 и 2 основная часть формирования свидетельств надежности начинается с определения требования высшего уровня. Использованная формулировка показывает связь с надежностью открытых систем. Чтобы определить это требование, надо установить его интерпретацию для интеллектуальной электросети посредством определений терминов (таких как "система", "непрерывность обслуживания") и разработки четкого текста. Энергосистема ДОЛЖНА иметь наименьшую продолжительность неработоспособного состояния, сохранять установленные напряжение и частоту в сети при всех условиях нагрузки. Эти цели кодируют в виде формулировки требований высшего уровня. ...
  • Детали, установленные на этапе 3, и их связь с требованием высшего уровня четко зарегистрированы в свидетельствах надежности. Если [10] используется как в приложении B, свидетельства обеспечивают ссылки на документацию о деталях. Для интеллектуальной электросети: "энергосистема ОБЯЗАНА иметь готовность 0,99997"; "в 98% случаев периоды неработоспособного состояния ДОЛЖНЫ быть менее 1 ч"; "напряжение, частота, их скачки и перебои ДОЛЖНЫ удовлетворять установленным требованиям в течение 99,8% времени"; "определения терминов в соответствии с [2] и [14]"; "географическим районом, охваченным энергосистемой, является Северная Европа с температурой, осадками, ветром и солнечным излучением в соответствии с [21]". ...
  • После того как общая структура доказательств определена, документы, необходимые для каждого довода, ДОЛЖНЫ быть приложены. Классификацию документов исходной и выходной информации за весь жизненный цикл интеллектуальной электросети проводят на этом этапе. ...
  • ДОЛЖНЫ быть разработаны доказательства в контексте приложенных документов в соответствии с этапом 6. Стратегии обоснования часто включают обычные процедурные проверки сложного текста и свидетельств. Указания, какая стратегия использована, часто недостаточно, чтобы восполнить расхождения между целью стратегии и ее подцелями и/или свидетельствами. В таком случае стратегии обоснований расширяют до элемента свидетельств надежности, который объясняет результат выполнения процедуры, в данном случае свидетельство надежности, основанное на содержании документов. Эти элементы свидетельств надежности часто получают автоматически, если документы хорошо структурированы. ...
  • Свидетельства надежности ДОЛЖНЫ часто обновляться, так как система является открытой. ...
  • Это требует повторного контролируемого подключения поставщиков и потребителей. Основная часть этих действий может быть выполнена автоматически или полуавтоматически при наличии программных модулей контроля эксплуатации. Обнаружение (или прогнозирование) отказа начинает этап реакции на отказ, который состоит из предотвращения отказа, реакции на отказ и анализа причин отказа. Реакция на отказ описана выше. Анализ причин отказа - это действия по определению причин отключения электроснабжения (см. [22]). Некоторые типичные причины описаны выше. Предотвращение отказа включает, например, переход от линий электропередач на опорах к кабелям, профилактическому обслуживанию трансформаторных станций. Предотвращению отказа также помогает создание карт соединений кабелей для учета при земляных работах и ЗАПРЕТ на постановку судов на якорь около подводных кабелей. ...
  • Первым действием при нарушении электроснабжения ДОЛЖНА быть изоляция проблемы таким образом, чтобы она не распространилась дальше по системе. Может потребоваться отключение части системы для уменьшения нагрузки. В крайних случаях может возникнуть необходимость замены сети на определенном участке, то есть управления системой как обычной системой без поставки или доставки в закрытой области. Цель действий реакции на отказ состоит в том, чтобы восстановить электроснабжение всех потребителей за самое короткое время. ...
  • Для открытой системы обнаружение аномалии является очень важным действием. Модуль наблюдения за программным обеспечением ДОЛЖЕН непрерывно выявлять аномальные действия. Такое наблюдение ДОЛЖНО прежде всего обнаруживать попытки проникновения в сеть и управления программным обеспечением при помощи вредоносных программ. Это может произойти через потребителей, у которых есть соединение сети с Интернетом, домашними устройствами, потребляющими мощность и производящими мощность, а также связь с согласованием цен, поставок и бухгалтерской подсистемой. Обнаружение аномалии также ДОЛЖНО искать некорректный бухгалтерский учет, такой как чрезмерный денежный перевод и внезапные изменения в потреблении или поставке от потребителя. Это непрерывное обнаружение аномалии также очень важно для открытых систем, для закрытых систем со встроенным программным обеспечением это менее важно. ...
  • Операторы открытой системы ДОЛЖНЫ поддерживать круглосуточную готовность к изоляции потенциальных вредоносных программ, анализу и удалению угрозы. Эти действия могут включать размещение некоторых адресов, например адресов потребителей, в карантин до тех пор, пока проблема не будет проанализирована и решена. Решение может включать соединение с циклами адаптации изменений посредством сбора информации о требовании анализа риска, согласования с заинтересованными сторонами и разработки блоков программного обеспечения (проект, реализация, проверка и тестирование). ...
  • IEC 60050-192, International Electrotechnical Vocabulary - Part 192: Dependability (available at electropedia.org) ...

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

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

« все документы

Телеграм-канал
Подпишитесь и читайте
новости промбезопасности Оставить заявку
Если вы хотите, чтобы
мы выполнили работу Узнать стоимость
Если вы хотите просто
сравнить стоимость работ Коммерческое предложение
Документ, чтобы заложить
бюджет или НМЦ для тендера Пригласить на тендер
Если идет тендер и
нужны еще участники