Назовем наше произведение Теоретические Оценки Надежности Программного Обеспечения (ТОНПО – звучит :) однако гордо )
Программистам свойственно ошибаться, а программам содержать ошибки, это аксиома, на плечах которой будут гнездиться наши дальнейшие умозаключения.
Под надежностью программного обеспечения (ПО) будем понимать меру безошибочной работы программного комплекса (ПО-Операционная система-Оборудование) в рамках техническим заданием. Нюанс в том, что грамотно составить техническое задание то же, большая проблема.
Заметим, что жизненный цикл ПО состоит из нескольких этапов, и на каждом из них, можно привнести в ПО те или иные ошибки
1)Определение требований к системе
2)Создание спецификации
3)Алгоритмизация
4)Программирование
5)Тестирование
6)Эксплуатация и сопровождение
Что же такое программная ошибка? Это многоплановое понятие – сюда входит ошибочное использование оператора, операции, вычислительные ошибки, не соответствие ПО спецификации и проч. Все это ОШИБКИ, в нашем понимании.
Оценивать надежность ПО можно по разному.
1)По времени.
2)Трудоемкости
3)Отношению успешных тестовых прогонов к полному числу
и.т.п.
Разумеется, существую математические модели используя которые можно оценить реальное ПО.
Я не буду приводить математических выкладок, это и не нужно – пытливый читатель сам легко найдет нужные формулы. Просто коротенько расскажу, что и как используют.
В моделях оценки ПО по времени обычно вводят функцию риска R(t) показывающую интенсивность обнаружения ошибок в момент времени t (советую пролистать теорию надежности). Т.е. Ведут журнал. В который и заносят (в зависимости от модели)
a) Колл-во ошибок за одинаковый временной период, найденных в программе
б)Время, с момента обнаружения i-1 ошибки до обнаружения i
И в предположении, ОБЫЧНО, что появление ошибок равновероятно, все ошибки имеют одинаковую серьезность, ошибки ИСПРАВЛЯЮТСЯ без внесения новых и еще некоторых предположений зависящих от используемых моделей РАСЧИТЫВАЮТ теоретическую величину G – оставшихся ошибок в ПО. Т.е. после тщательного тестирования можно предсказать число оставшихся ошибок.
Для самостоятельного ознакомления: модели Джелинского-Моранды, Шика-Уолвертона, Шнейдевинда.
В моделях оценки ПО по трудоемкости исследуют объем программ. Так как модель сама по себе интересна и достаточно прозрачно приведем кое какую цифирь.
Вводят понятие (следуя Холстеду)
n1- число различных операций (=, <,+, else и проч)
n2- число различных операндов (переменные, константы)
N1-общее число операций
N2-общее число всех операндов
n=n1+n2словарь программы
N=N1+N2 – длина реализации
Дальше есть ТОНКОСТЬ! Используется понятие БИТ в смысле теории ИНФОРМАЦИИ. Т.е. не те биты, что занимает программа, скажем на винте, а информационные, т.е. Рассматривают ИНФОРМАЦИЮ, что несет программа.
Тогда теоретическая длинна программы U=n1*ln2(n1)+n2*ln2(n2) и потенциальный объем программы V*=(n2*+2)ln2(n2*+2)
здесь n2* - минимальное число различных операндов – обычно это ВХОДНЫЕ и ВЫХОДНЫЕ параметры.
т.е. V* - теоретически минимальный объем ПО с заданным ИНТЕРФЕЙСОМ.
Учет сложности алгоритмических языков приводит к выражению для оценки потенциальное число ошибок в ПО
B=(V*)**2/(3000*L)
L-константа для ассемблера 0.88 для фортрана 1.14 для английского языка 2.16
Кстати 1 ошибка примерно для 3000 бит проги на фортране :) Для ассемблера, как оказалось, формула дает заниженное значение более адекватно ассемблерную прогу можно оценить
B=(V*)**2/576
(т.е. Одна ошибка на 576 бит ассемблерного кода)
В качестве примера в литературе приводят пример объема программы одного из элементов ПРО. Есть 20 целей, для перехвата нужно 30 измерений их местоположения. Для определения объекта необходимо измерить 5 параметров. Для каждого объекта определяют 2е координаты. Таким образом число входных параметров 20*2*5*30=6000. Входные параметры угловые координаты (2е) и расстояние до них. 20 целей*3=60.
N2*=6000+60=6060. Таким образом V*=7.6E4.
И оценка для B~1.7E5 прямо скажем не мало.
Сермяга
Уменьшаем общее количество переменных ,констант, меток, переходов. Использовать МИНИМУМАЛЬНЫЙ набор команд (блин РИСК
)Для самостоятельного изучения: метрика Холстеда
Существует интересный метод оценки оставшихся ошибок в ПО, метод ПОСЕВА, это контролируемое внесение в текст программы известное количество ошибок. Предполагается, что ошибки распределены так же, как ошибки собственно ПО (что является не очевидным предположением).
Затем тестируют ПО. Находят определенное число привнесенных ошибок и собственных.
После чего, можно оценить оставшееся количество ошибок в ПО.
Метод интересный и несколько неожиданный.
Для самостоятельного изучения: метод Нельсона.
Между прочем, был предложен медот оценивающий РЕЙТИНГ программиста. Суть метода
Берутся программы написанный определенным программистом. Определяется их объем и количество ошибок. Сочиняется линейная функция из этих параметров, и определяется некий рейтинг. Причем рейтинг, будет меняется (а мож и не будет), от времени (приобретения опыта). И теперь зная рейтинг программера можно определить число ошибок в программе заданного объема написанной им.
Засим заканчиваю дозволенные речи. Ежли интересно, можно и продолжить ( предполагается, что читатель не пассивен :) )
продолжение будет?
| QUOTE (roach_killer @ 20.10.2007 - время: 02:25) |
| интересно. продолжение будет? |
Если интересно....то будет :)
Просто отзывов нет, я думал - все все знают :) Чего мысью по древу течь.
JeyLo
| QUOTE |
| Теоретики, блин. |
Персонально для JeyLo БЛИНы(сам делал :) ) - от всего своГо боШого сердца
Получить код этого изображения
Блины, чистая ЭМПИРИКА :) Даны нам в ощущениях, как до, так и во время и после. Ток ощущения разные конеШна
Это сообщение отредактировал do-do - 21-10-2007 - 20:17