Руководство по обеспечению надежности - RukovodstvoRus.ru - инструкции пользования и руководства

ГОСТ Р МЭК 62628-2021

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Надежность в технике

РУКОВОДСТВО ПО ОБЕСПЕЧЕНИЮ НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Dependability in technics. Guidance on provision of software dependability

ОКС 03.120.01

Дата введения 2022-01-01

Предисловие

1 ПОДГОТОВЛЕН Закрытым акционерным обществом «Научно-исследовательский центр контроля и диагностики технических систем» (ЗАО «НИЦ КД») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 119 «Надежность в технике»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 21 сентября 2021 г. N 990-ст

4 Настоящий стандарт идентичен международному стандарту МЭК 62628:2012* «Руководство по обеспечению надежности программного обеспечения» (IEC 62628:2012 «Guidance on software aspects of dependability», IDT).

Международный стандарт разработан Техническим комитетом IEC/TC 56.

Наименование настоящего стандарта изменено относительно наименования указанного международного документа для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

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

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ «О стандартизации в Российской Федерации«. Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)

Введение

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

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

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

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

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

Настоящий стандарт не предназначен для оценки соответствия или сертификации.

1 Область применения

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

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты [для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных — последнее издание (включая все изменения)]:

IEC 60050-191, International Electrotechnical Vocabulary — Chapter 191: Dependability and quality of service (Международный электротехнический словарь. Глава 191. Надежность и качество услуг)

IEC 60300-3-15, Dependability management — Part 3-15: Application guide — Engineering of system dependability (Менеджмент надежности. Часть 3-15. Прикладное руководство. Разработка надежности систем)

3 Термины, определения и сокращения

В настоящем стандарте применены термины по МЭК 60050-191, а также следующие термины с соответствующими определениями:

3.1 Термины и определения

3.1.1 программное обеспечение (software): Программы, процедуры, правила, документация и данные системы обработки информации.

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

Примечание 2 — Для работы программного обеспечения, выполнения программ, хранения и передачи данных необходимы аппаратные средства.

Примечание 3 — Типы программного обеспечения охватывают прошивку, системное программное обеспечение и прикладное программное обеспечение.

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

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

ПРИМЕР — Базовая система ввода/вывода (BIOS) персонального компьютера.

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

3.1.3 встроенное программное обеспечение (embedded software): Программное обеспечение, применяемое в системе, основная цель которой не является вычислительной.

ПРИМЕР — Программное обеспечение, используемое в системе управления двигателем или в системах управления тормозами транспортных средств.

3.1.4 программный блок; программный модуль (software unit, software module): Элемент программного обеспечения, который может быть отдельно скомпилирован в программных кодах для выполнения задачи или действия по достижению желаемого результата функции или функций программного обеспечения.

Примечание 1 — Термины «модуль» и «блок» часто используют как синонимы или как субэлементы друг друга (по-разному) в зависимости от контекста. Взаимосвязь этих терминов еще недостаточно стандартизирована.

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

3.1.5 объект конфигурации программного обеспечения (software configuration item): Объект программного обеспечения, скомпонованный и рассматриваемый как единый объект в процессе управления конфигурацией.

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

3.1.6 функция программного обеспечения (software function): Элементарная операция, выполняемая модулем или блоком программного обеспечения в соответствии с установленными требованиями.

3.1.7 система программного обеспечения (software system): Определенный набор объектов программного обеспечения, которые интегрированы и совместно работают в соответствии с установленными требованиями.

ПРИМЕР — Прикладное программное обеспечение (программное обеспечение для учета и управления информацией); программное обеспечение для программирования (программное обеспечение для анализа работы и методов CASE), системное программное обеспечение (программное обеспечение для контроля и управления компьютерной системой, такой как операционные системы).

3.1.8 надежность программного обеспечения (software dependability): Способность программного блока работать в составе системы в соответствии с установленными требованиями.

3.1.9 неисправность программного обеспечения, ошибка (software fault, bug): Состояние объекта программного обеспечения, препятствующее его работе в соответствии с установленными требованиями.

Примечание 1 — Неисправности программного обеспечения — это ошибки спецификации, проектирования, программирования, встроенного компилятора или неисправности, возникшие при обслуживании программного обеспечения.

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

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

3.1.10 отказ программного обеспечения (software failure): Отказ, представляющий собой проявление неисправности программного обеспечения.

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

3.1.11 код (code): Символьная или битовая комбинация, которой присваивают определенное значение для представления компьютерной программы на языке программирования.

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

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

Примечание 3 — Язык программирования — это язык, используемый для записи компьютерных программ.

3.1.12 (компьютерная) программа ((computer) program): Набор закодированных инструкций, предназначенных для выполнения установленных логических и математических операций с данными.

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

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

3.2 Сокращения

В настоящем стандарте применены следующие сокращения:


ASIC	— интегральная схема для конкретного применения;
CASE	— автоматизированная разработка программного обеспечения;
CMM	— модель зрелости возможностей;
CMMI	— комплексная модель зрелости;
COTS	— приобретаемая продукция;
FMEA	— анализ видов и последствий отказов;
FTA	— анализ дерева неисправностей;
IP	— интернет-протокол;
IT	— информационные технологии;
KSLOC	— тысяча строк исходного кода;
ODC	— классификация ортогональных дефектов;
RBD	— структурная схема надежности;
USB	— универсальная последовательная шина.

4 Анализ аспектов надежности программного обеспечения

4.1 Программное обеспечение и системы программного обеспечения

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

В комбинированной аппаратно-программной системе блоки программного обеспечения системы выполняют две основные функции: a) операционное программное обеспечение для обеспечения непрерывной работы аппаратных элементов системы; b) прикладное программное обеспечение, которое запускают, как и когда это требуется по запросам пользователя для предоставления потребителю определенных услуг. Анализ надежности подсистем программного обеспечения должен учитывать факторы времени применения программного обеспечения в профиле эксплуатации системы и те элементы программного обеспечения, которые необходимы для работы системы в течение всего времени ее работы. Моделирование программного обеспечения необходимо для распределения вероятности безотказной работы по компонентам системы и оценки надежности систем, основанных на применении программного обеспечения.

Аспекты надежности человеческого фактора [1] играют ключевую роль в результативном проектировании и разработке программного обеспечения. Интерфейс человек-машина и операционная среда влияют на результат взаимодействия программного и аппаратного обеспечения и влияют на надежность работы системы. Это приводит к стратегической потребности в разработке надежного программного обеспечения и приложению усилий по сопровождению программного обеспечения в процессе жизненного цикла [2].

4.2 Надежность и организация работы программного обеспечения

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

— политика менеджмента надежности и техническое управление надежностью;

— процессы проектирования и разработки;

— конкретные требования проекта и условий применения.

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

Обычно такие организации:

a) разрабатывают программное обеспечение как основную продукцию;

b) разрабатывают аппаратное обеспечение со встроенным программным обеспечением;

c) осуществляют сопровождение программных средств у потребителей;

d) эксплуатируют и обслуживают системы и сети программного обеспечения.

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

4.3 Связь надежности программного обеспечения с надежностью аппаратных средств

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

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

Системы программного обеспечения и аппаратные объекты имеют много общего. Они проходят стадию проектирования и разработки, за которой следуют интеграция, испытания и производство (изготовление). Обнаружение отказов и скрытых неисправностей происходит в результате тщательного анализа, процессов тестирования и верификации с высоким уровнем охвата тестированием отказов. Высокий уровень охвата процессом проверки (тестирования) определяет оценка процента обнаружения неисправностей или вероятности обнаружения неисправностей. Хотя методы управления похожи, существуют и различия [5], [6]. Ниже приведены некоторые примеры:

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

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

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

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

4.4 Взаимодействие программного обеспечения и аппаратных средств

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

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

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

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

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

5 Надежность программного обеспечения: разработка и применение

5.1 Структура жизненного цикла системы

Организация должна установить структуру жизненного цикла системы, в соответствии с которой будет проведена разработка продукции и изготовление системы. Структуру используют для определения жизненного цикла системы и управления работой процессов жизненного цикла системы. В МЭК 60300-3-15 приведено описание обеспечения надежности системы и реализации жизненного цикла, основанное на технических процессах ИСО/МЭК 15288 [7]. Данную структуру применяют ко всем системам, состоящим из аппаратных средств, программных средств или и тех и других.

5.2 Обеспечение надежности программного обеспечения

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

Деятельность по обеспечению надежности должна быть интегрирована в планы проекта и включена в задачи разработки системы для эффективного проектирования, изготовления, внедрения, эксплуатации и обслуживания системы. К настоящему стандарту также может быть применено руководство по проектированию надежности систем, установленное в МЭК 60300-3-15. Руководство по обеспечению надежности программного обеспечения состоит из следующих рекомендуемых процедур:

a) определение целей применения программного обеспечения и требований, относящихся к жизненному циклу программного обеспечения (см. 5.3) и условиям его применения (см. А.2);

b) определение применимых показателей надежности программного обеспечения (см. 5.4), относящихся к проекту программного обеспечения;

c) анализ адекватности процессов управления надежностью и наличия ресурсов для поддержки разработки проекта и изготовления программного обеспечения (см. 5.5);

d) установление требований к программному обеспечению и целей обеспечения надежности (см. 5.6, приложение В);

e) классификация неисправностей программного обеспечения (см. 5.7) и определение соответствующих параметров программного обеспечения (см. 6.2, приложение Е) для реализации стратегии обеспечения надежности программного обеспечения (см. 5.8);

f) применение соответствующих методов надежности при проектировании и изготовлении программного обеспечения (см. 6.1, 6.3);

g) инициирование повышения надежности, если применимо, с учетом различных ограничений при адаптации проекта (см. 6.4, 7.2);

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

5.3 Действия жизненного цикла программного обеспечения

Жизненный цикл программного обеспечения включает в себя:

— определение требований системы одновременно к элементам аппаратного и программного обеспечения в соответствии с потребностями пользователей и ограничениями в применении системы;

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

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

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

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

— кодирование программных блоков;

— модульное тестирование для проверки программного блока на соответствие требованиям проекта;

— проверку подсистемы для верификации функций программного обеспечения на соответствие требованиям проекта;

— интеграцию, в процессе которой собирают программные блоки и подсистемы в соответствии с конфигурацией структуры проекта и устанавливают программную систему в аппаратную систему для тестирования;

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

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

— квалификационные испытания для подтверждения приемки системы программного обеспечения и поставки ее заказчику;

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

— обновление/улучшение программного обеспечения, направленное на улучшение работы программного обеспечения за счет расширения его свойств;

— распоряжение программным обеспечением и прекращение поддержки конкретной услуги программного обеспечения.

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

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

Рисунок 1 — Действия жизненного цикла программного обеспечения

5.4 Свойства надежности программного обеспечения

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

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

— готовность: подготовленность к работе программного обеспечения;

— безотказность: непрерывность оказания услуг программным обеспечением;

— ремонтопригодность: простота модификации, обновления и улучшения программного обеспечения;

— восстанавливаемость: восстановление программного обеспечения после отказа с внешними действиями или без них;

— целостность: корректность данных программного обеспечения.

Свойства, относящиеся к конкретному применению системы, способствующие достижению целей надежности системы, включают (но не ограничиваются):

— защищенность: защита от вторжения при применении и использовании программного обеспечения;

— безвредность: для предотвращения вреда при применении и использовании программного обеспечения;

— работоспособность: робастность, отказоустойчивость и бесперебойная работа;

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

— поддержку: поддержание работы системы с помощью ресурсов логистики и обслуживания;

— переносимость: кроссплатформенные применения.

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

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

Целью менеджмента надежности является обеспечение сбалансированных условий проектирования для творчества в рамках ресурсов бюджета, графика и поставленных целей проекта. Организации, связанные с разработкой программного обеспечения и предоставлением программных услуг, ориентированы на пользовательские приложения. Адаптация проектов программного обеспечения необходима для управления распределением доступных ресурсов и поиска подходящих вариантов проекта для его эффективного выполнения. Выбор и принятие применимых процессов для обеспечения надежности конкретной системы программного обеспечения осуществляют с помощью процесса адаптации проекта. Рекомендуемые задачи процесса адаптации приведены в 7.2. Следует изучить возможности аутсорсинга, повторного использования программного обеспечения и применения готовых коммерческих программных продуктов (COTS) для интеграции системы при проектировании.

Условия разработки программного обеспечения опираются на организованный процесс продвижения передовых методов проектирования для безошибочного кодирования, минимизации ошибок при определении требований и обеспечении верификации испытаний при выпуске программного обеспечения. Культурные аспекты в управлении программным обеспечением часто принимают форму концепции модели зрелости возможностей для разработки инфраструктуры [8]. Это похоже на формальную реализацию интеграции модели зрелости [9], описанную в приложении С для управления процессами программного обеспечения. Разработка программного обеспечения — это технический процесс в соответствии с установленными правилами разработки программного обеспечения и рекомендациями по его применению. Условия и принципы разработки программного обеспечения должны быть включены в политику организации, по установлению его целей и задач достижения надежности.

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

5.6 Установление требований к программному обеспечению и целей в области надежности

Для стадий жизненного цикла программного обеспечения должны быть установлены требования к программному обеспечению. Для каждой стадии должны быть определены применимые действия по обеспечению надежности. Установление сроков выполнения действий по обеспечению надежности очень важны. Применение действий по обеспечению надежности зависит от времени и оказывает значительное влияние на стоимость жизненного цикла системы [10]. Адаптация проекта необходима для поиска компромиссных вариантов проектов с учетом ограничений. Требования к программному обеспечению и цели обеспечения в области надежности должны быть частью общих спецификаций на программный продукт. Стратегия реализации надежности программного обеспечения описана в 5.8. Методология обеспечения надежности в программных модулях или блоках при построении структуры системы программного обеспечения рассмотрена в разделе 6. Процесс адаптации описан в 7.2.

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

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

— культуру проектирования организации, процесс развития возможностей и опыт проектирования, разработки и изготовления программного обеспечения (см. приложение С);

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

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

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

— эффективное использование применимых методов и приемов программирования, таких как структурированное проектирование, обеспечение устойчивости к неисправностям, документальный анализ проекта [12] и управление неисправностями программного обеспечения, для повышения его надежности;

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

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

5.7 Классификация неисправностей программного обеспечения

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

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

Классификация ортогональных дефектов (ODC) [13] — это метод, используемый при разработке программного обеспечения для анализа данных о неисправностях (дефектах) программного обеспечения. ODC направлена на анализ проблем качества программного обеспечения, касающихся его проектирования и кодирования в процедурной языковой среде. Дефект — это невыполнение требования, связанного с предполагаемым или установленным использованием программного обеспечения. В настоящем стандарте неисправность, вызванная неспособностью программного обеспечения выполнять требуемые функции, демонстрирует характеристики атрибута дефекта в схеме ODC. Атрибут дефекта — это описание, содержащее соответствующую информацию, связанную с неисправностью программного обеспечения. Метод ODC собирает информацию о неисправности программного обеспечения в виде дефекта для анализа и моделирования. Анализ данных ODC представляет собой ценный метод диагностики для оценки зрелости программного продукта на различных стадиях жизненного цикла программного обеспечения. ODC также можно использовать для оценки процесса путем анализа типов триггеров и определения конкретных технических потребностей для стимулирования отсутствующих триггеров. Данные анализа причин неисправностей (дефектов) представляет собой способ снижения количества неисправностей программного обеспечения и повышения его надежности.

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

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

В приложении D представлена классификация атрибутов дефектов программного обеспечения.

5.8 Стратегия обеспечения надежности программного обеспечения

5.8.1 Предотвращение неисправностей программного обеспечения

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

a) Предотвращение неисправностей:

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

— инициирование анализа спецификаций требований;

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

— введение формальных методов, где это применимо и практически осуществимо;

— внедрение систематических методов повторного использования программного обеспечения и гарантии его применения.

b) Устранение неисправностей:

— обнаружение и устранение существующих неисправностей программного обеспечения путем тестирования (испытаний);

— проведение документальной проверки по выявлению неисправностей, их исправления и проверки результатов исправлений;

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

5.8.2 Контроль неисправностей программного обеспечения

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

a) Обеспечение устойчивости к неисправностям:

— разработка методологии локализации, обнаружения и устранения неисправностей;

— выполнение различных вариантов проекта программного обеспечения и схем снижения скорости передачи данных;

— введение многовариантных методов программирования;

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

b) Прогнозирование неисправностей (отказов):

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

— создание системы сбора данных;

— проведение испытаний на повышение надежности, где это применимо;

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

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

6 Методы обеспечения надежности при применении программного обеспечения

6.1 Практика разработки программного обеспечения для достижения надежности

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

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

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

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

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

