Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Управління ІТ-проектами / Література / Липаев В.В. Модели зрелости программной инженерии

.pdf
Скачиваний:
47
Добавлен:
23.02.2016
Размер:
423.63 Кб
Скачать

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

И Н Ф О Р М А Ц И О Н Н Ы Й Б Ю Л Л Е

Т Е Н Ь

№ 6 (157)/2006

 

 

 

 

 

 

 

 

Модели зрелости программной инженерии – СMMI Содержание и применение

УП РА В Л Е Н И Е

КАЧ Е С Т В О М

Модели зрелости программной инженерии – СMMI Содержание и применение

Владимир Васильевич Липаев,

профессор, доктор технических наук

СОДЕРЖАНИЕ

 

Введение ......................................................

2

Структура и содержание модели

 

зрелости – CMMI = 1.1 ................................

4

Организация сертификации

 

программных продуктов ..........................

9

Документирование процессов и

 

результатов сертификации

 

программных продуктов ........................

13

Базовые документы системы качества

 

предприятия и жизненного цикла

 

программного средства ......................

14

Исходные документы, отражающие

 

особенности жизненного цикла

 

конкретного программного средства ....14

Результирующие документы испытаний –

 

сертификации системы качества

 

предприятия и/или программного

 

продукта ..............................................

15

Литература ................................................

15

Введение

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

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

и моделями зрелости SEI (Института програм

мной инженерии США). Первые достаточно полно представлены в [1,4], а вторые – в [2,3]. Именно моделям зрелости посвящено основное содержание статьи.

Для обеспечения конкурентоспособности в мире сложных программных продуктов и воз можности их успешного экспорта они должны быть разработаны и сертифицированы в соот ветствии с требованиями профилей междуна родных стандартов на базе ISO 9000:2000 или

моделей зрелости – CMMI:2003 (Capability

Maturity Model Integration – Интегрированная модель оценивания зрелости программной ин женерии). Эти два направления методологичес

Модели зрелости программной инженерии – СMMI

ки очень близки и частично пересекаются по

вые задачи и генераторы для их формирования,

средством взаимных ссылок.

а также высокая квалификация и авторитет ис

Совершенствование технико экономиче

пытателей. Применение на предприятиях раз

ских показателей и качества программных про

работчиках программных продуктов, сертифи

дуктов, а также предотвращение ошибок и

цированных систем качества обеспечения ЖЦ

дефектов обеспечивается применением совре

ПС на базе требований ISO 9000:2000 или

менных технологий программной инженерии и

CMMI:2003, гарантирует высокое, устойчивое

систем автоматизированного проектирования.

управление качеством процессов и продуктов

Это высокопроизводительные, ресурсосберега

их жизненного цикла, а также позволяет во

ющие технологии создания комплексов про

многих случаях облегчать сертификацию ко

грамм высокого качества, надежности и безо

нечного программного продукта. Поэтому за

пасности, имеющие своей целью сокращение

казчики сложных программных проектов стре

общих затрат ресурсов на проектирование, реа

мятся выбирать подрядчиков исполнителей,

лизацию и сопровождение программных

имеющих сертификаты, удостоверяющие при

средств (ПС). Для этого, прежде всего, необхо

менение ими систем гарантирования качества

димо применять методы и средства анализа и

на основе адаптированных профилей междуна

проектирования, обеспечивающие конкретиза

родных стандартов или моделей зрелости.

цию и максимально точное представление це

Пробелы в обучении методам програм

лей, назначения и функций с начала жизненно

мной инженерии оставляют широкое поле для

го цикла (ЖЦ) ПС и предотвращающие распро

произвола специалистов при оценивании каче

странение возможных системных дефектов на

ства их труда, а также для появления многочис

последующие этапы разработки. Такие техноло

ленных дефектов и ошибок в проектах про

гии программной инженерии позволяют исклю

граммных средств. Возрастание сложности и от

чать или значительно снижать уровень систем

ветственности современных задач, решаемых

ных, алгоритмических и программных ошибок в

программами, а также возможного ущерба от

программных продуктах, передаваемых для экс

недостаточного качества их результатов, значи

плуатации. Кроме того, они эффективны при

тельно повысило актуальность освоения мето

модификации и сопровождении ПС, а также

дов полного, стандартизированного описания

при изменениях внешней среды.

