Эмпирические данные о надежности программного обеспечения

Как будет показано в гл. 7, проекты программного обеспечения могут привести к созданию очень больших массивов данных) Располагая сведениями относительно базовых проектов, мы оказались в поло жении человека, впервые посетившего кондитерский магазин, т. е. перед нами встал вопрос, с чего начать и сколько покупать . Нетрудно было понять, что обработка всех имеющихся данных - задача, практически невыполнимая, не говоря уже о том, что данные, собранные задним числом , оставляют нерешенными многие вопросы относительно точности и полноты, а также возможности их получения в других проектах. Кроме того, оказалось, что многообещающие результаты, полученные на основе данных одного проекта, могут не подтвердиться в ходе выполнения подобных исследований по другим проектам. Поэтому было решено выбрать только такие проекты, данные по которым были наиболее свежими и полными, и проводить исследования лишь в тех направлениях, которые обещают быть наиболее продуктивными с точки зрения практической полезности полученных результатов В силу этих соображений в книге наиболее подробно представлены Проекты 3 и 5. По проекту 3 был получен наиболее полный (и окончательный) набор данных, а в ходе изучения продолжающегося Проекта 5

*) Только в одном Проекте 3 было получено -5619 Уведомлений о проблемах проектирования; 4.521 Уведомление о программных ошибках; данные о затратах, графике, производительности и данные по персоналу для 76 программистов, а также информация относительно структуры программного обеспечения, состоящего из 115 346 операторов исходного языка, образующих 249 про-

грамм.

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

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

ЗЛ. Принципы анализа и основополагающая информацигз

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

- Каков тип или категория ошибки?

- Когда ошибка была обнаружена?

- Могла ли ошибка быть обнаружена раньше?

- Когда была допущена ошибка?

- Насколько серьезно может отразиться ошибк.з на работе системы программного обеспечения?

- Сколько времени потребовалось, чтобы исправить ошибку?

Как уже отмечалось, при классификации ошибки приходится решать вопрос о том, каков ее характер: причинный или симптоматический. Ответ на этот вопрос зависит от точки зрения специалиста. Другими словами, характер одной и той же ошибки может трактоваться по-разному специалистом, который фиксирует ошибку, и специалистом, который ее исправляет. Это объясняется тем, что для одного из них пер-BOCTeneHHbifviH являются симптомы ошибки, а для другого-ее причина (см. разд. 3.2).

Второй вид исследований имел статистическую природу и заключался в анализе связи свойств и метрики ) программного обеспечения с хронологией ошибок.

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

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