Тихоненков В.А. Конструирование и надежность измерительно-вычислительных комплексов летательных аппаратов

Подождите немного. Документ загружается.

6. НАДЕЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Надежность – один из важнейших факторов, определяющих общую эф-

фективность системы. Поэтому на стадии проектирования системы вопросам

надежности уделяется пристальное внимание. Условием успеха исследования

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

к решению вопроса надежности. Поэтому следует рассматривать надежность

работы вычислительной аппаратуры совместно с программным обеспечением

как надежность вычислительного процесса.

Проблема надежности программного обеспечения (ПО) была объектом

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

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

ошибок в программах составляет большую часть времени процесса програм-

мирования.

6.1. Исходные понятия и определения надежности ПО

С началом исследования вопросов надежности ПО возникла проблема

стандартного определения собственно надежности ПО и программной ошиб-

ки.

Надежность ПО – определяется как свойство информационной системы

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

эксплуатационных показателей в заданных пределах, соответствующих за-

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

система выполняет поставленные перед ней задачи. Потеря надежности сис-

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

Следовательно надежность ПО – это вероятность того, что программа

какой-то период времени будет работать без сбоев, с учетом степени ее влия-

ния на выходные результаты. Надежность не является свойством присущим

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

Понятии надежности ПО аналогично надежности аппаратуры. Однако

механизмы возникновения отказа аппаратуры и отказа ПО существенно от-

личаются друг от друга.

Интенсивность отказов любого устройства информационной системы за-

висит от ошибок разработки, ошибок в производстве или отказов в работе в

результате старения элементной базы и может быть представлена во времени

кривой а на рисунке 6.1.

Интенсивность отказов ПО не зависит от старения и практически отсут-

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

быть исправлены (например, ошибки перезаписи при копировании). От-

казы ПО целиком опреде-

ляются ошибками разра-

ботки. Для среды, в кото-

рой ошибки по мере обна-

ружения исправляются и

не вносятся в результат

а исправления новые ошиб-

ки, интенсивность отказов

b ПО во времени изменяет-

ся в соответствии с кри-

вой b на рисунке 6.1. Из

t рисунка видно, что кри-

вые интенсивности отка-

Рис. 6.1 зов оборудования и ПО

ведут себя различно. На-

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

основе надежности ПО лежат предопределенные ошибки разработки.

Чтобы подчеркнуть различия между отказом оборудования и ошибкой

ПО необходимо рассмотреть поведение отказов и ошибок с учетом их зави-

симости от входных данных и от времени.

Во первых – отказ оборудования не зависит от обрабатываемой инфор-

мации (если какой-то блок находится на грани отказа, то его отказ не будет

зависеть от конкретных значений обрабатываемой информации). В то врем

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

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

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

вызвавшая проявление ошибки).

Во вторых – как было показано, отказы оборудования зависят от време-

ни. Ошибки ПО в действительности являются функцией от текущей входной

информации и текущего состояния системы. Кроме того ошибки ПО носят,

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

В третьих – различие заключается в области применения. Оборудование

в основном не зависит от области применения (например, центральный про-

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

ных, так и для решения конкретной математической задачи с несколькими

переменными). Большая же часть ПО в высшей степени чувствительна к кон-

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

В четвертых – различие базируется на природе составных элементов

оборудования и ПО. Большинство процессоров представляет собой объеди-

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

торые и определяют параметры процессора (объем, скорость, конфигурация).

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

лее примитивными (операторы на определенном языке, участки ранее напи-

санных программных систем). Это значит, что разработчик ПО для достиже-

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

оборудования.

Таким образом, ошибка ПО обусловлена его несоответствием постав-

ленным задачам. Это может произойти по двум причинам: либо разработчи-

ком программы допущено нарушение спецификации, либо спецификация не

точная или неполная.

Спецификация – это точное описание поведения системы с точки зрения

достижения поставленных перед ней целей и требований пользователя. В

разработке ПО трансляция целей и требований пользователя во внутренние

спецификации является самой значительной, так как по объему и степени

сложности ошибок, порождаемых в этот момент, она занимает основное ме-

сто во всем процессе разработки ПО. После написания внутренних специфи-

каций можно приступать к проектированию, кодированию и отлаживанию

ПО.

Несоответствие по первой причине встречается в первую очередь в

