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

В условиях жесткой конкуренции, важно гарантировать высокое качество процесса конструирования ПО.

CMM/CMMI

Наверное, самым именитым стандартом качества следует считать Capability Maturity Model (CMM) – модель оценки уровня зрелости процессов разработки вместе с его производными. Он был создан SEI (Software Engineering Institute), который финансируется за счет Министерства обороны США и является структурной единицей Университета Карнеги-Меллона. Первая официальная версия стандарта вышла в 1993 г., хотя работы над ним начались гораздо раньше – основные его положения были опубликованы еще в 1986 г.

Успех CMM предопределило несколько факторов. Этот стандарт был одним из первых, изначально учитывающих специфику создания ПО. Он оказался достаточно прост и прозрачен как для понимания, так и для использования, и регламентировал, «что», а не «как» делать, а потому подходил для различных моделей жизненного цикла, методологий разработки и не накладывал каких-либо ограничений на стандарты документирования, инструментарий, среду и языки, применяемые в проектах. И, пожалуй, основным фактором, предопределившим популярность CMM, явилось сотрудничество SEI с Министерством обороны США, что де-факто означало использование стандарта при реализации проектов по заказу этого ведомства.

Модель CMM (табл. 1) предусматривает пять уровней зрелости, каждому из которых соответствуют определенные ключевые области процессов (Key Process Areas, KPA).

Таблица 1. Уровни модели CMM

Деление на уровни и определение KPA для каждого из них позволяет последовательно внедрять CMM, используя стандарт в качестве руководства, которое может обеспечить постоянное совершенствование процесса разработки.

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

Таблица 2. Развитие стандартов CMM

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

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

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

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

Разрешить большинство проблем CMM призван новый стандарт SEI – Capability Maturity Model Integrated (CMMI) – Интегрированная модель оценки уровня зрелости процессов разработки. Стандарт CMMI изначально создавался таким образом, чтобы объединить существующие варианты CMM и исключить какие-либо противоречия при его практическом применении в различных сферах деятельности высокотехнологичных компаний.

Для того чтобы устранить необходимость «выравнивания» процессов организации и быть более приспособленным к ее бизнес-потребностям, а не наоборот, стандарт CMMI имеет две формы представления – классическую, многоуровневую, соответствующую CMM, и новую, непрерывную. Непрерывная форма представления рассматривает не уровни зрелости (Maturity Levels), а уровни возможностей (Capability Levels), которые оцениваются для отдельных областей процессов (Process Areas, PA). В табл. 3 дано соответствие уровней зрелости стандарта CMM, а также уровней зрелости многоуровневого представления CMMI и уровней возможностей непрерывного представления CMMI.

Таблица 3. Соответствие уровней CMM/CMMI

SEI отказывается от CMM и взамен активно продвигает CMMI, обещая ужесточить контроль за процессом сертификации, вводя новые классы, позволяющие сократить затраты на него и сделать его более привлекательным для небольших организаций; обеспечивая совместимость со стандартами ISO. Однако факт остается фактом: в современных условиях наличие сертификата определенного уровня CMM/CMMI не является таким значимым фактором, как несколько лет назад, и принимается без дополнительных вопросов разве что в проектах, выполняемых по государственному заказу.

Стандарты ISO

Стандарты ISO 9000 – обширная и наиболее распространенная во всем мире серия стандартов качества. Они охватывают множество отраслей современной индустрии и периодически обновляются.

Изначально стандарты ISO 9000 слабо учитывали специфику отрасли ПО и были больше ориентированы на производственную сферу. Однако в конце 1980-х годов в Великобритании был создан первый ориентированный на области разработки ПО стандарт, получивший название ISO 9000-3:1997. Несмотря на то, что ISO 9000-3 оперировал терминологией, которая используется при разработке ПО, и рассматривал характерные для программной индустрии вопросы, он являлся не более чем расширенным вариантом ISO 9001:1994, а потому не всегда соответствовал специфике программных проектов.