требований к характеристикам качества и спо

Для удостоверения качества, надежности

собов измерения их реальных, достигнутых зна

и безопасности применения сложных, критиче

чений на различных этапах жизненного цикла

ских систем, используемые в них программные

ПС. Резко возросла необходимость знания спе

продукты, подвергаются сертификации аттесто

циалистами понятий, определений и способов

ванными, проблемно ориентированными испы

оценивания характеристик качества програм

тательными центрами или лабораториями. Та

мных продуктов.

кие испытания необходимо проводить, когда

Быстрое увеличение и усложнение ком

программы управляют сложными, критически

плексов программ приводит к созданию круп

ми процессами или обрабатывают столь важ

ных программистских коллективов с професси

ную информацию, что дефекты в них или недо

ональным разделением труда, в которых необ

статочное качество могут нанести значитель

ходимо регламентирование координированной

ный ущерб. Сертификационные испытания

деятельности групп специалистов над единым

должны устанавливать соответствие комплек

проектом. Обещания разработчиков в контрак

сов программ требованиям документации и до

тах создать высококачественные программы в

пускать их к эксплуатации в пределах измене

согласованные сроки во многих случаях не вы

ния параметров внешней среды, исследованных

полняются. Часто это происходит в силу того,

при проведенных проверках. Эти виды испыта

что заказчик и исполнитель оценивают уровень

ний характеризуются наибольшей строгостью и

качества по разным критериям, и согласованно

глубиной проверок, должны проводиться специ

сти по этому вопросу у них нет, а подход к оцен

алистами, независимыми от разработчиков и от

ке качества программ недостаточно формализо

заказчиков (пользователей).

ван. Кроме того, иногда не хватает умения пра

Основой сертификации должны быть де

вильно оценить ресурсы, необходимые для

тальные и эффективные программы и методи

достижения высокого качества программ. В ре

ки испытаний комплексов программ на соот

зультате качество программной продукции за

ветствие стандартизированным требованиям

частую остается низким, неподдающимся досто

заказчиков, специально разработанные тесто

верной оценке и не конкурентоспособным на

 

 

 

3

 

 

 

В.В. Липаев

 

 

международном рынке. Поэтому важнейшей

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

проблемой развития и применения многих со

го оценивания и совершенствования зрелости

временных систем является обучение и воспи

предприятия, а также для организации ЖЦ ком

тание специалистов в области программной ин

плексов программ в целом. Модели CMMI пред

женерии, использованию международных стан

ставляют помощь специалистам при органи

дартов, способствующих высокому качеству ПС

зации и совершенствовании их продуктов, а

и достоверному его оцениванию с основной

также по упорядочению и обслуживанию про

целью – сделать процессы проектов управляе

цессов разработки и сопровождения ПС. Кон

мыми, а результаты – предсказуемыми. Необ

цепция этих моделей охватывает управление и

ходимо умение формализовать требования и до

оценивание зрелости сложных систем, инжене

стигать конкретные значения характеристик

рии программных средств, а также процессов

качества функционирования и применения

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

сложных комплексов программ с учетом тех ре

дуктов и совершенствования их разработки.

сурсов, которые доступны для обеспечения и со

Компоненты непрерывной и поэтапной моделей

вершенствования этого качества.

в значительной степени подобны, могут выби

 

Модель зрелости CMMI – 1.1, уточняет и

раться и применяться в разном составе и после

совершенствует предшествовавшие модели

довательности использования в зависимости от

CMM (см. [3]), а также частично учитывает ос

свойств и характеристик конкретных проектов.

новные требования существующих междуна

Варианты описания моделей построены

родных стандартов в области менеджмента про

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

граммных средств. Значительное внимание в

делы:

CMMI уделяется процессам разработки и учету

предисловие;

итераций при изменении требований заказчи

1 раздел – введение;

ков, их прослеживанию к функциям, компонен

2 раздел – модель компонентов;

там, тестам и документам проекта. В последнее

3 раздел – терминология;

время появилась информация о модернизации

4 раздел – содержание уровней и главные

институтом SEI версии 2003 го года CMMI – 1.1

компоненты каждого варианта модели (раз

на основе накопленного опыта и отзывов пред

работка целей и процедур);

приятий. Предполагается выпустить в 2006 году

5 раздел – структура взаимодействия про

