Проверка качества - инспекция программ (по методу Фагана).

Автор: Admin

Дата:2012-02-18

Проверка качества предусматривает выполнение большого количества некомпьютеризированных операций. Например, предстоит установить, что продукт:
характеризуется полнотой и не имеет косметических и механических дефектов;
корректно выполнен (то есть с соблюдением спецификации или плана), характеризуется комплексностью и приспособлен к уровню компетентности персонала, для использования которым он предназначен;
удовлетворяет требованиям применимых стандартов.
    Существует несколько подходов к проверке качества с использованием проектной документации. Предложенный здесь Вашему вниманию был разработан сотрудником компании "IBM" Майклом Е. Фаганом (Michael E Fagan). Данный подход, в котором развиваются и ранее высказывавшиеся мысли относительно статистических процессов и статистического контроля качества, был впервые использован для проверки кода программного обеспечения. Впоследствии ряд специалистов (в особенности следует отметить еще одного сотрудника "IBM" - Кэролин Джонс (Carolyn Jones)) наглядно показали, что подход применим к проверке практически любого документа.
    Цель инспекции программ по методу Фагана - получить свидетельства, доказывающие, что вся проектная документация составлена ясно, недвусмысленно и максимально понятно (насколько позволяет предмет), её понимание не требует специальных объяснений, вся документация по проекту взаимно согласуется и соответствует стандартам, принятым при выборе организацией методологии жизненного цикла разработки системы. Данный метод инспекции предусматривает использование достаточно жестких организационных мер, которые нередко, особенно в самом начале использования, вызывают недовольство и противодействие со стороны персонала. Однако, очевидные свидетельства роста производительности и уменьшения коэффициента ошибок в случае правильного применения этой бюрократической процедуры свидетельствуют в её пользу.
    Фундаментальной основой инспекции является база данных, содержащие связанные с дефектом сведения по таким аспектам как:
тип дефекта (логическая ошибка. нарушение стандарта, допущенный при проектировании просчет и т.д.);
серьезность дефекта (критический/существенный/незначительный);
причина дефекта (отсутствие/несоответствие/избыток);
процентное соотношение перечисленных выше видов, степеней серьезности и причин дефектов в расчёте на страницу, за период времени или применительно к установленной для данной организации норме.
    Подробные количественные данные помогают руководству адекватно оценить ситуацию и принять коррективные меры применительно к проблемным участкам и аспектам. Ниже приведена краткая характеристика (план) процесса инспектирования.
    Распределение ролей при проведении инспекции:
    Модератор: осуществляет общее руководство процессом (обычно для овладения соответствующими навыками требуется специальное обучение). Председательствует на заседаниях по вопросам регистрации дефектов.
    Инспектор (их может быть несколько): должен быть достаточно компетентным для адекватной оценки продукта с той или иной определенной точки зрения (например, пользовательской или технической). Инспектор несет непосредственную личную ответственность за качество продукта.
    Автор: составитель представленного для инспекции документа.
    Чтец: лицо, единственная роль которого в процессе сводится к зачитыванию вслух полного текста представленного документа на собрании инспекционной комиссии.
    Рабочая группа: принимает к исполнению результаты собрания по вопросам казуального анализа (см. ниже).
    Процесс:
    Начальная проверка условий: соответствует ли документ установленным критериям качества (то есть готов ли он к инспекции?).
    Установочное собрание: в нём принимают участие все заинтересованные стороны; цель его - выработать общее понимание содержания и побудительного мотива документа, а также правила проведения собрания по вопросам регистрации дефектов.
    Подготовка: инспекторы в независимом режиме изучают документ и отмечают дефекты.
    Собрание по вопросам регистрации дефектов: в ходе него составляется и утверждается общий список дефектов, обнаруженных в инспектируемом продукте. Фиксируются также статистические показатели. Протокол совещания не ведется, регистрируются только выявленные инспекторами дефекты.
    Собрание по вопросам казуального анализа: проверка статистических данных и сопоставление их с нормативными для данной организации показателями.
    Доработка: автор принимает меры для устранения всех дефектов.
    Заключительная проверка условий: можно ли квалифицировать выполнение доработки как удовлетворительное?
    Заключение: продукт интегрируется в проект (то есть к нему применяются стандартные процедуры управления конфигурацией и контроля внесенных изменений).

Количество просмотров: 4883

Комментарии к статье:

Добавить комментарий

Введите сумму с картинки

© Plutonit.ru - Администрирование, настройка Linux и Windows 2009 - 2024