Главная / Статьи / Менеджмент (1196) /

Насколько стандарт ISO 9001 сопоставим с CMM

Организации, обеспокоенные вопросом соответствия выпускаемого ПО стандарту ISO 9001, часто интересует, насколько требования данного стандарта совпадают с требованиями модели зрелости процессов разработки (СММ), разработанной Software Engeneering Institute (SEI) . Автор рассматривает 20 положений ISO 9001 и сравнивает их с практиками CMM. Данный анализ проливает свет на некоторые распространенные вопросы относительно двух этих документов.

Стандарт CMM, разработанный SEI (Software Engineering Institute,), и стандарты ISO 9000, принятые Международным Комитетом по Стандартизации (International Organization for Standardization), объединяет общее внимание к вопросам качества ПО и управления процессами. Появление обоих стандартов обусловлено одними и теми же проблемами. На интуитивном уровне они коррелируют, имея при этом разные базовые принципы. ISO 9001, стандарт из серии стандартов 9000, относится к разработке и обслуживанию ПО, определяя минимальные требования для качественной системы, тогда как в CMM упор делается на необходимости постоянной оптимизации процессов. Это положение, несомненно, представляется весьма субъективным. Некоторые члены международного сообщества специалистов по стандартизации утверждают, что если с пониманием подойти к изучению ISO 9001, становится ясно, что он также подразумевает необходимость постоянной оптимизации процессов. Таким образом, коррекционные действия, например, можно рассматривать как постоянную оптимизацию. Тем не менее, данный принцип проводится в СММ с большей определенностью, нежели в ISO 9001. (Прим. ред. Для оптимизации процесса выпуска ПО широко используются технологии компании Rational Software. Причин тому несколько: во-первых, Rational Software — практически единственная компания, которая четко описала весь производственный цикл по выпуску программного обеспечения (Rational Unified Process), определила все возможные виды документов, сопровождающие проект, строго расписала роли (входные/выходные документы, шаблоны документов и пр.) каждого участника проекта и все их действия. Во-вторых, компания создала специальное программное обеспечение для качественного исполнения как каждого этапа в отдельности, так и всего проекта в целом. Важно и то, что Rational посредством RUP предлагает перейти от программирования как искусства к программированию как к науке, где все понятно и прозрачно благодаря научному подходу к разработке. По некоторым оценкам западных аналитиков, соотношение возврата капитала до и после внедрения качественных процессов варьируется от 5:1 до 8:1.) В данной статье поднимается вопрос о связи между двумя указанными документами. В ней я попытался отобразить положения ISO 9001 посредством ключевых практик CMM, основываясь на ISO 9001, ISO 9000-3, TickIt (английское руководство по применению ISO 9000-3 и 9001 к разработке ПО) и учебных материалах по TickIt1. ISO 9000-3 в значительной степени базируется на ISO 9001, в то время как учебные материалы по TickIt помогают разобраться как с ISO 9000-3, так и с ISO 9001.

В ходе анализа я попытался ответить на некоторые распространенные вопросы, включая следующие:

• Какому уровню CMM будет принадлежать организация, соответствующая ISO 9001?

• Может ли организация, находящаяся на уровнях 2 (или 3), считаться соответствующей стандарту ISO 9001?

• Что следует выбрать в качестве основы для оценки управления качеством ПО и оптимизации процессов: ISO 9001 или CMM? Я исхожу из предположения, что читатель либо уже знаком, либо может легко ознакомиться как с тем, так и с другим.

Ниже приведены обзорные сведения, помогающие освежить понимание этих стандартов.

CMM и ISO 9000: ОБЗОР ДОКУМЕНТОВ

Ниже рассматриваются вопросы, содержащиеся в модели зрелости процессов разработки (CMM версия 1.1), а также в стандартах серии ISO 9000 (ISO 9001 и 9000-3), которые относятся к разработке и обслуживанию ПО. (Подробные сведения о CMM, смотри в документе CMM [1, 2]. Подробные сведения относительно применения ISO 9000-3 и ISO 9001, смотри документы [3, 4] и TickIt [5])

CMM. Вышеуказанная модель описывает принципы и практики, лежащие в основе зрелости процесса разработки ПО. Данная модель разрабатывалась с тем, чтобы помочь организациям повысить уровень зрелости подобных процессов. При этом организации должны пройти определенный путь эволюционного развития (от случайных, хаотических процессов к упорядоченным и зрелым). Кроме того, моделью могут воспользоваться клиенты таких организаций. Им она может помочь выявить риски, а также сильные и слабые стороны своих поставщиков ПО. Авторизованные специалисты по оценке должны пройти курсы обучения СММ и методам оценки.