новую, существенно модернизированную, вер

цессов; аннотированы четыре категории

сию модели CMMI – 1.2, после чего постепенно

процессов раздела 7, их общий обзор и схе

должно прекратиться применение версии 1.1.

мы взаимодействия CMMI процессов:

До конца 2007 года должен проводиться переход

•менеджмент процессов;

пользователей на версию CMMI – 1.2, а в даль

•менеджмент – управление проектом;

нейшем она станет обязательной для формали

•инжиниринг (технология);

зованной оценки качества (сертификации) тех

•поддержка;

нологии предприятий в области программной

6 раздел – использование модели CMMI

инженерии. При этом срок действия сертифи

краткие рекомендации для пользователей

ката будет ограничен тремя годами. К этим из

по применению модели и обучению; отме

менениям следует готовиться заказчикам и раз

чается совместимость и соответствие про

работчикам крупных ПС до официальной пуб

цессов модели, с регламентированными

ликации институтом SEI версии 1.2.

процессами предыдущей модели СММ в ча

 

 

 

сти 2 и 3 стандарта ISO 15504.

 

 

 

7 раздел – последний, самый большой в каж

 

 

 

дом стандарте, он занимает около 500 стра

 

 

 

ниц из полного объема документа, который

 

 

 

составляет свыше 700 страниц. В этом раз

Структура и содержание

деле представлены подробные рекоменда

ции для реализации каждого из перечислен

модели зрелости CMMI – 1.1

ных в нем процессов, которые учитывают

особенности конкретной модели.

Два варианта модели CMMI – 1.1 созданы для

Первый вариант (непрерывной) модели

обеспечения непрерывного оценивания ком

отражает документ: Capability Maturity Model

плекса процессов в определенной области со

Integration (CMMI) for Systems Engineering/

 

 

 

 

4

 

 

 

Модели зрелости программной инженерии – СMMI

Software Engineering/Integrated Prod uct and

D – описания требований и предложений для

Process Development, Version 1.1, Continuous

формирования компонентов модели по

Representation (CMMI SE/SW/IPPD, V1.1,

уровням зрелости;

Continuous). Интегрированная модель оценива

Е – список участников разработки CMMI

ния зрелости инженерии систем/программной

проекта.

инженерии/интегрированных продуктов и про

В этой модели внимание акцентировано

цессов разработки – непрерывное представле

на организационных процессах, на планирова

ние. В этой модели седьмой раздел составляют

нии, управлении и контроле процессов реализа

процессы:

ции проектов программных средств, на разра

менеджмент процессов:

ботке и управлении требованиями к програм

•содержание организационных процессов;

мным продуктам. Ниже представлены примеры

•определение организационных процес

детализации в CMMI некоторых из них [2].

сов;

Планирование проекта в этой также как и

•организация обучения;

во второй модели включает:

•организация преобразования (изменений)

• оценку возможного размера (масштаба)

процессов;

программного продукта;

•организация инноваций и расширений;

• оценку сложности функций и характерис

управление проектом:

тик проекта ПС;

•планирование проекта;

• определение модели и этапов жизненного

•мониторинг и контроль процессов проекта;

цикла комплекса программ;

•управление соглашениями с поставщиками;

• технико экономическое обоснование про

•интегрированное управление процессами

екта – определение стоимости, трудоем

и продуктами проекта;

кости и длительности ЖЦ ПС;

•управление рисками;

• разработка поэтапного графика работ и

•интеграция команды разработчиков;

бюджета проекта;

•интегрированное управление поставщи

• анализ, идентификация и оценка проект

ками;

ных рисков;

•количественное управление проектом;

• планирование и управление документиро

инженерия (технология):

ванием процессов и продуктов в ЖЦ про

•управление требованиями;

екта ПС;

•разработка требований;

• планирование и распределение техничес

•технические решения;

ких и людских ресурсов по этапам ЖЦ ПС;

•интеграция продукта;

• планирование обеспечения знаний и квали

•верификация;

фикации коллектива специалистов для реа

•валидация (аттестация, утверждение);

лизации проекта;

поддержка:

• обобщение и анализ совокупности планов

•управление конфигурацией;

проекта ПС;

•обеспечение качества процессов и про

• согласование работ и ресурсов по этапам

дуктов;