e) использование методов разработки надежного программного обеспечения [14] для оценки и повышения надежности программного обеспечения [15];

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

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

h) тестирование программных блоков и подсистем для верификации функций на низком уровне проекта и валидация работы интегрированной системы со структурой высокого уровня для постепенного устранения ошибок и предотвращения распространения неисправностей;

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

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

k) анализ первопричин проблем и выполнение соответствующих корректирующих действий для постоянного улучшения программного обеспечения;

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

6.2 Показатели надежности программного обеспечения и сбор данных

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

a) Коэффициент готовности: вероятность работоспособного состояния в конкретный момент времени в течение периода работы системы.

b) Частота отказов: количество отказов за время работы системы.

c) Наработка до отказа: продолжительность безотказной работы.

d) Время восстановления: продолжительность периода восстановления системы из неисправного состояния (неработоспособного состояния) в состояние нормальной работы (работоспособное состояние).

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

f) Функциональная точка: функциональный размер применения программного обеспечения для планирования проекта программного обеспечения с помощью метода анализа функциональных точек [16].

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

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

i) Остаточные неисправности программного обеспечения: оценка количества ошибок, которые все еще остаются в программном продукте после тестирования.

j) Время выпуска программного обеспечения: оценка времени выпуска программного продукта в соответствии с графиком, на основе установленных критериев с приемлемым уровнем ошибок, оставшихся в программном средстве для управления проектом программного обеспечения.

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

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

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

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

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

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

В приложении Е представлены примеры данных о программном обеспечении, полученных при сборе данных.

6.3 Оценка надежности программного обеспечения

6.3.1 Процесс оценки надежности программного обеспечения

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

— определение потребностей пользователей, цели работы системы и разработка спецификации надежности;

— установление профиля эксплуатации программного обеспечения;

— распределение применимых показателей надежности;

— выполнение анализа и оценки надежности для определения вариантов и возможных решений;

— проведение тестирования (испытаний) программного обеспечения и его параметров;

— проведение верификации программного обеспечения и валидации системы программного обеспечения;

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

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

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

6.3.2 Спецификация работы системы и ее надежности

Цель состоит в определении цели работы системы для разработки спецификации надежности системы [11], если она не представлена заказчиком или пользователем. Рекомендуется следующий процесс:

— определение сценариев работы системы и условий ее применения;

— определение соответствующих факторов, влияющих на работу системы;

— определение границ системы и интерфейсов с внешними взаимодействующими системами;

— определение соответствующих параметров работы системы;

— определение структуры системы, конфигурации аппаратных и программных средств;

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

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

Документация спецификации надежности системы должна включать в себя следующие данные как часть спецификации системы:

— идентификацию системы;

— цель работы системы;

— профиль эксплуатации системы;

— цели надежности системы при эксплуатации;

— конфигурацию системы;

— функции системы;

— требования к надежности для каждой функции;

— требования к сопровождению системы.

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

6.3.3 Установление профиля эксплуатации программного обеспечения

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

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

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

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

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

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

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

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

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

6.3.4 Распределение показателей надежности

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

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

6.3.5 Анализ и оценка надежности

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

a) Моделирование коэффициента готовности и вероятности безотказной работы функций.

Простой подход к анализу коэффициента готовности и вероятности безотказной работы системы, состоящей из аппаратного и программного обеспечения, заключается в формировании структурной модели системы. Функциональная модель коэффициента готовности и вероятности безотказной работы для комбинированной аппаратно-программной системы, состоящей из функциональных блоков, может быть построена с использованием метода структурной схемы надежности (RBD) [17]. Модель выполняет декомпозицию системы на отдельные модели подсистем, представляющие составляющие аппаратные и программные элементы системы: анализ дерева неисправностей (FTA) [18], цепи Маркова [19] и сети Петри [20] также полезны для разработки моделей коэффициента готовности и вероятности безотказной работы системы. Например, FTA может быть использован для моделирования надежности системы с помощью динамических вентилей, что позволяет определить функции коэффициента готовности и вероятности безотказной работы аппаратного и программного обеспечения для поиска компромиссных решений и улучшений [21]. Следует отметить, что RBD и FTA логически эквивалентны. RBD ориентирован на успех системы, а FTA — на отказ системы.

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

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

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

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

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

Функции программного обеспечения, составляющие систему, относятся к синхронизации и топологии безотказности.

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

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

c) Опорное время выполнения функции программного обеспечения.

Интенсивность отказов программного обеспечения может быть выражена относительно трех разных параметров времени.

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

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

— Календарное время — это период времени, используемый для планирования и составления графика выполнения проекта. Календарное время всегда больше первых двух параметров.

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

d) Критичность функции программного обеспечения.

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

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

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

Анализ дерева неисправностей [18] можно использовать для выявления возможных причин нежелательной вершины событий. FTA используют для исследования возможных неисправностей и их причин, а также для количественной оценки их вклада в коэффициент неготовности системы. Анализ дерева неисправностей — это нисходящий технический подход, где отправной точкой является программа подсистемы высшего уровня, которая следует по иерархической структуре программного обеспечения до самого низкого программного модуля. Для возможных неисправностей могут быть индивидуально идентифицированы и оценены соответствующие вероятности возникновения неисправностей. Количественная оценка обеспечивает признаки или величину критичности функции программного обеспечения. Это представляет интерес для оптимизации проекта и предотвращения неисправностей.

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

Другие методы анализа надежности системы [24] используют для декомпозиции программного обеспечения и моделирования системы. Их можно выборочно использовать для подробной оценки показателей безотказности и ремонтопригодности функций программного обеспечения в комбинированных аппаратно-программных системах.

Уровень целостности программного обеспечения — это показатель, отражающий уникальные для проекта характеристики, которые определяют значимость программного обеспечения для пользователя. Примеры уникальных характеристик проекта включают сложность, критичность, риск, уровень безопасности, уровень защиты, желаемое выполнение и вероятность безотказной работы программного обеспечения. Уровень целостности программного обеспечения определяется классификацией критичности влияния последствий отказов и соответствующих частот возникновения отказов [25]. Критичность функций программного обеспечения также зависит от конкретного применения. Для систем, связанных с безопасностью, уровень целостности безопасности должен быть определен и включен в разработку системы программного обеспечения для соответствия требованиям функциональной безопасности [26]. Для систем, связанных с безопасностью, должны быть включены конкретные требования безопасности системы [27].

6.3.6 Верификация программного обеспечения и валидация системы программного обеспечения

Спецификация программного обеспечения имеет тенденцию быть намного более сложной, чем спецификация физических аппаратных систем, таких как машины и электрические/электронные системы. «Правильность» программного обеспечения имеет первостепенное значение. Процесс верификации [2] заключается в определении того, что требования к программному обеспечению являются полными и правильными в соответствии со стадиями жизненного цикла программного обеспечения. Процесс валидации [7] состоит в определении соответствия работы системы программного обеспечения и услуг требованиям заказчика/пользователя. Для выполнения процессов верификации и валидации необходимы соответствующие вспомогательные системы, такие как испытательное оборудование, средства и дополнительные ресурсы. Активирующая система не дает вклада в функции работы программного обеспечения или тестируемой системы во время ее работы на стадиях жизненного цикла.

a) Верификация программного обеспечения.

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

— определение стратегии верификации программного обеспечения;

— разработка плана верификации на основе требований к программному обеспечению;

— идентификация ограничений, в том числе ограничений, связанных с проектными решениями;

— обеспечение того, что подключающая система для проведения верификации доступна, а соответствующие устройства и ресурсы для тестирования (испытаний) подготовлены;

— проведение верификации для демонстрации соответствия установленным требованиям проекта;

— документирование результатов и данных верификации;

— анализ данных верификации для инициирования корректирующих действий.

b) Валидация системы программного обеспечения.

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

— определение стратегии валидации услуг в условиях эксплуатации и достижения удовлетворенности заказчиков/пользователей;

— подготовка плана валидации;

— обеспечение того, что подключающая система доступна для валидации, а соответствующие устройства и ресурсы — для тестирования (испытаний);

— проведение валидации для демонстрации соответствия услуг требованиям заказчика/пользователя;

— документирование результатов и данных валидации;

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

6.3.7 Тестирование и определение параметров программного обеспечения

a) Общие положения по тестированию программного обеспечения.

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

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

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

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

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

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

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

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

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

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

b) Типы программного тестирования.

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

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

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

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

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

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

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

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

c) Тестируемость программного обеспечения.

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

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

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

d) Тестовые примеры.

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

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

e) Определение параметров программного обеспечения и параметры управления проектом.

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

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

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

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

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

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

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

6.3.8 Повышение и прогнозирование безотказности программного обеспечения

Повышение безотказности программного обеспечения — это состояние, которое характеризуется повышением вероятности безотказной работы системы программного обеспечения во времени. Повышения безотказности программного обеспечения достигают за счет проектирования и прогрессивного достижения значения вероятности безотказной работы с помощью испытаний на повышение надежности. Программное обеспечение не отказывает, если только оно не предназначено для выявления отказов. Программа может отказать только после того, как она выполнена. Отказы программного обеспечения выявляют его неисправности, а устранение этих неисправностей приводит к повышению безотказности. Тенденции повышения безотказности программного обеспечения основаны на интенсивности устранения неисправностей по отношению к совокупному времени выполнения программного обеспечения. Для целей планирования время выполнения может быть преобразовано в календарное время для установления интенсивности отказов программного обеспечения и оценки вероятности безотказной работы. Программа повышения надежности [29] может быть установлена для комбинированной аппаратно-программной системы. Модели повышения надежности и методы оценки, основанные на данных об отказах, собранных в соответствии с программой повышения надежности, описаны в статистических методах повышения надежности [30]. Типичные методы улучшения проекта программного обеспечения приведены в 6.4. Испытания на повышение надежности программного обеспечения включают следующие действия.

a) Испытания на повышение надежности программного обеспечения.

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

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

b) Условия изготовления программного обеспечения.

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

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

c) Несколько копий программного обеспечения.

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

d) Прогнозирование безотказности программного обеспечения.

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

e) Модели безотказности программного обеспечения.

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

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

6.3.9 Данные обратной связи о надежности программного обеспечения

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

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

6.4 Повышение надежности программного обеспечения

6.4.1 Обзор повышения надежности программного обеспечения

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

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

6.4.2 Снижение сложности программного обеспечения

a) Сложность структуры.

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

b) Функциональная сложность.

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

6.4.3 Устойчивость программного обеспечения к неисправностям

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

— Ограничение неисправности: программное обеспечение должно быть написано так, чтобы при возникновении неисправности она не могла распространяться на части программного обеспечения за пределами локального домена, где она произошла.

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

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

— Разнообразие проектов: программное обеспечение и его данные создают таким образом, чтобы были доступны резервные версии.

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

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

6.4.4 Функциональная совместимость программного обеспечения

Функциональная совместимость программного обеспечения — это способность различных систем программного обеспечения работать вместе для обмена информацией и ее использования. В открытой системе, такой как IP-сеть, важно обеспечить взаимодействие различных систем программного обеспечения для установления линий связи. Отказ линии связи может повлиять на надежность работы системы. Один из практических подходов, рекомендуемых для улучшения взаимодействия в сети связи, заключается во включении специального средства в проект системы программного обеспечения для мониторинга ситуации в установленной связи. Например, технология «сердцебиение» (схема обработки и синхронизации сигналов), включающая функцию мониторинга, заключается в отправке сигнала «сердцебиения» друг другу, когда установлена линия связи. Если связь прервана из-за изменений в условиях работы или по каким-либо другим причинам, система программного обеспечения автоматически пытается найти и восстановить соединение, чтобы поддерживать непрерывную связь, так чтобы надежность работы сети связи не ухудшалась.

6.4.5 Повторное использование программного обеспечения

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

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

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

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

Программное обеспечение для многократного использования должно быть хорошо документировано для отслеживания и облегчения управления конфигурацией программных активов. Покупные готовые (COTS) программные средства и системы следует рассматривать как программное обеспечение многократного использования для различных применений. В целях обеспечения достоверности следует проводить квалификационные испытания для валидации работы и соответствия программного продукта/системы требованиям проекта.

6.4.6 Обслуживание и улучшение программного обеспечения

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

— Корректирующее обслуживание: модификация программного продукта, выполняемая после поставки для устранения обнаруженных проблем.

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

— Безупречное обслуживание: модификация программного продукта после поставки для улучшения его работы или обслуживания.

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

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

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

6.4.7 Документация программного обеспечения

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

a) Документация по проекту и его структуре.

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

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

— Проект структуры, используя характеристики информационного потока, формирует структуру программы, что влияет на модульность проекта программного обеспечения и его безотказность. Должны быть использованы рекомендуемые методы описания структуры [32].

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

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

b) Техническая документация.

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

c) Документация пользователя.

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

d) Маркетинговая документация.

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

6.4.8 Автоматизированные средства

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

6.4.9 Техническая поддержка и обучение пользователей

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

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

7 Гарантия на программное обеспечение

7.1 Общие понятия гарантии на программное обеспечение

Гарантия на программное обеспечение — это запланированный и систематизированный набор действий, которые обеспечивают соответствие процессов жизненного цикла программного обеспечения и его самого требованиям, стандартам и процедурам. Модели зрелости возможностей [8, 9] являются распространенным методом управления, рекомендуемым для реализации программ гарантии на программное обеспечение в организациях, разрабатывающих программное обеспечение. Существуют также хорошо документированные методологии и процедуры формирования гарантии на программное обеспечение, применяемые при его разработке и применении [34].

Формирование гарантии на программное обеспечение обычно включает применение технических дисциплин в области качества, надежности, безопасности и защищенности, связанных с разработкой программного продукта и работой системы. Гарантия на программное обеспечение является основой доверия и принятия решений при планировании, разработке, обслуживании программного обеспечения. Гарантией управляют в соответствии с жизненным циклом [35] для проверки соответствия программных продуктов установленным целям для достижения соответствующей безопасности, защищенности, надежности и других целей. Исследования на основе гарантийного случая [36] представляют собой записи о претензиях к работе процесса, а также к физическим свойствам и функциональным характеристикам системы программного обеспечения, проверенным для подтверждения соответствия спецификациям системы. Гарантию на программное обеспечение учитывают при оценке рисков, верификации и валидации тестирования (испытаний), документировании и ведении записей аудита в качестве объективных свидетельств. При формировании гарантии используют данные соответствующих оценок на основе проекта для мониторинга программного продукта и соответствующего процесса возможного улучшения.

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

7.2 Процесс адаптации

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

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

— Определение входных требований для принятия решений.

— Установление целей проекта и плана процесса адаптации.

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

— Документирование результатов адаптации для облегчения анализа его результативности и улучшения проекта.

7.3 Влияние технологий на гарантию на программное обеспечение

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

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

Это приводит к тому, что организации, связанные с программным обеспечением, переопределяют гарантийные обязательства на программное обеспечение при его эксплуатации. Например, гарантию на программное обеспечение можно интерпретировать как «уровень уверенности в том, что программное обеспечение не содержит уязвимостей, намеренно или непреднамеренно встроенных в программное обеспечение, либо случайно введенных в любое время в течение жизненного цикла программного обеспечения, и что программное обеспечение функционирует по назначению» [38]. Гарантия на программное обеспечение должна обеспечивать разумный уровень обоснованной уверенности в том, что программное обеспечение функционирует правильно и предсказуемо в соответствии с документированными требованиями. Целью гарантии на программное средство является обеспечение того, что функционирование программного обеспечения не может быть скомпрометировано ни путем прямой атаки, ни путем воздействия со стороны вредоносного кода.

В зависимости от конкретного применения уровень доверия к гарантии на программное обеспечение связан:

a) с достоверностью — отсутствием уязвимостей, которые могут быть использованы злонамеренно или непреднамеренно;

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

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

Проблемы, определенные для обеспечения гарантии на программное обеспечение, включают в себя:

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

2) изменяющуюся технологическую среду, которая выявляет новые уязвимости и обеспечивает кибер-преступников новыми методами работы;

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

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

7.4 Лучшие практики гарантии на программное обеспечение

Существуют форумы по программным технологиям и гарантии на программное обеспечение [39], в которых участвуют правительства, промышленность, научные круги и пользователи, участвующие в реализации передовых методов гарантии на программное обеспечение. Рекомендуемые методы разработки программного обеспечения указаны в 6.1. Рекомендуемые лучшие практики гарантии на программное обеспечение представлены ниже:

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

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

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

d) выполнение процессов жизненного цикла программного обеспечения;

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

f) установление общих критериев для верификации и валидации квалификации и соответствия программного обеспечения;

g) управление конфигурацией для выпуска версий программного обеспечения;

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