Как следует из таблицы 2, CMM делится на 5 уровней. За исключением первого, каждый последующий уровень обладает набором групп ключевых практик, имеющих первостепенное значение для организаций, желающих улучшить процесс разработки ПО. Каждая такая группа содержит в себе набор ключевых практик, позволяющих установить эффективность, а также стабильность и повторяемость внедрения и установления той или иной группы. Для удобства ключевые практики в каждой группе разделены по общим признакам:

• Обязательства по выполнению. Какие действия должна предпринять организация, чтобы гарантировать стабильность процесса? Данная группа включает практики, относящиеся к политике и лидерству.

• Возможность выполнения. Какими предпосылками должна обладать организация или проект, чтобы компетентно внедрить процесс разработки ПО? Данная группа включает практики, относящиеся к ресурсам, обучению, ориентации, организационной структуре и инструментарию.

• Выполняемые действия. Какие роли и процедуры необходимы для внедрения группы ключевых практик? Включает практики, имеющие отношение к планам, процедурам, выполняемым работам, контролю и корректировке.

• Измерения и анализ. Какие процедуры необходимы для измерения процесса и выполнения анализа таких измерений? Группа включает практики, посвященные измерению и анализу различных показателей процессов.

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

ISO 9001, 9000-3. Стандарты ISO 9000 содержат требования к качественной системе, которые следует использовать при заключении контракта между двумя сторонами, одна из которых требует демонстрации способности поставщика разработать и поставить продукт. Двумя договаривающимися сторонами могут являться: внешний клиент и поставщик. Также обе стороны могут принадлежать одной и той же компании, как в случае договора между маркетинговым отделом и группой разработчиков. Из всех стандартов серии ISO 9000 стандарт ISO 9001 является наиболее применимым к разработке и обслуживанию ПО. Организации прибегают к его использованию тогда, когда желают убедиться в том, что поставщик соответствует определенным требованиям для каждого этапа создания продукта (разработка, производство, установка и обслуживание). ISO 9000-3 выступает в роли руководства по применению ISO 9001 к процессам разработки, поставки и сопровождения ПО. Как правило, организации используют стандарты ISO 9000 в целях налаживания внутрикорпоративной системы контроля над качеством и оценки эффективности таких систем у своих поставщиков. Фактически, данные стандарты зачастую применяются для регистрации внутрикорпоративной системы контроля над качеством сторонних компаний. Регистрационные сертификаты обладают определенной сферой действия в рамках организации и выдаются регистраторами системы контроля качества. Аудиторы проходят обучение стандартам ISO 9000, однако они могут не иметь соответствующей подготовки в области проблем, связанных с ПО. Если в сферу охвата аудита входят подобные проблемы, в команду аудиторов должны быть включены специалисты по ПО.

Статус. Версия 1.1 CMM вышла в свет в феврале 1993 года. С тех пор SEI занималась сбором запросов на изменение и исследованиями.

Одно из важнейших требований, предъявляемых к компании, претендующей на сертификат соответствия стандарту ISO 9000, — наличие четких описаний применяемых на этом предприятии бизнес-процедур. Проблема состоит в том, что текстовое описание деятельности всех должностных лиц требует от менеджеров не только значительных трудозатрат, но и способности к написанию объемных и при этом внутренне непротиворечивых текстов. Здесь на помощь приходит BPwin — CASE-средство, позволяющее документировать бизнес-процедуры графически. Описание бизнес-процедур на языке IDEF-диаграмм будет одновременно и формально строгим, и достаточно лаконичным.

Особенности соответствия

В ходе анализа 20 положений ISO 9001 сравнивались с соответствующими ключевыми практиками CMM вплоть до уровня подпрактик. Данный анализ является, естественно, субъективным, поскольку другие могут интерпретировать требования стандартов иначе. Действительно, проблема надежного непротиворечивого истолкования и оценки встает при проведении сертификации по обоим стандартам. Однако я надеюсь, что мой анализ все же достаточно объективен для того, чтобы помочь тем, кто желает узнать, насколько сертификация по стандарту ISO 9001 вписывается в стратегию постоянного улучшения качества. В таблице 1 представлен обзор отображения положений ISO 9001 с помощью групп ключевых практик и практик CMM. В столбце под названием "Явное соответствие" я привожу те группы ключевых практик и общие признаки, для которых корреляция с положениями ISO 9001 очевидна. В столбце "Сомнительное соответствие" представлены те группы ключевых практик и общих признаков, корреляция которых может восприниматься в значительной степени субъективно.

Таблица 1. Обзор соответствия ISO 9001 и CMM

 

 

Параграф ISO 9001	Явное соответствие	Сомнительное соответствие
4.1: Ответственность за управление	Обязательства по выполнению Планирование проекта Управление программным проектом Обеспечение качества	Возможность выполнения Проверка внедрения Управление качеством
4.2: Качественная система	Проверка внедрения Планирование проекта Обеспечение качества Разработка программного продукта	Определение организационного процесса
4.3: Обзор контракта	Управление требованиями Планирование проекта	Управление субподрядчиками
4.4: Управление проектом	Планирование проекта Управление программным проектом Управление конфигурацией ПО Разработка программного продукта	Управление качеством
4.5: Контроль над документами и данными	Управление конфигурацией ПО Разработка программного продукта
4.6: Закупка	Управление субподрядчиками
4.7: Контроль над продуктом, поставляемым заказчику		Управление субподрядчиками
4.8: Идентификация продукта и отслеживаемость	Управление конфигурацией ПО Разработка программного продукта
4.9: Контроль над процессом	Планирование проекта Обеспечение качества Разработка программного продукта	Управление количественными процессами Управление изменениями в технологии
4.10: Инспектирование и проверка	Разработка программного продукта Экспертная оценка
4.11: Контроль над инспектированием, змерением и испытательным оборудованием	Разработка программного продукта
4.12: Статус инспекций и тестирования	Управление конфигурацией ПО Разработка программного продукта
4.13: Контроль над несоответствием продуктов	Управление конфигурацией ПО Разработка программного продукта
4.14: Коррекционные и профилактические меры	Обеспечение качества Управление конфигурацией ПО	Предотвращение дефектов
4.15: Погрузка/разгрузка, хранение, упаковка, предохранение и доставка		Управление конфигурацией ПО Разработка программного продукта
4.16: Контроль записей о проверке качества	Управление конфигурацией ПО Разработка программного продукта Экспертная оценка
4.17: Внутренний аудит качества	Проверка внедрения Обеспечение качества
4.18: Обучение	Возможность выполнения Программа обучения
4.19: Обслуживание
4.20: Статистические техники	Измерение и анализ	Определение организационного процесса Управление количественными процессами Управление качеством ПО

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

Таблица 2. Области ключевых процессов в СMM

 

 

Уровень CMM	Области ключевых процессов
5. Оптимизирующий Постоянная оптимизация процессов обеспечивается количественной обратной связью со стороны процесса, а также макетированием новых идей и технологий.	Предотвращение дефектов Управление изменениями в технологиях Управление изменениями в процессах
4. Управляемый Измерение всех аспектов процесса и качества продукта и сбор результатов. Как процесс разработки ПО, так и продукты представлены в количественной форме и контролируются	Управление количественными процессами Управление качеством ПО
3. Определенный Процесс разработки ПО (управление и программирование) документируются, стандартизируются и интегрируются в стандартный для организации процесс. Во всех проектах применяется утвержденная, настроенная для конкретных задач версия этого стандартного процесса создания и обслуживания ПО.	Акцентирование организационного процесса Определение организационного процесса Программа обучения Управление интегрированным ПО Создание программного продукта Межгрупповая координация Экспертная оценка
2. Повторяемый Базовые процессы управления проектом реализуются для отслеживания затрат, сроков и функционального объема. Учитывается опыт успешных предыдущих проектов разработки аналогичных приложений.	Управление потребностями Планирование проекта Управление программным проектом Управление субподрядчиками Обеспечение качества Управление конфигурацией ПО
1. Начальный Процесс разработки ПО во многом зависит от случая и время от времени даже хаотичен. Определены лишь несколько процессов, и успех зависит от усилий и героизма отдельных сотрудников

Пункт 4.1: Ответственность руководящих лиц.

ISO 9001 требует от организации:

• определить, документировать, понять, внедрить и поддерживать политику обеспечения качества;

• определить права и обязанности персонала управляющего, выполняющего и проверяющего действия, способные повлиять на качество конечного продукта, а также

• выявить и применить возможности верификации.

Для проведения в жизнь программы обеспечения качества следует назначить специального менеджера. В СММ ответственность за обеспечение качества и верификацию приходится на второй уровень. Она включает ответственность за выполнение всех предусмотренных проектом ролей, создание группы квалифицированных специалистов по контролю качества ПО (SQA) и назначение руководителя, отвечающего за проведение соответствующих действий. Исходя из того, что практики входят в состав общих признаков, CMM определяет сферы ответственности, как на высшем управленческом уровне, так и на уровне проекта по созданию ПО, поддерживает аудит SQA, обеспечивает руководство и создание организационных структур поддержки разработчиков ПО, а также распределяет ресурсы. Мне могут возразить, что данное положение также затрагивает политику обеспечения качества, описанную на четвертом уровне. Однако данная политика является количественной. В ISO 9001 существует ряд неясностей относительно роли измерения в системе управления качеством (см. обсуждение этой проблемы в пункте 4.20 "Статистические методы"). От организации требуется определить и документировать свои цели в связи с обеспечением качества, однако ей необязательно представлять их в количественной форме.

Пункт 4.2: система обеспечения качества.

Согласно ISO 9001, организация должна создать документированную систему обеспечения качества, включающую в себя руководство, планы, процедуры и инструкции. В ISO 9000-3 такая система описывается как интегрированный процесс, имеющий место на протяжении всего жизненного цикла. CMM обращается к системным операциям по проверке соответствия и процессам управления на втором уровне. Особенности используемых в проекте процедур и стандартов описываются в плане разработки ПО. На третьем уровне организация должна определить задачи для разработчиков ПО, которые были бы интегрированы с управленческими процессами для последовательного их выполнения. Данные требования напрямую соотносятся с принятой в ISO 9000-3 интерпретацией данного вопроса. С помощью практики в Проверке внедрения CMM определяет проверку на соответствие выбранным стандартам и процедурам. В данном случае затруднения связаны с набором стандартов, процедур и описаний процессов, определенных в организации для третьего уровня. Создание подобных наборов организационных требований без сомнения вносит свой вклад во внедрение системы обеспечения качества, однако, к стандартам и процедурам в данном случае можно обращаться на уровне проекта. В ISO 9001 обсуждается система контроля качества для поставщика, но при этом в отличие от СММ не затрагивается связь между организационной поддержкой и реализацией проекта. ISO 9000-3, в свою очередь, содержит два раздела, посвященных планированию качества: в пункте 4.2.3 обсуждается планирование качества для нескольких проектов; а в пункте 5.5 — планирование качества в рамках конкретного отдела.

Пункт 4.3: обзор контрактов

Согласно ISO 9001, организациям следует изучать контракты для выяснения адекватности определения требований, их согласованности с требованиями в заявке и осуществимости. В СММ подписание контракта относится ко второму уровню. Организация должна задокументировать и просмотреть требования заказчика, отнеся их к ПО и выявить отсутствующие или неясные требования. Однако, поскольку применение CMM ограничено сферой ПО, требования клиента, как правило, выходят за пределы, установленные для группы ключевых практик Управление требованиями. Кроме того, на уровне 2 в СММ описываются предложение, акт о проделанных работах и план разработки ПО, в котором определены внешние (контрактные) требования, подлежащие изучению группой разработки ПО и высшим руководством. И, наконец, CMM открыто затрагивает вопрос о том, как можно приобрести ПО, заключая договоры с внешними заказчиками и субподрядчиками (при этом поставщик может исполнять роль заказчика). Разделы ISO 9001, посвященные контрактам, не объясняют в явной форме роль поставщика в тех случаях, когда он выступает в роли заказчика по отношению к субподрядчику.

Пункт 4.4: контроль над разработкой.

ISO 9001 требует от организации разработки процедур контроля и проверки разработки. В их число входят:

• действия по планированию, проектированию и разработке;

• определение организационных и технических интерфейсов;

• решение -задач ввода/вывода;

• просмотр, проверка и верификация разработки, а также

• контролирование изменений в дизайне.

ISO 9000-3 подробно останавливается на этом вопросе, обращаясь также к проблемам, связанным со спецификацией требований заказчика (5.3), планированием разработки (5.4), планированием качества (5.5), проектированием и внедрением (5.6), тестированием и проверкой (5.7), а также управлением конфигурацией (6.1). CMM описывает действия, входящие в жизненный цикл анализа требований, разработки, кода, и тестирования на уровне 3. Второй уровень, в свою очередь, отвечает за планирование и контроль над всеми действиями по проекту, включая вышеуказанные. Кроме того, на втором уровне рассматриваются вопросы управления конфигурацией промежуточных программных продуктов. ISO 9001 (в редакции от 1994 года) требует создания обзоров разработки. Согласно ISO 9000-3 такие обзоры должен выполнять поставщик с тем, чтобы убедиться в выполнении требований и адекватности методов разработки. И все же, хотя такие обзоры и обязательны, существует ряд вариантов их создания: от технических обзоров до инспекций. CMM, напротив, требует выполнения экспертной оценки программ на третьем уровне и указывает ряд промежуточных продуктов, которые следует подвергнуть такому анализу. Руководство TickIt проясняет подход, изложенный в ISO 9001. В нем перечислены три примера анализа разработки: инспекции, структурированный сквозной контроль и экспертная оценка программ (то есть, "проверка программы за столом"). В руководстве также говорится на странице 17.10, что "аудитор должен убедиться, что имеющиеся процедуры и записи, относящиеся к анализу, соответствуют типу и важности анализируемого проекта". CMM описывает более формальные, количественные аспекты процесса разработки на уровне 4, в то время ISO 9001 не требует столь выраженной формальности.

Пункт 4.5: контроль над данными и документацией.

Согласно ISO 9001 организация должна контролировать распространение и изменения в документации и данных. В СММ практики управления конфигурацией, относящиеся к этому, описаны на уровне 2. Документация, необходимая для работы с системой и ее обслуживания, приведена на уровне 3. Специальные процедуры, стандарты и прочие документы, которые можно отнести к категории управления конфигурацией, отнесены к различным группам ключевых процессов в общем признаке Выполняемые действия.

Пункт 4.6: закупка.

Положения ISO 9001 обязывают организации удостовериться в том, что закупаемые продукты соответствуют оговоренным требованиям. Это подразумевает оценку потенциальных субподрядчиков и проверку закупаемых продуктов. В СММ вопросы разработки ПО на заказ рассмотрены на втором уровне (включая оценку субподрядчиков и тестирование в ходе приемки поставленных ими программ).

Пункт 4.7: контроль над продуктами, поставляемыми заказчику.

Согласно стандарту ISO 9001, организации обязаны проверять, контролировать и обслуживать все поставляемые заказчику материалы. В ISO 9000-3 данный вопрос обсуждается в контексте включенного ПО (6.8), затрагивая также коммерческие "готовые к продаже" продукты. Единственной практикой СММ, в которой описывается использование приобретенного ПО, является подпрактика на третьем уровне. Контекстом в данном случае является идентификация "готового к продаже" или многократно используемого ПО как части планирования. Проблема интеграции этих двух видов программ является слабым местом СММ. В действительности этот вопрос, особенно в том виде в каком он представлен ISO 9000-3, не может считаться адекватно проясненным CMM. Кажется целесообразным, хотя и недостаточным, применить в отношении любого включенного ПО практику тестирования при приемке у субподрядчика на втором уровне. Я направил запрос на изменение СММ (версия 1.1) с предложением включить в стандарт практики оценки продуктов, к которым в том числе относились бы программы "готовые к продаже" и прочие типы программ, разработанных внешними специалистами.

Пункт 4.8: идентификация и отслеживание продукта.

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

Пункт 4.9: управление процессом.

В соответствие с ISO 9001 организация должна определить и запланировать свои производственные процессы. Это подразумевает контроль над условиями производства согласно задокументированным инструкциям. Если организация не может в полной мере оценить и проверить результат своей работы постфактум, то она должна хотя бы постоянно контролировать производственный процесс. Среди пунктов ISO 9000-3 имеются указания на необходимость включения в число контролируемых процессов разработку и внедрение (5.6); правила, практики и конвенции (6.5); а также инструменты и техники (6.6). В CMM специальные процедуры и стандарты, которые требуется использовать в процессе разработки ПО, указаны в плане разработки ПО на втором уровне. Определение и интеграция процессов производства ПО, а также инструменты, которые поддерживают данные процессы, описаны на третьем уровне. Четвертый уровень посвящен количественным аспектам контроля, примером которого служит статистический контроль. Однако контроль на этом уровне редко требуется осуществлять на практике. Кроме того, в параграфе 6.6 ISO 9000-3 говорится, что "поставщик должен улучшать (указанные выше) инструментарий и техники". Это относится к переходу организации к использованию новых технологий, который описывается на уровне 5.

Пункт 4.10: инспектирование и тестирование.

ISO 9001 требует от организаций инспектировать/верифицировать поступающие материалы перед использованием, а также выполнять инспектирование и тестирование на рабочем месте. Помимо этого организация должна также провести финальное тестирование перед выпуском продукта на рынок и сохранить полученную в результате документацию. Я уже описывал точку зрения СММ на вопросы, возникающие в ходе инспектирования поступающего материала (Пункт 4.7: контроль над продуктами, поставляемыми заказчику). В CMM тестирование и инспектирование на рабочем месте (строго для ПО) описаны на уровне 3.

Пункт 4.11: контроль над инспектированием, измерением и испытательным оборудованием.

Согласно ISO 9001 организация должна контролировать, калибровать и осуществлять техническое обслуживание оборудования, используемого для проверки соответствия. При использовании испытательных аппаратных и программных средств их необходимо проверить перед началом тестирования, а также устраивать периодические проверки через предписанные промежутки времени. ISO 9000-3 содержит пояснения к этому параграфу (см. тестирование и проверка (5.7); правила, практики и конвенции (6.5); а также инструменты и техники (6.6)). В CMM данный вопрос рассматривается в общем и помещается в разряд тестовых практик Создания программного продукта. Испытательное ПО упоминается в общем признаке Возможность выполнения (см. практику, описывающую инструментарий тестирования — Возможность 1.2).

Пункт 4.12: инспектирование и статус теста.

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

Пункт 4.13: контроль над несоответствием продуктов

ISO 9001 требует от организации контроля над несоответствующими продуктами (т.е. продуктами, не удовлетворяющими имеющимся требованиям), нацеленного на предотвращение случайного использования или установки. ISO 9000-3 отражает данную концепцию в параграфах, описывающих разработку и внедрение (5.6); тестирование и проверку (5.7); тиражирование, поставку и установку (5.9), а также управление конфигурацией (6.1). Проблема несоответствующих продуктов не затрагивается отдельным образом в CMM. В ISO 9000-3 эта проблема теряется в ряду связанных с ней процессов, которые охватывают весь жизненный цикл продукта. В СММ статус позиций конфигурации, включая статус позиций, содержащих выявленные, но еще не устраненные дефекты, ведется на втором уровне. Вопросы разработки, внедрения, тестирования и проверки относятся к третьему уровню.

Пункт 4.14: коррекционные и профилактические меры

Согласно ISO 9001, организации должны выяснить причины несоответствия продукта и принять коррекционные меры, направленные на устранение причин фактического несоответствия. Профилактические меры направлены на устранение причин потенциального несоответствия. В ISO 9000-3 данный параграф, взятый из ISO 9001 (версия 1987 года) цитируется дословно, без дальнейших пояснений. Буквальное прочтение данного параграфа потребует применения многих практик СММ из группы ключевых процессов пятого уровня Предотвращение дефектов. Согласно руководству для аудиторов TickIt (стр. 139- 140) и результатам обсуждения этой проблемы с аудиторами, работающими на основе ISO 9000, коррекционные меры принимаются, как правило, в ответ на жалобы заказчика. Группа разработки ПО должна выявлять дефекты на местах, анализировать причины их возникновения и предпринимать коррекционные меры. Чаще всего дефекты имеют место в процессе обновления распространяемого ПО и выпуска патчей к нему. Согласно указанной интерпретации, подходящее отображение мер по исправлению ситуации должно производиться на уровне 2 (отчет о проблемах), вслед за чем должно вестись контролируемое обслуживание промежуточных программных продуктов базовой линии конфигурации. В разделе 23 руководства TickIt имеется еще одно толкование данного вопроса: коррекционные меры должны приниматься в ответ на обнаружение дефектов при аудите (как внешнем, так и внутреннем). Данная интерпретация подразумевает отображение на группу ключевых процессов второго уровня Обеспечение качества. ISO 9001 дает противоречивое толкование термина "профилактические меры" в отношение ПО. Некоторые аудиторы предполагают, что в стандарте речь идет о профилактике аналогичной производственной. Другие склоняются лишь к необходимости рассмотрения пользовательских отчетов о проблемах. Вопрос о том, насколько применимы в данной связи анализ причин в процессе производства ПО (уровень 5 СММ) и профилактика неполадок, остается спорным.

Пункт 4.15: Погрузка/разгрузка, хранение, упаковка, предохранение и доставка

Согласно ISO 9001, организации должны определить и выполнять процедуры, связанные с погрузкой/разгрузкой, хранением, упаковкой и поставкой. Данный вопрос находит отражение в тех параграфах ISO 9000-3, которые посвящены приемке (5.8), тиражированию, поставке и установке (5.9). CMM не охватывает тиражирование, поставку и установку. Создание и выпуск ПО рассматриваются в нем на втором уровне, а тестирование при приемке — на третьем. При этом СММ, однако, не описывает практики, связанные с поставкой и установкой продуктов. Я направил запрос на изменение версии 1.1 СММ с предложением ввести описание практик для этих областей.

Пункт 4.16: контроль записей о проверке качества.

В соответствие с ISO 9001 организации обязаны вести и сохранять записи о проверке качества. В СММ практики, отвечающие за ведение таких записей, разнесены по нескольким группам в пределах общего признака Выполняемые действия. К данном вопросу имеет отношение составление отчетов о проблемах, описанное на уровне 2, а также тестирование и экспертная оценка программ, в особенности сбор и анализ данных о дефектах (уровень 3).

Пункт 4.17: внутренние проверки качества.

ISO 9001 требует от организаций планирования и выполнения таких проверок. Результаты должны направляться руководству, а дефекты — быть найдены и исправлены. СММ описывает процесс аудита на втором уровне. Практики аудита, призванного удостовериться в соответствии программного продукта имеющимся стандартам, определены в общем признаке Проверка внедрения.

Пункт 4.18: обучение.

Согласно положениям ISO 9001 организации должны выявить потребности в обучении, провести обучение (исходя из списка задач, требующих для выполнения квалифицированного персонала) и выполнить ведение соответствующих записей. СММ касается проблемы выявления потребностей в обучении в разделе, посвященном практикам обучения и ориентации (общий признак Возможности выполнения). При этом общая инфраструктура обучения, включая ведение записей об обучении, описывается на уровне 3.

Пункт 4.19: обслуживание.

