Главная Случайная страница


Полезное:

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


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






Причины появления ошибок в программном обеспечении





 

Причины появления ошибок в программном обеспечении заключаются в недостаточном тестировании ПО (недотестировании) в процессе выполнения работы 5.3.7 «Программирование и тестирование ПС» процесса 5.3 «Разработка» ЖЦ ПП. Общеизвестно, что главные работы по обеспечению качества и надёжности на стадии разработки – это тестирование ПС

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

1) квалификационных испытаний ПС;

2) приёмки ПС;

3) эксплуатации.

Чем раньше обнаружены пропущенные ошибки (дефекты), тем дешевле разработка и эксплуатация ПП.

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

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

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

 


 

Тема 4. МОДЕЛИ НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ (МАТЕМАТИЧЕСКИЕ МОДЕЛИ НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ)

 

Методы оценки надежности, которые разрабатывались для аппаратуры, были успешно использованы при оценке надежности ПО. В частности, математические и статистические методы позволяют инженеру прогнозировать надежность. Эти математические методы используют вероятностные модели и широко применяются во многих инженерных областях. Теория надежности аппаратуры появилась раньше, чем надежность ПО. Вполне естественно, что оценки надежности аппаратуры попытались применить к надежности ПО [32 – 35].

Среди показателей надежности аппаратных средств и ПО самым важным является вероятность безотказной работы. Оценка этой вероятности требуется при тестировании, чтобы решить, когда можно закончить процесс, т.е., когда ПО соответствует требованиям к качеству его работы [32–35].

Из всех областей программной инженерии надежность ПС является самой исследованной областью. Ей предшествовала разработка теории надежности технических средств, оказавшая влияние на развитие надежности ПС. Вопросами надежности ПС занимались разработчики ПС, пытаясь разными системными средствами обеспечить надежность, удовлетворяющую заказчика, а также теоретики, которые, изучая природу функционирования ПС, создали математические модели надежности, учитывающие разные аспекты работы ПС (возникновение ошибок, сбоев, отказов и др.) и позволяющие оценить реальную надежность. В результате надежность ПС сформировалась как самостоятельная теоретическая и прикладная наука [36].

 

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

 

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

Базовыми понятиями, которые используются в моделях надежности ПС, являются [33–36]:

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

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

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

Интенсивность отказов – это частота появления отказов или дефектов в ПС при ее тестировании или эксплуатации.

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

Модели оценки надежности ПС в качестве входных параметров используют сведения об ошибках, отказах, их интенсивности, собранных в процессе тестирования и эксплуатации [33–36].

 

Date: 2016-07-25; view: 1379; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.006 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию