7.4. Выводы и рекомендации

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

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

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

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

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

информация трех видов: признаки проблемы, описание причины, описание принятых мер по разрешению проблемы. Необходима.также дополнительная информация о степени серьезности ошибки (поскольку ошибки неодинаковы по степени их влияния на надежность и по усилиям, требующимся для исправления каждой такой ошибки). Рекомендуется связывать оценку серьезности ошибки с ее влиянием на успех вьшолнения системой заданных функций. Для оценки степени влияния ошибки можно использовать следующую шкалу:

Критическое влияние - задание пользователя не мо-

жет быть завершено

Сильное влияние -задание пользователя может

быть завершено, но функционирование ухудшается

Среднее влияние - функционирование нормаль-

ное, показатели не ухудшаются

Слабое влияние - ошибка не отражается иа

функционировании системы

Влияния нет - в систему вносятся усовер-

шенствования

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

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

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