Контроль качества в ходе проектирования
Итак, мы четко сформулировали требования к качеству нашего программного продукта, организовали и используем систему управления конфигурацией, позволившую нам скоординировать работу всех сотрудников. Можем ли мы еще что-то сделать для повышения качества процесса разработки и его результата? Оказывается, да! Как бы не была совершенна процедура разработки, со временем она перестает удовлетворять предъявляемым к ней требованиям. Причин тому много:
люди, загруженные работой, постепенно начинают игнорировать требования процедур (например, забывают оповестить коллег о внесенных ими изменениях);
появляются новые требования, которые действующая система не могла предсказать и не учитывает;
появились новые методы и информационные технологии, решающие поставленные проблемы более эффективно и т.д.
Кроме того, конкуренты не дремлют, повышают эффективность своего производства. И если мы не примем меры для постоянного повышения качества своей организации, она может оказаться аутсайдером на своем сегменте рынка. Поэтому мы должны спланировать и постоянно проводить контроль качества (quality assurance (QA)) всех наших процессов и выпускаемой продукции25.
Методами контроля являются:
обзоры - собрания специалистов, на которых обсуждаются вопросы качества и разрабатываются меры, направленные на его повышения;
внутренние проверки (инспекции), в ходе которых специалисты проверяют друг друга, выявляют ошибки и помогают осознать проблемы;
тестирования и испытания продукции, процессов ее производства и управления, позволяющие продемонстрировать эффективность системы менеджмента качества или выявить проблемы в ее функционировании.
Результаты контроля должны фиксироваться в документации, анализироваться и использоваться для совершенствования системы менеджмента качества.
Во многих случаях система контроля качества в ходе проектирования существенно эффективнее контроля качества готовой продукции, так как позволяет выявить ошибки на более ранних этапах жизненного цикла. На рис.*2 образно представлено соотношение трудоемкостей устранения ошибок на этапах разработки спецификаций (технического задания), написания кода и эксплуатации программного продукта.
На рис проиллюстрировано соотношение усилий, необходимых для устранения ошибок, выявленных на различных этапах разработки ПП. Польза от раннего обнаружения несоответствий
План контроля качества (SQAP): стандарт IEEE
Рис. 19.2. Соотношение усилий на исправление ошибки, найденной на разных этапах
В заключение приведем таблицу, иллюстрирующую преимущества обнаружения и исправления дефектов с помощью инспектирования.
Таблица 19.2.
Оценка количества времени, затрачиваемого на один дефект
Количество часов на: |
Дефект, найденный во время: |
|
инспектирования |
интеграции |
|
отыскание |
0,7–2 |
0,2–10 |
исправление |
0,3–1,2 |
9 и более |
Всего: |
1,0–3,2 |
9,2–19 и более |