В основе настоящего исследования лежит идея о том, что анализ статистики содержащихся в программе ошибок позволяет сделать важные выводы о качестве и надежности программы. При осуществлении анализа эмпирических данных об ошибках целесообразно воспользоваться следующим определением надежности программного обеспечения [1]: программа обладает свойством надежности в той мере, в какой она способна удовлетворительно выполнять функции, для которых предназначена. Опенка удовлетворительно не имеет в настоящее время какого-либо общепринятого точного количественного эквивалента. Однако если, например, среди разработчиков программ практикуется такая форма обратной связи, как Уведомление о проблеме (см. приложение Б), то уже сам факт появления подобного документа является доказательством некоторой неудовлетворенности качеством программы; при этом не имеет значения, отражает ли он действительную проблему, свидетельствует ли он о необходимости усовершенствования программы или содержит сведения, которые, как оказывается, говорят об отсутствии какой-либо проблемы вообще.

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

Согласно приведенному выше определению, число ошибок, зафиксированных в Уведомлениях о

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

проблемах, может служить показателем надежности программы. Однако простой подсчет числа ошибок не только не может дать полного представления о на-дежности программы, но может привести к неверным выводам. Поэтому необходим более детальный анализ данных, позволяющий выделить категории ошибок, определить время, место возникновения и способы их определения, а также установить степень влияния ошибок на работу всей сжт&шы.ЛШШЦ}}-оХР обеспечения.

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

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

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

Программист {разработчик или программист-ана-литик) -лицо, создающее программное изделие и составляющее соответствующую документацию. Программист конструирует, кодирует и тестирует те части конечного программного изделия, за которые он отвечает. Таким образом, работа программиста не ограничивается простым кодированием программ.

) огда дефекты называют неполадками.

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

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

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