В.Ильин.

Руководитель Службы качества Компании TopSBI

"Если делаешь что-нибудь

неправильно - не нужно
рассчитывать на правильный результат."

Народная китайская мудрость

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

Но на вопрос, гарантирует ли внедрение системы качества и успешная сертификация выпуск качественного продукта, необходимо ответить честно - "нет".

Подчеркивая, что ISO 9000 - "превосходная идея", Gartner Group рекомендует рассматривать сертификацию на ISO 9001 только, как исходную точку на пути к качеству {1}.

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

В связи с вышеизложенным и с методологической, и с практической точек зрения многие специалисты в области менеджмента качества считают целесообразным строить стратегию развития ИТ-компаний следующим образом:

Сначала разработать и внедрить СМК по модели ISO 9001:2000. (Ведь большинство компаний, которые сейчас находятся на 4-ом и 5-ом уровнях SW-CMM, сначала прошли через приведение своих процессов в соответствие по модели ISO. Как показывает практика, это оптимальный вариант в плане управления развитием СМК и снижения рисков).

И только затем начать разрабатывать и внедрять ключевые процессы модели SW-CMM и далее, при необходимости, модели CMMI.

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

1. Обзор претендентов.

Проведем краткий обзор наиболее популярных стандартов, которые могут быть использованы ИТ-компанией для оптимизации своих бизнес-процессов.

ISO 9001. Наиболее популярным, и особенно, в Европе, является ISO 9001 {2}

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

Упрощенно "качество", согласно серии стандартов ISO 9000, это ситуация, при которой потребители получают от производителя продукцию соответствующую их прямым требованиям и подспудным ожиданиям. Поэтому управление качеством, в соответствии с ISO 9000, предполагает применение т.н. "процессного подхода", когда моделируется и внедряется наиболее оптимальная цепь "преобразований-процессов", гарантирующая, что потребности потребителей воспринимаются производителем и воплощаются в любой продукт без искажений.

Многие организации -разработчики ПО успешно используют именно эту широко известную серию стандартов ISO 9000. Новая версия стандартов этой серии вышла в 2000 году и уже содержит в себе такие понятия, как процессный подход, анализ и измерения, совершенствование процессов, заимствованные из модели СММ и ранее отсутствовавшие в предыдущих версиях ISO 9000. Правда, следует заметить, что стандарты этой серии универсальны - они не ориентированы на какую либо конкретную отрасль, не учитывает специфики IT-сферы и, в этом смысле, конечно по степени конкретизации, заметно уступают СММ. Кроме того, ISO 9000 не предполагает никаких градаций (уровней) соответствия и, тем самым, затрудняет определение "истинных" возможностей той или иной организации и, соответственно, - путей их дальнейшего развития.

CMM (Capability Maturity Model) разработана Software Engineering Institute при университете Карнеги-Меллона (США) и описывает модель зрелости процессов разработки программного обеспечения на предприятиях {3}. В рамках этой модели для каждой компании может быть сопоставлен некоторый уровень (один из пяти возможных), свидетельствующих о достигнутом качестве процесса разработки ПО. Так как эти стандарты разрабатывались, прежде всего, в целях упорядочивания процесса выбора подрядчиков для Министерства обороны США, особое внимание в них уделяется процессам управления ПО проектам, в то время как технические аспекты разработки освещены меньше.

В версии SW-CMM v.1.1 (Capability Maturity Model for Software) имеется 316 Key Practices. Key Practices - это то, что должно быть внедрено на предприятии и то, на что будет обращать внимание команда, проводящая оценку процессов. Они объединяются в области - Key Practices Areas (KPA) - это уже совокупности взаимосвязанных процессов, которые при совместном выполнении и приводят к достижению определенного набора целей.

CMMI (Capability Maturity Model Integration) - дальнейшее развитие модели CMM. В CMMI-SE/SW Version 1.02 (CMMI for Systems Engineering/Software Engineering), пожалуй, наиболее приемлемой для разработчиков программных систем, - количество Key Practices достигает уже 417.

Увеличение Key Practices связано с самой целью разработки CMMI - модель должна помочь избежать проблем, связанных с использованием различных отраслевых моделей CMM.

(Начиная с1991 года, были разработаны модели CMM для различных областей применения, наиболее существенными из них были:

Модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software - SW-CMM)
- модель зрелости процессов для системного реинжиниринга (Electronic Industries Alliance Interim Standard - EIA/IS 731)
- модель зрелости процессов интегрированной разработки продуктов Integrated Product Development Capability Maturity Model - IPD-CMM)

На основе этих моделей и был построен CMMI. Он вобрал в себя лучшее из этих моделей, устранив неоднозначность трактования некоторых понятий ввиду наличия множества моделей - поэтому и число ключевых практик значительно выросло).

Понятно, что это получилась уже существенно более "тяжелая" модель- см. Рис. 1 , которая, к тому-же, еще не достаточно проверена на практике (вышла только в 2002 году). В связи с этим, по моему мнению, при внедрении модели возможны большие риски, связанные, как с неоправданными потерями скорости разработки ПО, так и с одновременным однозначным возрастанием трудозатрат на функционирование (и поддержку) внедренных KPA - cм. Рис 1. Мне, как практику уже построившему СМК в трех различного профиля ИТ-компаниях, кажется, что в модели CMMI явно нарушен баланс необходимого и достаточного - персонал ИТ-компании (а это, как правило, большей частью- "художники кода ") просто "не примет к исполнению" такое количество контроллируемых регламентов (здесь есть очень большой риск построить "потемкинскую деревню") !

Рис. 1 Сравнение состава KPA в моделях CMM и CMMI.

Кроме того Assessment для CMMI будет значительно дороже, так как авторизованных SEI Lead Assessor" ов будет пока очень мало, и услуги эти будут значительно более дорогие, чем при оценке на соответствие модели CMM.

Более того, многие зарубежные специалисты в области менеджмента качества, (к мнению которых я на данный момент полностью присоединяюсь), довольно скептически отзываются о CMMI в контексте полезности ее для реализации в небольших и средних организаций (именно такие организации, как раз и характерны для России). Высказывается даже мнение, что через некоторое время SEI придется либо выпустить адаптированную SW-CMM v.2, либо произвести какие-то подобные шаги. Т.е. если рынок не примет модели, а такие предпосылки уже на момент написания этой статьи есть, то SEI надо будет адаптироваться к требованиям рынка.

В связи с вышеизложенным представляется целесообразным провести анализ уже упомянутого баланса необходимого и достаточного во всех этих основных моделях СМК.

Проведем его в следующих координатах (см. Рис. 2 ) :

степень регламентируемости процессов разработки - обозначим это понятие - RP ,

вероятность достижения запланированных результатов- обозначим это понятие -PQ .

На Рис. 2 показана экспертная оценка баланса степени регламентируемости и вероятности достижения при этом запланированных результатов, проведенная автором по результатам практики внедрения требований этих моделей в процессы разработки и внедрения ПС (программных средств).

Выражаясь математическим языком, величина производной: F(Q) = dPQ \ dRQ (прирост эффективности в достижении качества dPQ при приросте затрат рабочего времени на поддержку выполнения требований dRQ ),уменьшается,соответственно, в следующей последовательности: ISO 9000, CMM, CMMI.

Поэтому Рис. 2 наглядно и просто объясняет:

популярность именно модели ISO 9000,

правильность методики: сначала ISO, и только потом, при необходимости, CMM,

определенный скепсис в отношении эффективности модели CMMI.

Рис. 2 Анализ баланса степени регламентируемости и вероятности достижения при этом запланированных результатов (по экспертной оценке автора)

Расмотрим теперь еще одно руководство, которое широко используется в ИТ-компаниях и будет упомянуто ниже при анализе вопросов практики внедрения СМК.

