Приложение В (справочное). Методы разработки и обеспечения надежности системы

Приложение В
(справочное)

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

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

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

В.2 Общее применение методов обеспечения надежности при проектировании

В.2.1 Безотказность и ремонтопригодность

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

Данный метод обеспечивает:

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

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

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

Дополнительные сведения см. в [2].

В.2.2 Программа повышения надежности

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

В.2.3 Управления конфигурацией

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

В.2.4 Байесовские сети

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

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

В.3 Методы проектирования надежности аппаратного обеспечения системы

В.3.1 Улучшение безотказности

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

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

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

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

- использование анализа дерева неисправностей (FTA) для выявления критических отказов системы;

- использование анализа видов и последствий отказов (FMEA) для определения возможных видов отказов, последствий, причин и критичности соответствующих экспозиций риска;

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

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

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

В.3.2 Улучшение ремонтопригодности

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

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

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

c) уровень депо. Восстановление системы включает более обширный ремонт и доработку объекта для его восстановления до рабочего состояния. Это требует гораздо больше времени.

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

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

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

В.3.3 Улучшение технического обслуживания и логистического обеспечения

Система технического обслуживания и логистического обеспечения направлена на поддержание работоспособности системы в соответствии с целями ее эксплуатации. Действия в основном проводят на стадии эксплуатации и технического обслуживания системы. Улучшения технического обслуживания и логистического обеспечения достигают за счет улучшения обслуживаемости системы в пределах ограничений, установленных конфигурацией системы и сценарием ее эксплуатации. Существуют значимые цели, которые должны быть достигнуты за счет улучшения, - внимательное обслуживание и упрощение процедур обслуживания. Улучшение также может быть достигнуто благодаря эффективной автоматизации отчетности по техническому обслуживанию и разработке системы анализа логистического обеспечения. Решение вопросов логистического обеспечения, касающихся централизованной или децентрализованной системы обеспечения депо, стратегического планирования и составления графика решения задач технического обслуживания, может привести к сокращению времени и трудоемкости технического обслуживания. В сегодняшней конкурентной среде, когда системы находятся в помещениях потребителя, основные работы по техническому обслуживанию могут быть выполнены сторонней организацией. Для аутсорсинга работ по техническому обслуживанию требуется дополнительная подготовка персонала с надлежащими навыками и компетенцией для выполнения необходимого обслуживания потребителей. Это обслуживающий персонал первой линии для рассмотрения жалоб потребителей. Сбор информации о проблемах потребителей в отношении выполненных сервисных работ и доверия потребителей стало главной проблемой координации процесса технического обслуживания системы. Для таких методов улучшения используют различные методы, включая техническое обслуживание, ориентированное на безотказность (RCM) (см. ГОСТ Р 27.606) и процесс интегрированного логистического обеспечения (LSI) (см. ГОСТ Р 53392).

В.4 Методы проектирования надежности программного обеспечения

В.4.1 Объектно-ориентированная методология

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

В.4.2 Методология структурирования

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

a) Метод, ориентированный на процедуры, - подход, который рассматривает алгоритмические процессы модели системы как ее фундаментальную характеристику. Определение данных следует из определенных процессов;

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

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

В.4.3 Функциональная декомпозиция проекта

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

В.4.4 Анализ ошибок

Анализ ошибок состоит:

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

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

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

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

В.4.5 Метод Дельфи

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

В.4.6 Метод автоматизированного проектирования и программного обеспечения для автоматизации процессов

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

В.4.7 Средства автоматизированного проектирования

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

В.4.8 Модель технологической зрелости

Организации используют эту модель для описания зрелости процесса программного обеспечения. Модель ранжирует организации по уровням от 1 до 5:

уровень 1: считается случайным или хаотичным;

уровень 2: повторяемые процессы;

уровень 3: определенные процессы (отраслевой минимальный стандарт на технические процессы);

уровень 4: измеряемые процессы;

уровень 5: оптимизированные процессы.

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

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

Модель зрелости направлена на процесс разработки. Участки процесса определяют блоки или объемы знаний на основе отраслевой практики. Уровень зрелости определяет зависимости и приоритеты для улучшения.

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

Уровень 2 направлен в основном на процессы управления для улучшения планирования, распределения времени и ресурсов, прослеживания и управления проектами.

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

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

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

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

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

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

2) воспроизводимость процесса;

3) технологии, которые доступны и применимы.

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

Преодоление этой путаницы состоит в борьбе с несоответствием путем создания интегрированной модели зрелости (СММ). Эта модель устраняет несоответствия в архитектуре, подходе, терминологии и других проблемах совместимости между SW CMM, SE-CMM и связанными с ними моделями. Результат создания представляет собой набор моделей и вспомогательной инфраструктуры, именуемых далее CMMi ¹⁾.

------------------------------

¹⁾_{См. также www.sel/cmu.edu}

------------------------------