сложных программных системах, где отдельные ошибки программиста труд-

но обозримы и могут оставаться не раскрытыми.

Несоответствие по второй причине, возникает в первую очередь по тому,

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

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

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

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

невозможно оговорить и проверить все ситуации, которые могут возникнуть

при использовании программы. Дело в том, что программа является краткой

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

свойства функции зачастую становится просто невыполнимой задачей. На-

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

торых может принимать 10

различных значений, то число возможных вход-

ных комбинаций будет 10

. Если допустить, что проверка реакции програм-

мы на каждую из входных комбинаций занимает одну микросекунду, то в год

можно проверить только 10

комбинаций. Поэтому естественно, что в разра-

ботанной программе всегда могут встречаться непроверенные сочетания ис-

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

полнении нужных функций.

Поэтому возникновение ошибок по первой причине не говорит о надеж-

ности ПО, в этом случае говорят о корректности программы.

Корректность программы – это ее соответствие спецификации. По-

скольку спецификация не всегда и не полностью соответствует фактическим

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

работает надежно, или наоборот, корректная программа – ненадежно.

Характерной особенностью ошибок, обуславливающих отказы про-

грамм, является скрытость ошибок – это означает, что скрытая ошибка про-

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

возможных комбинаций исходных данных. Поэтому такие ошибки обнару-

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

Ошибки, проявляющиеся при любых исходных данных, не опасны, поскольку

обнаруживаются сразу при первых пробных прогонах программы.

Анализ ошибок программирования основан на их классификации.

Ошибки ПО могут быть разделены на:

- программные ошибки – ошибки, обусловленные ограниченными воз-

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

или при заданных ограничениях по объему вычислений);

- алгоритмические ошибки – ошибки, которые выражаются в получении

неправильных результатов, несмотря на время и объем вычислений, и связан-

ные с неполным формированием необходимых условий решения и некор-

ректной постановкой задачи;

- системные ошибки – ошибки обусловленные отклонением функцио-

нирования программы в системе и характеристик взаимодействующих объек-

тов от предполагавшихся при проектировании.

В настоящее время в литературе имеется представительная статистика,

как по классификационным признакам, так и по характеру ошибок ПО и их

причинах возникновения [31]. Наиболее интересные статистические данные

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

ботки и эксплуатации ПО приведены в [30], поэтому для получения общего

представления о характере ошибок ПО и их процентной частоте появления

эти данные представлены в таблице 6.1.

Таблица 6.1

Причина ошибки

Частота

появления в

Неполное или ошибочное задание

Отклонение от задания

Пренебрежение правилами программирования

Ошибочная выборка данных

Ошибочная логика или последовательность операций

Ошибочные арифметические операции

Нехватка времени для решения

Неправильная обработка прерываний

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

Неточная запись

Из таблицы 6.1 видно, что к наиболее часто встречающимся ошибкам

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

от задания, частота появления которых достигает 40% от всевозможных при-

чин возникновения ошибок. В свою очередь , в таблице 6.2 представлена час-

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

Таблица 6.2

Причина ошибки

Частота

появления в

Ошибки в числовых значениях

Недостаточные требования к точности

Ошибочные символы или знаки

Ошибки в оформлении

Неправильное описание аппаратуры

Основы разработки неполные или неточные

Двусмысленность требований

Из таблицы 6.2 видно, корректность составления технического задания к

программе (полнота и точность описания требований, ошибки в оформлении

и двусмысленность требований) может уменьшить количество ошибок на

80%. А общий вес ошибок, связанных с составлением спецификаций и пра-

вильным отражением требований спецификаций в программе, составляет бо-

лее 30% от общего количества ошибок. Эти статистические данные подтвер-

ждают утверждение о внесении максимального количества ошибок на этапе

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

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

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

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

Для принятой классификации ошибок представляет интерес статистиче-

ские данные представленные в [32] по изменению процентного содержания

ошибок различного типа от времени, с привязкой к этапам разработки (рису-

нок 6.2).

В процессе разработки (отладки) и эксплуатации программы общее чис-

ло ошибок снижается (см. рис. 6.1), однако, из рисунка 6.2 видно, что одно-

временно происходит перераспределение процентного содержания ошибок

по причинам их возникновения.

Ошибки в %

80-

60- системные ошибки

40-