Это PMBoK (Guide to the Project Management Body of Knowledge) - это проект Project Management Institute, вобравший в себя накопленные знания в области управления проектами. Последняя версия документа вышла в 2000 году и тогда же получила статус стандарта американского института стандартизации ANSI (хотя стандарты ANSI и IEEE формально считаются американскими, большинство из них носит де-факто международный характер). Важной особенностью PMBоK является то, что он рассматривает управление проектами в общем смысле, без привязки к конкретным предметным областям, таким как ИТ, и потому не может применяться самостоятельно - ниже мы рассмотрим, какой это дает эффект при его использовании совместно с ISO 9000.

Рассмотрим теперь, как соотносятся требования уже популярного стандарта ISO 9001:2000 с общими свойствами становящейся все более популярной модели СММ {3}- см. Рис. 3 .

Рис. 3. Соответствие между общими свойствами СММ и элементами ISO 9001:2000

Каждый уровень СММ, как было уже упомянуто выше, характеризуется набором областей ключевых процессов- KPA (Key Process Areas) - см. Рис.3. Достижение всех целей в рамках KPA для определенного уровня СММ определяет соответствие организации данному уровню. Если хотя бы одна цель хотя бы одной KPA для уровня СММ не достигнута, то организация не может соответствовать данному уровню CMM. KPA можно разбить на три категории: управляющие , организационные и обеспечивающие (см. Рис. 4 ).

СММ не определяет все процессы, имеющие отношение к разработке программного обеспечения; в ней выделяются только те, которые необходимы для достижения уровня СММ, они и включаются в KPA . Каждая KPA разбивается на 5 общих свойств (Common Features): Обязательство выполнить (Comment to perform); Способность выполнить (Ability to Perform); Выполняемые действия (Activities Performed); Измерение и анализ (Measurement and Analysis); Проверка реализации (Verifying Implementa­tion)

Общее свойство "Выполняемые действия" описывает действия, которые необходимо выполнить для достижения целей KPA , остальные четыре общих свойств описывают формальные факторы, делающие процесс частью организационной культуры. Полное выполнение всех ключевых приемов (key practice) из всех общих свойств обеспечивает достижение целей KPA . Ключевые приемы работы описывают, каким должен стать рабочий процесс (или элемент процесса, или часть инфраструктуры), но не определяют способ достижения (конкретные технологии или методики), хотя для некоторых приемов даются общие рекомендации. Для различных условий один и тот же результат может достигаться различными способами. Это скорее общие принципы работы, чем конкретные действия.

Последовательное выполнение общих свойств фактически реализует цикл улучшения бизнес-процессов (Buisness-process Improvement -BPI -см. Рис. 5. ), т.е. непрерывное улучшение бизнес-процессов (БП).

Рис. 5. Цикл непрерывного улучшения бизнес-процессов по модели CMM и ISO 9000:2000.

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

И сделать это волевым решением руководства невозможно. Именно поэтому подход, который определен в СMM, просто более жизнеспособен и реалистичен, чем в моделях ISO 9000 -см. Рис. 5 .

Рассмотрим теперь, как на практике можно построить СМК совместимую с обоими моделями.

Экспертная оценка степени покрытия ключевых процессов CMM требованиями ISO 9000:2000, в соответствии с оценкой самих авторов CMM {4}, показана на Рис.6 .

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

степень обеспечиваемости (в %) соответствия процессов разработки (SWP) уровню зрелости в рамках CMM -"обеспечиваемость" ;

степень возможности(в %) такой обеспечиваемости, которую дает ISO 9000:2000 - "возможность" .

Как видно из Рис. 6, требованияISO 9000:2000 создают реальную возможность для достижения даже верхнего (CMM Level 5) уровня зрелости SWP.

Однако в смысле уже обеспечения зрелости SWP хотя-бы третьего (CMM Level 3) уровня, СМК по модели ISO 9000:2000 необходимо немного доработать- а именно разработать и внедрить еще две организационные процедуры (Organization process definition and focus) и процедуру общего управления (Integrated softwaremanagement), содержаниекоторых не представляют сложности для любой ИТ-компании.

Но можно и нужно пойти дальше (CMM Level 4) - например, в скобках показана оценка автора этой статьи (в тех-же коорддинатах -обеспечиваемости и возможности), которая соответствует СМК по модели ISO 9000:2000, в которой процессный ландшафт СМК дополнен процессами управления проектами в соответствии с уже требованиями другого упомянутого выше стандарта PM Bok - это поможет вам существенно увеличить зрелость еще таких SWP , как:

Контроль за ходом выполнения проектов (Software project tracking and oversight);

• Планирование проектов (Software project planning);

Общее управление ПО (Integrated software management);

Управление процессами через количественные оценки (Quantitative process management).

Рис. 6. Экспертная оценка степени покрытия ключевых процессов CMM требованиями ISO 9000:2000

Как видно из Рис.6 ., модель СММ по заложенным в ней принципам очень близка к СМК построенной по стандарту ИСО 9001:2000 и дополненной процессами управления проектами в соответствии с PM BoK ..

Для того, чтобы не делать лишней работы при одновременных сертификации по ISO 9000 и последующей оценке по CMM, я рекомендую при определении ваших производственных процессов включить (а может и ими ограничиться - ведь это для ИТ-компании и есть производственные процессы!) в их число все необходимые в модели CMM KPA. Таким образом компания одновременно:

выполняет требования ISO 9001:2000 по внедрению процессного подхода;

документирует все необходимые CMM процессы (KPA );

реализует при этом ряд таких важных требований ISO 9001:2000 как:

управление процессами на основе метрик (Quantitative process management);

управление Поставщиками на основе управления субконтрактами (Software subcontract management);

анализ требований Потребителей на основе управления требованиями (Requirements management);

управление человеческими ресурсами на основе Программы обучения персонала (Training program);

управление коммуникациями на основе создания формальных моделей организационных процессов (Organization process definition);

запускает механизм улучшения (Plan-Dо-Check -Action) всех описанных процессов (SWP) посредством последовательной реализации всех пятиих Common Features -см.Рис. 5.

Таким образом, если в качестве БП использовать KPA CMM и использовать для процедур управления проектами разработки ПС требования PM BoK, то построенная таким образом СМК, может вполне быть оценена на CMM Level 4 - см . Рис. 7.

Рис. 7. Cхема достижения CMM Level 4 при совместном использовании модели СМК по ISO 9000 и руководства PM BoK 2000.

В заключении, исходя из соображений наглядности (в стилизации автора), представляю схему функционирования СМК ИТ-компании при последовательном внедрении моделей ISO 9000 и CMM - см. Рис. 8.

Рис. 8. Схема функционирования СМК при последовательном внедрении моделей ISO 9000 и CMM (стилизация автора)

Здесь важно понять, что и СММ и ISO 9001:2000 сами по себе являются всего лишь инструментами для непрерывного улучшения деятельности.

Таким образом, сертификация по стандарту ИСО 9001:2000 и подтверждение сертификата должны способствовать росту именно качества процессов компании, где критерий оценки роста качества процессов - выход предприятия на новый уровень BPI, то есть оценка их уже по модели именно CMM {3}.

Литература

"Оценка качества Програмных средств", В. Липаев, Синтег, 2001 г.

ISO 9001:2000. Система менеджмента качества. Требования.

Paulk M.C., Curtis B., Chrissis M.B., Weber C.V. Capability Maturity Model for Software (SW-CMM), version 1.1. // CMU/SEI-93-TR-024, - Februaru, 1993.

Введение

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