i) создание центра поддержки потребителей для облегчения обслуживания пользователей и применения программного продукта.

Приложение А

(справочное)

Категоризация и применение программного обеспечения

А.1 Категоризация программного обеспечения

А.1.1 Категории программного обеспечения

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

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

А.1.2 Характеристики

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

— Масштаб программного обеспечения: категории, определяемые объемом (например, KSLOC) или сложностью (например, потоком данных) программного обеспечения и интерпретируемые как небольшое, среднее или большое программное обеспечение; программное обеспечения простое или сложное программное обеспечение. Сложное или большое программное обеспечение должно быть разделено на более мелкие части, чтобы облегчить управление проектом, поэтапное тестирование и интеграцию.

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

— Функция программного обеспечения: категории, определяемые типом функции, таким как компилятор, обработка бизнес-транзакций, обработка текстов, система управления. Для бизнес-транзакций должны быть обеспечены безопасность и доступность. Системы управления должны быть сосредоточены на доступности, безопасности и защищенности.

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

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

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

— Язык: категории, определяемые типом языка программирования, в основном использованном в программном обеспечении, таком как традиционный (например, COBOL, FORTRAN), процедурный (например, С), функциональный (например, Lisp), объектно-ориентированный (например, C++). Особое внимание следует уделять обучению программистов и знакомству пользователей с особенностями и ограничениями языка программирования.

А.1.3 Условия окружающей среды

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

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

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

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

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

— Доступность программного продукта: категории, определяемые доступностью программного продукта, такие как коммерческое приобретение (COTS), пользовательское или фирменное программное обеспечение. Сроки приобретения и доступность программного продукта определяют решение о собственном проектировании или аутсорсинге в управлении проектом.

А.1.4 Данные

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

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

А.2 Применения программного обеспечения

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

— Программное обеспечение системы: программное обеспечение, обеспечивающее инфраструктуру для управления аппаратным обеспечением компьютера, чтобы применение программного обеспечения могло быть выполнено. Примерами являются операционные системы, такие как системы Microsoft Windows, Mac OS и Linux.

— Прикладное программное обеспечение: компьютерное программное обеспечение, предназначенное для облегчения пользователю выполнения определенных задач, таких как обработка текста, работа с электронными таблицами и использование баз данных.

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

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

— Тестовое программное обеспечение: подмножество программного обеспечения, специально предназначенное для тестирования программного обеспечения и автоматизации тестирования.

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

— Вредоносное программное обеспечение: программное обеспечение, предназначенное для проникновения в компьютер без согласия владельца.

Приложение В

(справочное)

Требования системы к программному обеспечению и соответствующие действия по обеспечению надежности

В.1 Общие положения

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

В.2 Определение требований

Требования системы к программному обеспечению

Соответствующие действия по обеспечению надежности

— Рыночная информация о программных продуктах

— Требования к применению системы и потребности пользователей

— Домен и платформа операционной системы

— Идентификация требований к программному обеспечению

— Идентификация потребности в работе системы

— Идентификация потребности в поддержке (сопровождении) системы

В.3 Анализ требований

Требования системы к программному обеспечению

Соответствующие действия по обеспечению надежности

— Требования к функциям и возможностям работы

— Сценарии применения

— Установленные требования к безопасности, защищенности и целостности применения, где это применимо

— Требования к интерфейсу

— Квалификационные требования

— Возможности проекта и тестируемость программного обеспечения

— Возможность эксплуатации и обслуживания

— Требования к установке и приемке

— Требования к документации

— Разработка профиля эксплуатации

— Разработка плана проекта надежности

— Разработка плана обеспечения надежности

— Идентификация показателей надежности программного обеспечения

— Определение требований к целостности данных

— Определение требований безопасности и защищенности

— Установление правил разработки проекта с учетом человеческого фактора (эргономики)

— Установление критериев поддержки программного обеспечения

— Идентификация ограничений, влияющих на проектирование и реализацию надежности, включая специфические требования для включения в проект

— Установление критериев повторного использования программного обеспечения

— Установление критериев повышения безотказности программного обеспечения и приемлемости квалификации

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

В.4 Структурное проектирование и разработка

Требования системы к программному обеспечению

Соответствующие действия по обеспечению надежности

— Структура, описывающая верхний уровень и определяющая составляющие элементы программного обеспечения

— Преобразование и распределение требований для облегчения компоновки объектов программного обеспечения

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

— Внутренние и внешние интерфейсы для интеграции и проверки системы

— Предварительная документация по базе данных и требованиям к испытаниям

— Рекомендуемые методы проектирования и стандарты для выполнения целей проекта и проектных спецификаций

— Прослеживаемость требований программного объекта

— Возможность детального проектирования

— Условия эксплуатации и обслуживания

— Выполнение анализа сценария применения

— Определение структурной и функциональной сложности программного обеспечения

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

— Выполнение анализа функциональной модели готовности/безотказности

— Выполнение распределения готовности/безотказности по блокам программного обеспечения

— Создание базы данных показателей надежности

— Выполнение предварительного прогноза готовности/безотказности

— Разработка плана повышения надежности программного обеспечения и плана принятия квалификации

— Установление системы регистрации данных и отчетности

— Установление плана поддержки программного обеспечения

— Анализ структуры проекта для его реализации

В.5 Детальное проектирование

Требования системы к программному обеспечению

Соответствующие действия по обеспечению надежности

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

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

— Согласованность и прослеживаемость подробных спецификаций проекта и структуры

— Установление методов проектирования и стандартов для удовлетворения требований проекта

— Установление специальных методов проектирования для решения вопросов безопасности, защищенности и целостности, где это применимо

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

— Документирование требований к базе данных и к тестированию (испытаниям) и графики тестирования

— Анализ управления проектом для мониторинга прогресса и достижения поставленных целей

— Базовый уровень конфигурации программного обеспечения и обмен информацией об изменениях проекта

— Внедрение правил проектирования программного обеспечения

— Установление стандартов и критериев оценки показателей

— Введение специальных проектов для удовлетворения требований безопасности, защищенности и целостности

— Повышение отказоустойчивости проекта

— Применение стандартов надежности программного обеспечения

— Проведение анализа и контроля кода программного обеспечения

— Уточнение распределения готовности/безотказности программного обеспечения

— Выполнение оценки сложности программного обеспечения

— Прогнозирование безотказности модулей программного обеспечения

— Прогнозирование показателей готовности/безотказности подсистем программного обеспечения

— Выполнение анализа компромиссов проекта

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

— Обновление базы данных показателей надежности

— Выполнение управления конфигурацией

— Выполнение документального анализа проекта

— Выполнение анализа проекта

В.6 Изготовление

Требования системы к программному обеспечению

Соответствующие действия по обеспечению надежности

— Методы и стандарты проектирования модулей и кодирования программного обеспечения и стандарты

— Объекты конфигурации программного обеспечения с определенными программными модулями

— Критерии верификации для тестирования модулей

— Охват тестированием модулей программного обеспечения

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

— Возможность интеграции и тестирования программного обеспечения

— Выполнение стандартов и критериев оценки показателей

— Определение охвата кодированием модулей программного обеспечения

— Выполнение тестирования модулей

— Определение охвата неисправностей и завершение тестирования

— Классификация данных о неисправностях

— Выполнение процесса гарантии надежности для тестирования модулей и функций

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

— Установление отчетности, анализа и корректирующих действий в случае отказа

— Выполнение программы гарантии на программное обеспечение, включая аутсорсинг и цепочку поставок, где это необходимо

— Выполнение анализа проекта

В.7 Интеграция

Требования системы к программному обеспечению

Соответствующие действия по обеспечению надежности

— Стратегия интеграции для модулей и конфигурации программного обеспечения

— Критерии верификации для тестирования объекта конфигурации программного обеспечения

— Верификация подсистем программного обеспечения, включая спецификации на применение и требования безопасности, защищенности и целостности

— Документирование результатов тестирования интеграции

— Документация об изменениях проекта

— Стратегия регрессии для повторной верификации измененных объектов

— Система сбора данных тестирования (испытаний)

— Выполнение процедуры отслеживания неисправностей

— Выполнение процедуры анализа неисправностей

— Инициирование программы повышения надежности

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

— Выполнение системы сбора данных

— Проверка подсистем программного обеспечения для интеграции

— Выполнение тестирования интеграции

— Определение оценок показателей готовности/безотказности по данным испытаний

— Определение проблемных областей

— Выполнение корректирующих действий

— Управление изменениями проекта и выпусками версий

— Проведение документального анализа проекта

В.8 Приемка

Требования системы к программному обеспечению

Соответствующие действия по обеспечению надежности

— Критерии приемки системы программного обеспечения

— Демонстрация соответствия результатов испытаний (тестирования) установленным требованиям

— Валидация результатов испытаний после интеграции на соответствие требованиям

— Валидация системы программного обеспечения для принятия заказчиком (потребителем)

— Регрессионная стратегия повторного тестирования изменений в интеграции программного обеспечения

— Документирование результатов приемки квалификации

— Проведение испытаний на повышение надежности и ускоренных испытаний по мере необходимости

— Мониторинг тенденций и улучшения надежности

— Выполнение квалификационных испытаний

— Анализ результатов испытаний для приемки

— Инициация приемки потребителем (заказчиком)

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

— Подготовка документа о статусе версии программного обеспечения

В.9 Эксплуатация и техническое обслуживание

Требования системы к программному обеспечению

Соответствующие действия по обеспечению надежности

— Процедуры и условия эксплуатации

— Стратегия поддержки сопровождения

— Логистическая поддержка

— Сбор данных эксплуатации

— Обучение пользователей

— Программа гарантии на программное обеспечение для поддержания надежности системы в эксплуатации

— Мониторинг тенденций работы в эксплуатации

— Обновление записей о работе и сопровождении в эксплуатации

— Проведение опросов об удовлетворенности потребителей

— Анализ данных эксплуатации для определения области повышения безотказности

— Установление профиля эксплуатации

— Ведение базы данных о результатах испытаний и эксплуатации системы и ее прототипов

— Сбор соответствующих показателей надежности для прогнозирования безотказности

— Внедрение лучших практик гарантии на программное обеспечение

В.10 Обновление/улучшение программного обеспечения

Требования системы к программному обеспечению

Соответствующие действия по обеспечению надежности

— Обновление программного обеспечения

— Безупречное выполнение стратегии обслуживания

— Введение новой услуги и оценка ее влияния

— Влияние улучшения на работу программного обеспечения

— Отслеживание обновления программного обеспечения

— Безупречное выполнение обслуживания

— Выполнение изменений проекта и контроль конфигурации

— Оценка влияния введения новых услуг

— Управление выпуском новых версий программного обеспечения

В.11 Вывод из эксплуатации

Требования системы к программному обеспечению

Соответствующие действия по обеспечению надежности

— Прекращение выполнения конкретной услуги

— Консультирование пользователей о прекращении выполнения старых услуг и замене их новыми.

— Информирование пользователей о прекращении использования программного обеспечения и выполнения услуг поддержки

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

Приложение С

(справочное)

Процесс комплексной модели зрелости

Комплексная модель зрелости (CMMI) — это процесс улучшения модели зрелости для обеспечения надежности программных продуктов и услуг. Процесс состоит из лучших практик, которые касаются деятелей разработки и технического обслуживания, охватывающих весь жизненный цикл продукта от концепции до поставки и технического обслуживания. CMMI для разработки модулей [9] содержит методы, охватывающие управление проектами, управление процессами, разработку системы, разработку аппаратных средств, разработку программных средств и другие вспомогательные процессы, используемые при разработке и обслуживании. Процесс CMMI коррелирует с выполнением требований к системе программного обеспечения и соответствующими действиями по обеспечению надежности, как показано в приложении В. CMMI используют для бенчмаркинга и оценки, а также для руководства усилиями организации по постоянному улучшению. Процесс CMMI относят к одному из уровней.

— Уровням возможностей, которые относятся к непрерывному представлению, их применяют к достижению организацией улучшения процессов в отдельных областях процессов. Эти уровни являются для руководства процессом средствами постепенного улучшения, соответствующими данной области процесса. Существует шесть уровней возможностей, пронумерованных от 0 до 5.

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

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

Таблица С.1 — Сравнение уровней возможностей и зрелости


Уро- вень	Уровни возможностей	Уровни зрелости
0	Неполный процесс — это процесс, который либо не выполняют, либо выполняют частично. Одна или несколько конкретных целей процесса не достигнуты. Для этого уровня не существует общих целей, поскольку нет оснований формализовать частично выполняемый процесс	Нет данных
1	Выполняемый процесс — это процесс, который удовлетворяет установленным целям к процессу. Он поддерживает и делает возможным работу, необходимую для создания рабочих продуктов. Хотя уровень возможностей 1 приводит к важным улучшениям, эти улучшения могут быть потеряны со временем, если они не установлены. Установление помогает обеспечить поддержку улучшений	На уровне зрелости 1 процессы обычно носят случайный и хаотичный характер. Организация обычно не обеспечивает стабильные условия для поддержки процессов. Успех в этих организациях зависит от компетентности специалистов организации, а не от использования установленных процессов. Организации, имеющие уровень зрелости 1, часто производят работоспособные продукты и услуги, однако такие организации часто превышают запланированный бюджет и не выполняют графики выполнения работ. Существует тенденция к принятию чрезмерных обязательств, отказу от процессов в случае кризиса и неспособности воспроизведения успешных проектов
2	Управляемый процесс — это выполняемый процесс, который имеет базовую инфраструктуру для поддержки данного процесса. Этот процесс планируют и выполняют в соответствии с политикой организации; нанимают квалифицированных специалистов, обладающих достаточными ресурсами для получения управляемых результатов; вовлекают соответствующие заинтересованные стороны; проводят мониторинг, управляют, анализируют и оценивают на предмет соответствия описанию процесса. Организация процесса в соответствии с уровнем возможностей 2 помогает гарантировать сохранение существующих практик в кризисный период	На уровне зрелости 2 при выполнении проектов организации обеспечивают планирование и выполнение процессов в соответствии с политикой; в проектах работают квалифицированные специалисты, обладающие достаточными ресурсами для получения управляемых результатов; в работу вовлекают соответствующие заинтересованные стороны; проводят мониторинг, управляют, анализируют и оценивают на предмет соответствия описанию процесса. Результаты уровня зрелости организации 2 обеспечивают сохранение существующей практики в кризисные периоды; выполнение проектов и управление ими в соответствии с их документированными планами; состояние разрабатываемых продуктов и предоставления услуг демонстрируют руководству в определенные моменты на основных этапах и по завершении основных задач. Соответствующие заинтересованные стороны устанавливают между собой обязательства и пересматривают их по мере необходимости. Разрабатываемые продукты должным образом управляются. Разрабатываемые продукты и услуги удовлетворяют установленным описаниям процессов, стандартам и процедурам.
3	Определенный процесс — это управляемый процесс, который адаптирован в соответствии с набором стандартных процессов организации, руководящими принципами организации, процесс вносит разрабатываемые показатели, меры и другую информацию по совершенствованию процессов в активы процесса организации. Соответствующие стандарты, описания процессов и процедуры согласованы и адаптированы к конкретному проекту или к подразделению организации. Определенный процесс четко устанавливает цель, входные данные, входные критерии, виды деятельности, обязанности, параметры, этапы проверки, результаты и выходные критерии. Процессами управляют проактивно, путем понимания взаимосвязей действий процесса и показателей процесса, разрабатываемых им продуктов и услуг	На уровне зрелости 3 процессы организации хорошо характеризованы и понятны, а также описаны в стандартах, процедурах и методах. Эти стандартные процессы используют для установления их последовательности при выполнении в организации. Проекты устанавливают свои определенные процессы путем адаптации набора стандартных процессов организации в соответствии с руководящими принципами адаптации. Результаты организаций, имеющих уровни зрелости 3, демонстрируют постоянство в работе
4	Количественно управляемый процесс — это процесс, которым управляют с помощью статистических и других количественных методов. Устанавливают количественные цели качества и работы процесса, которые используют в качестве критериев управления процессом. Качество и работа процесса понимаются в статистических терминах и управляются на протяжении всего жизненного цикла процесса с помощью статистических методов	На уровне зрелости организации 4 для проектов устанавливают количественные цели качества и эффективности процессов и используют их в качестве критериев управления процессами. Количественные цели основаны на потребностях заказчика (потребителя), конечных пользователей, организации и исполнителей процессов. Качество и работу процессов понимают в виде статистических показателей, которыми управляют на протяжении всего жизненного цикла процессов. Для отобранных подпроцессов собирают и статистически анализируют подробные показатели работы процесса. Показатели качества и работы процессов включены в хранилище показателей организации для поддержки принятия решений на основе фактов. Выявляют особые причины изменения процесса и, при необходимости, корректируют источники особых причин для предотвращения появления их в будущем. Результаты деятельности организаций 4-го уровня зрелости демонстрируют адекватное управление работой процессов с использованием статистических и других количественных методов для обеспечения количественной предсказуемости результатов работы
5	Оптимизирующий процесс — это количественно управляемый процесс, который совершенствуется на основе понимания общих причин изменчивости, присущей процессу. Основное внимание в процессе оптимизации уделяют постоянному улучшению работы процесса за счет постоянных инновационных улучшений	На 5-м уровне зрелости организация постоянно совершенствует свои процессы, основываясь на количественном понимании общих причин изменчивости, присущей процессам; фокусируется на постоянном улучшении работы процессов путем постепенного и инновационного совершенствования процессов и технологий. Устанавливают количественные цели улучшения процессов. Их постоянно пересматривают с учетом меняющихся бизнес-целей и используют в качестве критериев управления улучшением процессов. Результаты внедренных улучшений процессов измеряют и оценивают с учетом количественных целей улучшения процесса. Как определенные процессы, так и набор стандартных процессов организации являются целями измеримых мероприятий по улучшению. Результаты организаций 5-го уровня зрелости демонстрируют постоянное улучшение процессов для достижения установленных количественных целей улучшения процессов

