Надежность параллельных вычислений

     
     численность и квалификацию обслуживающего и ремонтного персонала.
     
     1.4. Номенклатуру задаваемых ПН изделия выбирают в соответствии с положениями настоящего стандарта и согласовывают в установленном порядке между заказчиком (потребителем) и разработчиком (изготовителем). Показатели, как правило, должны выбираться из числа показателей, определения которых приведены в ГОСТ 27.002. Допускается применять показатели, наименования и определения которых конкретизируют соответствующие термины, установленные ГОСТ 27.002, с учетом особенностей изделия и (или) специфики его применения, но не противоречат стандартизованным терминам.
     
     Условные обозначения показателей, применяемых в настоящем стандарте, приведены в приложении 1, примеры возможных модификаций стандартизованных показателей - в приложении 2.
     
     1.5. Общее количество задаваемых на изделие показателей должно быть минимальным, но характеризовать все этапы его эксплуатации. Все показатели должны иметь однозначное толкование и для каждого из них должны существовать методы контроля (оценки) на всех стадиях жизненного цикла изделий.
     
     1.6. Для изделий, подлежащих перед началом или в процессе эксплуатации хранению (транспортированию), задают показатели сохраняемости. При этом должны быть определены и учтены условия и режимы хранения (транспортирования), применительно к которым задают указанные показатели.
     
     1.7. Для восстанавливаемых изделий, как правило, задают комплексный ПН или определяющий его набор единичных показателей безотказности и ремонтопригодности, причем первый вариант задания требований является предпочтительным. По требованию заказчика в дополнение к комплексному показателю может быть задан один из определяющих его показателей безотказности или ремонтопригодности. Не допускается одновременное задание комплексного и всех определяющих его единичных показателей. Для показателей ремонтопригодности должны быть определены и учтены условия и виды восстановления, ремонта и технического обслуживания, применительно к которым задают указанные показатели.
     
     Пример. Для восстанавливаемых изделий непрерывного действия, выходной эффект от применения которых пропорционален суммарной продолжительности пребывания изделий в работоспособном состоянии, основным показателем является . По согласованию между заказчиком и разработчиком возможны следующие сочетания задаваемых показателей: и или и , или и .

     
     Недопустимое сочетание: , и .

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

     
     требования и (или) ограничения по видам и кратности резервирования;
     
     требования и (или) ограничения по затратам (стоимости) в изготовлении и эксплуатации, массе, габаритам, объему изделия и (или) его отдельных составных частей, комплектов ЗИП, оборудования для технического обслуживания и ремонтов;

     
     требования к структуре и составу ЗИП;

     
     требования к системе технического диагностирования (контроля технического состояния);

     
     требования и (или) ограничения по способам и средствам обеспечения ремонтопригодности и сохраняемости;

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

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

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

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

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

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

     
     1.11. Требования к эксплуатационным способам обеспечения надежности могут содержать:

     
     требования к системе технического обслуживания и ремонтов;
     
     требования к алгоритму технического диагностирования (контроля технического состояния);

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

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

     
     требования к объему и форме представления информации о надежности, собираемой (регистрируемой) в ходе эксплуатации и др.

     
     1.12. Требования по надежности включают в:

     
     тактико-технические задания (ТТЗ), технические задания (ТЗ) на разработку или модернизацию изделий;

     
     технические условия (ТУ) на изготовление опытной и серийной продукции (если согласованы правила или условия их подтверждения);

     
     стандарты общих технических требований (ОТТ), общих технических условий (ОТУ) и технических условий (ТУ).

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

Введение избыточности в ПО

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

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

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

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

                        Временная избыточность. Использование части производительности ЭВМ для контроля исполнения и восстановления работоспособности ПО после сбоя.

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

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

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

                        обработку сбоев аппаратуры;

                        повторное выполнение операций;

                        динамическое изменение конфигурации;

                        сокращенное обслуживание в случае отказа отдельных функций системы;

                        копирование и восстановление данных;

                        изоляцию ошибок.

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

                        Автономное тестирование, контроль отдельного программного модуля отдельно от других модулей системы.

                        Тестирование сопряжений, контроль сопряжений (связей) между частями системы (модулями, компонентами, подсистемами).

                        Тестирование функций, контроль выполнения системой автоматизируемых функций.

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

                        Тестирование полноты и корректности документации, выполнение программы в строгом соответствии с инструкциями.

                        Тестирование конфигураций, проверка каждого конкретного варианта поставки (установки) системы.

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

Качество подготовки исходных данных для проведения тестирования серьёзно влияет на эффективность процесса в целом и включает в себя:

                        техническое задание;

                        описание системы;

                        руководство пользователя;

                        исходный текст;

                        правила построения (стандарты) программ и интерфейсов;

                        критерии качества тестирования;

                        эталонные значения исходных и результирующих данных;

                        выделенные ресурсы, определяемые доступными финансовыми средствами.

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

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

                        предлагаемых изменений;

                        найденных дефектов;

                        утвержденных корректировок;

                        реализованных изменений;

                        пользовательских версий.

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

Надежность и правильность программы

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