В настоящее время сложилось два почти независимых направления стандартизации в программной инженерии и обеспечении качества программных продуктов, которые условно можно назвать профилями стандартов ISO (Международной организации стандартизации) и моделями зрелости SEI (Института программной инженерии США). Первые достаточно полно представлены в [ , ], а вторые - в [ , ]. Именно моделям зрелости посвящено основное содержание статьи.

Для обеспечения конкурентоспособности в мире сложных программных продуктов и возможности их успешного экспорта они должны быть разработаны и сертифицированы в соответствии с требованиями профилей международных стандартов на базе ISO 9000:2000 или моделей зрелости - CMMI:2003 (Capability Maturity Model Integration - Интегрированная модель оценивания зрелости программной инженерии). Эти два направления методологически очень близки и частично пересекаются посредством взаимных ссылок.

Совершенствование технико-экономических показателей и качества программных продуктов, а также предотвращение ошибок и дефектов обеспечивается применением современных технологий программной инженерии и систем автоматизированного проектирования. Это высокопроизводительные, ресурсосберегающие технологии создания комплексов программ высокого качества, надежности и безопасности, имеющие своей целью сокращение общих затрат ресурсов на проектирование, реализацию и сопровождение программных средств (ПС). Для этого, прежде всего, необходимо применять методы и средства анализа и проектирования, обеспечивающие конкретизацию и максимально точное представление целей, назначения и функций с начала жизненного цикла (ЖЦ) ПС и предотвращающие распространение возможных системных дефектов на последующие этапы разработки. Такие технологии программной инженерии позволяют исключать или значительно снижать уровень системных, алгоритмических и программных ошибок в программных продуктах, передаваемых для эксплуатации. Кроме того, они эффективны при модификации и сопровождении ПС, а также при изменениях внешней среды.

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

Основой сертификации должны быть детальные и эффективные программы и методики испытаний комплексов программ на соответствие стандартизированным требованиям заказчиков, специально разработанные тестовые задачи и генераторы для их формирования, а также высокая квалификация и авторитет испытателей. Применение на предприятиях-разработчиках программных продуктов, сертифицированных систем качества обеспечения ЖЦ ПС на базе требований ISO 9000:2000 или CMMI:2003 , гарантирует высокое, устойчивое управление качеством процессов и продуктов их жизненного цикла, а также позволяет во многих случаях облегчать сертификацию конечного программного продукта. Поэтому заказчики сложных программных проектов стремятся выбирать подрядчиков-исполнителей, имеющих сертификаты, удостоверяющие применение ими систем гарантирования качества на основе адаптированных профилей международных стандартов или моделей зрелости.

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

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

Модель зрелости CMMI - 1.1 , уточняет и совершенствует предшествовавшие модели CMM (см. ), а также частично учитывает основные требования существующих международных стандартов в области менеджмента программных средств. Значительное внимание в CMMI уделяется процессам разработки и учету итераций при изменении требований заказчиков, их прослеживанию к функциям, компонентам, тестам и документам проекта. В последнее время появилась информация о модернизации институтом SEI версии 2003-го года CMMI - 1.1 на основе накопленного опыта и отзывов предприятий. Предполагается выпустить в 2006 году новую, существенно модернизированную, версию модели CMMI - 1.2 , после чего постепенно должно прекратиться применение версии 1.1. До конца 2007 года должен проводиться переход пользователей на версию CMMI - 1.2 , а в дальнейшем она станет обязательной для формализованной оценки качества (сертификации) технологии предприятий в области программной инженерии. При этом срок действия сертификата будет ограничен тремя годами. К этим изменениям следует готовиться заказчикам и разработчикам крупных ПС до официальной публикации институтом SEI версии 1.2.

Структура и содержание модели зрелости CMMI - 1.1

Два варианта модели CMMI - 1.1 созданы для обеспечения непрерывного оценивания комплекса процессов в определенной области создания программных средств или для поэтапного оценивания и совершенствования зрелости предприятия, а также для организации ЖЦ комплексов программ в целом. Модели CMMI представляют помощь специалистам при организации и совершенствовании их продуктов, а также по упорядочению и обслуживанию процессов разработки и сопровождения ПС. Концепция этих моделей охватывает управление и оценивание зрелости сложных систем, инженерии программных средств, а также процессов создания интегрированных программных продуктов и совершенствования их разработки. Компоненты непрерывной и поэтапной моделей в значительной степени подобны, могут выбираться и применяться в разном составе и последовательности использования в зависимости от свойств и характеристик конкретных проектов.

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

• предисловие;
• 1 раздел - введение;
• 2 раздел - модель компонентов;
• 3 раздел - терминология;
• 4 раздел - содержание уровней и главные компоненты каждого варианта модели (разработка целей и процедур);
• 5 раздел - структура взаимодействия процессов; аннотированы четыре категории процессов раздела 7, их общий обзор и схемы взаимодействия CMMI процессов:
  • менеджмент процессов;
  • менеджмент - управление проектом;
  • инжиниринг (технология);
  • поддержка;
• 6 раздел - использование модели CMMI - краткие рекомендации для пользователей по применению модели и обучению; отмечается совместимость и соответствие процессов модели, с регламентированными процессами предыдущей модели СММ в части 2 и 3 стандарта ISO 15504 .
• 7 раздел - последний, самый большой в каждом стандарте, он занимает около 500 страниц из полного объема документа, который составляет свыше 700 страниц. В этом разделе представлены подробные рекомендации для реализации каждого из перечисленных в нем процессов, которые учитывают особенности конкретной модели.

Первый вариант (непрерывной) модели отражает документ: Capability Maturity Model Integration (CMMI) for Systems Engineering/ Software Engineering/Integrated Prod-uct and Process Development, Version 1.1, Continuous Representation (CMMI-SE/SW/IPPD, V1.1, Continuous ). Интегрированная модель оценивания зрелости инженерии систем/программной инженерии/интегрированных продуктов и процессов разработки - непрерывное представление . В этой модели седьмой раздел составляют процессы:

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

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

А - состав использованных литературных источников и документов, в котором, однако, не упоминаются стандарты ISO ;

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

С - глоссарий на основе терминологии ISO , применяемой только в четырех стандартах ISO 9000, ISO 12207, ISO 15504:1-9, ISO 15288 ;

D - описания требований и предложений для формирования компонентов модели по уровням зрелости;

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

В этой модели внимание акцентировано на организационных процессах, на планировании, управлении и контроле процессов реализации проектов программных средств, на разработке и управлении требованиями к программным продуктам. Ниже представлены примеры детализации в CMMI некоторых из них .

Планирование проекта в этой также как и во второй модели включает:

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

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

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

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

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

Второй вариант представляет документ: Capability Maturity Model Integration (CMMI) for Systems Engineering/Software Engineering/Integrated Product and Process Development, Version 1.1, Staged Representation (CMMI-SE/SW/IPPD, V1.1, Staged ). Интегрированная модель оценивания зрелости инженерии сложных систем/программной инженерии/интегрированных продуктов и процессов разработки - поэтапное представление . Модель базируется на сохранении концепции пяти уровней зрелости CMM [ , ]. Состав процессов практически повторяет приведенный выше для первого варианта модели, но в несколько иной последовательности и с относительно небольшими дополнениями.

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

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

Приложения во втором варианте модели подобны по составу приведенным выше приложениям для первой модели. Рекомендуется на каждом более высоком уровне зрелости применять все процессы предыдущих нижних уровней. В обоих вариантах модели каждый, выделенный выше, базовый процесс комментируется подробными рекомендациями для его практической реализации, которые содержат унифицированные по структуре описания объемом около 20 - 30 страниц:

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