алгоритмические ошибки

20-

программные ошибки

0 | | | |

1,2 3 4 5 6

этапы разработки

Рис. 6.2

Где: 1 – этап исследований; 2 – этап составления технического задания;

3 – этап программирования; 4 – этап автономной отладки подпрограмм; 5 –

этап комплексной отладки программы; 6 – этап эксплуатации.

П р о г р а м м ы е о ш и б к и по количеству и типам зависят от квали-

фикации специалистов-разработчиков, от общего объема программы, глуби-

ны логического и информационного взаимодействия отдельных частей алго-

ритма и от ряда других факторов. На начальных этапах разработки 1 и 2 и

этапе программирования 3, программные ошибки составляют более 30% от

всех ошибок (37% – см. рис. 6.2). Каждая программная ошибка влечет за со-

бой необходимость изменения около шести команд, что существенно меньше,

чем при алгоритмических и системных ошибках. На этапах комплексной от-

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

15% и 3% соответственно от общего количества ошибок, выявляемых в еди-

ницу времени.

А л г о р и т м и ч е с к и е о ш и б к и обусловлены некорректной по-

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

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

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

чем программные ошибки. Эти условия формируются и уточняются в про-

цессе выявления ошибок в результате функционирования алгоритмов. Ошиб-

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

наиболее частыми в этой группе и составляют до 70% всех алгоритмических

ошибок, или около 30% общего количества ошибок. Полученные результаты

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

лицах 6.1 и 6.2. Однако в процессе отладки программы их доля в общем объ-

еме ошибок уменьшается, хотя и не так быстро как программные ошибки, и к

моменту начала эксплуатации они, как правило, не превышают 15% от обще-

го объема ошибок.

С и с т е м н ы е о ш и б к и в сложных комплексах программ опреде-

ляются неполной информацией о реальных процессах, происходящих в ис-

точниках и потребителях информации. Эти процессы часто зависят от алго-

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

нирования программы во взаимодействии с внешними абонентами. Так как на

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

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

уточняются и конкретизируются технические задания на отдельные програм-

мы и выявляются отклонения от уточненного задания, которые квалифици-

руются как системные ошибки. Ошибки, связанные с неполной формализаци-

ей целевой функции системы, наиболее трудно квалифицировать и выделить.

В отдельных случаях эти ошибки требуют полной переработки и замены ал-

горитмов и существенно сказывается на длительности проектирования слож-

ных программ. При автономной и в начале комплексной отладки доля сис-

темных ошибок не велика (примерно 10%), но она существенно возрастает

(до 35 – 40%) на завершающих этапах комплексной отладки. На этапе экс-

плуатации системные ошибки являются преобладающими и достигают 80%

от общего числа ошибок.

Кроме перераспределения ошибок по характеру их возникновения в про-

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

процессе разработки, одновременно с уменьшением интенсивности устране-

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

времени и по затратам труда на поиск и создание соответствующих ситуаций

в системе. Для сложных программ происходит дальнейшее возрастание за-

трат на поиск и исправление ошибок [32] на начальных этапах массового

внедрения и эксплуатации. На рисунке 6.3 представлены относительные за-

траты на обнаружение и исправление одной ошибки в зависимости от этапа

разработки программы.

Убывание ошибок в программах и интенсивности их обнаружения в

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

наработки на отказ Т от длительности отладки

Из графика видно, что

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

’

интенсивность обнаружения

ошибок снижается на столько, что разработчик попадает в зону нечувстви-

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

вии ошибок, о невозможности и бесцельности их поиска, вследствие чего

усилия на отладку сокращаются и интенсивность обнаружения ошибок еще

больше снижается. Этой предельной интенсивности обнаружения отказов

’

соответствует наработка на отказ Т

’

, при которой прекращается улучшение

надежностных характеристик программ на этапе отладки и испытаний у за-

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

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

рое увеличение суммарной интенсивности обнаружения ошибок. Это позво-

ляет поднять наработку на отказ до значения Т

”

при проведении эксплуата-

ции и проверок в течение времени

”

. Таким образом можно определять и

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

ки и их тиражирования.

Относительные

затраты в % Т

100-

50- Т

”

20-

10- T

’

0 | | | | | |

1 2 3 4 5 6

’

”

этапы разработки

Рис. 6.3 Рис. 6.4