ЖЦ разработчиком с заказчиком проекта

•измерение и анализ процессов и продук

ПС;

тов;

• документирование плана работ и утвержде

•анализ и принятие решений на измене

ние его менеджером разработчиков проекта.

ния;

 

•организация окружения для интеграции;

Процессы разработки требований к прог

•анализ причин и разрешение проблем

раммному продукту аналогичны процессам в

(устранение дефектов).

обеих моделях и включают:

 

• выявление реальных потребностей заказчи

В пяти приложениях приводятся:

ка и пользователей к функциям и характе

А – состав использованных литературных ис

ристикам программного продукта;

точников и документов, в котором, однако,

• разработку и согласование между заказчи

не упоминаются стандарты ISO;

ком и разработчиком исходных, базовых

В – сокращения;

требований к функциям программного про

С – глоссарий на основе терминологии ISO,

дукта;

применяемой только в четырех стандартах

• определение доступных ресурсов и ограни

ISO 9000, ISO 12207, ISO 15504:1 9, ISO 15288;

чений проекта комплекса программ;

 

 

 

5

 

 

 

В.В. Липаев

 

 

• декомпозицию базовых исходных требова

второй уровень – формализует базовое

ний к функциям ПС в набор требований к

управление проектами:

компонентам и тестам комплекса программ;

•управление требованиями;

• формализацию требований к интерфейсам

•планирование проекта;

между компонентами, с операционной и

•мониторинг и контроль проекта;

внешней средой;

•управление соглашениями с поставщиками;

• разработку концепции программного про

•измерение и анализ процессов и продук

дукта и сценариев его использования;

тов;

• разработку требований к обобщенным ха

•обеспечение качества процессов и про

рактеристикам функциональной пригод

дуктов;

ности и использованию функций програм

•управление конфигурацией;

много продукта по назначению.

третий уровень – содержит стандартиза

 

 

 

цию основных процессов:

 

Управление требованиями в обеих моде

•разработка требований;

лях включает:

•технические решения;

• достижение однозначного понимания тре

•интеграция продукта;

бований к проекту ПС заказчиком и разра

•верификация;

ботчиками;

•валидация (аттестация);

• получение заказчиком от разработчиков

•содержание организационных процессов;

обязательств выполнить все его требования

•определение организационных процес

к программному продукту;

сов;

• согласованное между заказчиком и разра

•организация обучения;

ботчиком управление изменениями требо

•интегрированное управление процессами

ваний к проекту ПС;

и продуктами проекта;

• обеспечение прослеживания корректности

•управление рисками;

изменений от общих требований к проекту

•интеграция команды разработчиков;

ПС до требований к компонентам и част

•интегрированное управление поставщи

ным процессам;

ками;

• выявление и идентификация несоответ

•анализ и разрешение проблем (устране

ствий между процессами разработки проек

ние дефектов);

та и требованиями заказчика.

•организация окружения для интеграции;

 

 

 

четвертый уровень – определяет количест

 

Второй вариант представляет документ:

венное управление:

Capability Maturity Model Integration (CMMI) for

•организация представления качества про

Systems Engineering/Software Engineering/In

цессов;

tegrated Product and Process Development, Version

•количественное управление всем проек

1.1, Staged Representation (CMMI SE/SW/IPPD,

том и ресурсами;

V1.1, Staged). Интегрированная модель оценива

пятый уровень – оптимизационный, не

ния зрелости инженерии сложных систем/про

прерывное совершенствование:

граммной инженерии/интегрированных про

•организация, инновации, количественное

дуктов и процессов разработки – поэтапное

управление процессами и обеспечением

представление. Модель базируется на сохране

ресурсами;

нии концепции пяти уровней зрелости CMM

•анализ причин дефектов, совершенство

[1, 3]. Состав процессов практически повторяет

вание качества и управления процессами

приведенный выше для первого варианта моде

и продуктами.

ли, но в несколько иной последовательности и с

 

относительно небольшими дополнениями.

Приложения во втором варианте модели

 

Первый уровень отличается значительной

подобны по составу приведенным выше прило

неопределенностью состава и содержания про

жениям для первой модели. Рекомендуется на

цессов в различных относительно простых про

каждом более высоком уровне зрелости при

ектах, поэтому он в документе не комментиру

менять все процессы предыдущих нижних уров

