Записаться

Ревизия, аудит и общая логика обеспечения качества

После верификации (verification) и валидации (validation) остаются два более простых процесса — ревизия (review) и аудит (audit). Вместе с процессом обеспечения гарантии качества (quality assurance, QA) они образуют пять процессов, которые по стандарту 1207 позволяют решать задачу обеспечения качества программного продукта или услуги. Процесс менеджмента качества здесь не раскрывается.

Ревизия программных средств

Ревизия — это контроль объёма работ. На определённый момент смотрят, что сделано: один компонент — на 20%, другой — на 10%, третий — на неизвестную величину. При следующей ревизии сравнивают динамику: было 20% — стало 21%; было 10% — осталось 10%; неопределённость сохранилась. По этой динамике делают выводы.

На выходе выполняются технические ревизии и ревизии менеджмента (management review). Оценивают состояние и результаты действий процесса через ревизию деятельности. Результаты доводят до всех участвующих сторон. Контролируют то, что по итогам ревизии выявлено как нехорошее, и устраняют. Риски и проблемы идентифицируются обычным образом. Проблемы направляются в процесс 7.2.8.

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

Ревизия менеджмента проекта

Ревизия менеджмента проекта (project management review) оценивает состояние проекта относительно планов, графиков работ, стандартов и руководящих указаний. Проверяют, не поехали ли сроки; применялся ли выбранный стандарт управления проектами; выполнены ли руководящие указания спонсора и руководства организации.

Технические ревизии

Технические ревизии не касаются функциональности, требований или объёмов в том же смысле. Они формально проверяют:

• укомплектованы ли продукты и есть ли подтверждение;
• соответствуют ли они стандартам организации, спецификациям или другим требованиям и есть ли подтверждение;
• внесены ли изменения в продукты и есть ли подтверждение.

Аудит

Аудит — короткий процесс. Стороны заранее договариваются о проведении аудитов, теме, предмете, выделяют ресурсы, планируют. Если привлекается третья сторона, обеспечивается её независимость. Аудиты проводят, результаты делают доступными.

Общая логика обеспечения качества

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

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

Краткие итоги

Качество в проекте не возникает как отдельная финальная проверка. Оно становится управляемым, когда контроль распределён по жизненному циклу и опирается на заранее выбранные процедуры. Ревизия и аудит занимают в этой системе особое место: они не подменяют верификацию и валидацию, а дополняют их управленческим и договорным контуром. Ревизия отвечает на вопрос, как меняется объём работ и состояние проекта от одной контрольной точки к другой. Её ценность не в фиксации процентов, а в интерпретации динамики: где движение есть, где его нет, где сохраняется неопределённость. Такая интерпретация позволяет своевременно корректировать планы, распределение ресурсов и ответственность.

Управленческая ревизия смещает фокус с продукта на организацию работ. Она показывает, насколько реальное управление соответствует планам, графикам, стандартам и руководящим указаниям. Техническая ревизия проверяет формальную зрелость продукта: комплектность, соответствие принятым требованиям, внесение изменений и наличие подтверждений. Аудит добавляет независимую и договорную проверку: стороны заранее согласуют тему, ресурсы, процедуры и доступность результатов. Практический смысл в том, что качество перестаёт быть предметом личных договорённостей и становится воспроизводимым процессом.

Общая логика требует проактивности. Задачи качества планируются на весь проект, а не решаются по случаю. Для каждой проверки нужно обосновать объект, метод и связь с целями проекта или организации. Это позволяет выбирать между верификацией, валидацией, ревизией и аудитом осознанно, а не по инерции. Второй опорный принцип — совпадение интересов заказчика и поставщика. Обе стороны выигрывают от качественного результата, поскольку исправление ошибок после сдачи дороже, чем своевременный контроль.

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