Эти рекомендации по объему, содержанию и полноте описаний базовых процессов подобны ряду стандартов профиля ЖЦ ПС, представленного в . Упорядочение и оценка полноты используемых процессов в соответствии с уровнями зрелости, позволяет устанавливать производственный потенциал предприятий - разработчиков программных продуктов по прогнозируемому качеству процессов и результатов их деятельности и готовности к сертификации на соответствие определенному уровню зрелости модели CMMI - 1.1.

Особое внимание в моделях CMMI уделяется процессам менеджмента проекта ПС. Эти требования и процессы моделей практически соответствуют регламентированным и детализированным рекомендациям в стандартах ISO 9001:2000 и основных компонентах профиля стандартов жизненного цикла сложных ПС [ , ]. Требованиям к процессам в функциональных разделах 4-8 стандартов ISO 9001, ISO 9004, ISO 90003 может быть сопоставлен адекватный по содержанию ряд разделов в модели CMMI (на Рис. 1 зона перекрытия содержания). Общность процессов и требований состоит в подобии: состава, терминологии, структуры, перечня рекомендуемых процессов управления, планирования, учета доступных ресурсов, реализации процессов программной инженерии, оценивания и организации специалистов.

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

С точки зрения поддержки и регламентирования полного жизненного цикла крупных проектов программных средств к недостаткам моделей CMMI относительно профиля существующих стандартов ISO можно отнести следующие:

Для определения представленных выше уровней зрелости процессов обеспечения жизненного цикла ПС разработан и первоначально утвержден в 1998 году обширный технический отчет ISO 15504 , состоящий из девяти частей и множества приложений. В нем изложены модель зрелости CMM и восемь базовых принципов программной инженерии на основе стандарта ISO 9000:2000 . Затем в ISO этот документ претерпел коренную переработку, сокращение, упрощение структуры и содержания, при полном сохранении целей и концепции, и утвержден как стандарт в составе пяти частей.

Стандарт ISO 15504:1-5:2003-2006 регламентирует оценку и аттестацию зрелости процессов создания, сопровождения и совершенствования программных средств и систем, выполняемых предприятиями:

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

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

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

Аттестация в стандарте рассматривается в двух аспектах : для усовершенствования процессов ЖЦ ПС и систем конкретного предприятия и для определения соответствия декларированной зрелости процессов обеспечения проекта или предприятия реальным используемым процессам. Это отражено в следующих пяти частях стандарта ISO 15504:1-5:2003-2006 .

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

Часть 2 - Выполнение (производство) аттестации. Включает детальные требования к проведению процессов аттестации как основы для совершенствования и определения уровня зрелости технологических процессов обеспечения ЖЦ ПС и систем. Документ определяет процессы выполнения аттестации, модели рекомендуемых процессов аттестации и верификации процессов, с тем чтобы они были объективными, содержательными и репрезентативными.

Часть 3 - Руководство по производству аттестации. Содержит обзор технологии выполнения процессов аттестации зрелости и интерпретации реализации требований. В нем отражено: исполнение аттестации; измерительные средства для определения процессов зрелости; выбор и применение средств аттестации; оценка компетентности аттестаторов; верификация соответствия аттестации декларированным требованиям. Средства аттестации могут использоваться предприятиями при планировании, менеджменте, мониторинге, контроле и усовершенствовании программных продуктов и систем, при их приобретении, разработке, применении и сопровождении.

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

Часть 5 - Образец модели процессов аттестации на соответствие требованиям, представленным в части 2. Обширный документ (162 стр.) содержит примеры практического применения предыдущих частей стандарта для организации, оценивания и совершенствования аттестации зрелости процессов жизненного цикла для различных областей использования, проектов программных средств и предприятий.

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

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

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

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

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

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

• политика в области обеспечения качества проведения испытаний и экспертиз;
• оснащение центра актуальными методологическими материалами и программно-инструментальными средствами испытаний;
• формализация требований к объектам испытаний;
• политика в области технической оснащенности центра и повышения квалификации персонала;
• архивация и контроль сохранности документации результатов сертификации.

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

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

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

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

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

Процесс сертификации программных продуктов и систем качества предприятия включает:

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

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

• наличия и полноты технологической документации и соблюдения её требований на практике;
• состояния средств технологического оснащения и наличия системы их технического обслуживания;
• наличия и эффективности системы контроля и испытаний;
• состояния средств измерений и испытаний;
• наличие системы выявления и устранения выявленных недостатков продукции или технологии.

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

После получения и проверки комплектности и качества документации специалистами испытательной лаборатории следует провести экспертизу степени реального применения системы качества на предприятии. Испытания начинаются с составления программы проверки системы качества, которая должна служить рабочим планом проведения последующих работ. Программа является внутренним рабочим документом испытательной лаборатории и должна содержать перечень работ, детализируемый в соответствии со спецификой предприятия-разработчика и включающий в себя анализ полноты и качества представленных исходных документов и степени их практического применения при проектировании, разработке и поставке ПС. Экспертиза применения процедур системы качества осуществляется испытательной лабораторией на рабочих местах предприятия, обеспечивающего ЖЦ ПС. Проверки проводятся по наличию на рабочих местах специалистов-разработчиков соответствующих документов и по полноте использования их положений и рекомендаций. Анализы состояния проекта и внутренние проверки системы качества, процессов и/или продукции должны проводиться персоналом, независимым от лиц, непосредственно ответственных за выполнение этих работ.

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

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

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

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

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

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

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

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

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

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

Документирование процессов и результатов сертификации программных продуктов

Состав и содержание документации для сертификации системы качества предприятия зависят от характеристик проектирования, разработки и модификации программных средств, а также от требований к их качеству и особенностей технологической среды. Поэтому необходимый комплект документов для каждого предприятия или проекта следует выбирать и адаптировать применительно к этим характеристикам. Оцениваемыми при сертификации показателями системы качества являются наличие соответствующих документов и практическое выполнение требований определенного уровня модели зрелости СММI или адаптированного профиля стандартов на базе ISO 9000:2000 , а также, созданных на их основе, должностных инструкций специалистами предприятия-разработчика. Заявитель должен подготовить и предъявить испытательной лаборатории согласованный между заказчиком и разработчиком и утвержденный комплект документов для проверки их достоверности, достаточности состава и качества изготовления в соответствии с нормативными документами.

Ориентировочный комплект основных документов при сертификации состоит из трех групп:

• базовые нормативные документы систем качества в соответствии с номенклатурой и содержанием профиля стандартов на базе ISO 9000:2000 или модели зрелости СММI , а также подготовленные разработчиками на их основе программа, руководство и инструкции, предъявляемые испытателям (экспертам) системы качества или продукции проверяемого предприятия;
• исходные документы, характеризующие конкретное предприятие или проект, а также жизненный цикл программного средства, подготавливаемые руководством проекта для сертификации его качества;
• отчетные документы испытателей, отражающие результаты проверки (сертификации) системы качества предприятия и/или программного продукта, представляемые органу сертификации, заявителю и руководству проверяемого предприятия.

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

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

1. Концепция, терминология, требования и руководство по улучшению деятельности - системы менеджмента качества - ISO 9000:2000 или версия модели зрелости СММI.
2. Адаптированные версии или перечень разделов и рекомендаций стандартов ISO 12207, ISO 15504 , их изменений и руководств по применению, выделенных при адаптации и обязательных для использования в системе качества конкретного предприятия или проекта программного продукта.
3. Адаптированная версия или перечень разделов и рекомендаций стандарта ISO 900003 , выделенных при адаптации и обязательных для применения в системе качества предприятия, выпускающего программный продукт.
4. Базовые характеристики и атрибуты качества проекта ПС, выделенные, адаптированные и конкретизированные на основе стандартов ISO 12182, ISO 9126, ISO 14598, ISO 25000 .
5. Адаптированная версия и утвержденная редакция руководства по сопровождению и конфигурационному управлению основе рекомендаций стандартов ISO 14764, ISO 10007, ISO 15846 .
6. Комплект должностных инструкций, определяющих ответственность, полномочия и порядок взаимодействия всего руководящего, выполняющего и проверяющего работу персонала, участвующего в процедурах системы качества предприятия для конкретного проекта ПС.

