ния ошибки. Если его поиски увенчались успехом, то локализация и устранение ошибки - удел разработчика ПО.

Впроблеме борьбы с ошибками имеется три направления:

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

проведение отладки,

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

55.Анализ обнаруживаемых в ПО ошибок и важность его проведения

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

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

Кратковременная память позволяет хранить семантические сущности в течении времени до 30 секунд.

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

Наибольший интерес с точки зрения совершения ошибок имеет емкость и устройство кратковременной памяти. Она была описана Дж. Миллером. Имеется число Миллера , равное 7 2 , характеризующее возможности человека по обработке информации. Число Миллера характеризует число семантических сущностей, которыми человек может манипулировать без ошибок, одновременно удерживая их в памяти.

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

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

Имеются работы , которые связывают сложность с нагрузкой на кратковременную память. Перегрузил ее – вот тебе и ошибка.

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

[Введите текст]

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

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

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

в чем состоит ошибка,

когда ( на каком этапе) сделана ошибка,

почему она не проявлялась ранее ,

почему она не была обнаружена при отладке,

как можно было ее предотвратить.

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

Классификация ошибок ПО

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

1)Ошибки – промахи или оплошности, как результат автоматических действий на подсознательном уровне Неправильные действия по правильным предпосылкам (планам), представлениям.

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

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

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

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

82

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

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

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

Часть алгоритмических ошибок связана с невыполнением требований по управлению аппаратурой системы или неправильностью этих требований, изложенных в НТД на аппаратуру – несоответствию реального прибора его описанию, а также требований по управлению СТС в целом.

Отдельно следует говорить о недостатках или отсутствии внутренних или внешних по отношению к ПО средств контроля правильности вводимых в ПО исходных данных. Это тоже недостаток алгоритма работы с системой.

Алгоритмические ошибки обнаруживаются трудно и могут обнаруживаться при отладке ПО в случае использования реальных образцов аппаратуры системы и объекта управления или при адекватной имитации аппаратуры СТС и объекта управления.

Одна из самых важных истин профессии разработчика ПО - любая странность в работе программы, любое замечание должно быть разобрано до конца, так как за ними вероятно стоит ошибка. Многие ошибки имеют сложный неочевидный характер и не всегда повторяются при повторении фрагмента ПО(изменились данные или временные соотношения при исполнении, или работа программного окружения).В этих условиях имеется тенденция списать причину аномального поведения ПО на «сбой».

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

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

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

[Введите текст]