ется. Поэтому при уточнении и детализации со

ней. В обоих вариантах модели каждый, выделен

держания процессов в поэтапном варианте

ный выше, базовый процесс комментируется по

CMMI рекомендуется ограничиваться четырьмя

дробными рекомендациями для его практической

основными уровнями:

реализации, которые содержат унифицирован

 

 

 

 

6

 

 

 

Модели зрелости программной инженерии – СMMI

ные по структуре описания объемом около 20 –

• не все процессы предусмотрены в составе

30 страниц:

процессов моделей CMMI – 1.1, которые

• общие цели процесса, которые должны

развиваются и детально комментируются

быть достигнуты;

для их реализации в стандартах ISO

• вводные замечания и общее описание

9004:2000 и ISO 90003:2004, а также в профи

функций процесса;

ле стандартов ISO [1];

• специфические цели процесса;

• не отражены особенности системной инже

• менеджмент процесса;

нерии и международные стандарты, регла

• разработка требований к процессу;

ментирующие процессы жизненного цикла

• взаимодействие и интерфейсы с другими

сложных систем ISO 15288:2002 и ISO

процессами;

19760:2003;

• практические цели – требуемые результа

• при анализе процессов обеспечения качест

ты действий процесса;

ва используется ряд традиционных характе

• планирование действий в определенном

ристик систем и программных продуктов,

процессе;

которые применяются в сложных проектах,

• анализ и валидация (утверждение) резуль

однако не описаны и не комментируются

татов реализации процесса;

базовые международные стандарты, систе

• мониторинг и контроль выполнения про

матизирующие и регламентирующие каче

цесса.

ство программных средств – ISO 9126:1 4,

 

ISO 14598:1 6, ISO 15939;

Эти рекомендации по объему, содержа

• отсутствуют описания характеристик и

нию и полноте описаний базовых процессов по

конкретных процессов обеспечения инфор

добны ряду стандартов профиля ЖЦ ПС, пред

мационной и функциональной безопаснос

ставленного в [1]. Упорядочение и оценка пол

ти программных продуктов и ссылки на

ноты используемых процессов в соответствии с

многочисленные стандарты в этой области;

уровнями зрелости, позволяет устанавливать

• не отражены регламентированные интер

производственный потенциал предприятий –

фейсы открытых систем на взаимодействие

разработчиков программных продуктов по про

программных компонентов, а также с опе

гнозируемому качеству процессов и результа

рационной и внешней средой, в соответ

тов их деятельности и готовности к сертифика

ствии со стандартами ISO 9945:1 4;

ции на соответствие определенному уровню

• документирование процессов и продуктов

зрелости модели CMMI – 1.1.

ЖЦ ПС комментируется только по мере их

Особое внимание в моделях CMMI уделя

реализации, и не представлены обобщенные

ется процессам менеджмента проекта ПС. Эти

требования к технологической и эксплуа

требования и процессы моделей практически

тационной документации на программный

соответствуют регламентированным и детали

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

зированным рекомендациям в стандартах ISO

ISO 9294, ISO 15910, ISO 18019.

9001:2000 и основных компонентах профиля

 

стандартов жизненного цикла сложных ПС [1,

Для определения представленных выше

4]. Требованиям к процессам в функциональных

уровней зрелости процессов обеспечения

разделах 4–8 стандартов ISO 9001, ISO 9004, ISO

жизненного цикла ПС разработан и первона

90003 может быть сопоставлен адекватный по

чально утвержден в 1998 году обширный тех

содержанию ряд разделов в модели CMMI (на

нический отчет ISO 15504, состоящий из де

Рис.1 зона перекрытия содержания). Общность

вяти частей и множества приложений. В нем

процессов и требований состоит в подобии: со

изложены модель зрелости CMM и восемь ба

става, терминологии, структуры, перечня реко

зовых принципов программной инженерии на

мендуемых процессов управления, планирова

основе стандарта ISO 9000:2000. Затем в ISO

ния, учета доступных ресурсов, реализации про

этот документ претерпел коренную переработ

цессов программной инженерии, оценивания и

ку, сокращение, упрощение структуры и со

организации специалистов.

держания, при полном сохранении целей и

С точки зрения поддержки и регламентиро

концепции, и утвержден как стандарт в соста

вания полного жизненного цикла крупных проек