ISO 9001 требует от организаций выполнения сервисного обслуживания в тех случаях, когда оно предусмотрено требованиями. В ISO 9000-3 это получает название обслуживания (5.10). Хотя CMM предназначено для применения как при разработке, так и при обслуживании ПО, практики в CMM напрямую не затрагивают специфику сферы обслуживания. Упоминания о нем разбросаны по всему документу, однако, организации должны сами выбирать правильный контекст. Таким образом, обслуживание в СММ не рассматривается в качестве отдельного процесса. В запросах на изменение версии 1.0 СММ была выражена озабоченность вопросом использования стандарта в проектах, связанных с обслуживанием. В ответ SEI изменила некоторые относящиеся к вопросу формулировки в версии 1.1 в сторону большего подчеркивания соотнесенности со сферой обслуживания. SEI предполагает, что эта проблема подлежит дальнейшему обсуждению, поскольку ее решение может помочь адаптировать CMM к различным средам (таким, как обслуживание) и собирается учесть ее в последующих редакциях стандарта.

Пункт 4.20: статистические техники.

Согласно ISO 9001 организации должны выбрать адекватные статистические техники и применять их для проверки соответствия возможностей процесса и характеристик продуктов. Что до ISO 9000-3, то в нем просто указывается, что эти техники следует считать измерением (6.4). В CMM измерения характеристик продукта обычно включены в различные практики, входящие в состав общего признака Выполняемые действия. Измерение процесса описывается как часть общего признака Измерения и анализ. На третьем уроне описывается создание базы данных процессов масштаба предприятия для сбора информации о процессах и продуктах. Кажется вероятным, что большинство аудиторов удовольствуются в данном вопросе данными уровня проекта (относящимися ко второму уровню). Однако, по крайней мере, несколько аудиторов обратятся к базе исторических данных уровня организации и простым статистическим таблицам. Если из этого параграфа выводить контроль над статистическими процессами, организации будет достаточно развернуть систему контроля на уровне 4. Однако стоит процитировать ISO 9000-3: "на сегодняшний день не существует общепринятых мер по обеспечению качества ПО". Некоторые аудиторы прибегают к использованию таких статистических инструментов, как, например, анализ Парето. Другим достаточно правильно собранных и использованных результатов измерений. В общем, единственное, что можно заявить с полной уверенностью, это то, что аудиторы склонны толковать изучаемый вопрос очень по-разному.

Выводы.

Существование сильной корреляции между ISO 9001 и CMM очевидно, хотя некоторые проблемы, упомянутые в ISO 9001, не затрагиваются в CMM и наоборот. Уровень детальности изложения значительно варьируется: раздел 4 ISO 9001 занимает около пяти страниц, разделы 5, 6 и 7 в ISO 9000-3 умещаются в 11 страниц, в то время как CMM опубликован более чем на 500 страницах. Чтобы установить точную степень соответствия, следует провести дополнительное исследование с учетом разных уровней абстракции. Как показано в таблице 1, следующие параграфы ISO 9001 слабо соотносятся с группами ключевых процессов СММ и не получают должного истолкования: контроль над продуктами, поставляемыми заказчику (4.7), а также погрузка/разгрузка, хранение, упаковка, предохранение и доставка (4.15). Параграф ISO 9001, посвященный обслуживанию (4.19), в СММ предстает в ином свете: техническое обслуживание представлено как распределенный процесс. Параграфы ISO 9001 с сомнительной степенью соответствия CMM таковы: коррекционные и профилактические меры (4.14) и статистические техники (4.20). Как я уже упоминал, наиболее существенное различие между двумя этими документами, состоит в том, что CMM явным образом подчеркивает необходимость постоянной оптимизации, в то время как ISO 9001 описывает лишь критерии минимальной приемлемости качественной системы. Еще одно различие заключается в том, что в CMM рассматривается только ПО, тогда как сфера действия ISO 9001 значительно шире (аппаратное и программное обеспечение, обрабатываемые материалы и обслуживание). Оба документа сходятся в проведении принципа: "Обещай только то, что можешь выполнить и выполняй обещанное". Основной предпосылкой ISO 9001 является то, что организации должны документировать каждый сколько-нибудь важный процесс и проверять качество поставляемых продуктов путем принятия мер по контролю над качеством. ISO 9001 требует документации, содержащей инструкции относительно того, что следует предпринять и каким образом. В СММ также делается акцент на документируемых процессах, выполняемых в качестве таковых. Такие фразы как "проводится в соответствие с документированной процедурой" и "следуя записанной организационной политике" хорошо характеризуют группы ключевых процессов в CMM.

Переходя к рассмотрению отдельных вопросов, необходимо отметить, что некоторые параграфы ISO 9001 могут быть легко увязаны с эквивалентными практиками СММ. Другие соотношения относятся друг к другу как множество к множеству, частично "перекрывая" друг друга, поскольку документы имеют разную структуру. Так, например, параграф, посвященный обучению (4.18) в ISO 9001 находит отражение как в группе ключевых процессов Программа обучения, так и в практиках обучения и ориентации, относящихся ко всем группам.

Проблемы соответствия

