Управління ІТ-проектами / Література / Липаев В.В. Модели зрелости программной инженерии
.pdf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
И Н Ф О Р М А Ц И О Н Н Ы Й Б Ю Л Л Е |
Т Е Н Ь |
№ 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 |
|