ве пяти частей.

тов программных средств к недостаткам моделей

Стандарт ISO 15504:1 5:2003 2006 регла

CMMI относительно профиля существующих

ментирует оценку и аттестацию зрелости про

стандартов ISO можно отнести следующие:

цессов создания, сопровождения и совершен

 

 

 

7

В.В. Липаев

CMMI:2003 – модели зрелости

Менеджмент,

организация,

планирование,

проектирование программных средств

ISO 9000:2000 = стандарты менеджмента

Стандарты жизненного цикла сложных систем и программных средств

ISO 15288 и ISO 12207

Стандарты качества программных средств – ISO 9126:1=4, ISO 14598:1=6, ISO 15939

Стандарты обеспечения информационной и функциональной безопасности программных продуктов

Стандарты интерфейсов Открытых систем – ISO 9945:1=4

Стандарты документирования процессов и продуктов ЖЦ ПС – ISO 9294, ISO 15910, ISO 18019

ISO 15504:2003 – аттестация зрелости

Профиль

стандартов

жизненного

цикла

программных

средств

Рис. 1. Общность процессов и требований стандартов и моделей зрелости

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

рам ПС и систем. Применение стандарта на

полняемых предприятиями:

правлено на выработку предприятиями и специ

• для установления состояния собственных

алистами культуры постоянного совершенство

технологических процессов и их совершен

вания зрелости технологий обеспечения ЖЦ

ствования;

ПС, отвечающих бизнес целям проектов и опти

• для определения пригодности собственных

мизации использования доступных ресурсов.

процессов для выполнения определенных

Аттестация зрелости процессов предприятий

требований или классов требований заказ

обеспечивает возможность их сопоставления и

чиков;

выбора, предпочтительных для определенных

• с целью его пригодности для выполнения

проектов:

определенных договоров с заказчиками ПС

• для заказчиков, покупателей, пользователей

и систем.

программных продуктов и систем: способ

 

ность определять текущую и потенциаль

Стандарт способствует: самоаттестации

ную зрелость процессов жизненного цикла

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

у поставщика;

го управления аттестуемыми процессами, опре

• для поставщиков и разработчиков: способ

делению профиля рейтингов процессов, а также

ность определять текущую и потенциаль

подходит к любым сферам применения и разме

ную зрелость собственных процессов жиз

 

 

8

 

Модели зрелости программной инженерии – СMMI

ненного цикла ПС и систем, области и прио

шаги по определению уровня зрелости; сравне

ритеты усовершенствования процессов;

ние результатов анализа аттестации с требова

• для аттестаторов зрелости: основу для про

ниями.

ведения и совершенствования процессов

Часть 5 – Образец модели процессов ат

аттестации.

тестации на соответствие требованиям,

 

представленным в части 2. Обширный доку

Аттестация в стандарте рассматривается в

мент (162 стр.) содержит примеры практическо

двух аспектах: для усовершенствования про

го применения предыдущих частей стандарта

цессов ЖЦ ПС и систем конкретного предприя

для организации, оценивания и совершенство

тия и для определения соответствия деклариро

вания аттестации зрелости процессов жизнен

ванной зрелости процессов обеспечения проек

ного цикла для различных областей использова

та или предприятия реальным используемым

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

процессам. Это отражено в следующих пяти

ятий.

частях стандарта ISO 15504:1 5:2003 2006.

При практической реализации проектов

Часть 1 – Концепция и словарь. Содержит

и обеспечении жизненного цикла сложных ПС

общую информацию о процессах аттестации

разработчикам и поставщикам иногда трудно

зрелости ПС и систем и рекомендации по ис

определить и выделить для применения преиму

пользованию частей стандарта. Изложены об

щества моделей CMMI. В зависимости от тради

щие требования к аттестации, терминология,

ций предприятия и особенностей крупного про

структура, определена область применения ос

екта ПС зачастую целесообразно использовать

тальных частей стандарта.

как основной полный профиль стандартов ISO,

Часть 2 – Выполнение (производство)

а для оценивания заказчиками уровня зрелости

аттестации. Включает детальные требования к

менеджмента, организационного и технологи

проведению процессов аттестации как основы

ческого обеспечения проектов ПС применять

для совершенствования и определения уровня

конкретные рекомендации CMMI. Эти реко

