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

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

- Необходима дальнейшая работа по созданию средств сбора данных о надежности. Эти средства должны быть по возможности универсальными.

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

- Сбор данных о надежности необходимо начинать на раннем этапе цикла разработки программного обеспечения.

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

7.2.1. Важные элементы данных

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

Глат 7

Таблица 7.2

Информация, полезная для анализа Уведомлений о проблемах программного обеспечения

Параметр

Описание

Требования п проблемы проектирования

Критичность проблемы

Тестовая нагрузка

Используемое процессорное время

Трудность разрешения проблем

Показатель независимости проблемы

Показатель объема программирования

Оценка первоначальных и более позд1шх труд- иостей

Используемые людские ресурсы

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

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

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

Машинное время, отводимое па конкретные задания процесса разработки и испытаний

Относительная характеристика трудности закрытия проблемы с указанием причины затруднения

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

Количество строк программы, написанное в течение заданного периода времени

Субъективные оценки трудностей проектирования, кодирования, тестирования, документировапия и внедрения программы, сделанные при первом описанпн программы и после того, как она полностью готова к использованию

Результат точного учета количества человеко-часов трудозатрат разработчиков, испытателей и заказчика программных средств

Уведомлений о проблемах программного обеспечения, приводится в табл. 7.2.

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

7.2.2. Концепция групповых данных

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