Приложение D

(справочное)

Классификация признаков дефектов программного обеспечения

D.1 Общие положения

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

D.2 Открытие

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

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

Таблица D.1 — Классификация особенностей дефектов программного обеспечения при обнаружении неисправности


Действия по устранению неисправностей (при обнаружении)	Триггер (обнаружения)	Воздействие (влияние и значимость)
— Анализ проекта — Проверка кода — Тестирование модулей — Тестирование функций — Тестирование системы — Приемочные испытания — Квалификационные испытания — Испытания на повышение надежности	— Соответствие проекту — Совместимость — Параллельность — Охват — Последовательность — Взаимодействие — Конфигурация	— Возможность установки — Удобство обслуживания — Целостность/безопасность/ защищенность — Безотказность — Обслуживание — Доступность — Удобство использования
Примечание 1 — Неисправности программного обеспечения часто трудно воспроизвести. Важно зафиксировать обстоятельства и условия, приводящие к неисправности. Примечание 2 — Требуется прослеживаемость требований; либо прослеживаемость требований к программному обеспечению, либо прослеживаемость конкретного тестового примера.
Действия: фактические действия, выполняемые в момент обнаружения неисправности. Триггер: среда или условие, которые должны существовать для появления неисправности. Воздействие: для неисправностей разработки воздействие оценивают как возможное влияние и значимость для пользователя; для неисправностей, зарегистрированных в эксплуатации, воздействие — это последствие и значимость отказа для пользователя.

D.3 Закрытие

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

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

Таблица D.2 — Классификация сведений о дефектах программного обеспечения при устранении неисправности


Цель	Тип	Квалификатор	Возраст	Источник
Проект/код	Инициация Проверка Функция Синхронизация Интерфейс	Отсутствие Некорректность Несовместимость	Основной Новый Улучшенный	Разработано внутри компании Разработано при помощи аутсорсинга Повторно использован из библиотеки Портирован
Цель: верхнеуровневая идентификация объекта исправления. Тип: особенности фактической коррекции, которая была сделана. Квалификатор: (применяется к типу дефекта): описывает элемент либо отсутствия, либо некорректности, либо ошибки, либо несовместимого выполнения. Возраст: идентифицирует историю цели (проект/код), в которой обнаружен дефект. Источник: определяет происхождение цели (проект/код), которая имела дефект.

D.4 Составление карты триггеров и действий

Составление карты действий и триггеров группирует применимые триггеры, относящиеся к деятельности, связанной с анализом контроля и тестированием проекта программного обеспечения. В таблицах D.3, D.4, D.5 и D.6 приведено несколько общих примеров составления карт действий и триггеров.

Таблица D.3 — Составление карты действий и триггеров для анализа проекта и контроля кодов


Действия	Триггеры
Анализ проекта/ контроля/кодирования Пересмотр проекта или сравнение проектной документации с известными требованиями	Соответствие проекта Проверяющий инспектор обнаруживает неисправность, сравнивая проверяемый элемент проекта или сегмент кода с его спецификацией, установленной на предыдущем этапе. Проверка может охватывать проектную документацию, кодекс, практику разработки и стандарты, а также гарантировать, что требования проекта не будут пропущены или не будут неопределенными. Логика/поток Инспектор использует знание основных методов программирования и стандартов для изучения логики потока или данных, чтобы гарантировать их правильность и полноту. Обратная совместимость Инспектор использует обширный опыт работы с продуктом/компонентом для выявления несовместимости функции, описанной в проектной документации или кодах, и более ранними версиями того же продукта или компонента. С точки зрения эксплуатации приложение пользователя, которое успешно работало в предыдущем выпуске, отказывает в текущем выпуске Горизонтальная совместимость Инспектор, обладающий обширным опытом, обнаруживает несовместимость функции, описанной в проектной документации или кодах, и другими системами, продуктами, услугами, компонентами или модулями, с которыми функция должна взаимодействовать. Параллельность Инспектор рассматривает организацию серийного производства, необходимую для управления общим ресурсом при обнаружении неисправности. Это включаете себя организацию серийного выпуска большого количества функций, потоков, процессов или контекстов ядра, а также наложение и снятие блокировок. Внутренний документ Наличие неверной информации, несоответствий или неполноты во внутренней документации. Прологи, комментарии к коду и планы тестирования представляют собой некоторые примеры документации, которая подпадает под эту категорию
	Языковая зависимость Разработчик обнаруживает дефект при проверке специфических для языка деталей выполнения компонента или функции. Стандарты языка, проблемы компиляции и эффективность конкретных языков являются примерами проблемных областей Побочные эффекты Инспектор использует обширный опыт и знание продукта, чтобы предвидеть поведение какой-либо системы, продукта, функции или компонента, которое может возникнуть в результате рассматриваемого проекта или кода. Побочные эффекты характеризуют результат общего использования или конфигураций, в том числе за пределами области действия компонента или функции, с которыми связан рассматриваемый проект или код Редкая ситуация Инспектор использует обширный опыт и знание продукта, чтобы предвидеть некоторое поведение системы, которое не учитывается или не рассматривается в исследуемом документированном проекте или коде и обычно связано с необычными конфигурациями или использованием. Отсутствующее или неполное восстановление неисправностей, как правило, не классифицируют как триггер редкой ситуации, но, скорее всего, относят к соответствию конструкции, если неисправность обнаружена во время пересмотра/проверки

Таблица D.4 — Карты действий и триггеров для тестирования модулей

Действия

Триггеры

Тестирование модулей

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

Простой путь

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

Сложный путь

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

Таблица D.5 — Карты действий и триггеров для тестирования функций

Действия

Триггеры

Тестирование функций

Выполнение тестирования черного ящика на основе внешних спецификаций функций

Охват

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

Изменение

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

Последовательность действий

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

Взаимодействие

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

Таблица D.6 — Карты действий и триггеров для тестирования системы

Действия

Триггеры

Тестирование системы

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

Рабочая нагрузка/повышенная нагрузка

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

Восстановление/исключение

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

Запуск/перезапуск

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

Конфигурация аппаратных средств

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

Конфигурация программного обеспечения

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

Блокированный тест (нормальный режим)

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

Приложение Е

(справочное)

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

Е.1 Данные о неисправностях


Данные	Применение
Данные записей и отчетов о проблемах: — дата и время обнаружения неисправности; — описание обнаруженной неисправности; — неисправность обнаружена в программной области; — специалист, обнаруживший неисправность; — симптомы и состояния неисправности; — значимость и приоритет	Данные, собранные по проектам программного обеспечения, должны быть использованы в отчете о проблеме после возникновения и идентификации неисправности
Данные о корректирующих действиях: — дата устранения неисправности; — специалист, исправивший ошибку; — выполнение действий технического обслуживания; — описание модификации; — идентификация модифицированных модулей; — информация о контроле версий; — время, необходимое для устранения неисправности; — дата верификации устранения неисправности; — специалист, верифицировавший устранение неисправности	Собранные данные о корректирующих действиях, проверенные как исправленные неисправности, должны использоваться для составления отчетов об устранении проблем
Накопленные данные об обнаруженных неисправностях	Накопленные данные об обнаруженных неисправностях следует использовать для определения интенсивности возникновения неисправностей и тенденции изменения вероятности безотказной работы в течение определенного периода времени.
Накопленные данные об устраненных неисправностях	Накопленные данные об устраненных неисправностях следует использовать для определения известных неисправностей, требующих корректирующих действий, и отслеживания эффективности действий технического обслуживания
Интенсивность обнаружения неисправностей	Интенсивность обнаружения неисправностей используют для выявления тенденций и облегчения планирования стратегии технического обслуживания и управления ресурсами
Интенсивность устранения неисправностей	Интенсивность устранения неисправностей используют для выявления тенденций и облегчения планирования стратегии технического обслуживания и управления ресурсами. Установка приоритета для действий технического обслуживания основана на значимости проблем, вызванных неисправностью
Неисправности по расположению	Отслеживание неисправностей в соответствии с программными функциями для идентификации конкретных областей кода, более подверженных ошибкам
Критичность неисправностей	Классификация степени воздействия неисправностей для установления приоритета действий технического обслуживания
Количество и процент значимых неисправностей	Показания к планированию стратегии технического обслуживания.
Структурная сложность в соответствии с расположением	Используется с другими показателями для определения влияния генерируемых неисправностей, связанных со сложностью структуры программного обеспечения и расположением
Функциональная сложность в соответствии с расположением	Используется с другими показателями для определения влияния генерируемых неисправностей, связанных со сложностью функций программного обеспечения и с расположением (в коде)

Е.2 Данные о продукте


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

Е.3 Данные о процессе


Данные	Применение
Неисправности, внесенные на стадиях жизненного цикла	Указание того, когда и на каком этапе были внесены неисправности и приняты соответствующие меры
Неисправности, обнаруженные на стадиях жизненного цикла	Указание того, когда и на какой стадии были обнаружены неисправности, а также обоснование задержки корректирующих действий по устранению неисправности
Общее время, затраченное на анализ	Указание времени, затраченного на анализ, для выявления проблемы и определения корректирующих действий, а также соответствующих необходимых ресурсов
Общее время, затраченное на проектирование	Указание времени, затраченного на проектирование программного обеспечения, и соответствующих необходимых ресурсов
Общее время, затраченное на кодирование	Указание времени, затраченного на кодирование и программирование, и соответствующих необходимых ресурсов
Общее время, затраченное на тестирование модулей	Указание времени, затраченного на тестирование модулей, и соответствующих необходимых ресурсов
Общее время, затраченное на тестирование системы	Указание времени, затраченного на тестирование системы, и соответствующих необходимых ресурсов
Общее время технического обслуживания	Указание времени, затраченного на техническое обслуживание, и соответствующих необходимых ресурсов
Среднее время администрирования технического обслуживания	Указание времени, затраченного на администрирование технического обслуживания, и соответствующих необходимых ресурсов. Административные обязанности по техническому обслуживанию включают в себя действия до и после устранения неисправности, такие как время, затраченное на назначение обслуживающего персонала, выпуск новой (исправленной) версии
Среднее время корректирующих действий	Указание времени, затраченного на корректирующие действия, и соответствующие необходимые ресурсы. Отражает экономическую эффективность деятельности по техническому обслуживанию
Причина корректирующих действий	Используют для определения источника неисправностей Типичные причины включают в себя: — предыдущие действия технического обслуживания; — новые требования; — изменение требований; — неверно истолкованное требование; — отсутствие требования; — неоднозначное требование; — изменение программной среды; — изменение аппаратной среды; — ошибка в коде или логическая ошибка; — ошибка при работе
Стоимость корректирующих действий	Указание общей стоимости корректирующих действий, включая обнаружение неисправностей, решение проблем и администрирование для эффективного технического обслуживания
Процент тестированных и верифицированных функций	Индикация охвата тестированием, эффективности и полноты тестирования
Процент тестированных и верифицированных независимых путей	Указание охвата тестированием структурных испытаний и полноты их проведения
Процент тестированных и верифицированных исходных строк кода	Указание охвата тестированием программного кода и его полноты
Исторические данные	Предоставление предыдущих данных по проблемным областям, связанным с проектированием, процессами и продуктами

Приложение F

(справочное)

Пример функций надежности комбинированного аппаратного и программного обеспечения

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

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

— компоненты электронной схемы срабатывания;

— аппаратная функция распознавания активации запуска или остановки;

— компоненты электронной схемы распознавания;

— функции применения программного обеспечения для управления быстрым запуском и отключением аппаратной функции распознавания, включая:

— программный модуль управления инициированием активации,

— программный модуль управления отключением и деактивацией,

— программный модуль для мониторинга скорости активации и деактивации.

Эти функции представлены схемой, показанной на рисунке F.1.

Рисунок F.1 — Структурная схема системы управления мониторингом

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

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

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

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

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

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

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

— Вероятность безотказной работы системы и управления мониторингом с точки зрения интенсивности отказов соответствует сумме

Приложение G

(справочное)

Краткое описание модели безотказности программного обеспечения

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

a) Общее количество неисправностей, присущих программному обеспечению. Предполагается, что это количество является постоянным и конечным.

b) Общее количество скрытых неисправностей (ошибок) в программном обеспечении. Предполагается, что это количество является переменным из-за возможности введения в код новых неисправностей с течением времени.

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

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

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

f) Общее количество неисправностей, устраненных за определенный период тестирования (испытаний)

g) Изменение интенсивности отказов.

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

i) Накопленное время работы.

j) Начальная интенсивность отказов.

k) Настоящая (текущая) интенсивность отказов.

l) Повышение интенсивности.

m) Оценка количества строк исполняемого кода во время тестирования или использования.

n) Общее количество выполненных тестовых примеров.

o) Общее количество успешно выполненных тестовых примеров.

Приложение Н

(справочное)

Выбор и применение моделей безотказности программного обеспечения

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

В таблице Н.1 представлены некоторые примеры моделей безотказности программного обеспечения, используемых в отраслевой практике. В цели настоящего стандарта не входит детальная формулировка модели и ее применения. Ссылки на модели безотказности программного обеспечения и их конкретные применения хорошо описаны в литературе [14, 37].

Таблица Н.1 — Примеры моделей безотказности программного обеспечения


	Наименование модели	Предположения	Требования к данным	Ограничения применения
1	Musa-basic	— Конечное количество присущих неисправностей (скрытых неисправностей) — Постоянная интенсивность неисправностей во времени — Экспоненциальное распределение	— Количество обнаруженных неисправностей в определенный момент времени — Оценка начальной интенсивности отказов — Текущая интенсивность отказов системы программного обеспечения	— Программное обеспечение находится в эксплуатации — Использование после интеграции системы — Предполагается, что корректировка не вводит новые неисправности — Предполагается, что количество остаточных неисправностей линейно уменьшается с течением времени
2	Musa-Okumoto	— Бесконечное количество присущих неисправностей (скрытых неисправностей) — Изменение интенсивности ошибок во времени — Логарифмическое распределение	— Количество обнаруженных неисправностей в определенный момент времени — Оценка начальной интенсивности отказов — Относительное изменение интенсивности отказов во времени — Текущая интенсивность отказов системы программного обеспечения	— Программное обеспечение находится в эксплуатации — Использование модулей в тестовых системах — Предположение, что корректировка не вводит новые неисправности — Предположение, что количество остаточных неисправностей со временем экспоненциально уменьшается
3	Jelinski- Moranda	— Конечное и постоянное количество присущих неисправностей (скрытых неисправностей) — Постоянная интенсивность ошибок во времени — Неисправности устраняют сразу после обнаружения — Биномиальное экспоненциальное распределение	— Количество устраненных неисправностей в определенный момент времени — Оценка начальной интенсивности отказов — Текущая интенсивность отказов системы программного обеспечения	— Программное обеспечение находится в эксплуатации — Использование после интеграции системы — Предположение, что корректировка не вводит новые неисправности — Предположение, что количество остаточных неисправностей линейно уменьшается с течением времени
4	Littlewood- Verrall	Неопределенность в процессе коррекции	— Оценка количества отказов — Оценка скорости повышения надежности — Время между обнаруженными отказами или время возникновения отказа	Программное обеспечение находится в эксплуатации
5	Schneidewind	Корректировка не вводит новые неисправности	— Оценка интенсивности отказов в начале первого интервала — Оценка константы пропорциональности изменения интенсивности отказов во времени — Неисправности, обнаруженные в равные промежутки времени	— Программное обеспечение находится в эксплуатации — Скорость обнаружения неисправностей уменьшается экспоненциально с течением времени
6	Geometric	Количество присущих неисправностей должно быть бесконечным	— Уменьшение в соответствии с функцией геометрической прогрессии по мере обнаружения отказов — Время между возникновением отказов или время возникновения отказа	— Программное обеспечение находится в эксплуатации — Неисправности независимы и неравны по вероятности возникновения и степени тяжести
7	Brooks-Motley	Интенсивность обнаружения неисправностей во времени	— Трудозатраты выполнения каждого теста — Вероятность обнаружения неисправности в -м тесте — Вероятность устранения неисправностей без введения новых — Количество неисправностей, оставшихся к началу -го теста — Общее количество неисправностей, обнаруженных в каждом тесте	— Программное обеспечение в процессе разработки — Некоторые программные модули отличаются по тестовым усилиям
8	Bayesian	Программное обеспечение относительно свободно от неисправностей	— Продолжительность времени тестирования для каждого интервала — Количество отказов, обнаруженных в каждом интервале	— Программное обеспечение находится в эксплуатации — Программное обеспечение корректируется в конце интервала тестирования
9	Keene	Корреляция количества скрытых неисправностей в поставляемых блоках с возможностями процесса разработки и объемом программного обеспечения (KSLOCs)	Уровень зрелости СММ для оценки возможностей процесса, оцененный KSLOC поставляемый код, оцененное количество месяцев до достижения зрелости после выпуска, скрытые неисправности, процент неисправностей 1-й и 2-й степени значимости, время восстановления, часы использования кода в неделю и процент активации неисправностей	— Процент активации неисправностей является оценочным параметром, представляющим средний процент мест пользователей системы, у которых, вероятно, возникнет конкретная неисправность — Уровень возможностей СММ должен быть оценен для организации разработки, а также для организации технического обслуживания

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