Исходные документы, отражающие особенности жизненного цикла конкретного программного средства

1. Описание характеристик программных продуктов, создаваемых на предприятии, системы и внешней среды их жизненного цикла, необходимых для адаптации и подготовки рабочих версий стандартов и требований проекта ПС и системы качества предприятия в соответствии с рекомендациями стандартов ISO 12207, ISO 15504, ISO 90003 и ISO 9126 .
2. Описание целей, требований и обязательств предприятия-разработчика в области системы качества, критериев качества процессов и продуктов разработки, поставки и поддержки всего жизненного цикла ПС.
3. Комплект эксплуатационных документов, поставляемых заказчику и пользователям для обеспечения ЖЦ и применения конкретной версии программного продукта на основе адаптированных стандартов ISO 9294, ISO 15910, ISO 18019 .
4. Документация и средства автоматизации проектирования, разработки, модификации, контроля и испытаний, используемых для обеспечения жизненного цикла программного продукта.
5. Планы и методики испытаний применения и оценки эффективности процессов системы качества предприятия и программного продукта.
6. Методики сопровождения, идентификации компонентов программного продукта и документации, анализа и утверждения версий комплексов программ и данных.
7. Методика конфигурационного управления, утверждения, хранения, защиты, копирования версий программного продукта и сопровождающих документов, а также накопления и хранения, зарегистрированных в архиве предприятия данных о характеристиках качества в течение жизненного цикла версий программного продукта.

Результирующие документы испытаний - сертификации системы качества предприятия и/или программного продукта

1. Отчет о наличии, актуальности и систематичности оформления документации, адаптированной к требованиям и положениям системы качества предприятия, обеспечивающей интегрированный процесс гарантии качества на протяжении всего жизненного цикла программного продукта.
2. Результаты контроля и испытаний состояния и применения системы качества, проводимых периодически для определения ее пригодности и эффективности.
3. Отчет о наличии и поддержании в рабочем состоянии методик проведения проверок и документально оформленных отчетов о результатах достигнутого качества выполнения требований договора на сертификацию с заказчиком.
4. Результаты регистрации достигнутых характеристик качества комплекса программ: идентификация, накопление, хранение зарегистрированных данных о характеристиках и атрибутах качества программного продукта и его компонентов.
5. Результаты реализации плана разработки, документально оформленных входных и выходных данных этапов разработки и протоколов проверки реализации жизненного цикла ПС.
6. Результаты практического выполнения программы качества и осуществления регламентированной деятельности в области качества на всех этапах жизненного цикла ПС.
7. Результаты аттестации имитаторов внешней среды и генераторов тестов, а также оценка их достаточности для выполнения сертификационных испытаний программного продукта.
8. Результаты анализа выполнения планов и методик проведения испытаний, протоколы испытаний, оценки соответствия результатов испытаний предъявляемым требованиям, а также результаты испытаний, утвержденные представителями заявителя, заказчика и поставщика.
9. Акт результатов проверок реальных характеристик жизненного цикла ПС и системы качества предприятия, выводы о их соответствии требованиям к сертификации производства программного продукта.
10. Сертификат системы качества предприятия и/или программного продукта и обеспечения его жизненного цикла, лицензия на применение знаков соответствия.

Литература

В.В. Липаев -- Профили стандартов жизненного цикла программных средств. -- Jet Info, Информационный бюллетень , N 12 , 2005

К. Мильман, С. Мильман -- СММI - шаг в будущее. -- Открытые системы. , N 5-6.(2005), N2.(2006) , 2005, 2006

Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем ISO IEC TR 15504-CMMI. Пер. с англ -- М.: Книга и бизнес , 2001

В.В. Липаев -- Процессы и стандарты жизненного цикла сложных программных средств. Справочник. -- М.: СИНТЕГ , 2006

В.В. Липаев -- Методы обеспечения качества крупномасштабных программных средств. -- М.: РФФИ. СИНТЕГ , 2003

"; antisource: "Программные продукты сейчас применяются для решения задач управления практически во всех сферах деятельности человека: в экономике, социальной, военной и других областях. Обеспечение высокого качества отечественных программных продуктов при их массовой разработке и поставке для различных сфер применения в стране и на мировом рынке стало стратегической задачей."; condition: 1]$

05.04.2007 Вячеслав Панкратов

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

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

Очевидно, что качество программного обеспечения напрямую зависит от качества процесса его производства. Управляя процессом производства и контролируя показатели эффективности всех его технологических этапов, можно влиять на качество производимого продукта. Говоря о характеристиках программ, можно выделить простые для понимания и анализа количественные метрики, относящиеся к качеству программного кода (цикломатическая сложность кода - сложность структуры модуля, например, количество независимых маршрутов в нем); количество строк кода, отнесенное к артефактам проектного репозитория и т.п.; тесты (покрытие веток и модулей кода сценариями тестов, соотношение количества ошибок, найденных до и после выпуска продукта, динамика обнаружения ошибок и др.); покрытие требований на соответствие рекомендациям к интерфейсу приложений и операционным платформам. Однако, при переходе на процессный уровень обеспечения качества разрабатываемых программ возникают определенные трудности в понимании качества этого процесса. В самом деле, как, например, оценить и измерить эффективность того или иного способа разработки, если практически не существует проектов разработки двух одинаковых программных систем, и тем более не встречаются две идентичные по опыту и навыкам команды разработчиков? Судить по конечному результату не представляется возможным: кроме процессных условий производства программного обеспечения (применяемая методология, структура проектной команды, способы коммуникации с заказчиком) зачастую сильно разнятся и условия проекта (сроки, стоимость и объемы ресурсов). Более детальное рассмотрение процесса тестирования программного обеспечения - технологической составляющей процесса производства - выявляет проблему выбора метрик эффективности тестирования.

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

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

В 1980 году в Институте программной инженерии при Университете Карнеги-Меллона была разработана модель зрелости процессов разработки программного обеспечения (Capability Maturity Model for Software, CMM), которая впоследствии получила развитие в CMMI (Capability Maturity Model Integration), де-факто признанном в индустрии производства программного обеспечения сертификате уровня зрелости процесса разработки. По аналогии с миром разработки программного обеспечения и существующими моделями зрелости их процессов, рассмотрим модели зрелости процесса тестирования.

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

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

Консультант по вопросам тестирования Терри Везерил в 2001 году одним из первых сравнил существующие модели зрелости тестирования и выделил шесть моделей:

Testability Maturity Model (TMM);

Software Testing Maturity Model (TMMSW);

Test Process Improvement (TPI);

Test Organization Maturity (TOM);

Testing Assessment Program (TAM);

Proposed Evaluation and Test SW-CMM Key Process Areas (SW-CMM KPA).

Затем в некоторые модели были внесены принципиальные изменения; так, модель ТОМ (ее создала и развивает компания Gerrard Consulting) предлагает обновленный набор метрик, описывающих непосредственно процесс тестирования (длительность тестовых итераций, соотношение тестовых сценариев и функциональных требований и др.), которые собираются и анализируются на этапе описания существующего процесса.

Среди шести моделей зрелости тестирования программного обеспечения практики и консультанты выделяют две: TMMSW, разработанную в Технологическом институте штата Иллинойс, и TPI, предложенную в компании Sogeti. Обе модели получили распространение в первую очередь благодаря своей простоте, а также предлагаемым практикам внутренних аудитов, которые могут производиться специалистами компании, вставшей на путь процессных улучшений. Рассмотрим структуру моделей зрелости тестирования программного обеспечения на примере модели TMM.

