Классификация ошибок программного обеспечения
Рассмотрим классификацию ошибок по месту их возникновения, которая рассмотрена в книге С. Канера «Тестирование программного обеспечения». Фундаментальные концепции менеджмента бизнес-приложений. . Главным критерием программы должно быть ее качество, которое трактуется как отсутствие в ней недостатков, а также сбоев и явных ошибок. Недостатки программы зависят от субъективной оценкой ее качества потенциальным пользователем. При этом авторы скептически относятся к спецификации и утверждают, что даже при ее наличии, выявленные на конечном этапе недостатки говорят о ее низком качестве. При таком подходе преодоление недостатков программы, особенно на заключительном этапе проектирования, может приводить к снижению надежности. Очевидно, что для разработки ответственного и безопасного программного обеспечения (ПО) такой подход не годится, однако проблемы наличия ошибок в спецификациях, субъективного оценивания пользователем качества программы существуют и не могут быть проигнорированы. Должна быть разработана система некоторых ограничений, которая бы учитывала эти факторы при разработке и сертификации такого рода ПО. Для обычных программ все проблемы, связанные с субъективным оцениванием их качества и наличием ошибок, скорее всего неизбежны.
В краткой классификации выделяются следующие ошибки.
Ошибки пользовательского интерфейса.
Ошибки вычислений.
Ошибки управления потоком.
Ошибки передачи или интерпретации данных.
Перегрузки.
Контроль версий.
Ошибка выявлена и забыта.
Ошибки тестирования.
1. Ошибки пользовательского интерфейса.
Многие из них субъективны, т.к. часто они являются скорее неудобствами, чем «чистыми» логическими ошибками. Однако они могут провоцировать ошибки пользователя программы или же замедлять время его работы до неприемлемой величины. В результате чего мы будем иметь ошибки информационной системы (ИС) в целом. Основным источником таких ошибок является сложный компромисс между функциональностью программы и простотой обучения и работы пользователя с этой программой. Проблему надо начинать решать при проектировании системы на уровне ее декомпозиции на отдельные модули, исходя из того, что вряд ли удастся спроектировать простой и удобный пользовательский интерфейс для модуля, перегруженного различными функциями. Кроме того, необходимо учитывать рекомендации по проектированию пользовательских интерфейсов. На этапе тестирования ПО полезно предусмотреть встроенные средства тестирования, которые бы запоминали последовательности действий пользователя, время совершения отдельных операций, расстояния перемещения курсора мыши. Кроме этого возможно применение гораздо более сложных средств психо-физического тестирования на этапе тестирования интерфейса пользователя, которые позволят оценить скорость реакции пользователя, частоту этих реакций, утомляемость и т.п. Необходимо отметить, что такие ошибки очень критичны с точки зрения коммерческого успеха разрабатываемого ПО, т.к. они будут в первую очередь оцениваться потенциальным заказчиком.
2. Ошибки вычислений.
Выделяют следующие причины возникновения таких ошибок:
Неверная логика (может быть следствием, как ошибок проектирования, так и кодирования);
Неправильно выполняются арифметические операции (как правило - это ошибки кодирования);
Неточные вычисления (могут быть следствием, как ошибок проектирования, так и кодирования). Очень сложная тема, надо выработать свое отношение к ней с точки зрения разработки безопасного ПО.
Выделяются подпункты: устаревшие константы; ошибки вычислений; неверно расставленные скобки; неправильный порядок операторов; неверно работает базовая функция; переполнение и потеря значащих разрядов; ошибки отсечения и округления; путаница с представлением данных; неправильное преобразование данных из одного формата в другой; неверная формула; неправильное приближение.
3. Ошибки управления потоком.
В этот раздел относится все то, что связано с последовательностью и обстоятельствами выполнения операторов программы.
Выделяются подпункты:
Очевидно неверное поведение программы;
Переход по GOTO;
Логика, основанная на определении вызывающей подпрограммы;
Использование таблиц переходов;
Выполнение данных (вместо команд). Ситуация возможна из-за ошибок работы с указателями, отсутствия проверок границ массивов, ошибок перехода, вызванных, например, ошибкой в таблице адресов перехода, ошибок сегментирования памяти.
4. Ошибки обработки или интерпретации данных.
Выделяются подпункты:
Проблемы при передаче данных между подпрограммами (сюда включены несколько видов ошибок: параметры указаны не в том порядке или пропущены, несоответствие типов данных, псевдонимы и различная интерпретация содержимого одной и той же области памяти, неправильная интерпретация данных, неадекватная информация об ошибке, перед аварийным выходом из подпрограммы не восстановлено правильное состояние данных, устаревшие копии данных, связанные переменные не синхронизированы, локальная установка глобальных данных (имеется в виду путаница локальных и глобальных переменных), глобальное использование локальных переменных, неверная маска битового поля, неверное значение из таблицы);
Границы расположения данных (сюда включены несколько видов ошибок: не обозначен конец нуль-терминированной строки, неожиданный конец строки, запись/чтение за границами структуры данных или ее элемента, чтение за пределами буфера сообщения, чтение за пределами буфера сообщения, дополнение переменных до полного слова, переполнение и выход за нижнюю границу стека данных, затирание кода или данных другого процесса);
Проблемы с обменом сообщений (сюда включены несколько видов ошибок: отправка сообщения не тому процессу или не в тот порт, ошибка распознавания полученного сообщения, недостающие или несинхронизированные сообщения, сообщение передано только N процессам из N+1, порча данных, хранящихся на внешнем устройстве, потеря изменений, не сохранены введенные данные, объем данных слишком велик для процесса-получателя, неудачная попытка отмены записи данных).
5. Повышенные нагрузки.
При повышенных нагрузках или нехватке ресурсов могут возникнуть дополнительные ошибки. Выделяются подпункты: требуемый ресурс недоступен; не освобожден ресурс; нет сигнала об освобождении устройства; старый файл не удален с накопителя; системе не возвращена неиспользуемая память; лишние затраты компьютерного времени; нет свободного блока памяти достаточного размера; недостаточный размер буфера ввода или очереди; не очищен элемент очереди, буфера или стека; потерянные сообщения; снижение производительности; повышение вероятности ситуационных гонок; при повышенной нагрузке объем необязательных данных не сокращается; не распознается сокращенный вывод другого процесса при повышенной загрузке; не приостанавливаются задания с низким приоритетом.
В этом разделе хотелось бы обратить внимание на следующее:
1) Часть ошибок из этого раздела могут проявляться и при не очень высоких нагрузках, но, возможно, они будут проявляться реже и через более длительные интервалы времени;
2) Многие ошибки из 2-х предыдущих разделов уже в своей формулировке носят вероятностный характер, поэтому следует предположить возможность использования вероятностных моделей и методов для их выявления.
6. Контроль версий и идентификаторов.
Выделяются подпункты: таинственным образом появляются старые ошибки; обновление не всех копий данных или программных файлов; отсутствие заголовка; отсутствие номера версии; неверный номер версии в заголовке экрана; отсутствующая или неверная информация об авторских правах; программа, скомпилированная из архивной копии, не соответствует проданному варианту; готовые диски содержат неверный код или данные.
7. Ошибки тестирования.
Являются ошибками сотрудников группы тестирования, а не программы. Выделяются подпункты:
Пропущенные ошибки в программе;
Не замечена проблема (отмечаются следующие причины этого: тестировщик не знает, каким должен быть правильный результат, ошибка затерялась в большом объеме выходных данных, тестировщик не ожидал такого результата теста, тестировщик устал и невнимателен, ему скучно, механизм выполнения теста настолько сложен, что тестировщик уделяет ему больше внимания, чем результатам);
Пропуск ошибок на экране;
Не документирована проблема (отмечаются следующие причины этого: тестировщик неаккуратно ведет записи, тестировщик не уверен в том, что данные действия программы являются ошибочными, ошибка показалась слишком незначительной, тестировщик считает, что ошибку не будет исправлена, тестировщика просили не документировать больше подобные ошибки).
8. Ошибка выявлена и забыта.
Описываются ошибки использования результатов тестирования. По-моему, раздел следует объединить с предыдущим. Выделяются подпункты: не составлен итоговый отчет; серьезная проблема не документирована повторно; не проверено исправление; перед выпуском продукта не проанализирован список нерешенных проблем.
Необходимо заметить, что изложенные в 2-х последних разделах ошибки тестирования требуют для устранения средств автоматизации тестирования и составления отчетов. В идеальном случае, эти средства должны быть проинтегрированы со средствами и технологиями проектирования ПО. Они должны стать важными инструментальными средствами создания высококачественного ПО. При разработке средств автоматизированного тестирования следует избегать ошибок, которые присущи любому ПО, поэтому нужно потребовать, чтобы такие средства обладали более высокими характеристиками надежности, чем проверяемое с их помощью ПО.
Основные пути борьбы с ошибками
Учитывая рассмотренные особенности действий человека при переводе можно указать следующие пути борьбы с ошибками:
· сужение пространства перебора (упрощение создаваемых систем),
· обеспечение требуемого уровня подготовки разработчика (это функции менеджеров коллектива разработчиков),
· обеспечение однозначности интерпретации представления информации,
· контроль правильности перевода (включая и контроль однозначности интерпретации).
Используемые в данном случае модели надежности представляют интерес прежде всего для прогнозирования отказов в процессе эксплуатации и отладки программы. При этом значения параметров моделей определяют в процессе эксплуатации или отладки программы по данным о моментах возникновения отказов. Отсутствие общих справочных данных объясняется тем, что каждый программист является уникальным технологическим объектом по созданию программ, а каждая его программа – эксклюзивное изделие.
Наиболее разработанный аппарат оценки характеристик надежности опирается на модель надежности Джелинского-Моранды, которая будет рассмотрена ниже.
Методика расчета при прогнозировании отказов программного обеспечения
Рассматриваемая модель основана на следующих допущениях:
время до следующего отказа распределено экспоненциально;
интенсивность отказов программы пропорциональна количеству оставшихся в программе ошибок.
Согласно этим допущениям вероятность безотказной работы программ как функция времени t i равна:
P(t i )=exp(- l i × t i ) , (1)
где l i = С × (N-(i-1)). (2)
Здесь С – коэффициент пропорциональности;
N – первоначальное число ошибок программы.
В выражении (1) отсчет времени t i начинается от момента последнего(i -1) отказа программы, а значениеl i изменяется при прогнозировании разных отказов.
Значения C иN в выражении (2) определяются по экспериментально зафиксированным интервалам времениD t i между моментами возникновения отказов в процессе отладки программы. На основе методики максимума правдоподобия значениеN получают как решение нелинейного уравнения:
где К – число экспериментально полученных интервалов между отказами.
Реально значение N получают методом подбора, основываясь на том, что это целое число.
Значение коэффициента пропорциональности С получают как:
.
(4)
Данная методика работает для К³2, т.е. надо иметь хотя бы два экспериментально полученных интервала между моментами возникновения ошибок.
Пример прогнозирования отказов программного обеспечения
Пусть в ходе отладки программы зафиксированы интервалы времени D t 1 =10, D t 2 =20, D t 3 =25 между отказами программы. ЗначенияD t могут определяться в единицах времени, а могут – в числе прогонов программы при тестировании. Определим вероятность работоспособности программыP (t 4 )= exp (- l 4 × t 4 ) , т.е. отсутствия следующего, четвертого отказа, начиная от момента устранения третьего отказа и среднее времяТ 4 до следующего отказа программы.
Решаем уравнение (3) относительно N методом перебора.
Для N =4 имеем приК=3
Для N =5
Наименьшую ошибку обеспечивает N =4 , откуда в соответствии с выражением (4):
.
Таким образом вероятность безотказной работы в отсутствии 4-го отказа составляет
P (t 4 )= exp (-0,02 × t 4 ) , аT 4 =1/ l 4 =50 .
Напоминаем, что отсчет t 4 начинается после возникновения третьего отказа и определяется в единицах времени или в числе прогонов программы.
Пример расчета звездообразной сети:
Локальная вычислительная сеть (ЛВС) обычно включает в свой состав комплект рабочих станций пользователя, рабочую станцию администратора сети (может использоваться одна из пользовательских станций), серверное ядро (комплект аппаратных серверных платформ с серверными программами: файл-сервер, WWW-сервер, сервер БД, почтовый сервер и т.п.), коммуникационное оборудование (маршрутизаторы, коммутаторы, концентраторы) и структурированную кабельную систему (кабельное оборудование).
Расчет надежности ЛВС начинают с формирования понятия отказа данной сети. Для этого анализируются управленческие функции, выполнение которых на предприятии осуществляется с использованием данной ЛВС. Выбираются такие функции, нарушение которых недопустимо, и определяется оборудование ЛВС, задействованное при их выполнении. Например: безусловно, в течение рабочего дня должна обеспечиваться возможность вызова/записи информации из базы данных, а также обращение к Internet.
Для совокупности таких функций по структурной электрической схеме определяется оборудование ЛВС, отказ которого непосредственно нарушает хотя бы одну из указанных функций, и составляется логическая схема расчета надежности.
При этом учитываются количества и условия работы ремонтно-восстановительных бригад. Обычно принимаются следующие условия:
Восстановление ограниченное – т.е. в любой момент времени не может восстанавливаться более, чем один отказавший элемент, т.к. имеется одна ремонтная бригада;
Среднее время восстановления отказавшего элемента устанавливается или исходя из допустимых перерывов в работе ЛВС, или из технических возможностей доставки и включения в работу этого элемента.
В рамках изложенного выше подхода к расчету схема расчета надежности, как правило, может быть сведена к последовательно-параллельной схеме.
Установим в качестве критерия отказа ЛВС отказ оборудования, входящего в ядро сети: серверов, коммутаторов или кабельного оборудования.
Считаем, что отказ рабочих станций пользователей не приводит к отказу ЛВС, а поскольку одновременный отказ всех рабочих станций – событие маловероятное, сеть при отдельных отказах рабочих станций продолжает функционировать.
Надёжность звездообразной сети.
Отказы не влияют на отказ всей сети. Надёжность ЛВС определяется надёжностью центрального узла.
Примем, что рассматриваемая локальная сеть включает один сервер, два коммутатора и четырнадцать кабельных фрагментов, относящихся к ядру сети. Интенсивность отказов и восстановлений для них приведены ниже, по-прежнему К Г =1-l/m.
Значения интенсивности восстановлений максимальны для кабелей, замена которого проводится с использованием запасных и минимальны для коммутаторов, ремонт которых осуществляется специализированными фирмами.
Расчет характеристик подсистем серверов, коммутаторов и кабелей проводится по выражениям для последовательного соединения элементов.
Подсистема серверов:
l С =2*l 1 =2*10 -5 ;
К ГС =1-2*10 -4 ;m С =
=0,1
1/ч.
Подсистема коммутаторов:
l к =2*10 -5 ;
К Гк =1-2*10 -3 ;m к = 
1/ч.
Подсистема кабелей:
l л =14*10 -6 ; К Гл =1-14*10 -6 ;m л = 1 1/ч.
Для всей сети:
l s =6,5*10 -5 ; К Г s =1-2,4*10 -3 ;m s =0,027 1/ч.
Результат расчета:
Т=15 тыс. ч., К Г =0,998, Т В »37 ч.
Расчет стоимости ЛВС:
14 сетевых карт: 1500руб.
Кабель 1км: 2000руб.
Разъемы: 200руб.
Сервер: 50тыс. руб.
Всего: 2 53700 т. Руб.
Значительная часть производственного процесса опирается на тестирование программ. Что это такое и как осуществляется подобная деятельность обсудим в данной статье.
Что называют тестированием?
Под этим понимают процесс, во время которого выполняется программное обеспечение с целью обнаружения мест некорректного функционирования кода. Для достижения наилучшего результата намеренно конструируются трудные наборы входных данных. Главная цель проверяющего заключается в том, чтобы создать оптимальные возможности для отказа Хотя иногда тестирование разработанной программы может быть упрощено до обычной проверки работоспособности и выполнения функций. Это позволяет сэкономить время, но часто сопровождается ненадежностью программного обеспечения, недовольством пользователей и так далее.
Эффективность
То, насколько хорошо и быстро находятся ошибки, существенным образом влияет на стоимость и длительность разработки программного обеспечения необходимого качества. Так, несмотря на то, что тестеры получают заработную плату в несколько раз меньшую, чем программисты, стоимость их услуг обычно достигает 30 - 40 % от стоимости всего проекта. Это происходит из-за численности личного состава, поскольку искать ошибку - это необычный и довольно трудный процесс. Но даже если программное обеспечение прошло солидное количество тестов, то нет 100 % гарантии, что ошибок не будет. Просто неизвестно, когда они проявятся. Чтобы стимулировать тестеров выбирать типы проверки, которые с большей вероятностью найдут ошибку, применяются различные средства мотивации: как моральные, так и материальные.
Подход к работе
Оптимальной является ситуация, когда реализовываются различные механизмы, направленные на то, чтобы ошибок в программном обеспечении не было с самого начала. Для этого необходимо позаботится о грамотном проектировании архитектуры, четком техническом задании, а также важно не вносить коррективы в связи, когда работа над проектом уже начата. В таком случае перед тестером стоит задача нахождения и определения небольшого количества ошибок, которые остаются в конечном результате. Это сэкономит и время, и деньги.
Что такое тест?
Это немаловажный аспект деятельности проверяющего, который необходим для успешного выявления недочетов программного кода. Они необходимы для того, чтобы контролировать правильность приложения. Что входит в тест? Он состоит их начальных данных и значений, которые должны получиться как результирующие (или промежуточные). Для того чтобы успешнее выявлять проблемы и несоответствия, тесты необходимо составлять после того, как был разработан алгоритм, но не началось программирование. Причем желательно использовать несколько подходов при расчете необходимых данных. В таком случае растёт вероятность обнаружения ошибки благодаря тому, что можно исследовать код с другой точки зрения. Комплексно тесты должны обеспечивать проверку внешних эффектов готового программного изделия, а также его алгоритмов работы. Особенный интерес предоставляют предельные и вырожденные случаи. Так, в практике деятельности с ошибками часто можно выявить, что цикл работает на один раз меньше или больше, чем было запланировано. Также важным является тестирование компьютера, благодаря которому можно проверить соответствие желаемому результату на различных машинах. Это необходимо для того, чтобы удостовериться, что программное обеспечение сможет работать на всех ЭВМ. Кроме того, тестирование компьютера, на котором будет выполняться разработка, является важным при создании мультиплатформенных разработок.
Искусство поиска ошибок
Программы часто нацелены на работу с огромным массивом данных. Неужели его необходимо создавать полностью? Нет. Широкое распространение приобрела практика «миниатюризации» программы. В данном случае происходит разумное сокращение объема данных по сравнению с тем, что должно использоваться. Давайте рассмотрим такой пример: есть программа, в которой создаётся матрица размером 50x50. Иными словами - необходимо вручную ввести 2500 тысячи значений. Это, конечно, возможно, но займёт очень много времени. Но чтобы проверить работоспособность, программный продукт получает матрицу, размерность которой составляет 5x5. Для этого нужно будет ввести уже 25 значений. Если в данном случае наблюдается нормальная, безошибочная работа, то это значит, что всё в порядке. Хотя и здесь существуют подводные камни, которые заключаются в том, что при миниатюризации происходит ситуация, в результате которой изменения становятся неявными и временно исчезают. Также очень редко, но всё же случается и такое, что появляются новые ошибки.
Преследуемые цели
Тестирование ПО не является легким делом из-за того, что данный процесс не поддаётся формализации в полном объеме. Большие программы почти никогда не обладают необходимым точным эталоном. Поэтому в качестве ориентира используют ряд косвенных данных, которые, правда, не могут полностью отражать характеристики и функции программных разработок, что отлаживаются. Причем они должны быть подобраны таким образом, чтобы правильный результат вычислялся ещё до того, как программный продукт будет тестирован. Если этого не сделать заранее, то возникает соблазн считать всё приблизительно, и если машинный результат попадёт в предполагаемый диапазон, то будет принято ошибочное решение, что всё правильно.
Проверка в различных условиях
Как правило, тестирование программ происходит в объемах, которые необходимы для минимальной проверки функциональности в ограниченных пределах. Деятельность ведётся с изменением параметров, а также условий их работы. Процесс тестирования можно поделить на три этапа:
- Проверка в обычных условиях. В данном случае тестируется основной функционал разработанного программного обеспечения. Полученный результат должен соответствовать ожидаемому.
- Проверка в чрезвычайных условиях. В этих случаях подразумевается получение граничных данных, которые могут негативно повлиять на работоспособность созданного программного обеспечения. В качестве примера можно привести работу с чрезвычайно большими или малыми числами, или вообще, полное отсутствие получаемой информации.
- Проверка при исключительных ситуациях. Она предполагает использование данных, которые лежат за гранью обработки. В таких ситуациях очень плохо, когда программное обеспечение воспринимает их как пригодные к расчету и выдаёт правдоподобный результат. Необходимо позаботиться, чтобы в подобных случаях происходило отвержение любых данных, которые не могут быть корректно обработаны. Также необходимо предусмотреть информирование об этом пользователя
Тестирование ПО: виды
Создавать программное обеспечение без ошибок весьма трудно. Это требует значительного количества времени. Чтобы получить хороший продукт часто применяются два вида тестирования: «Альфа» и «Бета». Что они собой представляют? Когда говорят об альфа-тестировании, то под ним подразумевают проверку, которую проводит сам штат разработчиков в «лабораторных» условиях. Это последний этап проверки перед тем, как программа будет передана конечным пользователям. Поэтому разработчики стараются развернуться по максимуму. Для легкости работы данные могут протоколироваться, чтобы создавать хронологию проблем и их устранения. Под бета-тестированием понимают поставку программного обеспечения ограниченному кругу пользователей, чтобы они смогли поэксплуатировать программу и выявить пропущенные ошибки. Особенностью в данном случае является то, что часто ПО используется не по своему целевому назначению. Благодаря этому неисправности будут выявляться там, где ранее ничего не было замечено. Это вполне нормально и переживать по этому поводу не нужно.
Завершение тестирования
Если предыдущие этапы были успешно завершены, то остаётся провести приемочный тест. Он в данном случае становиться простой формальностью. Во время данной проверки происходит подтверждение, что никаких дополнительных проблем не найдено и программное обеспечение можно выпускать на рынок. Чем большую важность будет иметь конечный результат, тем внимательней должна проводиться проверка. Необходимо следить за тем, чтобы все этапы были пройдены успешно. Вот так выглядит процесс тестирования в целом. А теперь давайте углубимся в технические детали и поговорим о таких полезных инструментах, как тестовые программы. Что они собой представляют и в каких случаях используются?
Автоматизированное тестирование
Ранее считалось, что динамический анализ разработанного ПО - это слишком тяжелый подход, который неэффективно использовать для обнаружения дефектов. Но из-за увеличения сложности и объема программ появился противоположный взгляд. Автоматическое тестирование применяется там, где самыми важными приоритетами является работоспособность и безопасность. И они должны быть при любых входных данных. В качестве примера программ, для которых целесообразным является такое тестирование, можно привести следующие: сетевые протоколы, веб-сервер, sandboxing. Мы далее рассмотрим несколько образцов, которые можно использовать для такой деятельности. Если интересуют бесплатные программы тестирования, то среди них качественные найти довольно сложно. Но существуют взломанные «пиратские» версии хорошо зарекомендовавших себя проектов, поэтому можно обратиться к их услугам.
Avalanche
Этот инструмент помогает обнаружить дефекты, проходя тестирование программ в режиме динамического анализа. Он собирает данные и анализирует трассу выполнения разработанного объекта. Тестеру же предоставляется набор входных данных, которые вызывают ошибку или обходят набор имеющихся ограничений. Благодаря наличию хорошего алгоритма проверки разрабатывается большое количество возможных ситуаций. Программа получает различные наборы входных данных, которые позволяют смоделировать значительное число ситуаций и создать такие условия, когда наиболее вероятным является возникновение сбоя. Важным преимуществом программы считается применение эвристической метрики. Если есть проблема, то ошибка приложения находится с высокой вероятностью. Но эта программа имеет ограничения вроде проверки только одного помеченного входного сокета или файла. При проведении такой операции, как тестирование программ, будет содержаться детальная информация о наличие проблем с нулевыми указателями, бесконечными циклами, некорректными адресами или неисправностями из-за использования библиотек. Конечно, это не полный список обнаруживаемых ошибок, а только их распространённые примеры. Исправлять недочеты, увы, придётся разработчикам - автоматические средства для этих целей не подходят.
KLEE
Это хорошая программа для тестирования памяти. Она может перехватывать примерно 50 системных вызовов и большое количество виртуальных процессов, таким образом, выполняется параллельно и отдельно. Но в целом программа не ищет отдельные подозрительные места, а обрабатывает максимально возможное количество кода и проводит анализ используемых путей передачи данных. Из-за этого время тестирования программы зависит от размера объекта. При проверке ставка сделана на символические процессы. Они являются одним из возможных путей выполнения задач в программе, которая проверяется. Благодаря параллельной работе можно анализировать большое количество вариантов работы исследуемого приложения. Для каждого пути после окончания его тестирования сохраняются наборы входных данных, с которых начиналась проверка. Следует отметить, что тестирование программ с помощью KLEE помогает выявлять большое количество отклонений, которых не должно быть. Она может найти проблемы даже в приложениях, которые разрабатываются десятилетиями.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
1. Анализ особенностей программной надежности АСОИУ и методов прогнозирования программных отказов
1.1 Основные понятия надежности программного обеспечения
Автоматизация процессов управления является главным направлением развитие систем управления войсками, в ходе которого осуществляется разработка, создание и использование в процессах управления войсками электронно-вычислительной техники, сопряженных с ней технических средств, информационного и математического обеспечения, что позволяет значительно повысить оперативность управления, улучшить качество обработки информации и производительность систем управления. Для этих целей создаются автоматизированные системы управления войсками.
Основным элементом автоматизированной системы управления войсками является комплекс средств автоматизации КП различных уровней, которые представляют собой совокупность технических средств (передачи, обработки, отображения информации) и программного обеспечения.
Одними из самых серьезных недостатков программного обеспечения АСОИУ является дороговизна и низкая надежность. Многие специалисты считают первый из этих недостатков продолжением второго. Поскольку программное обеспечение по самой своей природе ненадежно, его тестирование и сопровождение требует постоянных существенных расходов.
Перед тем как анализировать надежность программного обеспечения уточним фундаментальные основные понятия теории надежности.
Надежность программного обеспечения - это свойство обеспечивать получение в соответствии с заданным алгоритмом правильных результатов в течении определенного интервала времени.
Отказпрограммного обеспечения - состояние комплекса программ связанное с нарушением работоспособности комплекса программ и прекращением дальнейшего функционирования из-за ошибок.
Под ошибкойв программном обеспечении будем понимать такое сочетание команд в программе, при исполнении которых при правильных исходных данных получают результат, не соответствующий эталонным значениям, заданные в технической документации.
Надежность программного обеспечения АСОИУ определяется его безотказностью, восстанавлиемостью и устойчивостью.
Безотказность программного обеспечения есть его свойство сохранять способность правильно выполнять задание функции и решать задачи, возложенные на вычислительные средства АСУ в процессе обработки информации на ЭВМ в течение заданного времени. При этом состояние программного обеспечения, при котором задачи по обработке информации на ЭВМ решаются правильно (корректно), называется работоспособным состоянием. В противном случае состояние носит название неработоспособным.
Переход из работоспособного состояния в неработоспособное происходит под воздействием программных отказов. Особенностью программного отказа является то, что его устранение осуществляется путем исправления программы или входных данных.
Важным свойством программного обеспечения является его восстанавлиемость, под ним понимается свойство, заключающее в приспособленности программного обеспечения к обнаружению причин возникновения программных отказов и устранению их. Восстановление после отказа в программе может заключатся в корректировке и восстановлении текста программы, исправления данных, внесении изменений в организацию вычислительного процесса (что часто оказывается необходимым при работе вычислительных средств в реальном масштабе времени).
Известно, что сбой в теории надежности определяется как самоустраняющийся отказ, не требующий вмешательства из вне для его устранения. Другим словом - сбой есть автоматически устраняющийся отказ, имеющий достаточно малое время восстановления. Поэтому применительно к надежности программного обеспечения АСУ следует конкретно указывать критерий, позволяющий отнести потерю работоспособности комплекса программ к отказу или сбою. В качестве такого критерия возьмем некоторое пороговое значение времени восстановления (? в пор).
Таким образом на устранение сбоя затрачивается меньше времени и ресурсов чем на устранение отказа. В формализованном виде определение сбоя и отказа программного обеспечения могут быть представлены как:
В с < ? в пор
В с - время восстановления после сбоя.
В о - время восстановления после отказа.
Устойчивость функционирования программного обеспечения - это способность ограничивать последствия внутренних ошибок в программах и неблагоприятных воздействий внешней среды (к которым относится неисправности аппаратуры, некорректность входных данных, ошибки оператора и другие) и противостояние им.
В проведенном анализе основных понятий надежности программного обеспечения даны определения, отказа, ошибки и надежности программного обеспечения. Выяснилось, что переход из работоспособного состояния в неработоспособное происходит под воздействием программных отказов. Из временных показателей видно, что на устранение сбоя затрачивается меньше времени и ресурсов чем на устранение отказа.
1.2 Основные причины и признаки выявления ошибок программного обеспечения
Основными причинами ошибок программного обеспечения являются:
Большая сложность программного обеспечения, например, по сравнению с аппаратурой ЭВМ.
Неправильный перевод информации из одного представления в другое на макро и микро уровнях. На макро уровне, уровне проекта, осуществляется передача и преобразование различных видов информации между организациями, подразделениями и конкретными исполнителями на всех этапах жизненного цикла ПО. На микро уровне, уровне исполнителя, производится преобразование информации по схеме: получить информацию, запомнить, выбрать из памяти, воспроизвести информацию.
Источниками ошибок программного обеспечения являются:
Внутренние: ошибки проектирования, ошибки алгоритмизации, ошибки программирования, недостаточное качество средств защиты, ошибки в документации.
Внешние: ошибки пользователей, сбои и отказы аппаратуры ЭВМ, искажение информации в каналах связи, изменения конфигурации системы.
Признаками выявления ошибок являются:
1. Преждевременное окончание программы.
2. Увеличение времени выполнения программы.
3. Нарушение последовательности вызова отдельных подпрограмм.
4. Ошибки выхода информации, поступающей от внешних источников, между входной информацией возникает не соответствие из-за: искажение данных на первичных носителях, сбои и отказы в аппаратуре, шумы и сбои в каналах связи, ошибки в документации.
Ошибки скрытые в самой программе: ошибка вычислений, ошибка ввода-вывода, логические ошибки, ошибка манипулирования данными, ошибка совместимости, ошибка сопряжения.
Искажения входной информации подлежащей обработке: искажения данных на первичных носителях информации; сбои и отказы в аппаратуре ввода данных с первичных носителей информации; шумы и сбои в каналах связи при передачи сообщений по линиям связи; сбои и отказы в аппаратуре передачи или приема информации; потери или искажения сообщений в буферных накопителях вычислительных систем; ошибки в документировании; используемой для подготовки ввода данных; ошибки пользователей при подготовки исходной информации.
Неверные действия пользователя:
1. Неправильная интерпретация сообщений.
2. Неправильные действия пользователя в процессе диалога с программным обеспечением.
3. Неверные действия пользователя или по-другому, их можно назвать ошибками пользователя, которые возникают вследствие некачественной программной документации: неверные описания возможности программ; неверные описания режимов работы; неверные описания форматов входной и выходной информации; неверные описания диагностических сообщений.
Неисправности аппаратуры установки: приводят к нарушениям нормального хода вычислительного процесса; приводят к искажениям данных и текстов программ в основной и внешней памяти.
Итак, при рассмотрение основных причин возникновения отказа и сбоев программного обеспечения можно сказать, что эти знания позволяют своевременно принимать необходимые меры по недопущению отказов и сбоев программного обеспечения.
1.3 Основные параметры и показатели надежности программ АСОИУ
Термин модели надежности программного обеспечения, как правило относится к математической модели, построенной для оценки зависимости программного обеспечения от некоторых определенных параметров.
Параметр - количественные величины, в функции или математической модели выбираемая или оцениваемая в конкретных условиях.
Значение таких параметров либо предлагаются известными, либо могут быть измерены в ходе наблюдений или экспериментального исследования процесса функционирования программного обеспечения.
Усложнение алгоритмов функционирования автоматизированных систем приводит к значительному объему и сложности программного обеспечения. Увеличение же объема (до 10 5 и более машинных команд) и сложности программного обеспечения делает невозможной разработку полностью бездефектных составляющих программного обеспечения программ. В результате программное обеспечение сдается в эксплуатацию с ошибками, являющимися причинами отказа программного обеспечения. Процесс отладки программного обеспечения по выявлению и устранению ошибок в программах можно представить графиком изменения интенсивности отказов программного обеспечения о.
Рис. 1.3.1. - время жизни программы.
Участок 1 соответствует этапам отладки, испытания и опытной эксплуатации программного обеспечения. На участке 2 остаточные после проектирования ошибки программного обеспечения, соответствующие достаточно редкому сочетанию входных данных, и отладка ошибок. На участке 3 появляются новые ошибки и после нескольких доработок комплекса программ наступает моральное устаревание программного обеспечения. После этого программное обеспечение подлежит полной замене как отработавший свой срок и не соответствующий новым условиям.
1.4 Методы прогнозирования программных отказов и тестирование программ
Предупреждение ошибок - лучший путь повышения надёжности программного обеспечения. Для его реализации была разработана методика проектирования систем управления, соответствующая спиральной модели жизненного цикла программного обеспечения. Методика предусматривает последовательное понижение сложности на всех этапах анализа объекта. При декомпозиции АСОИУ были выделены уровни управления системы, затем подсистемы, комплексы задач и так далее, вплоть до отдельных автоматизируемых функций и процедур.
Методы прогнозирования и тестирования программного обеспечения позволяют предупредить, минимизировать или исключить появление ошибок.
Методы прогнозирования и тестирования программного обеспечения включают в себя:
1. Методы, позволяющие справиться со сложностью системы.
Сложность системы является одной из главных причин низкой надежности программного обеспечения. В общем случае, сложность объекта является функцией взаимодействия между его компонентами. В борьбе со сложностью программного обеспечения используются две концепции: [Л.1]
Иерархическая структура. Иерархия позволяет разбить систему по уровням понимания. Концепция уровней позволяет анализировать систему, скрывая несущественные для данного уровня детали реализации других уровней. Иерархия позволяет понимать, проектировать и описывать сложные системы.
Независимость. В соответствии с этой концепцией, для минимизации сложности, необходимо максимально усилить независимость элементов системы.
2. Методы достижения большей точности при переводе информации.
Методы улучшения обмена информацией базируются на введении в программное обеспечение системы различных видов избыточности:
Временная избыточность. Использование части производительности ЭВМ для контроля исполнения и восстановления работоспособности программного обеспечения после сбоя.
Информационная избыточность. Дублирование части данных информационной системы для обеспечения надёжности и контроля достоверности данных.
Программная избыточность включает в себя:
взаимное недоверие - компоненты системы проектируются, исходя из предположения, что другие компоненты и исходные данные содержат ошибки, и должны пытаться их обнаружить;
немедленное обнаружение и регистрацию ошибок;
выполнение одинаковых функций разными модулями системы и сопоставление результатов обработки;
контроль и восстановление данных с использованием других видов избыточности.
Каждый из методов позволяет повысить надежность программного обеспечения и устойчивость к ошибкам. Какой из данных методов лучше определить нельзя, так как каждый метод основан на своих принципах и концепциях. Поэтому можно использовать оба метода.
Важным этапом жизненного цикла программного обеспечения, определяющим качество и надёжность системы, является тестирование. Тестирование - процесс выполнения программ с намерением найти ошибки. Этапы тестирования: контроль отдельного программного модуля отдельно от других модулей системы; контроль сопряжений (связей) между частями системы (модулями, компонентами, подсистемами); контроль выполнения системой автоматизируемых функций; проверка соответствия системы требованиям пользователей, и корректности документации, выполнение программы в строгом соответствии с инструкциями.
Существуют две стратегии при проектировании тестов: тестирование по отношению к спецификациям (документации), не заботясь о тексте программы, и тестирование по отношению к тексту программы, не заботясь о спецификациях. Разумный компромисс лежит где-то посередине, смещаясь в ту или иную сторону в зависимости от функций, выполняемых конкретным модулем, комплексом или подсистемой.
Качество подготовки исходных данных для проведения тестирования серьёзно влияет на эффективность процесса в целом и включает в себя:
1. Техническое задание.
2. Описание системы.
3. Руководство пользователя.
4. Исходный текст.
5. Правила построения (стандарты) программ и интерфейсов.
6. Критерии качества тестирования.
7. Эталонные значения исходных и результирующих данных.
8. Выделенные ресурсы, определяемые доступными финансовыми средствами.
Однако, исчерпывающее тестирование всех веток алгоритма любой программы для всех вариантов входных данных практически неосуществимо. Следовательно, продолжительность этапа тестирования является вопросом чисто временным. Учитывая, что реальные ресурсы любого проекта ограничены бюджетом и временным показателем, можно утверждать, что искусство тестирования заключается в отборе тестов с максимальной отдачей.
Ошибки в программах и данных могут проявиться на любой стадии тестирования, а также в период эксплуатации системы. Зарегистрированные и обработанные сведения должны использоваться для выявления отклонений от требований заказчика или технического задания. Для решения этой задачи используется система конфигурационного управления версиями программных компонент, база документирования тестов, результатов тестирования и выполненных корректировок программ. Средства накопления сообщений об отказах, ошибках, предложениях на изменения, выполненных корректировках и характеристиках версий являются основной для управления развитием и сопровождением комплекса программного обеспечения и состоят из журналов:
Предлагаемых изменений.
Найденных дефектов.
Утвержденных корректировок.
Реализованных изменений.
Пользовательских версий.
В данной главе анализируются основные причины и признаки ошибок, вводятся основные параметры и показатели надежности программного обеспечения. Также рассмотрены методы прогнозирования программных отказов и тестирование программ с целью повышения надежности. Для оценки надежности программного обеспечения используются специальные модели на основание параметров и показателей приведенных выше.
2. Анализ моделей оценки программной надежности
Существующие математические модели должны оценивать характеристики ошибок в программах и прогнозировать их надежность при эксплуатации. Модели имеют вероятностный характер, и достоверность прогнозов зависит от точности исходных данных и глубины прогнозирования по времени.
Эти математические модели предназначены для оценки:
1. Показателей надежности комплекса программ в процессе отладки;
2. Количества ошибок оставшиеся не выявленными;
3. Времени, необходимого для обнаружения следующей ошибки в функционирующей программе;
4. Времени, необходимого для выявления всех ошибок с заданной вероятностью.
Существуют ряд математических моделей:
Экспоненциальная модель изменения ошибок в зависимости от времени отладки.
Дискретно-меняющаяся модель, учитывающая дискретно-повышающую времени наработки на отказ, как линейную функцию времени тестирования и испытания.
Модель Шумана. Исходные данные для модели Шумана собираются в процессе тестирования программного обеспечения в течение фиксированных или случайных временных интервалов.
Модель La Padula. По этой модели выполнение последовательности тестов в m этапов. Каждый этап заканчивается внесением исправлений в программное обеспечение.
Модель Джелинского - Моранды. Исходные данные собираются в процессе тестирования программного обеспечения. При этом фиксируется время до очередного отказа.
Модель Шика - Волвертона. Модификация модели Джелинского - Моранды для случая возникновения на рассматриваемом интервале более одной ошибки.
Модель Муса. В процессе тестирования фиксируется время выполнения программы (тестового прогона) до очередного отказа.
Модель переходных вероятностей. Эта модель основана на марковском процессе, протекающем в дискретной системе с непрерывным временем.
Модель Миллса. Использование этой модели предполагает необходимость перед началом тестирования искусственно вносить в программу некоторое количество известных ошибок.
Модель Липова. Модификация модели Миллса, рассматривающая вероятность обнаружения ошибки при использовании различного числа тестов.
Простая интуитивная модель. Использование этой модели предполагает проведения тестирования двумя группами программистов независимо друг от друга, использующими независимые тестовые наборы.
Модель Коркорэна. Модель использует изменяющиеся вероятности отказов для различных типов ошибок.
Модель Нельсона. Данная модель при расчете надежности программного обеспечения учитывает вероятность выбора определенного тестового набора для очередного выполнения программы.
При таком большом количестве моделей все-таки основными из них являютсяэкспоненциальная и дискретно-меняющаяся модели.
2.1 Дискретно-меняющая модель
В данной работе под дискретно-меняющей моделью подразумевается модель, которая основывается на дискретном увеличении времени наработки на отказ. Такая модель базируется на следующих предположениях:
1. Устранение ошибок в программе приводит к увеличению времени наработки на отказ T на одну и ту же величину, равную:
T (1) =T (2) =…=T (i) = const (2.1.1)
T (i) = T (i) - T (i-1) (2.2.2)
2. Время между двумя последовательными отказами:
i = t i - t i -1 (2.1.3)
является случайной величиной, которую можно представить в виде суммы двух случайных величин:
i = i -1 + I (2.1.4)
где i - независимые случайные величины, которые имеют одинаковые математические ожидания M{} и среднеквадратические отклонения.
3. Начальный интервал времени 0 сравним со случайной величиной 0 , т.е. 0 0 , поскольку в начальный период эксплуатации программ отказы в них возникают весьма часто.
На основании второго предположения величину интервала между i-м (i-1) - м отказами можно определить соотношением:
i = i -1 + i = 0 + j (2.1.5)
из которого можно получить соотношение для определения времени наступления m-го отказа в программе:
t m = i = (0 + j) (2.1.6)
исходя из третьего предположения полученные соотношения примут вид:
i = 0 + j = j (2.1.7)
t m = (0 + j) = i j (2.1.8)
При этих предположениях средняя наработка между (m-1) - м и m-м отказами программы равна:
T 0 (m) = M{ m -1 } = M{ j } = i j = m M{}. (2.1.9)
Средняя наработка до возникновения m-го отказа может быть определена по соотношению:
T m = M{t m } = i jk) = M{}. (2.1.10)
2.2 Экспоненциальное распределение
Теперь непосредственно перейдем к анализу собственно экспоненциального распределения.
Рассматриваемое распределение характеризуется рядом свойств, такими как:
1. Ошибки в комплексе программ являются независимыми и проявляются в случайные моменты времени. Данное свойство характеризует неизменность во времени интенсивности проявления и обнаружения ошибок (т.е. ош =const) в течение всего времени выполнения программы (=t н -t 0).
2. Интенсивность проявления и обнаружения ошибок ош (интенсивность отказов) пропорционально числу оставшихся в ней ошибок:
()= Kn 0 () (2.2.1)
где K - коэффициент пропорциональности, учитывающий реальное быстродействию ЭВМ и число команд в программе.
3. В процессе исправления ошибок программы новые ошибки не порождаются. Это означает, что интенсивность исправления ошибок dn/dt будет равна интенсивности их обнаружения:
Тогда n 0 ()= N 0 - n(). (2.2.3)
Основываясь на предположениях, введенных выше, получим:
n()=N 0 (1-e - K); (2.5)
Если принять, что, получим:
2.3 Методика оценки надежности программ по числу исправленных ошибок
Пусть N 0 - число ошибок, имеющихся в программе перед началом испытаний.
n() - количество ошибок, устраненных в ходе испытаний (тестирования) программы;
n 0 () - число оставшихся в программе ошибок на момент окончания испытаний.
Тогда n 0 ()= N 0 - n().
Основываясь на предположениях введенных в пункте 2.2.1, а именно: и ()= Kn 0 () то получим:
K - коэффициент, учитывающий быстродействие компьютера.
Решением этого дифференциального уравнения при начальных условиях t=0 и =0 является:
n()=N 0 (1-e -K); (2.3.2)
n 0 ()=N 0 - n()=N 0 e -K . (2.3.3)
Надежность программы по результатам испытаний в течении времени можно охарактеризовать средним временим наработки на отказ, равным:
Если ввести исходное значение среднего времени наработки на отказ перед испытанием, равного, то получим:
откуда видно, что среднее время наработки на отказ увеличивается по мере выявления и исправления ошибок.
На практике в процессе корректировки программы все же могут появляться новые ошибки. Пусть В-коэффициент уменьшения ошибок, определяемый как отношение интенсивности уменьшения ошибок к интенсивности их проявления, или к интенсивности отказов, то есть:
Если обозначить за m - число обнаруженных отказов, а M 0 - число отказов, которое должно произойти, чтобы можно было выявить и устранить n соответствующих ошибок, то есть:
то среднее время наработки на отказ и число обнаруженных отказов определяется следующими соотношениями:
Если принять, что, получим:
Для практического использования представляет интерес число ошибок m, которое должно быть обнаружено и исправлено для того, чтобы добиться увеличения среднего времени наработки на отказ от T 01 до T 02 . Этот показатель может быть получен из следующих соотношений:
Итак, оценка надежности программ по числу исправленных ошибок определяется по формуле:
2.4 Методика оценки надежности программ по времени испытания
Дополнительное время испытаний, необходимое для обеспечения увеличения среднего времени наработки на отказ с T 01 до T 02 определяется из соотношений:
где T 01 и T 02 определяются согласно формуле (2.3.9):
Оценка надежности программ по времени испытаний определяется согласно формуле:
2.5 Методика оценки безотказности программ по наработке
Наработку между очередными отказами - случайную величину T (i) можно представить в виде суммы двух случайных величин:
T (i) = T (i -1) + T (i) (2.5.1)
Последовательно применяя (3.3.1) ко всем периодам наработки между отказами, получаем:
T (i) = T (0) + T (?) (2.5.2)
Случайная величина Т n - наработка до возникновения n-го отказа программы - равна:
T n = T (i) = (2.5.3)
Введем следующие допущения:
1) все случайные величины T () независимы и имеют одинаковые математические ожидания m ? t и среднеквадратические отклонения? ? t ;
2) случайная величина T (0) пренебрежимо мала по сравнению с суммой T (?)
Основанием для второго допущения могут служить следующие соображения: в самый начальный период эксплуатации программы ошибки возникают очень часто, то есть время T (0) мало. Сумма (2.5.3) быстро растет с увеличением n, и доля T (0) быстро падает. Будем считать что T (0) ? T (0) . В соответствии со вторым допущением имеем:
T (n) =T (?) . (2.5.4)
При одинаковых T (?) наработка между (n-1) и n отказами - случайная величина T (n) - имеет математическое ожидание:
m t (n) =M=nm ? t (2.5.6)
T (n) = ? ? t ; (2.5.7)
Для случайной величины T n математическое ожидание равно:
M ? t ; (2.5.8)
и среднеквадратическое отклонение:
T ; (2.5.9)
Чтобы вычислить значения, и, необходимо по данным об отказах программы в течение периода наблюдения t н найти статистические оценки числовых характеристик случайной разности T (i) :
n н - число отказов программы за наработку (0, t н).
Учитывая, что при t >t н число отказов n н >> 1, из (2.5.8) и (2.5.9) имеем:
m t (n) ? m ? t , (2.5.12)
T (n) = ? ? t n ; (2.5.13)
Поскольку случайные величины T (n) и T n согласно (2.5.4) и (2.5.5) равны суммам многих случайных величин, T (n) и T n можно считать распределенными нормально с математическими ожиданиями и дисперсиями, определенными по (2.5.6) - (2.5.9), (2.5.12) и (2.5.13). Так как наработка положительна, на практике используется усеченное на интервале (0, ?) нормальное распределение. Обычно нормирующий множитель с?1.
При n>n н плотность распределения наработки между очередными (n-1) и n отказами:
f (n) (?) = , (2.5.14)
где? отсчитывается с момента последнего, (n-1) отказа.
Заключение
В работе было показано, что надежность программного обеспечения, в десятки раз ниже чем аппаратурная надежность. Требования к программной надежности это определение необходимого выполнения боевых задач в течении не менее чем 1872 часов.
Из анализа видно, что наибольшее влияние на надежность программного обеспечения оказывают внутренние ошибки и ошибки которые находятся при начале эксплуатации программ. Исходя из этого был проведен анализ моделей надежности, методов расчета и оценки программной надежности. С помощью этого анализа, на основе дискретного и экспоненциального метода рассчитали время необходимое на тестирование программного обеспечения, для повышения времени жизни программы.
Список литературы
программный безотказность надежность прогнозирование
1. В.В. Липаев Проектирование математического обеспечения АСУ. (системотехника, архитектура, технология). М., «Сов. радио», 1977.
2. Р.С. Захарова Основные вопросы теории и практики надежности.
3. В.А. Благодатских, В.А. Волнин, К.Ф. ПоскакаловСтандартизация разработки программных средств.
4. А.А. ВороновТеоретические основы построения автоматизированных систем управления. Разработка технического задания.-М.: Наука, 1997.
5. Основы прикладной теории надежности АСУ. Учебное пособие, Тверь, ВА ПВО, 1995, н/с 32. 965,0-75. В.М. Ионов и др., инв. №8856.
6. Б.Н. Горевич. Расчет показателей надежности систем вооружения и резервированных элементов. Конспект лекций, ВА ПВО, 1998, н/с 68.501.4, Г68, инв. №9100
Размещено на Allbest.ru
Подобные документы
Анализ методов оценки надежности программных средств на всех этапах жизненного цикла, их классификация и типы, предъявляемые требования. Мультиверсионное программное обеспечение. Современные модели и алгоритмы анализа надежности программных средств.
дипломная работа , добавлен 03.11.2013
Действия, которые выполняются при проектировании АИС. Кластерные технологии, их виды. Методы расчета надежности на разных этапах проектирования информационных систем. Расчет надежности с резервированием. Испытания программного обеспечения на надежность.
курсовая работа , добавлен 02.07.2013
Программное обеспечение как продукт. Основные характеристик качества программного средства. Основные понятия и показатели надежности программных средств. Дестабилизирующие факторы и методы обеспечения надежности функционирования программных средств.
лекция , добавлен 22.03.2014
Модель надежности программного средства как математическая модель для оценки зависимости надежности программного обеспечения от некоторых определенных параметров, анализ видов. Общая характеристика простой интуитивной модели, анализ сфер использования.
презентация , добавлен 22.03.2014
Запросы клиента по области возможных запросов к серверу. Программа для прогнозирования поведения надежности программного обеспечения на основе метода Монте-Карло. Влияние количества программ-клиентов на поведение программной системы клиент-сервера.
контрольная работа , добавлен 03.12.2010
Особенности аналитической и эмпирической моделей надежности программных средств. Проектирование алгоритма тестирования и разработка программы для определения надежности ПО моделями Шумана, Миллса, Липова, с использованием языка C# и VisualStudio 2013.
курсовая работа , добавлен 29.06.2014
Надежность системы управления как совокупность надежности технических средств, вычислительной машины, программного обеспечения и персонала. Расчет надежности технических систем, виды отказов САУ и ТСА, повышение надежности и причины отказов САУ.
курс лекций , добавлен 27.05.2008
Точные и приближенные методы анализа структурной надежности. Критерии оценки структурной надежности методом статистического моделирования. Разработка алгоритма и программы расчета структурной надежности. Методические указания по работе с программой.
дипломная работа , добавлен 17.11.2010
Постановка проблемы надежности программного обеспечения и причины ее возникновения. Характеристики надежности аппаратуры. Компьютерная программа как объект исследования, ее надежность и правильность. Модель последовательности испытаний Бернулли.
реферат , добавлен 21.12.2010
Надежность как характеристика качества программного обеспечения (ПО). Методика расчета характеристик надежности ПО (таких как, время наработки до отказа, коэффициент готовности, вероятность отказа), особенности прогнозирования их изменений во времени.
