) Аналогичной по своему назначению формой закрытия проблемы является Памятка о. проведенных изменениях (НИИ), применявшаяся в Проектах -2 и 3.

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

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

В Проекте 5 использовалась еще одна форма документирования- Донесение о несоответствиях (ДН).

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

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

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

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

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

7.1.2. Влияние процедур сбора данных на затраты и сроки выполнения проекта

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

Приспособить систему сбора данных к нуждам исследования надежности и просить исполнителен проекта о помощи в классификации проблем программного обеспечения по ходу их возникновения оказалось возможным только в условиях разработки Проекта 5. Если не считать беззлобного ворчания по поводу дополнительных хлопот, .то это сотрудничество можно расценивать как весьма удачное, так же как, впрочем, и совместную работу по ретроспективному анализу данных по Проектам 2, 3 и 4. Совершенно очевидно, что наши умеренные пожелания в части сбора требуемых данных не оказывали отрицательного влияния ни на один из указанных выше проектов, в противном случае нам не позволили бы заниматься подобного . рода деятельностью.; . .