Проблемы сбора и анализа данных

1. Проекты, программное обеспечение и данные значительно изменяются и для их описания не пригодна обычная терминология

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

3. Сбор данных - это огромная работа, для выполпенпя которой нет четко определенных средств и методов

4. Некоторые элементы данных быстро теряются, и поэтому они должны собираться и анализироваться сразу по мере их возникновения, а не с задержкой

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

6. В некоторых проектах фигурируют данные, которые должны засекречиваться

7. Методы анализа н вопросы, которые следует задавать специалистам в процессе сбора нужных данных, недостаточно отработаны

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

9. Невысокая точность данных представляет собой хроническую трудность

10. Анализ данных часто неполон или неточен, если не организовано надлежащее общение исследователей с исполнителями проекта

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

12. Структура проекта обычно не приспосабливается к тому, чтобы использовать доступные данные (т. е. не создается аппарат анализа данных и нет обратной связи между результатами анализа и ходом проектирования)

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

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

15. Обычно думают, что в сборе оценочных данных нет необходимости, если управление проектом организовано правильно

официальным испытаниям, и период ввода системы в эксплуатацию.

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

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

Продолоюение

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

. ность сбора согласованных данных по многим проектам

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

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

286 - Глава 7

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

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

7.2. Рекомендации по совершенствованию процесса сбора данных

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

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

- Сбору данных и их анализу должно предшествовать создание стандартов, определяющих процеду-