Модель TMMSW, выбранная Томасом Стаaбом , одним из ведущих консультантов в области тестирования программного обеспечения, является наиболее интересной для применения, поскольку наряду с простотой понимания и использования практик позволяет организациям собственными силами проводить оценки (assessment) и постепенно приближаться к поставленным целям развития, контролируя промежуточные результаты. В своей работе мы также остановили выбор на этой модели, учитывая непопулярность у отечественных ИТ-компаний практики привлечения сторонней компетенции (компании стараются экономить на инвестиционных проектах, каковыми по сути являются проекты консалтинговые, а также на проектах, приносящих непрямые выгоды, к которым относят процессные изменения), и предлагаем познакомиться с нашим опытом, демонстрирующим готовность компаний самостоятельно проводить внутренние изменения силами собственных специалистов. Итеративность подхода является для многих компаний ключевым моментом при выборе той или иной модели зрелости, так как она позволяет контролировать сроки исполнения проекта по внедрению процессных изменений.

Модель TMMSW разработана группой специалистов под руководством Илен Барнштейн в 1996 году как расширение и дополнение к модели SW-CMM. К ее преимуществам можно отнести соответствие уровней зрелости процессов тестирования программного обеспечения и уровней зрелости процессов разработки в модели SW-CMM. Также модель TMMSW может быть использована в интеграции с CMMI, рекомендациями ISO-9001 и стандартом ISO/IEC Std 12207, которые позволяют пройти формальную сертификацию и при постоянном контроле в виде аудитов и переаттестаций оставаться на заданном уровне качества. С одной стороны, эта особенность TMMSW позволяет внедрять процессные изменения в подразделении тестирования программного обеспечения в формате выделенного проекта меньшего масштаба, чем внедрение CMMI во всей организации (что экономит средства и обеспечивает прозрачность); с другой стороны, при таком подходе исключаются затраты на адаптацию и сопряжение нескольких моделей. Говоря о своеобразном родстве с CMMI, хотелось бы подчеркнуть, что эта модель достаточно широко распространена в мире ИТ и заслужила высокую степень доверия к себе, что намного облегчает мотивацию руководства к затратам на проект по внедрению процессных изменений.

Модель TMMSW предлагает облегченное планирование, внедрение и мониторинг процесса улучшения. Из недостатков модели можно отметить ограниченность литературы: книга Practical Software Testing: A Process-oriented Approach, выпущенная Springer Professional Computing, - пожалуй, единственный значительный труд по данной тематике.

Модель TMMSW, как и CMM, предусматривает пять уровней зрелости.

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

Уровень 2 - фаза разработки. Тестирование программного обеспечения отделено от кодирования и выделяется как следующая фаза. Главная цель тестирования - показать, что приложение соответствует требованиям. Имеются базовые подходы и практики тестирования. Цели уровня: определить задачи разработки и тестирования, создать соответствующие процедуры, инициировать процесс планирования тестирования, зафиксировать и описать базовые процедуры и методики тестирования.

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

Уровень 4 - управление и измерение . Тестирование является измеряемым и контролируемым процессом. Процессы критических осмотров (review) проектных артефактов (тестовые планы и сценарии, сообщения об ошибках, итоговые отчеты о состоянии версии и т.д.) относятся к тестовым активностям. Продукт тестируется на соответствие таким качественным метрикам, как надежность, удобство, сопровождаемость. Тестовые сценарии записаны, хранятся в системе управления тестированием и могут быть многократно использованы вместе с тестовыми наборами данных. Обнаруженные дефекты не только фиксируются, но и анализируются по формальным признакам: критичность, «вес» дефекта, важность, время жизни и т.д. Цели уровня: внедрение программ критических пересмотров и аудитов на уровне всей организации/подразделения наравне с программой измеряемого тестирования. Проводится оценка качества программных продуктов.

Уровень 5 - оптимизация процесса, предотвращение ошибок и контроль качества. Тестирование является определенным и управляемым процессом. Стоимость тестирования наравне с показателями эффективности может быть определена. Тестирование как процесс поддается изменениям, которые однозначно положительно на него влияют. Внедрены и используются практики предотвращения ошибок и контроля качества. Автоматизированное тестирование применяется как основной подход в тестировании. Проектирование тестов, анализ полученных результатов, обработка описаний ошибок, а также метрик, связанных с тестированием, осуществляется при помощи соответствующих инструментальных средств. Широко распространен подход повторного использования процессных практик. Цели уровня: оптимизация процесса тестирования, предотвращение ошибок и контроль качества.

Все перечисленные уровни зрелости, кроме первого, включают цели развития, которые, в свою очередь, содержат подцели, то есть позволяют оперировать не только высокоуровневыми задачами менеджмента качества процесса разработки программного обеспечения, но и формулировать оперативные задачи для всех исполнителей в проекте. Контроль и анализ выполнения задач достигаются покрытием так называемых ATR-матриц (Activities - Tasks - Responsibilities) - артефактов проектного уровня, с которыми могут работать участники проекта без предварительной подготовки или длительного обучения. ATR-матрицы определяют активности и задачи, которые должны быть выполнены на каждом конкретном этапе внедрения модели, и служат одновременно и «дорожной картой», и своеобразным «контрольным листом» процесса внедрения изменений. Наличие предлагаемых самой моделью проектных артефактов зачастую является существенным критерием успешности проекта по адаптации и внедрению модели. Каждой активности в ATR-матрице назначается задача контроля, которая выполняется менеджерами, разработчиками/тестировщиками или же клиентами/пользователями. Особо отметим, что контроль над проектом по внесению изменений не возлагается на выделенную группу людей или конкретного человека в проекте, а является общей проектной функцией, в выполнении которой заинтересованы участники проекта всех уровней.

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

Применение конкретных методик или следование любой из выбранных методологий (RUP, MSF или Scrum) также не дает гарантий достижения качества продукта или успешности проекта, так как методология разработки программного обеспечения работает только для конкретного типа проектов. Аналогично для процесса тестирования программного обеспечения ни одна методология без адаптации к условиям конкретного проекта не дает гарантированного результата. Модель зрелости процесса - именно тем и интересная для применения практика достижения определенных уровней качества процесса, что представляет собой структуру целей и подходов для их достижения, позволяя использовать «внутри» практически произвольную методологию разработки (при правильной адаптации) и набор инструментария. Модель объясняет, «что и как» делать, но не «чем и в каком порядке».

Практика

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

Контролируемый по срокам процесс выпуска версий с заданным уровнем качества. Здесь не говорится об идеальном качестве выпускаемого продукта или полном отсутствии дефектов - речь идет об уверенности в состоянии выпускаемой версии, со стороны как проектной команды, так и группы тестирования.

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

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

Литература

Terry Weatherill, In the Testing Maturity Model Maze. Journal of Software Testing Professionals, 2001.

Thomas Staab, Using SW-TMM to Improve the Testing Process. Wind Ridge International.

Вячеслав Панкратов ([email protected] ) - генеральный директор компании QAExpert (Киев, Украина).

В ноябре 1986 года американский институт Software Engineering Institute (SEI) совместно с Mitre Corporation начали разработку обзора зрелости процессов разработки программного обеспечения, который был предназначен для помощи в улучшении их внутренних процессов.

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

В сентябре 1987 года SEI выпустил краткий обзор процессов разработки ПО с описанием их уровней зрелости, а также опросник, предназначавшийся для выявления областей в компании, в которых были необходимы улучшения. Однако, большинство компаний рассматривало данный опросник в качестве готовой модели, вследствие чего через 4 года вопросник был преобразован в реальную модель, Capability Maturity Model for Software (CMM). Первая версия СММ (Version 1.0), вышедшая в 1991 году, в 1992 году была пересмотрена участниками рабочей встречи, в которой принимали участие около 200 специалистов в области ПО, и членами общества разработчиков.

