Шаблон для учета действий по предотвращению ошибок на этапах составления требований, проектирования и разработки

Единственный способ активного предотвращения ошибок зак­лючается в управлении вводом и распространением ошибок.

Экспертные оценки и инспекционные проверки — традици­онный способ активного сокращения ошибок, появляющихся на одном этапе, и предотвращения их перехода на другой этап. Еще одно важное действие — измерение надежности приобретенного ПП. При расширенном использовании инструментальных средств, связанных с сетью Internet, и при более доступных совместно ис­пользуемых библиотеках программное обеспечение неизвестного происхождения (SOUP — Software Of Uncertain Pedigree) стано­вится частью продукта. Команда разработчиков проекта нуждает­ся в процессе верификации, аттестации, принятия и оценки на­дежности SOUP-компонентов. Это должен быть формальный про­цесс с тем же уровнем отслеживания и .конфигурации, что и в случае с компонентами ПП, созданным!? «с нуля». Повторное использование программ обеспечивает огромное повышение про­дуктивности разработчика. Однако при этом могут проявляться скрытые проблемы и дефекты.

Устранение ошибок

Старая поговорка о том, что день, потраченный на предотвра­щение, стоит года, потраченного на исправление последствий, остается весьма актуальной. Устранение возникающей в системе ошибки обходится в 10—100 раз дороже, чем ее предотвращение на начальном этапе.

Процесс устранения ошибок начинается на этапе проектиро­вания ПП и распространяется на этапы разработки и тестирова­ния. После завершения работы по функциональному профили­рованию осуществляется следующий шаг — тестирование степе­ни увеличения надежности ПП, называемое также испытанием под нагрузкой. Цель такого тестирования — определить совокуп­ность нагрузок, при которых система выходит из строя. Это фор­мальный процесс, при котором отслеживание хода выполнения тестирования имеет определенное значение. Результаты тестов анализируются с целью их применения для повторной калиб­ровки моделей, Применяемых для прогнозирования надежности на начальных стадиях проекта. Одной из задач руководителя про­екта является поддержание постоянного совершенствования про­цесса разработки. Благодаря использованию данных, получен­ных при выполнении предыдущих проектов, в текущем проекте поддерживается способность организации к обучению и совер­шенствованию.

Таблица 13.5

Шаблон для учета действий по устранению ошибок на этапах проектирования, разработки и тестирования

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

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