На первый взгляд организационная единица, получившая сертификат ISO 9001, должна находиться на третьем или четвертом уровне СММ. В действительности, сертификат выдается порой даже организациям первого уровня. Одной из причин такого положения дел является то, что положения ISO 9001 обладают высоким уровнем абстракции, что позволяет аудиторам истолковывать их по-разному. Если аудитор, сертифицирующий организацию, прошел обучение по программе TickIt, обзорный анализ разработки в ISO 9001 будет прямо соответствовать экспертной оценке программ в CMM, относящейся к уровню 3. Однако не все аудиторы разбираются в создании программ. Достоинство руководства подобного TickIt состоит в том, что она помогает аудиторам понять, каким образом ISO 9001 можно применить к ПО. Еще одной причиной возникновения указанной выше ситуации является то, что аудитору может не потребоваться убеждаться в идеальности решения проблемы, описанной в соответствующем параграфе ISO 9001. На рисунке 1 показан профиль групп ключевых процессов для организации с сертификатом ISO 9001, которая не внедряет никаких управленческих/инженерных практик за исключением тех, которые ISO 9001 требует от CMM. Длина полоски указывает на процент практик в рамках группы ключевых процессов, которые упоминаются либо в ISO 9001, либо в ISO 9000-3. На этом рисунке изображены группы, напрямую соотносимые с параграфами данных документов (темное затенение), группы, связь которых зависит от субъективной интерпретации (светлое затенение), а также группы, к которым указанные параграфы не имеют прямого отношения (белый).

Рис. 1. Профиль групп ключевых процессов для организации с сертификатом ISO 9001.
Темно-серым цветом выделены практики, прямо упомянутые в ISO 9001 или ISO 9000-3; светло-серым цветом — практики, соответствие которых положениям данных стандартов зависит от интерпретации ISO 9001; практики, которые напрямую не затрагиваются в этих стандартах, оставлены без затенения.

Анализ рисунка 1 позволяет отметить следующее:

• Каждая группа ключевых процессов на втором уровне сильно связана с ISO 9001.

• Каждая группа ключевых процессов, по меньшей мере, слабо соотносится с положениями ISO 9001 при определенном толковании. На основании этого профиля организация, отнесенная к первому уровню, может получить сертификат соответствия ISO 9001.

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

Хотя СММ применяет порой неадекватный подход к некоторым специфическим проблемам, как правило, он охватывает тот же круг вопросов, что и ISO 9001. Противоположное утверждение дальше от истины. ISO 9001 описывает лишь минимальный набор критериев признания системы управления качеством адекватной. Для данного документа нехарактерно рассмотрение всего континуума оптимизации процессов, хотя последующие версии стандарта могут оказаться иными. Различия между стандартами не позволяют напрямую сопоставить их, однако, имеющееся сходство обеспечивает высокую степень их пересечения.

Теперь попытаемся ответить на три вопроса, упомянутых в начале статьи:

• Организация с сертификатом ISO 9001, необязательно должна удовлетворять требованиям ко всем группам ключевых процессов второго уровня СММ, что не мешает ей, однако, достигать большинства целей второго уровня и многих целей третьего. Так как ISO 9001 не отражает все практики CMM, то организация первого уровня может вполне получить сертификат ISO 9001.

• Организация второго (или третьего) уровня, скорее всего, будет признана соответствующей ISO 9001, и все же даже организации третьего уровня необходимо будет убедиться в адекватном выполнении процесса, описанного в параграфе 4.15 ISO 9001 (доставка и установка). Кроме того, руководству такой организации стоит рассмотреть вопрос применения включенных программных продуктов (параграф 6.8 ISO 9000-3). При таких условиях получение сертификата не должно представлять затруднений для организации второго или более высокого уровня.

• Что касается вопроса о том, должна ли оптимизация процессов создания ПО, основываться на CMM или на ISO 9001,то проще всего будет ответить так: организации следует сочетать оба стандарта, учитывая значительную степень их совпадения. Требования рынка диктуют необходимость получения сертификата ISO 9001, в то время как соответствие положениям CMM поможет организации подготовиться к аудиту на основе ISO 9001. С другой стороны, организации первого уровня, несомненно, выиграют от рассмотрения положений ISO 9001. Хотя каждый из изучаемых документов можно применять и по отдельности для структурирования программы оптимизации процессов, СММ представляется более подходящим вариантом по причине более детализированного подхода и специализации на разработке ПО, хотя мое мнение может показаться субъективным. В любом случае организации должны уделять внимание оптимизации процессов для того, чтобы получить преимущество в конкурентной борьбе, а не для того, чтобы "набрать очки" в любом смысле: будь то получение сертификата или достижение определенного уровня зрелости. SEI утверждает, что СММ охватывает вопросы постоянной оптимизации процессов, но даже в этом случае существует необходимость обращения к более широкому деловому контексту в духе стремления к TQM (Всеобъемлющему управлению качеством).

Марк C. Паулк, SEI

Главная / Статьи / Менеджмент (1196) /