1. Начальный. Самый примитивный статус организации. Организация способна разрабатывать ПО. Организация не имеет явно осознанного процесса, и качество продукта целиком определяется индивидуальными способностями разработчиков. Один проявляет инициативу, и команда следует его указаниям. Успех одного проекта не гарантирует успех другого. При завершении проекта не фиксируются данные о трудозатратах, расписании и качестве.
2. Повторяемый. В некоторой степени отслеживается процесс. Делаются записи о трудозатратах и планах. Функциональность каждого проекта описана в письменной форме. В середине 1999 года лишь 20 % организаций имели 2-й уровень или выше.
3. Установленный. Имеют определённый, документированный и установленный процесс работы, не зависящий от отдельных личностей. То есть вводятся согласованные профессиональные стандарты, а разработчики их выполняют. Такие организации в состоянии достаточно надёжно предсказывать затраты на проекты, аналогичные выполненным ранее.
4. Управляемый. Могут точно предсказать сроки и стоимость работ. Есть база данных накопленных измерений. Но нет изменений при появления новых технологий и парадигм.
5. Оптимизированный. Есть постоянно действующая процедура поиска и освоения новых и улучшенных методов и инструментов.

Развитие

Использование модели на практике выявило неоднозначность в подходах к достижению более высоких уровней организации процессов разработки ПО. Поэтому к 2002 году разрабатываются рекомендации по улучшению процесса разработки, которые получают название CMMI (Capability Maturity Model Integration) . На текущий момент последняя версия CMMi - 1.3 (опубликована в ноябре 2010) .

См. также

Ссылки

Форум студентов МТИ > Основной раздел > Тесты > Моделирование систем управления

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

Я про решала все модули, сдала все на 4, а итоговый на 2, теперь через три дня попробую сдать повторно, не было ни одного одинакового вопроса. Итоговый тест пыталась исправлять, но проверяйте, за правильность не ручаюсь.Выставляю всё, что есть у меня, может быть кто то сдаст лучше меня. Если есть у кого то вторая, третья попытка, выставите, если не жалко, дисциплина, действительно очень трудная.:eek:

Итоговый тест 100 из 100

итоговое каждый раз разное?

Еще вопросы, которые здесь не указаны и попались мне. Ответы не искала, тк без этого сдала на 4. Кто захочет зоморочиться, выгрузите ответы здесь для остальных 🙂

Модуль 1:
Что не следует рассматривать в качестве отличительного признака бизнес-процесса?

Наращивание стоимости

Выберите один ответ:
Продукт процесса, воплощающий в себе ранее поставленные цели

Выберите один ответ:

В итоговом (сдано на 4.

What is the Capability Maturity Model? (CMM)

Эти вопросы + те, что уже есть на форуме):
1. Выберите правильное утверждение.
Выберите один ответ:
Бизнес-процесс подразделений состоит из различных цепочек создания ценности (НЕ УВЕРЕНА)
Сквозной бизнес-процесс состоит из бизнес-процессов различных организаций
Межфункциональный бизнес-процесс, как правило, состоит из бизнес-процессов подразделений

2. Что не является элементом универсальной структурной схемы бизнес-процесса?
Выберите один или несколько ответов:
Ресурсы процесса
Риски
Деятельность по управлению бизнес-процессом
Факторы внешней среды
Деятельность по преобразованию входов в выходы

3. Материальные ресурсы как базовый элемент процессов представляют собой:
Выберите один ответ:
Активные субъекты деятельности, объединенные в системы, взаимодействующие друг с другом и другими ресурсами
Управляющие воздействия, направляемые субъектами деятельности на объекты деятельности, определяющие цели и результаты процессов
Пассивные средства и предметы деятельности, используемые для выполнения процессов (НЕ УВЕРЕНА)

28.03.2014, 10:07

Модуль 1:
Что не следует рассматривать в качестве отличительного признака бизнес-процесса?Выберите один или несколько ответов:
Преобразование входов в выходы
Поставка продукта внешнему потребителю
Наращивание стоимости
Формирование прибавочной и/или потребительной стоимости

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

Что такое обратная связь в рамках бизнес-процесса?
Выберите один ответ:
Целенаправленное и сознательное воздействие на процесс, предназначенное для обеспечения необходимого результата
Анализ и сопоставление результатов процесса с ранее поставленными целями
Воздействие на систему объектов и факторов внешней среды, являющиеся источниками различного рода отклонений в функционировании системы
я так ответила! но все равно вышло 4

В итоговом — Эти вопросы + те, что уже есть:
1 Выберите из списка недостатки проектно-целевых структур.

2 Выберите из списка примеры использования команд.
Кружки качества
Комитеты
Рабочие команды

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

4 Выберите из списка преимущества проектно-целевых организационных структур.
прямое подчинение сотрудников руководителю проекта и таким образом достигается однозначность направленности усилий этих сотрудников

5 Вспомогательные процессы:
Обеспечивают эффективную реализацию основных процессов

Итоговое оценка 5
Вопрос 1
Выберите из списка примеры использования команд.

Кружки качества
Комитеты
Рабочие команды

Вопрос 2
Для чего применяются посредники в рамках функциональной структуры?

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

Вопрос 3
Назовите типы взаимосвязей в модели SADT:
Управление
Выход-механизм
Обратная связь по входу

Вопрос 4
Какой из перечисленных бизнес-процессов является самым коротким?
Бизнес-процесс подразделения

Вопрос 5
Какие методы, методологии и инструменты можно использовать для создания информационных моделей бизнес-процессов?

Методологию Гейна-Сарсона
Язык моделирования Чена и Баркера

Вопрос 6
Какое представление бизнес-процесса соответствует самому нижнему уровню (из перечисленных)?

Операции бизнес-процесса

Вопрос 7
Длина бизнес-процесса:

Представляет собой субъективную характеристику

Вопрос 8
Материальные ресурсы как базовый элемент процессов представляют собой:

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

Вопрос 9
Выберите из списка преимущества проектно-целевых организационных структур.

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

Вопрос 10
Выберите из списка преимущества матричных организационных структур.

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

Вопрос 11
Что в себя включает второй контур управления бизнес-системой?

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

Вопрос 12
Общая процессная модель бизнес-системы включает в себя следующие элементы:

Выход
процесс
Вход
Возмущение

Вопрос 13
Какой стандарт из семейства IDEF позволяет моделировать деятельность, потоки и состояние объектов?

Вопрос 14
Каковы полномочия Руководителя проекта в сильной матричной структуре?

От средних до высоких

Вопрос 15
Что можно отнести к числу основных элементов инвестиционно-финансовых процессов?

Инвесторов
Кредиторов

Вопрос 16
Выберите из списка недостатки проектно-целевых структур.

Снижается технологичность в функциональных областях

