) В Проектах 2-5 использовалась только одна из двух названных Лорм: Уведомления о проблемах программного обеспечения в Проектах 2 и 3 и Донесения о несоответствиях (ДИ) в Проектах 4 и 5.

1.5. Сведения о затруднениях при проектировании

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

Анализ упоминавшихся выше Уведомлений о проблемах в той форме, в которой они составляются в ходе проектирования, представляется достаточно сложным. Это связано с тем, что подобные документы формируются, как правило, без какой-либо четкой ориентации, и естественно, что важным параметрам в них порой не уделяется должного внимания. Огромный объем информации, содержащейся в подобных уведомлениях (при разработке Проекта 3 было составлено 5619 таких документов!) и зачастую касающейся важнейших проблем, возникающих в процессе проектирования, требует той же организации, что и информация Уведомлений о проблемах, формируемых в процессе эксплуатации программных средств.

1.6. Информация Уведомлений о проблемах (ошибках)

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

Для каждого проекта указанные документы (УППО и ППИ) являются средством выявления и разрешения проблем. Каждому документу типа УППО должен соответствовать по крайней мере один документ типа ППИ независимо от того, существовала ли проблема в действительности. Уведомление о проблеме программного обеспечения может относиться к программе, базе данных, объединенной системе связи COMPOOL (в случае Проектов 2 и 3), документу, контрольному примеру или просто использоваться с целью постановки вопроса, а также для последующего улучшения организации системы программного обеспечения. Уведомление о проблеме позволяет:

- выявить объект затруднения (программа, база данных и др.),

- установить дату выявления проблемы,

- определить контрольный пример, позволивший выявить проблему,

- определить конфигурацию программного обеспечения на момент выявления проблемы,

- составить описание существа проблемы.

Памятка об изменении говорит о закрытии проблемы либо путем создания новой модификации программного обеспечения, либо путем внесения изменений в базу данных, значения данных или в объединенную систему связи COMPOOL, либо посредством демонстрации того, что проблемы на самом деле не существует (устранение затруднения путем объяснения). В документе типа ППИ содержится также указание о том, правильно ли был распознан в соответствующем УППО объект затруднений. Однако ключевой информацией памятки является все же описание существа проблемы. В Проектах 4 и 5 Уведомления о проблемах программного обеспечения выдавались в виде единого документа, используемого как для постановки, так и для закрытия проблемы. Образцы форм рассмотренных документов приведены в приложении В.

Итоговые цифры анализа Уведомлений о проблемах для базовых проектов представлены в соответствующих разделах книги для каждого отдельного ае*

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

1.7. Характеристики программного обеспечения

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

1.7.1. Структурные характеристики

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

Языковый анализатор TMETRIC. Система TMETRIC представляет собой служебную стандартную программу, обеспечивающую статистический анализ исходной программы на языке JOVIAL J4 путем разложения ее на составляющие по элементам языка. Анализ проводится на уровне подпрограмм. На рис. 1.1 показан пример выданного на печать результата анализа для подпрограммы С0МР012. Использование системы TMETRIC позволяет получать сведения об общей длине исходной программы, измеряемой чис-