— профили отказов;

— зрелость программного продукта;

— параметры разработки программного обеспечения;

— характеристики тестирования программного обеспечения;

— существующие показатели и данные.

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

При выборе метода организации следует учитывать следующие критерии:

— наличие средства, совместимого с компьютерными системами организации;

— стоимость установки и обслуживания программы;

— количество исследований, которые, вероятно, будут проведены для применения средства;

— типы систем программного обеспечения, подлежащих изучению;

— качество документации о применении средства;

— простота изучения средства;

— гибкость и мощь средства;

— техническая поддержка средства.

Приложение ДА

(справочное)

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.1


Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
IEC 60050-191:1990*	—	Международный стандарт включает текст на русском языке
* IEC 60050-191:1990 заменен на IEC 60050-192:2015, которому соответствуют национальные стандарты ГОСТ Р 27.101-2021 (NEQ) и ГОСТ Р 27.102-2021 (NEQ).
IEC 60300-3-15:2009	MOD	ГОСТ Р 27.015-2019 «Надежность в технике. Управление надежностью. Руководство по проектированию надежности систем»
Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта: — MOD — модифицированный стандарт.

Библиография


[1]	IEC 62508, Guidance on human aspects of dependability
[2]	ISO/IEC 12207, Systems and software engineering — Software life cycle processes
[3]	IEC 60300-1, Dependability management — Part 1: Dependability management systems
[4]	IEC 60300-2, Dependability management — Part 2: Guidelines for dependability management
[5]	KLINE, M.B. Software and hardware R&M: What are the differences? Proceedings of the Annual Reliability and Maintainability Symposium, 1980
[6]	LIPOW, M., SHOOMAN, M.L. Software reliability, Tutorial Session, Annual Reliability and Maintainability Symposium, 1986
[7]	ISO/IEC 15288, Systems and software engineering — System life cycle processes
[8]	Capability Maturity ( ), Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA USA
[9]	Capability Maturity Model Integration® (CMMI®) for Development, Version 1.2; Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA USA 2006
[10]	IEC 60300-3-3, Dependability management — Part 3-3: Application guide — Life cycle costing
[11]	IEC 62347, Guidance on system dependability specifications
[12]	IEC 61160, Design review
[13]	CHILLAREGE, Ram. Orthogonal Defect Classification — Aconcept for in process Measurements, IEEE Transactions on Software Engineering, 1992
[14]	LYU, M.R. (Ed.): The Handbook of Software Reliability Engineering, IEEE Computer Society Press and McGraw-Hill Book Company, 1996
[15]	IEEE-1633: Recommended Practice on Software Reliability, 2009
[16]	ISO/IEC 20926, Software and systems engineering — Software measurement — IFPUG functional size measurement method 2009
[17]	IEC 61078, Analysis techniques for dependability — Reliability block diagram and boolean methods
[18]	IEC 61025, Fault tree analysis (FTA)
[19]	IEC 61165, Application of Markov techniques
[20]	IEC 62551, Analysis techniques for dependability — Petri net techniques2
[21]	DUGAN, J.B. Fault Tree Analysis for Computer-based Systems, Tutorial Session, Annual Reliability and Maintainability Symposium, 2000
[22]	IEC 62198, Project risk management — Application guidelines
[23]	IEC 60812, Analysis techniques for system reliability — Procedure for failure mode and effects analysis (FMEA)
[24]	IEC 60300-3-1, Dependability management — Part 3-1: Application guide — Analysis techniques for dependability — Guide on methodology
[25]	ISO/IEC 15026-3, Systems and software engineering — System and software assurance — Part 3: System integrity levels
[26]	IEC 61508-3, Functional safety of electrical/electronic/programmable electronic safetyrelated systems — Part 3: Software requirements
[27]	ISO/IEC 13335-1, Information technology — Security techniques — Management of information and communications technology security — Part 1: Concepts and models for information and communications technology security management (withdrawn)
[28]	IEC 62429, Reliability growth — Stress testing for early failures in unique complex systems
[29]	IEC 61014, Programmes for reliability growth
[30]	IEC 61164, Reliability growth — Statistical test and estimation methods
[31]	IEC 62506, Methods for product accelerated testing
[32]	ISO/IEC/IEEE 42010, Systems and software engineering — Architectural description
[33]	ISO/IEC 18019, Systems and software engineering — Guidelines forthe design and preparation of user documentation for application software (withdrawn)
[34]	Software Assurance Standard, NASA-STD-8739.8 w/Change 1, May 2005
[35]	ISO/IEC 15026-4, Systems and software engineering — System and software assurance — Part 4: Assurance in the life cycle2
[36]	ISO/IEC 15026-2, Systems and software engineering — System and software assurance — Part 2: Assurance case
[37]	LAKEY, P.B., NEUFELDER, A.M. System and Software Reliability Assurance Notebook, Rome Laboratory, 1996
[38]	National Information Assurance (IA) Glossary, (CNSS Instruction No. 4009), National Security Telecommunications and Information Systems Security Committee (NSTISSC), published by the United States federal government (unclassified), June 2006
[39]	Software Assurance: An Overview of Current Industry Best Practices, Software Assurance Forum for Excellence in Code, February 2008
[40]	ISO/IEC TR 12182, Information technology — Categorization of software


УДК 658.562.012.7:65.012.122:006.354	ОКС 03.120.01
Ключевые слова: надежность в технике, программное обеспечение, программный сбой

Источник

Утвержден и введен в действие

Приказом Федерального агентства

по техническому регулированию

и метрологии

от 21 сентября 2021 г. N 990-ст

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

НАДЕЖНОСТЬ В ТЕХНИКЕ

РУКОВОДСТВО ПО ОБЕСПЕЧЕНИЮ НАДЕЖНОСТИ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Dependability in technics.

Guidance on provision of software dependability

(IEC 62628:2012, Guidance on software aspects

of dependability, IDT)

ГОСТ Р МЭК 62628-2021

ОКС 03.120.01

Дата введения

1 января 2022 года

Предисловие
Введение
1 Область применения
2 Нормативные ссылки
3 Термины, определения и сокращения
4 Анализ аспектов надежности программного обеспечения
5 Надежность программного обеспечения: разработка и применение
6 Методы обеспечения надежности при применении программного обеспечения
7 Гарантия на программное обеспечение
КАТЕГОРИЗАЦИЯ И ПРИМЕНЕНИЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ТРЕБОВАНИЯ СИСТЕМЫ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ И СООТВЕТСТВУЮЩИЕ ДЕЙСТВИЯ ПО ОБЕСПЕЧЕНИЮ НАДЕЖНОСТИ
ПРОЦЕСС КОМПЛЕКСНОЙ МОДЕЛИ ЗРЕЛОСТИ
КЛАССИФИКАЦИЯ ПРИЗНАКОВ ДЕФЕКТОВ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ПРИМЕРЫ ДАННЫХ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, ПОЛУЧЕННЫХ В РЕЗУЛЬТАТЕ СБОРА ДАННЫХ
ПРИМЕР ФУНКЦИЙ НАДЕЖНОСТИ КОМБИНИРОВАННОГО АППАРАТНОГО И ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
КРАТКОЕ ОПИСАНИЕ МОДЕЛИ БЕЗОТКАЗНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ВЫБОР И ПРИМЕНЕНИЕ МОДЕЛЕЙ БЕЗОТКАЗНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ НАЦИОНАЛЬНЫМ СТАНДАРТАМ
БИБЛИОГРАФИЯ

Источник

Текст ГОСТ Р 27.014-2019 Надежность в технике. Управление надежностью. Руководство по установлению требований к надежности систем

ГОСТ Р 27.014-2019
(МЭК 62347:2006)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Надежность в технике

УПРАВЛЕНИЕ НАДЕЖНОСТЬЮ

Руководство по установлению требований к надежности систем

Dependability in technics. Dependability management. Guidance on system dependability specifications

ОКС 03.120.01

Дата введения 2020-07-01

Предисловие

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 119 «Надежность в технике»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 30 октября 2019 г. N 1228-ст

4 Настоящий стандарт является модифицированным по отношению к международному стандарту МЭК 62347:2006* «Руководство по установлению требований к надежности систем» (IEC 62347:2006 «Guidance on system dependability specifications», MOD) путем внесения технических отклонений, объяснение которых приведено во введении к настоящему стандарту.

________________

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

Международный стандарт разработан Техническим комитетом МЭК 56.

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

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

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

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

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

Настоящий стандарт представляет собой обоснование важности включения надежности в функциональные требования к системе и обеспечивает процедуру установления требований к надежности системы. В настоящем стандарте в общем виде описан процесс установления функций, необходимых для обеспечения надежности системы. Для специализированных систем введено понятие рабочего профиля. Настоящий стандарт основан на модели системы и классификации функций, установленных в ГОСТ Р МЭК 61069-1. Соответствующие технические требования для установления и анализа требований к системе установлены в ГОСТ Р 57193. Элементы процедуры и процесс установления требований к надежности системы приведены для примера. Стандарты ГОСТ Р МЭК 60300-1 и ГОСТ Р 51901.3 могут быть использованы в качестве руководства по менеджменту надежности. Настоящий стандарт обеспечивает более широкий подход к процессу установления требований к надежности и может быть использован при разработке предварительных требований при проектировании системы. Стандарт является полезным дополнением ГОСТ 27.003 в работах по установлению требований к надежности продукции и оборудования. Технический процесс проектирования надежности систем описан в ГОСТ Р 27.015.

В настоящем стандарте ссылки на международные стандарты заменены ссылками на национальные стандарты.

1 Область применения

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

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ 27.002 Надежность в технике. Термины и определения

ГОСТ 27.003 Надежность в технике. Состав и общие правила задания требований по надежности

ГОСТ Р 27.015 Надежность в технике. Управление надежностью. Руководство по проектированию надежности систем

ГОСТ Р 51901.3 Менеджмент риска. Руководство по менеджменту надежности

ГОСТ Р 57193 Системная и программная инженерия. Процессы жизненного цикла систем

ГОСТ Р МЭК 60300-1 Менеджмент риска. Руководство по применению менеджмента надежности

ГОСТ Р МЭК 61069-1-2017 Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 1. Терминология и общие концепции

ГОСТ Р ИСО 9000-2015 Системы менеджмента качества. Основные положения и словарь

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

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ 27.002, а также следующие термины с соответствующими определениями:

3.1

система (system): Совокупность взаимосвязанных и(или) взаимодействующих элементов.

[ГОСТ Р ИСО 9000-2015, пункт 3.5.1]

Примечания

1 В контексте надежности, система имеет:

— определенную цель, выраженную в предполагаемых функциях;

— установленные условия использования/эксплуатации;

— очерченные границы.

2 Структура системы может быть иерархической.

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

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

3.3

функция (function): Операция, выполняемая модулем, который позволяет системе выполнять задачу.

[ГОСТ Р МЭК 61069-1-2017, статья 3.1.28]

Примечание — Для некоторых систем информация и данные являются важными частями элементов системы.

3.4 элемент (element): Комбинация компонентов, которые составляют базовый блок, необходимый для выполнения отдельной функции.

Примечание — Элемент может включать в себя следующие компоненты: аппаратные средства, программное обеспечение, информацию и/или человека.

3.5 влияющие условия (influencing condition): Условия, определяемые внешними воздействующими элементами и/или другими факторами, с которыми система взаимодействует и которые могут повлиять на ее работу.

Примечание — Влияющие условия также могут включать правила и ограничения.

4 Концепция надежности системы

4.1 Определение системы

4.1.1 Цели и задачи

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

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

4.1.2 Свойства и характеристики системы

Система имеет набор свойств, которые специально заданы, выбраны или обусловлены конструкцией системы для соответствия системы поставленным целям. Конкретные свойства системы используют для разработки требуемых функций, необходимых для выполнения задач. Эти свойства представляют собой характерные особенности или атрибуты, присущие системе. Они могут быть классифицированы в основные группы в соответствии со стандартами серии ГОСТ Р МЭК 61069. Каждая группа включает набор характеристик, связанных с доминирующими характеристиками данной группы. Функции являются производными этих свойств системы в результате взаимодействия элементов системы. Взаимодействующие элементы проектируют для получения конкретных характеристик, соответствующих выполнению функций системы и выполнению ее задачи. Характеристики системы могут быть качественными или количественными. На рисунке 1 приведен пример характеристик системы, сгруппированных по различным свойствам системы.

Рисунок 1 — Пример свойств системы и соответствующих характеристик

Примечания

1 Функциональность — степень, с которой система обеспечивает функции выполнения, мониторинга и управления.

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

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

4 Надежность — степень уверенности в том, что система способна выполнять требуемые функции в заданных условиях эксплуатации и окружающей среды в заданный момент времени или в течение заданного интервала времени (см. также ГОСТ 27.002).

5 Обеспеченность технического обслуживания — степень, в которой могут быть обеспечены техническое обслуживание и ремонт системы.

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

4.1.3 Влияющие условия

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

— требования, связанные с выполнением системой своих задач;

— взаимодействие человека с системой;

— процессы, связанные с работой системы;

— воздействия окружающей среды, которым подвергается система;

— доступные услуги по техническому обслуживанию системы;

— внешние услуги, необходимые для работы с системой;

— внешние системы, взаимодействующие с системой;

— ограничения и обязательные требования.

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

4.1.4 Влияющие факторы

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

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

4.1.5 Взаимосвязь свойств системы и влияющих условий

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

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

4.1.6 Реализации функций системы

Система может состоять из таких элементов, как аппаратные средства, программное обеспечение и человек или любой комбинации из этих элементов. Функции системы могут быть реализованы путем использования в конструкции системы аппаратного или программного обеспечения. Для некоторых функций необходимо взаимодействие с человеком для достижения поставленных задач. При создании новой системы функции системы могут быть реализованы на этапе проектирования, конструирования и производства, как описано в ГОСТ Р 27.015. Улучшение системы часто требует введения дополнительных функций для повышения производительности и удаления устаревших функций. В таком случае необходимо учитывать вопросы преемственности, как описано в приложении А.

4.2 Жизненный цикл системы

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

Рисунок 2 — Стадии жизненного цикла системы

Каждая стадия жизненного цикла имеет свои цели:

— целью стадии концепции и определения является идентификация требований к системе и разработка спецификации системы;

— целью стадии проектирования и разработки является выполнение проектирования и разработка функций системы в соответствии с поставленными целями;

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

— целью стадии эксплуатации и технического обслуживания является обеспечение услуг по техническому обслуживанию и поддержке установленного уровня работоспособности системы в эксплуатации;

— целью стадии модернизации является повышение производительности системы путем внедрения дополнительных функций;

— целью стадии распоряжения (утилизации, списания) является прекращение существования объектов системы.