Моделирование систем управления.rar (http://mti.prioz.ru/krfilesmanager.php?do=downloadfile&dlfileid=107)

Каков порядок доминирования на диаграммах SADT?
Ответ: Наиболее доминирующие функции располагаются в верхнем левом углу.

помогите 3тренинг укого есть плиз

Добавлено через 1 минуту
прошу 3 тренинг укого есть Моделирование систем управления

vBulletin® v3.8.7, Copyright 2000-2018, vBulletin Solutions, Inc.

Перевод: zCarot

Методология разработки ИС. Модель зрелости CMM/CMMI.

В 1991 году Институтом программной инженерии Университета

Карнеги-Меллона (Software Engineering Institute, SEI) была создана модель зрелости СММ (Capability Maturity Model) для разработки программных продуктов. С течением времени было выпущено целое семейство моделей:

SW-CMM - для программных продуктов, SE-CMM - для системной инженерии, Acquisition CMM - для закупок, People CMM - для управления людскими ресурсами, ICMM -для интеграции продуктов.

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

требованиями международных стандартов. Поэтому в 2002 году SEI опубликовал новую модель CMMI (Capability Maturity Model Integration), объединяющую ранее выпущенные модели и учитывающую требования

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

области. При этом все области задаются в виде требований, определяющих не то, как они реализованы, а интерфейсные требования. Из этого имеется два следствия.

Следствие 1. CMMI допускает различные реализации и не является методологией разработки ПО, подобно MSF, Scrum, RUP и пр. Последние могут использоваться в его реализации. Так, существует, например, специальный шаблон процесса в VSTS для CMMI под названием MSF for CMMI.

Следствие 2. CMMI используется для сертификации компаний на зрелость их процессов. Изначально, в конце 80-х начале 90-х годов, CMM (тогда еще не CMMI) создавался именно как средство сертификации

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

Например, авиационная, аэрокосмическая индустрии. То есть разработка ПО

происходит вместе с инженерными работами иных видов. И часто бывает, что в одном проекте участвует более двух различных видов инженерии. Задача CMMI – предоставить таким проектам и компаниям единую платформу организации процесса разработки.

В отличии от классической модели CMM, которая была жестко иерархической и допускала только последовательное улучшение процессов по уровням, модель CMMI имеет два измерения - последовательное, такое

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

зрелости процессов (рис. 1).

Начальный уровень (уровень зрелости 1) - это уровень, на котором, по определению, находится любая компания. На этом уровне разработка ПО ведется более-менее хаотично.

Управляемый уровень (уровень зрелости 2) - здесь уже появляются политики и процедуры организации процессов, утвержденные на уровне компании. Но в полной мере процессы существуют лишь в рамках отдельных проектов.

Определенный уровень (уровень зрелости 3) - здесь появляется стандартный процесс на уровне всей компании в целом.

What is Capability Maturity Model (CMM)? What are CMM Levels?

Это большой и постоянно пополняющийся набор активов процесса: шаблонов документов,

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

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

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

Многим известна аббревиатура CMMI, многие знают, что это — модель, т.е. набор рекомендаций как улучшить процессы, связанные, например с разработкой ПО. Но немногие знают, что моделей CMMI несколько. Самая известная из них — CMMI for Development (CMMI-DEV), которая действительно связана во многом с деятельностью разработческих компаний (т.е. тех компаний и организаций, которые разрабатывают и поставляют некий программный продукт или иное комплексное — программно-аппаратное решение).

Но как быть тем, кто поставляет не продукт, а услуги (например, сопровождение продукта с незначительной долей разарботки в общих трудозатратах или вообще с отсутствием таковых)? Для них тоже есть набор рекомендаций — модель CMMI for Services (CMMI-SVC). Для IT-подразделений, например, эта модель (точнее — её рекомендации) может помочь понять — что надо сделать, чтобы, например, те же рекомендации ITIL, приобрели характер нормального процесса, а не некой «сакральной практики».

Capability Maturity Model (Модель развития функциональных возможностей) (CMM)

Любопытно, что рекомендации этой модели достаточно универсальны и не «замыкаются» только на информационные технологии. Пилотное внедрение практик этой модели проходило … в одной из больниц в США (ведь медицинское обслуживание — это тоже услуги).

Однако, любой модели из перечисленных лучше обучиться. И если на всё СНГ обученных модели CMMI-DEV несколько сотен наберется (порядка 250-300 человек), то обученных модели CMMI-SVC в СНГ… 6 человек. Речь идет именно об обученных, а не об инструкторах. Это как раз и было до декабря 2011 года главной проблемой: по CMMI-DEV на весь мир был только один сертифицированный институтом SEI (разработчиком моделей CMMI) русскоязычный инструктор, а по другим моделям таковых вообще ни одного! Теперь появился такой инструктор и по модели CMMI-SVC (отсюда и первые 6 обученных). Этим инструктором является автор данной публикации, который готов ответить на любые вопросы по упомянутым моделям, и по официальному обучению. Спрашивайте!

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

5 эволюционных этапов в управлении организационными процессами. Объяснение Capability Maturity Model (Модель развития функциональных возможностей). CMM

Моделью Capability Maturity Model (Модель зрелости возможности) CM-CEI организационная модель, которая описывает 5 эволюционных этапов (уровней), на которых управляются процессы в организации.

Смысл Capability Maturity Model (Модель зрелости возможности), первоначально созданной для развития программного обеспечения, в том, что организация должна быть способна принять и поддерживать приложения своего программного обеспечения. Модель также предлагает конкретные шаги и инициативы, которые помогут организации развиться до следующего уровня.

5 этапов Capability Maturity Model (Модель развития функциональных возможностей)

Начальный (Initial) (процессы специальные, хаотичные или, на самом деле, немногие из них определены) Повторяемый (Repeatable) (основные процессы установлены, и существует дисциплина для того, чтобы придерживаться этих процессов) Определяемый (Defined) (все процессы определены, документированы, унифицированы и интегрированы) Управляемый (Managed) (процессы измеряются путем агрегирования подробных данных о процессах и их качестве) Оптимизирование (Optimizing) (непрерывное развитие процесса с помощью количественной обратной связи и испытания новых идей и технологий)

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

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

Практики можно повторить. Если вы не повторяете какую-то операцию, то не стоит ее улучшать. Существуют правила, процедуры и практики, которые принуждают организацию к внедрению и последовательному исполнению. Лучшие методы организации производственных работ можно быстро распространить между группами. Практики определены так, чтобы позволить обмен между проектами, таким образом обеспечивая некоторцю стандартизацию для организации. Отклонения в исполнении этих методов минимизируются. Количественные цели установливаются для задач; и установливаются, производятся и поддерживаются измерения для формирования основы для оценки. Практики непрерывно улучшаются для совершенствования возможности (оптимизирование).

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

Структура Модели развития функциональных возможностей

Уровни зрелости - многоуровневая концепция, обеспечивающая последовательность дисциплины, которая необходима для достижения непрерывного улучшения. Важно отметить здесь, что организация развивает способность оценивания последствий новой практики, технологии или инструмента. Следовательно, дело не в принятии этих нововведений, а скорее в том, как эти инновационные усилия оказывают влияние на существующие практики. Это оказывает поддержку проектам, группам и организациям давая им основание для обоснованного выбора. Ключевые области процессов - Ключевая область процессов/Key process area (KPA) определяет группу родственных операций, которые при совместном выполнении, достигают ряда важных целей. Цели - цели ключевой области процессов описывают положения, которые должны существовать для той ключевой области процессов. Положения необходимо внедрить эффективным и надежным способом. Объем, в котором цели выполнены, показывает какого рода возможность организация установила на этом уровне совершенности. Цели очерчивают сферы деятельности, границы, и цель каждой ключевой области процессов. Общие характеристики - общие характеристики включают практики, которые внедряют и институционализируют ключевые области процессов. Эти 5 типов общих характеристик включают: Обязателъство исполнить, Способность исполнить, Выполняемые инициативы, Измерение и Анализ, и Контроль внедрения. Ключевые практики - ключевые практики описывают элементы инфраструктуры и практики, которые вносят наиболее эффективный вклад во внедрение и институционализацию ключевых областей процессов.

Критерии для пределения процесса

Критерии для пределения процесса - это совокупность элементов процесса, которые необходимо включить в описание программного процесса для того, чтобы люди могли использовать их на практике. Для того, чтобы установить критерии вам надо задать вопрос - «Какая информация по программному процессу нужна для документирования?»