Сегодня на смену ISO 9000-3 пришел стандарт ISO/IEC 90003:2004, который, в свою очередь, является проекцией промышленного стандарта ISO 9001:2000 на программную индустрию. По сравнению с предыдущим он гораздо более приспособлен к специфике отрасли, в частности, ссылается на модели жизненного цикла программных систем и детально рассматривает вопросы, характерные для разработки ПО. Однако стандарт ISO 90003:2004 – это стандарт обеспечения качества и не может быть использован для оценки уровня зрелости и предсказания результата программного проекта. В таких случаях прибегают к стандарту ISO/IEC 15504. Стандарт ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания ПО. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI. Его текущая версия предусматривает шесть уровней возможностей (от нулевого до пятого), которые соответствуют уровням возможностей непрерывного представления стандарта CMMI (табл. 4).

Таблица 4. Уровни CMMI (2004)

Следует отметить, что в целом стандарты ISO/IEC 15504 и CMMI взаимозаменяемы, в частности, для CMMI предусматривается режим сертификации, в соответствии с которым одновременно проводится и сертификация по ISO/IEC 15504.

Качество программного продукта регламентирует стандарт ISO/IEC 9126, состоящий из отдельных частей, которые выпускаются независимо (на текущий момент их четыре: модель качества, внешние метрики, внутренние метрики и качество при использовании метрик). ISO/IEC 9126 предлагает комплексную иерархическую структуру для описания качественных характеристик ПО. Так, характеристиками качества наиболее высокого уровня являются функциональность, надежность, удобство применения, эффективность, сопровождаемость, переносимость. Каждая из них, в свою очередь, подразделяется на другие, более детальные. На текущий момент ISO/IEC 9126 – пожалуй, самый авторитетный стандарт, определяющий качество программного продукта.

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

Шесть сигм

Начало методологии шести сигм (Six Sigma) было положено в Motorola в конце 1980-х годов. Motorola провозгласила курс на повышение качества производимой продукции, одним из направлений которого было снижение количества дефектов до уровня 6σ (где σ – дисперсия) – 3,4 дефекта на миллион возможных (на самом деле 3,4 дефекта на миллион возможных означает не 6, а 4,5 сигмы, однако разработчики методологии добавили полторы сигмы для того, чтобы учесть нестабильность процессов). Подобное значение было избрано не случайно – в результате проведенных в компании исследований было установлено, что именно такой уровень качества обеспечит, кроме явных преимуществ в виде повышения конкурентоспособности продукции, также сокращение издержек за счет уменьшения затрат на доводку некачественных разработок и устранение дефектов.

Реализация шести сигм происходит в виде процесса DMAIC (Define, Measure, Analyze, Improve, Control):

- определение;

- измерение;

- анализ;

- совершенствование;

- управление.

Этот процесс построен на количественных методах принятия решений. Сильная сторона шести сигм – ориентация на интенсивное применение математического аппарата.

Несмотря на промышленное происхождение, методология шесть сигм получила популярность среди разработчиков ПО. Ориентация на количественные методы позволила применять шесть сигм как инструмент для обеспечения постоянного совершенствования процесса. Особенно заметно его преимущество при использовании в организациях, которые достигли высоких уровней зрелости в соответствии с CMM/CMMI и ISO/IEC 15504.

Недостатки:

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

2 Шесть сигм ориентирована на совершенствование процесса и не предусматривает изначального повышения показателей его эффективности. Для этих целей необходимы другие подходы.

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

ITIL

Весьма популярная в Европе методология ITIL (IT Infrastructure Library) ориентирована на обеспечение функционирования IT-инфраструктуры. ITIL разработана при участии правительства Великобритании в конце 80-х – начале 90-х годов XX в. и первоначально получила распространение в правительственных проектах этой страны.

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

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

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

Стандартизация ПС