Описание стадий жизненного цикла системы на рисунке 2 является общим для технических систем. Существуют другие описания стадий жизненного цикла системы. В ГОСТ Р 51901.3 описаны стадии жизненного цикла продукции с точки зрения управления проектом. В ГОСТ Р 57193 приведено аналогичное описание стадии жизненного цикла системы с точки зрения программного обеспечения. Существуют различия в использовании терминов, использованных в этих стандартах.

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

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

4.3 Эксплуатация системы

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

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

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

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

Аварийные ситуации и ответные меры должны рассматриваться как отдельные стадии.

4.4 Рабочий профиль системы

Рабочий профиль системы представляет собой последовательность задач, выполняемых системой для достижения целей эксплуатации. Рабочий профиль системы представляет собой конкретный сценарий эксплуатации системы. Например, цель коммерческих перелетов из точки А в точку Б — доставить пассажиров. Эксплуатационный профиль системы связан с задачами выполнения взлета, полета и посадки в ходе конкретной операции. Каждой конкретной задаче соответствуют конкретные мероприятия и условия ее выполнения, установленные для воздушных судов. При завершении или в начале каждой задачи устанавливают критерии определения ее успешности или прерывания дальнейших действий.

Задачи рабочего профиля системы можно решить только путем выполнения функций, предусмотренных конструкцией в системе. С точки зрения эксплуатации некоторые из функций системы критичны, может потребоваться включение конкретных требований надежности для выполнения поставленных задач. Другие функции могут быть некритичными и могут быть необязательными для указанных задач. Например, работа авиационных двигателей является критически важной функцией для выполнения задач взлета, полета и посадки. Однако шасси используются только во время взлета и посадки. Функция шасси не требуется во время полета. Анализ рабочего профиля системы может помочь определить потребности и циклы конкретных функций в процессе эксплуатации. На рисунке 3 показана связь рабочего профиля системы и сценария эксплуатации системы на различных стадиях жизненного цикла.

Рисунок 3 — Связь рабочего профиля системы и сценария эксплуатации системы

4.5 Требования надежности

4.5.1 Требования надежности к функциям системы

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

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

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

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

4.5.2 Показатели надежности и другие характеристики системы

Концепция надежности описана в ГОСТ Р МЭК 60300-1 и определена в ГОСТ 27.002. Свойства и характеристики системы, применимые при установлении требований к надежности и другим свойствам системы, включают:

— готовность;

— безотказность;

— ремонтопригодность;

— обеспеченность технического обслуживания и ремонта.

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

4.5.3 Критерии приемлемости надежности и других свойств системы

Критерии приемлемости надежности и других свойств системы представляют собой (но не ограничиваются) сочетание следующих действий и сведений:

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

— демонстрация успешного завершения испытаний для моделирования функционирования системы, ее неисправностей и восстановления;

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

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

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

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

4.5.4 Верификация надежности функций системы

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

5 Процедура установления требований к системе

5.1 Процесс установления требований к системе

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

На рисунке 4 представлена схема процесса установления требований к системе. На рисунке 4 приведена последовательность действий процесса, показывающая результат действий по определению надежности системы в процессе установления требований к системе. Идентификация системы путем определения требований к функциям системы основана на потребностях пользователей и существующих ограничениях применения системы. Процесс анализа требований преобразует потребности пользователей системы в технические требования к конструкции системы. В процессе проектирования структуры системы формируется решение, которое удовлетворяет требованиям к системе с учетом сценариев эксплуатации системы путем идентификации функций системы. В процессе проектирования и оценки определяют средства реализации функций для облегчения поиска компромиссных решений и оптимизации конструкции при проектировании. Действия по документированию проекта системы обеспечивают информацию о системе, включающую данные о надежности, пригодные для проектирования системы. Подробное описание процесса проектирования надежности системы приведено в ГОСТ Р 27.015.

5.2 Процесс установления требований к надежности системы

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

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

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

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

Рисунок 4 — Схема процесса установления требований к системе

5.3 Определение значений показателей надежности и других свойств системы

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

— готовность: (процент) работоспособного состояния в процессе работы системы при эксплуатации; частота простоев и продолжительность неработоспособного состояния;

— безотказность: среднее время между отказами; продолжительность безотказной работы;

— ремонтопригодность: среднее время до (начала) ремонта; продолжительность восстановления;

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

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

5.4 Процедура определения требований

5.4.1 Описание этапов процедуры

5.4.1.1 Общие сведения

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

5.4.1.2 Идентификация системы

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

5.4.1.3 Описание целей системы

Необходимо установить цель основного применения системы. Цель эксплуатации системы должна быть достижима в соответствии с описанием системы.

5.4.1.4 Идентификация функций, соответствующих целям системы

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

5.4.1.5 Описание функций

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

5.4.1.6 Идентификация влияющих факторов

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

5.4.1.7 Оценка технических подходов для реализации функций

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

5.4.1.8 Описание элементов системы, связанных с функциями

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

5.4.1.9 Определение рабочего профиля системы

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

5.4.1.10 Описание конфигурации системы

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

5.4.1.11 Определение требований к надежности и другим свойствам системы

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

Рисунок 5 — Этапы определения требований к надежности и другим свойствам системы

5.4.1.12 Документирование спецификации системы

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

Документация о спецификации системы должна включать в себя следующие данные:

— идентификация системы;

— цели системы;

— функции системы;

— рабочий профиль системы;

— требования к ремонтопригодности и обеспеченности технического обслуживания системы;

— конфигурация системы;

— требования к надежности для каждой функции;

— утверждение надежности системы.

Приложение А
(справочное)

Оценка показателей надежности и других свойств системы

А.1 Примеры факторов, влияющих на надежность системы

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

А.1.1 Экономические ограничения

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

А.1.2 Нормативные ограничения и обязательные требования

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

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

А.1.3 Тип работы системы

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

А.1.4 Критичность работы системы

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

А.1.5 Тип применения

Система может иметь несколько вариантов использования:

— однократное применение;

— краткосрочное применение и короткий срок сохраняемости;

— краткосрочное применение и длительный срок сохраняемости;

— длительное время применения и короткий срок сохраняемости;

— длительное время применения с техническим обслуживанием;

— длительное время применения без технического обслуживания.

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

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

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

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

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

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

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

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

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

А.1.6 Тип пользователей

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

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

А.1.7 Зависимость взаимодействующих систем

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

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

— Средняя зависимость: система связана с другими системами, но ее функции не зависят от этих систем.

— Низкая зависимость: система не имеет никакой зависимости (помимо источников энергии) от других систем. Она способна работать самостоятельно.

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

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

Пример — Спецификация надежности резервного источника питания должна быть частью спецификации надежности основного источника питания в спецификации системы.

А.1.8 Структура или конфигурация системы

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

тип 1: система аппаратного типа, без применения программного обеспечения или участия человека;

тип 2: система аппаратного типа без применения программного обеспечения, но с существенным участием человека;

тип 3: система с элементами аппаратного и программного обеспечения, но без вмешательства человека в ее работу;

тип 4: система, включающая сочетание аппаратных средств, программного обеспечения и человека.

Для системы типа 1 полностью применимы классические методы надежности в соответствии с ГОСТ 27.003.

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

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

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

А.1.9 Техническая новизна

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

— полностью новая система с использованием новой технологии;

— новая система на основе существующей технологической системы и известных технологий;

— модификация существующей системы.

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

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

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

А.1.10 Новизна выполнения

Новизна выполнения заключается в постановке новых и неизвестных целей эксплуатации.

Примеры:

— постановка совершенно новой задачи эксплуатации системы;

— расширение работы существующей системы для достижения новых целей.

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

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

А.1.11 Вопросы преемственности

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

— сохранение инвестиций в существующую инфраструктуру;

— негативное отношение общества к изменениям и ограничениям;

— страховое покрытие существующих и новых объектов;

— перераспределение текущих ресурсов;

— потребности в обучении для наработки навыков;

— преимущества затрат жизненного цикла и обоснование повышения усилий на разработку.

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

А.1.12 Сложность

Сложность системы должна быть оценена с технической и функциональной точек зрения

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

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

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

А.1.13 Количество используемых систем

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

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

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

Таблица А.1 — Примеры влияющих факторов для каждого влияющего условия


Влияющие условия
Требования задачи (влияющие факторы)	Взаимо- действие с человеком	Процесс	Окружа- ющая среда	Поддержи- вающие услуги	Комму- нальные услуги	Системы взаимо- действия	Другие факторы
Особен- ности задачи	Санкциони- рование доступа и команд	Входы/ выходы	Темпе- ратура	Техническое обслужи- вание	Мощность	Границы	Эконо- мические ограничения
Область применения	Несанкциони- рованное взаимо- действие	Режимы работы	Влажность	Документи- рование	Топливо	Протокол	Обяза- тельные требования
Продолжи- тельность	Поопераци- онное взаимо- действие в работе	Стадии	Вибрация	Техническая поддержка	Энергия	Взаимо- действие	Техни- ческая новизна
Последова- тельность	Обучение	Циклы	Удар	Запасные части	Общест- венные комму- нальные услуги	Зависи- мость	Новизна выполнения
Режим работы	Навыки	Протоколы об отказах	Давление	Специальные средства и инструменты	Частные комму- нальные услуги		Сложность
Система запуска	Интерфейсы		Радиация	Доступность технического обслуживания	Комму- никации		Количество исполь- зуемых систем
Обычный режим работы			Загряз- нение	Уровни поддержки			Степень резерви- рования
Аварийный режим работы			Сохран- ность
Выключение			Транс- порти- ровка

Таблица А.2 — Связь свойств системы с влияющими условиями


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

Приложение В
(справочное)

Пример разработки спецификации системы обеспечения безопасности жилых помещений

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

В.1 Этап 1: Идентификация системы

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

В.2 Этап 2: Описание целей системы

Цели системы:

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

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

В.3 Этап 3: Идентификация функций в соответствии с целями системы

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

a) обнаружения опасностей и вторжения в жилое помещение;

b) управления для обработки информации;

c) сигнализации для оповещения жильцов помещения и служб обеспечения безопасности;

d) службы обеспечения безопасности для защиты жилого помещения и жителей от возможного вреда.

В.4 Этап 4: Описание функций

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

a) Функция обнаружения включает:

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

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

b) Функция управления включает:

— обработку обнаруженных сигналов, полученных с датчиков активации сигналов тревоги. Практическим средством обработки данных является электронный процессор со встроенным программно-аппаратным обеспечением для управления процессором;

— передачу обработанных данных для отображения на панели ручного управления. Практическим средством передачи обработанных данных и отображения является проводное или беспроводное соединение для облегчения обработки сигнала;

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

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

c) Функция сигнализации включает:

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

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

d) Функция службы обеспечения безопасности включает:

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

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

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

В.5 Этап 5: Идентификация факторов, влияющих на функции

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

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


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

В.6 Этап 6: Анализ технических подходов для реализации функций

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

Ключевые технические вопросы включают анализ с точки зрения стоимости, технологии и услуг по обеспечению защиты.


Обнаружение	— Технология — главная составляющая стоимости обнаружения. Типы датчиков включают датчики задымления и движения, магнитные и электрические датчики с доказанной безотказностью, которые отвечают большинству требований к обнаружению. Такие датчики доступны в различных формах и конфигурациях по разумной цене, но они требуют прямого проводного подключения в жилом помещении. Это влияет на стоимость установки. Существуют более дорогие датчики для обнаружения нарушения целостности стекол на окнах и беспроводные датчики контроля доступа для коммерческого применения. Такие датчики используют более передовую технологию по премиальной цене, но обычно они не оправданно дороги для жилых помещений. Беспроводная технология для датчика обнаружения более восприимчива к помехам, вызывающим ложную тревогу. Однако новые датчики, разработанные по усовершенствованным технологиям, применимы для больших комплексов зданий для того, чтобы облегчить установку, модификацию, техническое обслуживание и ремонт.
Управление	— Базовая конструкция блока управления является надежной, недорогой и коммерчески доступной. Блок управления является «сердцем» системы сигнализации жилого помещения, обеспечивая большую часть эксплуатационных функций, обычно необходимых для использования сигнализации в жилых помещениях. Беспроводная технология, включенная в новый проект системы, облегчает установку и техническое обслуживание, но по премиальной цене. Резервная батарея имеет срок от 3 лет до 5 лет. С точки зрения домашнего пользователя, нет никакой разницы при функционировании между проводной системой и беспроводной системой.
Сигнализация	— Все системы используют аналогичные устройства сигнализации. Нет никакой принципиальной разницы в стоимости или технологиях.
Обеспечение безопасности	— Поставщики услуг безопасности могут предлагать различные условия договоров на техническое обслуживание в соответствии с потребностями домовладельцев. Данные условия договоров основаны в первую очередь на первоначальной установке системы, гарантийных схемах и последующих услугах по техническому обслуживанию и сроках действия договора. Существуют некоторые незначительные изменения по стоимости и условиям договоров вследствие конкуренции на рынке бизнеса по предоставлению услуг по обеспечению безопасности жилых помещений. Целесообразно провести анализ стоимости жизненного цикла для обоснования инвестиций в приобретение и владение системой обеспечения безопасности жилого помещения в течение всего срока ее службы. Оборудование, установленное для сигнализации жилого помещения, должно иметь срок службы не менее 15 лет. Следует проводить регулярное техническое обслуживание и тестирование системы обеспечения безопасности.

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


Аппаратные средства	— Все аппаратные средства системы сигнализации жилого помещения могут быть встроены и установлены в жилых помещениях. Система автоматизирована. Система требует минимального внимания к своим эксплуатационным функциям. Техническое обслуживание и проверка безопасности являются простыми процедурами.
Программное обеспечение	— Блок управления системой включает встроенное программное обеспечение для управления функциями обработки. Программирование и изменение кодов доступа могут быть выполнены напрямую. Руководство по эксплуатации сигнализации жилого помещения предусматривает пошаговую процедуру программирования.
Человек	— Сигнализация жилого помещения разработана для обеспечения пригодности к использованию в соответствии с правилами обеспечения безопасности для работы системы обеспечения безопасности жилого помещения. Удобный доступ к дисплею панели управления облегчает диагностику и связь во время ежедневного нормального режима функционирования. Если срабатывает сигнализация, что приводит к срабатыванию режима оповещения службы обеспечения безопасности, реагирующие органы безопасности (т.е. полиция, пожарная охрана, скорая медицинская помощь, поставщик услуг безопасности) следуют стандартному протоколу в соответствии с установленными процедурами. Процедуру проверки ложной тревоги осуществляют по стандартному протоколу, инициированному поставщиком услуг обеспечения безопасности. Домовладелец может отменить ложную тревогу, введя установленный код доступа к панели управления. Уровень ложной тревоги очень важен для системы обеспечения безопасности жилого помещения.

В.8 Этап 8: Определение рабочего профиля системы

Различные сценарии могут быть установлены для обеспечения определенного рабочего профиля во время срабатывания режима тревоги службы обеспечения безопасности. Ниже приведены три типичных примера:

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

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

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

В.9 Этап 9: Описание конфигурации системы для достижения целей системы

а) В нормальном режиме функционирования

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

Рисунок В.1 — Конфигурация системы в нормальном режиме функционирования

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

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

Рисунок В.2 — Конфигурация системы в режиме тревожной кнопки

с) В режиме оповещения службы обеспечения безопасности с использованием сценария оповещения службы обеспечения безопасности

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

Элемент «человек» подразумевает участие сотрудника службы обеспечения безопасности и делает необходимые телефонные звонки.

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

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

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

На рисунке В.3 показана конфигурация системы в режиме оповещения службы обеспечения безопасности.

Рисунок В.3 — Конфигурация системы в режиме оповещения службы обеспечения безопасности

В.10 Этап 10: Определение требований к надежности

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

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

Система сигнализации жилого помещения:

— функция обнаружения: коэффициент готовности 99,5%; ежегодное техническое обслуживание, средний ресурс 15 лет;

— функция управления: коэффициент готовности 99,9%; ежемесячная проверка системы обеспечения безопасности, средний ресурс 20 лет;

— функция сигнализации: коэффициент готовности 99,9%; ежегодное техническое обслуживание, ожидаемый ресурс 20 лет.

Система защиты службы обеспечения безопасности:

— функция дежурного службы безопасности: коэффициент готовности 99,7% с заменой персонала каждые 24 ч, круглогодичное обслуживание сигнала тревоги;

— функция телефонной связи: коэффициент готовности 99,9997% для обслуживания проводной линии;

— функция транспортных средств: коэффициент готовности 99,8% при наличии резервных транспортных средств или других способов транспортировки, время реагирования (отклика) в пределах 10 мин.

В.11 Этап 11: Документирование требований к надежности системы

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

a) Идентификация системы

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

b) Цели системы

Автоматизированное обнаружение и подача сигнала тревоги для защиты жилого помещения службами безопасности.

c) Рабочий профиль системы:

