) Имеется в виду программист, который либо является разработчиком программного обеспечения, либо отвечает за его внедрение.

) Эта цифра включает время ознакомления с перечнем категорий ошибок в предположении, что доступна вся документация по конкретной проблеме. .......

Оценка степени влияния работы по сбору данных о надежности на ход разработки была проведена лишь в единственном аспекте: было определено время, затрачиваемое на классификацию Уведомлений о проблемах по категориям ошибок, с которыми они связаны. Было установлено, что в среднем у компетентного специалиста на присвоение тому или иному Уведомлению о проблеме программного обеспечения конкретного типа ошибок уходило 1,2 мин, если он делал это спустя много времени после того, как проблема была разрешенаУ неопытного аналитика в такой же ситуации подобная процедура отнимает в среднем 1,6 мин). Если же лицо, ответственное за разрешение проблемы, определяет категории ошибок в процессе документирования необходимых действий по разрешению проблемы, это время оказывается существенно меньше минуты и точность результатов значительно повышается.

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

7.1.3. Специфические проблемы сбора и анализа данных

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

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

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

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

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

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

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