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

Программное обеспечение

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

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

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

Программирование − научная и практическая деятельность по созданию программ.

Программа компонент − программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса. [2]

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

В зависимости от целевого предназначения, решаемых задач, области применения реализующих функций и особенностей функционирования различают следующие виды программ (табл.1.1). [2]

Таблица 1.1

Виды программ

№ п/п	Термин	Определение
2.	Системная программа	Программа, предназначенная для поддержания работоспособности системы обработки информации или повышения эффективности ее использования в процессе выполнения прикладных программ
3.	Управляющая программа	Системная программа, реализующая набор функций управления, в который включают управление ресурсами и взаимодействием с внешней средой системы обработки информации, восстановление работы системы после проявления неисправностей в технических средствах
4.	Супервизор	Часть управляющей программы, координирующая распределение ресурсов системы обработки информации
5.	Прикладная программа	Программа, предназначенная для решения задачи или класса задач и определенной области применения системы обработки информации
6.	Программа обслуживания	Программа, предназначенная для оказания услуг общего характера пользователям и обслуживающему персоналу системы обработки информации
7.	Абсолютная программа	Программа на машинном языке, выполнение которой зависит от ее местоположения в оперативной памяти
8.	Переместимая программа	Программа на машинном языке, выполнение которой не зависит от ее местоположения в оперативной памяти
9.	Реентерабельная программа	Программа, один и тот же экземпляр которой в оперативной памяти способен выполняться многократно, причем так, что каждое выполнение может начинаться в любой момент по отношению к другому выполнению
10.	Мобильная программа	Программа, которая написана для ЭВМ одной архитектуры, но может исполняться в системах обработки информации с другими архитектурами без доработки или при условии ее доработки, трудоемкость которой незначительна по сравнению с разработкой новой программы
11.	Драйвер	Программа, предназначенная для управления работой периферийных устройств, обычно в мини- и микро ЭВМ
12.	Подпрограмма	Программа, являющаяся частью другой программы и удовлетворяющая требованиям языка программирования к структуре программы
13.	Программный модуль	Программа или функционально завершенный фрагмент программы, предназначенный для хранения, трансляции, объединения с другими программными модулями и загрузки в оперативную память
14.	Исходный модуль	Программный модуль на исходном языке, обрабатываемый транслятором и представляемый для него как целое, достаточное для проведения трансляции
15.	Объектный модуль	Программный модуль, получаемый в результате компиляции исходного модуля. Примечание. Объектный модуль обычно полностью готов к редактированию связей
16.	Загрузочный модуль	.Программный модуль, представленный в форме, пригодной t для загрузки в основную память для выполнения
17.	Макроопределение	Программа, под управлением которой макрогенератор порождает макрорасширения макрокоманд
18.	Рекурсивная подпрограмма	Подпрограмма, которая может обращаться к себе самой

 

 

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

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

Надежность − свойство объекта выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующих заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования. (ГОСТ 13377-75). Таким образом, надежность является внутренним свойством системы, заложенным при ее создании и проявляющимся во временипри функционировании и эксплуатации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предупреждение ошибок

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

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

5. методы достижения большей точности при переводе;

6. методы улучшения обмена информацией;

7. методы немедленного обнаружения и устранения ошибок. Эти методы направлены на обнаружение ошибок на каждом шаге перевода, не откладывая до тестирования программы после ее написания.

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

Лучший способ обеспечить надежность − прежде всего не допустить возникновения ошибок. Гарантировать отсутствие ошибок, однако, невозможно никогда. Другие три группы методов опираются на предположение, что ошибки все-таки будут.

Обнаружение ошибок

Если предполагать, что в программном обеспечении какие-то ошибки все же будут, то лучшая (после предупреждения ошибок) стратегия − включить средства обнаружения ошибок в само программное обеспечение.

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

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

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

Разрабатывая эти меры, мы будем опираться на следующее.

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

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

Избыточность. Все средства обнаружения ошибок основаны на некоторой форме избыточности (явной или неявной).

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

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

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

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

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

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

Исправление ошибок

Следующий шаг − методы исправления ошибок; после того как ошибка обнаружена, либо она сама, либо ее последствия должны быть исправлены программным обеспечением. Исправление ошибок самой системой − плодотворный метод проектирования надежных систем аппаратного обеспечения. Некоторые устройства способны обнаружить неисправные компоненты и перейти к использованию идентичных запасных. Аналогичные методы неприменимы к программному обеспечению вследствие глубоких внутренних различий между сбоями аппаратуры и ошибками в программах. Если некоторый программный модуль содержит ошибку, идентичные "запасные" модули также будут содержать ту же ошибку.

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

Устойчивость к ошибкам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Контрольная точка/рестарт. Контрольная точка − это периодически обновляемая копия состояния прикладной программы или всей системы. Если происходит отказ аппаратуры, такой, как ошибка ввода-вывода, сбой памяти или питания, программа может быть запущена повторно с последней контрольной точки.

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

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

 

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

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

Модель Шумана

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

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