зрелости технологических процессов обеспече

мендации могут эффективно использоваться

ния ЖЦ ПС и систем. Документ определяет

при сертификации качества процессов на

процессы выполнения аттестации, модели реко

предприятиях, обеспечивающих ЖЦ ПС, как

мендуемых процессов аттестации и верифика

альтернатива или наряду с сертификацией по

ции процессов, с тем чтобы они были объектив

комплексу стандартов менеджмента ISO 9000, в

ными, содержательными и репрезентативными.

зависимости от особенностей проекта и требо

Часть 3 – Руководство по производству

ваний заявителя на сертификацию программно

аттестации. Содержит обзор технологии вы

го продукта или технологии обеспечения его

полнения процессов аттестации зрелости и

жизненного цикла.

интерпретации реализации требований. В нем

 

отражено: исполнение аттестации; измеритель

 

ные средства для определения процессов зре

 

лости; выбор и применение средств аттестации;

 

оценка компетентности аттестаторов; верифи

Организация сертификации

кация соответствия аттестации декларирован

ным требованиям. Средства аттестации могут

программных продуктов

использоваться предприятиями при планирова

нии, менеджменте, мониторинге, контроле и

 

усовершенствовании программных продуктов и

Сертификация состоит из ряда организацион

систем, при их приобретении, разработке, при

ных процессов, составляющих систему серти

менении и сопровождении.

фикации, эти процессы поддерживаются регла

Часть 4 – Руководство пользователей для

ментированными процедурами и документами и

процессов усовершенствования и определения

должны выполняться квалифицированными, ат

зрелости процессов по этим двум аспектам. Ре

тестованными экспертами – инспекторами.

комендуется ряд шагов, которые включают:

Для сертификации предприятия разработчика

применение результатов процессов аттестации;

и результатов его деятельности – программных

постановка целей аттестации зрелости; опреде

продуктов, моделями CMMI или профилями

ление исходных данных для аттестации; оценка

стандартов ISO [1,4] рекомендуется определен

возможного снижения результирующих рис

ная дисциплина, которая должна быть адаптиро

ков; шаги по усовершенствованию процессов;

вана к конкретным характеристикам объектов и

 

 

 

9

В.В. Липаев

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

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

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

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

Руководство по качеству содержит изло жение принципов, описание методов и про цедур, связанных с выполнением основных функций и задач органа по сертификации или лаборатории, обеспечивающих качество прово димых испытаний и доверие к результатам оце нок, испытаний и экспертиз. Руководство по ка честву, как правило, включает разделы [5]:

политика в области обеспечения качества проведения испытаний и экспертиз;

организации сертификации продукции по заяв ке. Эта работа включает в себя:

выбор схемы сертификации с учетом специ фики продукции (объем, технология, требо вания нормативных документов и др.) и предложений разработчика;

определение количества и порядка отбора образцов и компонентов, подлежащих ис пытаниям, если это не указано в стандартах;

выбор и определение аккредитованной ис пытательной лаборатории, которая должна проводить испытания;

подготовку проекта договора на выполне ние работ.

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

ществляется подбор и изучение действующих нормативных документов на продукцию, заяв ленную к сертификации, методов ее испытаний и оценки результатов.

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

оснащение центра актуальными методоло новленным требованиям. На основе анализа

гическими материалами и программно представленных с заявкой документально под

инструментальными средствами испытаний;

твержденных доказательств соответствия его

• формализация требований к объектам ис

продукции установленным требованиям, орган

пытаний;

по сертификации может принять решение о со

• политика в области технической оснащен

кращении объема испытаний или о выдаче сер

ности центра и повышения квалификации

тификата.

персонала;

Испытания проводятся испытательными

• архивация и контроль сохранности доку

лабораториями, аккредитованными на проведе

ментации результатов сертификации.

ние только тех испытаний, которые предусмот

 

рены в их нормативных, аккредитационных

Заявитель для оценивания продукции или

документах. При невозможности проведения

процесса, подлежащих сертификации, направ

испытаний на испытательной базе аккредито

ляет в орган по сертификации заявку по форме,

ванной лаборатории, испытания могут прово

принятой в системе сертификации. Орган по

диться персоналом этой лаборатории у изгото

сертификации проводит работу по подготовке и

вителя или потребителя данной продукции с ис

 

 

10