Главная страница  Анализ эмпирических данных 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 [ 86 ] 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

266 . . Глава 6. , . . . - v

Uj = О, если более чем 4 сегмента не были опробованы в процессе испытаний;

- вычисление грубой оценки R по формуле R =

- S Ру. где k представляет собой общее число ветвей программы.

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

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

6.7. Обеспечение защиты программ

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

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



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

Все сказанное выше свидетельствует о необходимости введения условия безопасности функционирования программы S(E,), такого, что безопасность обеспечивается при соблюдении ограничения:

Р(ЕЛ<5(Е,).

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

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

6.8. Разработка прогрессивных методов написания надежных программ

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



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

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

Чтобы удостовериться в этом, запишем программу А в следующей форме:

IF(GN. NE.0.)GOTO10

IF (CN. LT. СТ) GOTO 30

GOTO 20 10 IF(CN.LT.TR)GOTO30 20 JE = JE-fl

KI = JD

KM = 2

KR = 3



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 [ 86 ] 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

© 2000 - 2018 ULTRASONEX-AMFODENT.RU.
Копирование материалов разрешено исключительно при условии цититирования.