— нормальный режим функционирования;

— режим функционирования с использованием тревожной кнопки;

— режим обеспечения безопасности функционирования.

d) Требования к ремонтопригодности и обеспеченности технического обслуживания

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

e) Конфигурация системы

На этапе 9 приведено описание конфигураций системы в каждом режиме функционирования.

f) Функции системы:

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

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

g) Требования к надежности каждой функции

1) Домашняя система сигнализации

— Функция обнаружения: коэффициент готовности 99,5%; ежегодное техническое обслуживание, средний ресурс 15 лет.

— Функция управления: коэффициент готовности 99,9%; ежемесячная проверка системы обеспечения безопасности, средний ресурс 20 лет.

— Ожидаемый ресурс резервной батареи составляет 5 лет. Рекомендуемая замена каждые 3 года.

— Функция сигнализации: коэффициент готовности 99,9%; ежегодное техническое обслуживание, средний ресурс 20 лет.

2) Система защиты службы обеспечения безопасности

— Функция дежурного службы безопасности: коэффициент готовности 99,7% с заменой персонала каждые 24 ч, круглогодичное обслуживание сигнала тревоги.

— Функция телефонной связи: коэффициент готовности 99,9997% для обслуживания проводной линии.

— Функция транспортных средств: коэффициент готовности 99,8% при наличии резервных транспортных средств или других способов транспортировки.

h) Утверждение о надежности системы

1) Коэффициент готовности системы сигнализации жилого помещения: 99,3%.

2) Коэффициент готовности системы защиты службы обеспечения безопасности: 99,5%.

3) Коэффициент готовности системы обеспечения безопасности жилого помещения: 98,8%.

Приложение ДА
(справочное)

Таблица ДА.1


Обозначение ссылочного национального, межгосударственного стандарта	Степень соответствия	Обозначение и наименование ссылочного международного стандарта
ГОСТ 27.003-2016	NEQ	IEC 60300-3-4:2007 «Управление надежностью. Часть 3. Руководство по применению. Раздел 4. Руководство по заданию технических требований к надежности»
ГОСТ Р 27.015-2019	MOD	IEC 60300-3-15:2009 «Менеджмент обеспечения надежности. Часть 3-15. Руководство по применению. Проектирование надежности системы»
ГОСТ Р 51901.3-2007 (МЭК 60300-2:2004)	MOD	IEC 60300-2:2004* «Менеджмент надежности. Часть 2. Руководство по менеджменту надежности»
ГОСТ Р 57193-2016	NEQ	ISO/IEC/IEEE 15288:2016 «Системная и программная инженерия. Процессы жизненного цикла системы»
ГОСТ Р МЭК 60300-1-2017	IDT	IEC 60300-1:2014 «Менеджмент надежности. Часть 1. Руководство по управлению и применению»
ГОСТ Р МЭК 61069-1-2017	IDT	IEC 61069-1:2016 «Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 1. Терминология и общие концепции»
ГОСТ Р ИСО 9000-2015	IDT	ISO 9000-2015 «Системы менеджмента качества. Основные положения и словарь»
Примечание — В настоящей таблице использованы следующие условные обозначения степени соответствия стандартов: — MOD — модифицированные стандарты; — IDT — идентичные стандарты; — NEQ — неэквивалентные стандарты.

________________
* Заменен на IEC 60300-1:2014.


УДК 621.745.552:006.354	ОКС 03.120.01

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

Электронный текст документа

и сверен по:

, 2019

Источник

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

27.015—

2019

(МЭК 60300-3-15: 2009)

Надежность в технике

УПРАВЛЕНИЕ НАДЕЖНОСТЬЮ

Руководство по проектированию надежности систем

(IEC 60300-3-15:2009, Dependability management —

Part 3-15: Application guide — Engineering of system dependability, MOD)

Издание официальное

Москва

Стандартинформ

2019

Предисловие

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 119 «Надежность в технике»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 ноября 2019 г. № 1275-ст

4 Настоящий стандарт является модифицированным по отношению к международному стандарту МЭК 60300-3-15:2009 «Менеджмент надежности. Часть 3-15. Руководство по применению. Проектирование надежности системы» (IEC 60300-3-15:2009 «Dependability management — Part 3-15: Application guide — Engineering of system dependability». MOD) путем внесения технических отклонений, объяснение которых приведено во введении к настоящему стандарту.

Международный стандарт разработан Техническим комитетом по стандартизации ТС 56 Международной электротехнической комиссии (МЭК).

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

5 ВВЕДЕН ВПЕРВЫЕ

Правипа применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по соспюянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www gost.ru)

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

Рисунок 1 — Стадии жизненного цикла системы

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

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

a) определение требований, идентифицирующее требования пользователей и ограничения в области применения системы;

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

c) разработка структуры, синтезирующей решение, удовлетворяющее требованиям к системе 8 соответствии со сценариями ее эксплуатации, с выделением функций аппаратного, программного обеспечения и человеческого фактора;

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

e) создание системы проектной документации, охватывающей сведения о системе, включая данные о надежности проектируемой системы;

0 проектирование системы и подсистем, обеспечивающее выполнение требуемых функций системы и подсистем;

д) создание элементов системы и подсистем в форме аппаратного и программного обеспечения:

h) интеграция системы и подсистем в соответствии со структурой, предусмотренной проектом;

i) верификация системы, подтверждающая, что установленные требования к конструкции выполнены;

j) установка (монтаж), обеспечивающая системе возможность работать с требуемой производительностью в заданных условиях;

k) валидация и ввод в эксплуатацию, обеспечивающие объективные свидетельства того, что система соответствует функциональным требованиям;

l) эксплуатация системы, обеспечивающая оказание системой соответствующих услуг;

т) техническое обслуживание, обеспечивающее возможность эксплуатации системы;

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

р) вывод из эксплуатации и демонтаж системы, завершающие существование системы.

6.1.3 Применение процесса на протяжении жизненного цикла системы

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

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

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

Воздействующие факторы (процедуры, правила, ограничения)

_I_

Входы

(данные.

материалы.

требования)

Выходы (обработанные данные, продукция, услуги)

Процесс

Обеспечивающие механизмы (человеческие и материальные ресурсы, инструменты и методы)

Рисунок 2 — Пример модели процесса

Технические процессы используют для двух целей:

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

b) выполнение действий эксплуатации, технического обслуживания и распоряжения в отношении системы.

Применение технических процессов является одновременно рекурсивным и итеративным до достижения желаемого решения. Это относится ко всем стадиям жизненного цикла системы. Взаимодействие технических процессов не зависит от размера системы и ее структуры. Действия процесса, такие как определение требований, анализ требований и проектирование структуры системы являются техническими подходами «сверху вниз» для получения желаемого решения (т. е. декомпозиции системы вплоть до ее составляющих элементов); вместе с тем интеграция и верификация являются подходами «снизу вверх» к разработке конфигурации системы и валидации ее работоспособности (т. е. создание сначала элементов, а затем системы в целом). Переход от подхода «сверху вниз» к подходу «снизу вверх» происходит при завершении установки системы в начале ввода ее в эксплуатацию. Это называют моделью «V» в инженерной практике, она описана в ГОСТ Р 57193.

Примечание — Для получения дополнительной информации о модели «V» см. ГОСТ Р ИСО/МЭК ТО 15271.

В ГОСТ Р ИСО/МЭК 12207 установлены границы процессов жизненного цикла программного обеспечения. Приведено описание процессов, действий и задач, которые могут быть применены при приобретении программного продукта или услуги и при установке, разработке, эксплуатации, техническом обслуживании и распоряжении программных продуктов. Этот документ может быть использован самостоятельно или вместе с ГОСТ Р 57193.

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

6.2 Достижение надежности системы

6.2.1 Цель

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

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

6.2.2 Критерии достижения надежности системы

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

a) четкое понимание целей работы системы:

b) глубокое понимание условий эксплуатации:

c) результативное выполнение принципов надежности в рабочей структуре;

d) условия использования:

e) применение соответствующих процессов при изготовлении системы;

0 использование знаний и опыта для экономически эффективного внедрения системы.

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

1) Политика менеджмента надежности. Данный критерий влияет на рабочую инфраструктуру, распределение соответствующих ресурсов, распределение ответственности и лидерство надежности проекта. Значение политики в области надежности отражает ориентацию потребителя на стратегию и обязательства, совместные усилия и систематический процессный подход для эффективного применения принципов менеджмента надежности, описанных с ГОСТ Р МЭК 60300-1. Политику менеджмента надежности в соответствии с ГОСТРМЭК 60300-1 применяют ко всем техническим процессам, описанным в настоящем стандарте;

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

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

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

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

блем. Вспомогательные системы не всегда являются технически сложными, требующими специальных навыков для их понимания и использования. Некоторые из методологий представляют собой просто контрольные перечни и инструкции по принятию решений для операторов и специалистов по техническому обслуживанию при эксплуатации системы. Дополнительная информация о вспомогательных системах приведена в ГОСТ Р 57193,

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

6.2.3 Методология обеспечения надежности системы

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

Существует два подхода к обеспечению надежности функций системы:

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

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

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

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

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

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

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

6.2.4 Реализация функций системы

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

a) Аппаратное обеспечение представляет собой оборудование, широко используемое в конструкции системы. Оно может состоять из механических, электрических, электронных, оптических и других физических компонентов. Они используются в различных конфигурациях для реализации функций аппаратного обеспечения. Большая часть электронной продукции включает в себя элементы аппаратного обеспечения, которые являются относительно изученными при применении. Правила разработки четко установлены. Электронная продукция демонстрирует работоспособность в контролируемых условиях процесса производства. Качество и надежность продукции могут быть установлены соответствующими программами гарантии. Также имеется достаточно большое количество баз данных об испытании и эксплуатации электронной продукции, включающей аппаратные средства, полезные для обеспечения безотказности системы. Однако некоторые виды продукции с активными электронными компонентами чувствительны к различным условиям применения Физические свойства таких компонентов доминируют среди отказов элементов аппаратного обеспечения, а также причин феномена детской смертности. Конструкция, упаковка и проверка, соответствующие надлежащей безотказности, могут помочь значительно снизить количество отказов. Некоторые элементы аппаратного обеспечения могут изнашиваться в процессе эксплуатации или использования, в то время как другие могут иметь ограниченный срок хранения. Эти проблемы обеспечения безотказности могут быть решены путем осуществления профилактического планового технического обслуживания. Структура аппаратных систем является иерархической. Стратегия технического обслуживания может быть разработана собственными силами на основе функционального проектирования и представлять собой стратегию замены простейших сборочных элементов. Это облегчает техническое обслуживание конструкции и логистическое обеспечение системы и способствует улучшению показателей готовности системы;

b) программное обеспечение состоит из закодированных инструкций, компьютерных программ, установленных правил и процедур работы системы. Закодированные команды используются в программном обеспечении, осуществляющем управление выполнением функций системы. Программные коды трудно проверить на наличие ошибок кодирования без фактического выполнения компьютерных операций. Сбой программного обеспечения, приводящий к отказу системы, обусловлен активацией скрытой ошибки в программном обеспечении. Аккуратность при создании программного обеспечения необходима для минимизации возможного проявления непреднамеренных ошибок в разработке. Используемые подходы включают предотвращение отказов, устранение отказов и обеспечение отказоустойчивости. Они являются формализованными методами создания программного обеспечения. Хотя программное обеспечение не изнашивается, его функции могут ухудшаться вследствие введенных изменений. Поскольку программное обеспечение создается при участии человека, контроль за его созданием сосредоточен на условиях разработки программного обеспечения. Использование методологии «моделей зрелости» как основы для разработки программного обеспечения может быть способом обеспечения надежности функций программного обеспечения. Вопросы программного обеспечения и версии для его обновления должны быть под контролем процесса управления конфигурацией системы для поддержания совместимости функций и повышения надежности системы в эксплуатации;

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

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

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

6.2.5 Способы определения достижения надежности системы

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

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

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

— документальную демонстрацию надежности;

— показатели готовности в течение гарантийного периода;

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

— прогнозирование состояния системы с заданной конфигурацией;

— применение моделирования;

— применение моделей зрелости;

— верификация испытаний системы;

c) прогрессивные свидетельства представляют собой объективные доказательства, полученные в контрольных точках разработки проекта на основе аргументов. Типичные примеры включают:

— безотказность и техническое обслуживание;

— программу повышения надежности.

6.2.6 Объективные свидетельства достижения надежности системы

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

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

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

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

d) Заявление о характеристиках надежности и ремонтопригодности системы при эксплуатации и техническом обслуживании. Это заявление обеспечивает информацию для планирования и ло-12

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

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

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

6.3 Оценка надежности системы

6.3.1 Цель оценки надежности системы

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

6.3.2 Виды оценок

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

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

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

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

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

— идентификацию критических вопросов надежности, влияющих на удобство обслуживания и работоспособность системы;

— оценки надежности продукции потенциальных поставщиков и субподрядчиков;

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

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

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

— оценка функций системы, влияющих на показатели надежности;

— оценка структуры системы для оптимизации конфигурации системы с точки зрения безотказности;

— оценка доступности технического обслуживания.

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

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

— оценка программ надежности поставщиков и субподрядчиков;

— оценка производства приобретаемой продукции, влияющей на повышение безотказности;

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

c) Изготовление и производство системы. Целью является выполнение решений о приобретении и разработке элементов подсистем и выполнение обязательств по выделению ресурсов для изготовления и интеграции системы. Ключевыми оценками надежности на стадии изготовления и производства являются:

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

— оценка соответствия подсистем требованиям надежности;

— оценка процесса обеспечения качества;

— оценка результатов испытаний подсистем для интеграции системы;

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

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

— оценка работы системы путем наблюдения за эксплуатацией системы и ведения записей об инцидентах;

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

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

— оценка технического обслуживания системы в эксплуатации и эффективности логистического обеспечения;

— выполнение процедур управления изменениями проекта и управления конфигурацией.

e) Улучшение системы. Целью является обоснование инвестиций для улучшения и модернизации существующей системы. Эти действия включают действия, аналогичные мероприятиям по проектированию и разработке новой системы и модернизации части системы. Для обеспечения функциональной совместимости и возможности улучшения работы системы следует рассмотреть вопросы преемственности существующей системы. Ключевыми оценками надежности системы на стадии улучшения системы являются:

— анализ стоимости и получаемых преимуществ для выполнения изменений;

— оценка влияния на показатели надежности изменений, связанных с добавлением новых свойств;

— реакция потребителей на предлагаемые изменения;

— оценка риска и значения улучшений.

О Вывод системы из обращения или эксплуатации. Целью является изъятие системы из эксплуатации. Ключевыми оценками надежности на стадии вывода из эксплуатации являются:

— оценка стоимости вывода системы из эксплуатации;

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

6.3.3 Методология оценки надежности системы

Методология оценки надежности связана с вопросами, касающимися процессов, подходов и стратегий.

Методология оценки надежности охватывает два важных процесса верификации и валидации:

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

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

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

1) аналитического подхода включающего в себя такие действия, как анализ проектирования, моделирование системы, проверка соответствия стандартам и оценка соответствия спецификации;

2) экспериментального подхода включающего в себя такие действия, как испытания и техническая оценка функций системы, сборочных единиц приобретаемой продукции, интеграции подсистем, и приемка реальной системы;

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

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

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

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

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

6.3.4 Значимость и последствия оценки

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

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

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

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

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

6.4 Измерение надежности системы

6.4.1 Цель

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

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

b) определение соответствующих данных и особенностей источников, данных для измерений;

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

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

e) документирование результатов измерений для хранения записей и объективных свидетельств аудита качества:

О в [1] установлен процесс измерений, применимый к проектированию систем и программного обеспечения.

6.4.2 Классификации

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

a) Измерения присущих системе свойств надежности. Целью измерения является присвоение значения, характеризующего присущие системе свойства надежности. Этот класс измерений полезен для сопоставления свойств надежности проектов системы с различной структурой и конфигурацией. Процесс измерения выполняют на стадии концепции и определения системы для определения показателей надежности альтернативных вариантов. Цель направлена на обеспечение свидетельств возможности соответствия системы целям в области надежности для контрактных предложений или запросов. Количественные значения могут быть установлены в виде вероятности работоспособного состояния, среднего времени между отказами, ресурса или интенсивности отказов, которые количественно характеризуют готовность или безотказность системы. Измерения обычно выполняют методами прогнозирования в соответствии с ГОСТ Р 27.301.

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

Содержание

1 Область применения………………………………………………………..1

2 Нормативные ссылки………………………………………………………..1

3 Термины и определения……………………………………………………..2

4 Обеспечение надежности системы при проектировании………………………………3

5 Менеджмент надежности системы………………………………………………5