Всесторонний анализ ошибок, встречающихся в программах, возможен

только при наличии точных данных об отказах программ, причинах отказов, о

самих программах и условиях их разработки (квалификация программиста,

сроки разработки и т.д.). Эти данные являются основой для построения мате-

матических моделей надежности программ с целью ее оценки и прогнозиро-

вания, а также для нахождения путей ее обеспечения и повышения.

6.2. Математические модели надежности ПО

Существующие математические модели позволяют оценить характери-

стики ошибок в программах и прогнозировать их надежность при проектиро-

вании и эксплуатации. Модели имеют вероятностный характер, и достовер-

ность прогнозов зависит от точности исходных данных и глубины прогнози-

рования по времени. Эти математические модели предназначены для оценки:

- показателей надежности программ в процессе отладки;

- количества ошибок, оставшихся не выявленными;

- времени, необходимого для обнаружения следующей ошибки в функ-

ционирующей программе;

- времени, необходимого для выявления всех ошибок с заданной веро-

ятностью.

В настоящее время имеется ряд математических моделей [30,31,32,33],

основными из которых можно выделить:

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

ни отладки;

- модель, учитывающая дискретно-понижающуюся частоту появления

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

- модель, базирующуюся на распределении Вейбула;

- модель Литтлвуда – Вералома;

- модель Джелинского – Моранды;

- модель Шумана и др.

При выборе и обосновании применения математических моделей выдви-

гаются различные гипотезы о характере проявления ошибок в программах. В

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

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

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

тематическую модель. Поэтому рассмотрим наиболее простые модели для

оценки надежности ПО.

Экспоненциальная модель изменения ошибок в процессе отладки осно-

вана на следующих характеристиках их проявления.

1. Любые ошибки в программе являются независимыми и проявляются в

случайные моменты времени с постоянной средней интенсивностью, при от-

сутствии корректировок на всем протяжении функционирования программы.

2. Интенсивность проявления ошибок при реальном функционировании

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

сит от распределения типов команд на маршрутах обработки данных между

ошибками.

3. Потенциальное множество тестов при отладке должно покрывать все

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

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

чтобы исключить концентрацию необнаруженных ошибок для некоторых ре-

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

вать априорные данные для искусственного повышения интенсивности про-

явления ошибок, и распределение их во времени можно будет считать равно-

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

требование 1.

4. Ошибка, являющаяся причиной искажения результатов, фиксируется

и исправляется после завершения тестирования, либо вообще не обнаружива-

ется.

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

количество ошибок, проявляющихся в некотором интервале времени, распре-

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

кажениями распределена экспоненциально.

Предположим, что в начале отладки программы при

= 0 в ней содер-

жалось N

ошибок. После отладки в течение времени

осталось n

и уст-

ранено n ошибок, то есть n

+ n = N

. При этом время

соответствует дли-

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

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

корректировок. Календарное время отладочных и испытательных работ с ре-

альными программами значительно больше, так как после тестирования про-

граммы, на которое затрачивается рассматриваемое нами машинное время

необходимо время для анализа результатов, локализацию ошибок и их устра-

нение. Однако для определения надежностных характеристик существенна

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

При постоянных усилиях на отладку, интенсивность обнаружения иска-

жений вычислительного процесса, программ или исходных данных пропор-

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

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

жения ошибок. Этот анализ позволил установить сильную корреляцию между

значениями оставшихся ошибок n

, количеством ошибок выявляемых в еди-

ницу времени dn/d

и интенсивностью обнаружения ошибок

, то есть:

( )

nNKnKK

−⋅=⋅=⋅=

, (6.1)

где К и К

’

– коэффициенты, учитывающие масштаб изменения времени, ис-

пользуемого для описания процесса обнаружения ошибок, рас-

пределение тестовых значений на входе проверяемой програм-

мы и другие параметры.

Жесткую корреляцию между указанными параметрами и правомер-

ность введения коэффициентов К и К

’

наглядно видно из графиков, представ-

ленных на рисунке 6.5. Графи-

ки составлены на основании

статистических данных реаль-

ных программ в соответствии с

принятыми обозначениями [32]. n

Значения коэффициентов К и К

’

можно определить как измене-

ние темпа проявления искаже- dn/d

ний при переходе от функцио-

рования программы на специ- Рис. 6.5