- ошибки в подсчете числа строк или в форматировании страниц.

Ошибки сопряжения:

- ошибки в вызывающей последовательности или в операциях инициализации интерфейса.

Проверка проектных решений и программ. Предлагаемый метод проверки проектных решений в основном напоминает метод, описанный в работе [13], согласно которому подобные проверки представляют собой не что иное, как достаточно формализованные просмотры сначала проектной, а затем программной документации. Подобные просмотры по существа сводятся к тому, что лицо (или лица), ответственное за разработку конкретного проекта (или конкретной программы), представляет материалы, по этому проекту (или программе) на рассмотрение группе исполнителей, в состав которой входят специалисты по проектированию, программированию, испытаниям, компоновке систем программного обеспечения и организации баз данных. Кроме того, имеется руководитель проверки, обязанностью которого является проведение со-веш,аний в соответствии с повесткой дня, включающей типовые вопросы и вопросы, возникшие в связи с ошибками, которые квалифицируются как наиболее распространенные. Таким образом, проверки можно расценивать как рабочие совещания исполнителей проекта, создающих конечное изделие, и такие проверки не следует смешивать с более крупными ипро-иодимыми обычно на более высоком уровне предварительными и критическими обзорами состояния разработки в соответствии со стандартом MIL-STD-1521 [14]. Указанные обзоры должны осуществляться независимо и наряду с проверками проектных решений и программ.

По данным фирмы IBM [13], использование инспекционных методов позволяет лредупредить до 38% всех ошибок (в нашем случае эта гнфра для Проекта 3 составила 62,7%). Очевидно, это связано с тем, что в процессе проверок возникает такое общение заинтересованных сторон на рабочем уровне, которое в Обычной обстановке носит случайный и нерегулярный характер. Подобные проверки оказались успеш-

НЫМИ в рамк-ах отдельных груяп, работавших над Проектом 5. При этом было обнаружено, что жизненно необходимыми условиями проведения проверок являются сбор всех леобходкмых участников в одно и то же время; четкая формулировка всех пунктов повестки дня, продуманных применительно к конкрет-ному проекту, и, что, по-видимому, наиболее важно, выделение в графике работ времени яа проведенае кнспе1Шкояных проверок.

Прослеживание еегвей, ЛФВ ПОЭЗД и проверка алгоритмов. Обнаружительные методы типа указанных рекомендуется использовать ыа этапе стендовых испытаний, т. е. тестировалня, проводимого программистом после получения безошибочного результата комяилирования. Хотя эти методы не являются чем-то новым, тем не менее они оказываются довольно эффективными для устранения одиночных ошибок в цикле разработки. Это ©бъясняется тем, что проверке подвергаются достаточно малые структурные элементы программы {кяк правило, подпрограммы), и, следовательно, осуществляется очень тщательная проверкя. Так, например, в Проекте 5, согласно стандартам проектирования и программирования, максимальный размер программ составлял 100 исполняемых операторов.. Это позволило при проверке структурных элементов программы пройти по всем ее ветвям. Кроме того, следует иметь в виду, что проверку структурных элементов программного обеспечения осуществляют разработчики, т. е. люди, кото,р.ые лучше других специалистов знают, как должны функционировать эти элементы и где .возможны ошибки. По данным Проекта 3 было установлено, что 72,6% всех обнаруженных ошибок можно было предупредить с помощью комбинации методов проверки ветвей, функциональных возможн.естей и экстремальных условий. (Разумеется, что детальное еыяолнение таких работ возможно только при условии наличия достаточного .времени.) Результаты, полученные для Проекта 3 и представленные в табл. 4.13, показывают, что 72% ошибок могло бы .б-ыиь обнаружено при помощи описанной комбинированной стратегии проверок. Даи-ньте в графе ПОЭЗД свидетельствуют о том, что 51,i%J

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

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

Задачи проверки логики:

- выполнить по крайней мере один раз каждый оператор и каждю ветвь исходной программы;

- использовать по крайней мере один раз каждую входную точку;

- использовать по крайней мере один раз каждую выходную точку;

- отработать и подтвердить по крайней мере один раз правильность каждого сообщения об ошибках;

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

Задачи проверки вычислительных функций:

убедиться, что в каждом вычислении использу-JoTCH предусмотренные входные величины;

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

иримальными й laкmц&№ШЩX значениями