6 Выполнение обеспечения надежности системы…………………………………….6

Приложение А (справочное) Процессы жизненного цикла системы и их применение………….19

Приложение В (справочное) Методы разработки и обеспечения надежности системы…………27

Приложение С (справочное) Руководство по условиям применения систем…………………32

Приложение D (справочное) Контрольные перечни для обеспечения надежности систем………36

Приложение ДА (справочное) Сведения о соответствии ссылочных национальных и

межгосударственных стандартов международным стандартам, использованным

в качестве ссылочных в примененном международном стандарте…………..41

Библиография……………………………………………………………..43

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

c) Измерения надежности системы для улучшения ее работы. Целью является присвоение значений для количественного и качественного определения степени удовлетворенности потребителя или для определения значимости для потребителя улучшения системы. Это косвенные измерения, которые помогают определить влияние существенных свойств надежности на работу системы. Этот класс измерений направлен на поиск прямой и обратной связи с потребителем о работе системы или на определение значения обслуживания системы на этапе эксплуатации и технического обслуживания. Процесс измерений проводят посредством обследования пользователей, аудита, оценки рыночной цены, прямых контактов и диалога с потребителями и поставщиками. Обследования удовлетворенности потребителей направлены на выявление вопросов, волнующих потребителя. Разработку функций качества, как правило, используют для оценки работы системы, определения потребностей потребителей их преобразования в соответствующие технические требования и определения последующих действий в соответствии с этими требованиями. Значения могут быть установлены по шкале от 1 до 5 включительно для обозначения рейтингов от «плохо» до «превосходно».

d) Измерения надежности системы для определения экспозиции риска. Целью измерений является назначение количественного значения экспозиции риска, когда систему используют для охраны и безопасности. Это косвенное измерение для определения критичности свойств надежности, влияющих на работу функций системы. Этот класс измерений выполняют на стадии концепции и определение системы для выявления критических функций и элементов системы для конкретного применения системы или выполнения системой установленной задачи. Процесс оценки включает в себя определение вреда или угрозы, путем назначения их значимости и частоты возникновения. Классификация рисков может быть установлена качественно путем кпассификации событий, на катастрофические, критические, крупные, мелкие или незначительные. Значения вероятности присваивают для указания серьезности ситуации, например, один критический отказ за 10 лет. В ГОСТ Р 51901.1 установлены методы оценки риска, влияющего на надежность работы системы. Подобный метод использован в стандартах серии ГОСТРМЭК 61508 (см. также ГОСТ IEC 61508-3) по уровням безопасности для ранжирования функций безопасности (см. также ГОСТР МЭК 61508-1).

6.4.3 Источники измерений

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

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

6.4.4 Вспомогательные системы

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

Введение

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

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

Рассмотрены четыре основных аспекта проектирования надежности:

— процесс.

— достижение цели.

— оценка.

— измерение.

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

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

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

Настоящий стандарт является одним из стандартов на системы надежности (см, ГОСТ Р МЭК 60300-1 и ГОСТ Р 51901.3). В настоящем стандарте приведены ссылки на применимые к системам действия управления проектом. Они включают в себя определение надежности элементов, задачи, относящиеся к системе и руководящие принципы анализа менеджмента надежности и отработки проекта в части надежности.

В настоящем стандарте ссылки на международные стандарты заменены ссылками на национальные стандарты.

ГОСТ P 27.015—2019 (МЭК 60300-3-15:2009)

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Надежность в технике

УПРАВЛЕНИЕ НАДЕЖНОСТЬЮ

Руководство по проектированию надежности систем

Dependability In technics Dependability management Guide for engineering of system dependability

Дата введения — 2020—07—01

1 Область применения

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

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

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

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ 27.002-2015 Надежность в технике. Термины и определения

ГОСТ IEC 61508-3 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению

ГОСТ Р 27.014 Надежность в технике. Управление надежностью. Руководство по установлению требований к надежности систем

ГОСТ Р 27.301 Надежность в технике. Управление надежностью. Техника анализа безотказности. Основные положения

ГОСТ Р 27.606 Надежность в технике. Управление надежностью. Техническое обслуживание, ориентированное на безотказность

ГОСТ Р 51901 1 Менеджмент риска Анализ риска технологических систем ГОСТ Р 51901.3 Менеджмент риска. Руководство по менеджменту надежности ГОСТ Р 51901.6 (МЭК 61014:2003) Менеджмент риска. Программа повышения надежности ГОСТ Р 51901.16 (МЭК 61164:2004) Менеджмент риска. Повышение надежности. Статистические критерии и методы оценки

ГОСТ Р 53392 Интегрированная логистическая поддержка. Анализ логистической поддержки. Основные положения

ГОСТ Р 53613 (МЭК 60721-2-2:1988) Воздействие природных внешних условий на технические изделия Общая характеристика. Осадки и ветер

ГОСТ Р 53614 (МЭК 60721-2-3:1987) Воздействие природных внешних условий на технические изделия. Общая характеристика. Давление воздуха

Издание официальное

ГОСТ Р 53615 (МЭК 60721-2-4:1987) Воздействие природных внешних условий на технические изделия. Общая характеристика. Солнечное излучение и температура

ГОСТ Р 57193 Системная и программная инженерия. Процессы жизненного цикла систем ГОСТ Р ИСО 10007 Менеджмент организации. Руководящие указания по управлению конфигурацией

ГОСТ Р ИСО/МЭК 12207 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств

ГОСТ Р ИСО/МЭК 15026 Информационная технология. Уровни целостности систем и программных средств

ГОСТ Р МЭК 60300-1 Менеджмент риска. Руководство по применению менеджмента надежности ГОСТ Р МЭК 61508-1 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 1. Общие требования

ГОСТ Р МЭК 61508-2 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 2. Требования к системам

ГОСТ Р МЭК 61508-4 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 4. Термины и определения

ГОСТ Р МЭК 61508-5 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 5 Рекомендации по применению методов определения уровней полноты безопасности

ГОСТ Р МЭК 61508-6 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 6. Руководство по применению ГОСТ Р МЭК 61508-2 и ГОСТ Р МЭК 61508-3

ГОСТ Р МЭК 61508-7 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Методы и средства

ГОСТ ИСО/МЭК ТО 15271 Информационная технология Руководство по применению ГОСТ Р ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия) Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку

3 Термины и определения

В настоящем стандарте применены термины по ГОСТ 27.002. а также следующие термины с соответствующими определениями:

3.1 система (system): Набор взаимосвязанных объектов, рассматриваемый для определенной цели как единое целое, отделенный от других объектов¹).

Примечания

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

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

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

4 Структура системы может быть иерархической, например система, подсистемы, компоненты ит.д ¹

3.2 подсистема (subsystem): Система, которая является частью более сложной системы²¹.

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

Примечания

1 Конфигурации и сценарии эксплуатации системы влияют на режимы эксплуатации системы

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

3.4 функция (function): Элементарное действие, выполняемое системой, которое в сочетании с другими элементарными действиями (функциями системы) позволяет системе выполнить задачу.

3.5 элемент (element): Комбинация компонентов, которые составляют базовый блок, необходимый для выполнения отдельной функции³¹.

Примечания

1 Элемент может включать компоненты аппаратного и/или программного обеспечения, информацию и/или человека.

2 Для некоторых систем информация и данные являются важной частью работы системы

3.6 целостность (integrity): Способность системы поддерживать свою форму, сохранять стабильность и работоспособное состояние при работе и использовании.

4 Обеспечение надежности системы при проектировании

4.1 Общие сведения

Надежностью называют свойство системы сохранять во времени способность выполнять требуемые функции в соответствии с заданными целями и условиями применения (см. также 3.1.5 ГОСТ 27.002-2015). Свойства системы описывают показатели надежности (готовность, безотказность. ремонтопригодность, долговечность и др ). а также такие характеристики, как отказоустойчивость. восстанавливаемость, целостность, безопасность и обеспеченность техническим обслуживанием. Надежность системы означает, что система способна выполнять по запросу требуемые функции и удовлетворять потребности пользователя. Цель, структура, свойства системы и условия, влияющие на надежность системы, описаны в ГОСТ Р 27.014. в котором приведено руководство по определению соответствующих функций системы для установления требований к надежности системы.

Существует четыре основных аспекта проектирования надежности систем:

a) процесс обеспечения надежности — устанавливает технические процессы разработки системы. позволяющие обеспечить выполнение требований к надежности системы. Этот процесс состоит из разработки последовательности действий, осуществляемых на каждой стадии жизненного цикла для достижения установленных целей надежности системы. Процесс обеспечения надежности должен быть полностью интегрирован в процессы проектирования и управления;

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

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

d) оценка (измерение) показателей надежности и характеристик системы — количественное определение показателей надежности и других характеристик системы для включения в контракты, спецификации. Этот процесс состоит в присвоении количественного значения или числа целевому по-

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

4.2 Свойства, показатели надежности и характеристики системы

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

Важными свойствами надежности и характеристиками системы являются следующие:

a) готовность: свойство системы быть в состоянии выполнять требуемые функции в соответствии с заданными требованиями к системе. Показателями готовности являются процент продолжительности работоспособного состояния системы в соответствии с требованиями и продолжительность неработоспособного состояния;

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

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

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

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

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

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

д) доступность услуги: способность услуги быть полученной в пределах заданных границ и других условий по запросу пользователя. Измеримым показателем является вероятность доступности услуги;

h) сохранение услуги: свойство услуги однажды полученной пользователем быть непрерывно поддерживаемой в заданных условиях в течение требуемого периода. Измеримым показателем является вероятность сохранения услуги в течение заданного периода времени.

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

Показатели надежности системы определяют на основе измерений времени (наработки) и параметров. характеризующих инцидент. Инцидент — это нежелательное или непредвиденное событие, наблюдаемое в процессе испытаний или эксплуатации системы. Следует документировать и расследо-4

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

5 Менеджмент надежности системы

5.1 Менеджмент надежности

Надежность является технической дисциплиной и основана на инженерных принципах и практике. ГОСТ Р МЭК 60300-1 и ГОСТ Р 51901.3 использованы в настоящем стандарте для построения стратегий менеджмента надежности и общего применения технических подходов для решения задач надежности и обеспечения надежности элементов. Кроме того, для достижения конкретных целей менеджмента введены процессы менеджмента надежности. Менеджмент надежности включает в себя планирование работ по проектированию, распределению ресурсов, определению задач надежности, мониторингу и обеспечению надежности, измерению результатов, анализу данных и постоянному улучшению. Деятельность в области надежности следует сочетать с действиями в области других технических дисциплин. Это позволяет улучшить результаты разработки проекта. Необходима отработка проекта для обеспечения рентабельного менеджмента проекта системы. Там. где это применимо, следует использовать анализ стоимости жизненного цикла для распределения ресурсов и оптимизации оценки стоимости проекта.

5.2 Обеспечение надежности системы при проектировании

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

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

a) использование новых технологий;

b) разработка требований к надежности системы и ее подсистем;

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

d) оценка возможностей поставщиков для выполнения требований надежности;

e) гарантии надежности для приемки системы.

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

5.3 Учет требований проекта

Обеспечение надежности системы направлено на решение конкретных вопросов надежности системы. Учет требований проекта необходим для управления распределением доступных ресурсов и

См 3.4.1 ГОСТ 27 002—2015

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

a) бюджетное планирование распределения ресурсов надежности в соответствии с целями проекта:

b) оценка альтернативных технологий для приобретения высоконадежных комплектующих;

c) применение аутсорсинга при разработке подсистем в соответствии со строгими критериями требований к программному обеспечению, где это имеет решающее значение:

d) обучение в течение необходимого времени для получения достаточного опыта использования новых методов анализа надежности;

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

Руководящие принципы учета требований проектирования описаны в ГОСТ Р 51901.3.

5.4 Мероприятия, гарантирующие обеспечение надежности

Мероприятия менеджмента надежности должны быть частью процесса менеджмента качества при проектировании системы. Это необходимо для обеспечения того, что все спланированные и систематические действия выполнены в соответствии с системой менеджмента качества и продемонстрировали по мере необходимости достаточную уверенность в том. что требования к качеству системы и приобретаемых объектов выполнены. Основные действия включают: планирование, распределение ответственности в технической и организационной сфере, верификацию результатов оценки надежности, валидацию данных о надежности системы, мониторинг результативности процесса менеджмента надежности, ведение записей об отказах и анализ данных для оперативных корректирующих и предупреждающих действий, документирование соответствующей информации о надежности и ведение протоколов испытаний для поддержки объективных свидетельств и анализа со стороны руководства для инициирования процесса улучшения В ГОСТ Р 51901.3 приведена дополнительная информация по выбору элементов программы надежности и задач обеспечения надежности системы.

6 Выполнение обеспечения надежности системы

6.1 Процесс обеспечения надежности

6.1.1 Цель процесса

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

6.1.2 Жизненный цикл системы и процессы

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

Описание стадий жизненного цикла системы можно рассматривать с точки зрения конструирования систем. Существуют также и другие описания жизненного цикла системы. В ГОСТ Р 51901.3 стадии жизненного цикла объекта описаны с точки зрения управления проектом. В ГОСТ Р 57193 приведено аналогичное описание стадий жизненного цикла системы с точки зрения информационных технологий и разработки программного обеспечения. Рекомендации настоящего стандарта основаны на концепции стадий жизненного цикла системы в соответствии с описанием, приведенным на рисунке 1. Завершение каждой стадии жизненного цикла системы является точкой перехода на другую стадию жизненного цикла, тогда как этапы проекта могут перекрываться (по решению руководства) для достижения основных целей бизнеса. Менеджмент риска в соответствии с ГОСТ Р 51901.3 применяют на протяжении всего жизненного цикла системы.

Приведенное определение несколько отличается от стандартизованного (см 3 13 ГОСТ 27 002—2015).

Приведенное определение несколько отличается от стандартизованного (см 3.1.4 ГОСТ 27 002—2015).

Внутреннюю структуру элемента не учитывают, рассматривая его как неделимый обьект (см. 3.1.2 ГОСТ 27 002—2015).

Источник

Надежность в технике. Управление надежноcтью. Руководство по заданию технических требований к надежности

В документе освещены следующие темы:

Настоящий стандарт представляет собой руководство по заданию требуемых характеристик надежности в техническом задании и технических условиях, а также требования к процедурам и критериям верификации и валидации. Руководящие указания включают в себя: — рекомендации по количественному и качественному заданию показателей готовности, безотказности, ремонтопригодности и обеспечению технического обслуживания; — рекомендации потребителям системы относительно того, как обеспечить выполнение поставщиками предъявляемых требований; — рекомендации поставщикам, помогающие им выполнить требования потребителя. Методы настоящего стандарта касаются в первую очередь систем и изделий, но они могут быть применены и на уровне отдельных составных частей или компонентов. В настоящем стандарте использован термин «система»

В нашем электронном каталоге подзаконных нормативных актов, вы получите возможность получить документ ГОСТ Р 27.003-2011. Объем страниц документа составляет 1 стр. Мы имеем огромную базу документов ГОСТ Р. Для более удобного скачивания мы подогнали все файлы в популярные форматы PDF и DOC и оптимизировали файл до размера 1.2 МБ. Данный акт нормативной документации издан 13.03.2013 и введен 01.09.2012. В нашей базе всего 6300 файлов. Если, вы потеряете файл или пожелаете проверить его актуальность, он в любое время будет находиться по url: /media/new/regulation/gost-r-27-003-2011-nadezhnost-v-tekhnike-po-k_DFmitNX.pdf

Информация о файле

Статус: действующий

Дата
публикации: 26 января 2020 г.

Дата
введения: 13 марта 2013 г.

Количество
страниц: 1

Имя
файла: gost-r-27-003-2011-nadezhnost-v-tekhnike-po-k_DFmitNX.pdf

Размер
файла: 1,2 МБ

Скачать

Вам может быть интересно

ГОСТ Р 1.0-2004 Материалы строительные. Метод испытаний на возгораемость под воздействием малого пламени
ГОСТ Р 1.4-93 Государственная система стандартизации Российской Федерации. Стандарты отраслей, стандарты предприятий, стандарты научно-технических, инженерных обществ и других общественных объединений. Общие положения
ГОСТ Р 1.5-2004 Стандартизация в Российской Федерации. Стандарты национальные Российской Федерации. Правила построения, изложения, оформления и обозначения
ГОСТ Р 1.9-95 Государственная система стандартизации Российской Федерации. Порядок маркирования продукции и услуг знаком соответствия государственным стандартам

Мы приняли вашу зявку!

Свяжемся с вами в течении 5 минут

Ой, кажется что-то сломалось. Мы уже чиним проблему. Попробуйте чуть позже

Источник