4.1.6Количественная оценка качества программного обеспечения

Если характеристики качества выбраны правильно, такие измерения могут поддержать качество (уровень качества) многими способами. Метрики могут помочь в управлении процессом принятия решений. Метрики могут способствовать поиску проблемных аспектов и узких мест в процессах. Метрики являются инструментом оценки качества своей работы самими инженерами – как в целях, определенных при управлении качеством, так и с точки зрения более долгосрочного процесса совершенствования качества [орлик].

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

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

• статистические методы (анализ Парето, нормальное распределение и т.п.);

• статистические тесты;

• анализ тенденций (сравнительный анализ);

• предсказание (модели надежности).

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

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

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

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

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

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

4.2.1Качество процессов

ISO/IEC определяет три связанных модели качества программного обеспечения (ISO 9126-01 Software Engineering - Product Quality, Part 1: Quality Model) – внутреннее качество, внешнее качество и качество в процессе эксплуатации, а также  набор соответствующих работ по оценке качества программного обеспечения (ISO 14598-98 Software Product Evaluation).

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

Существует два основных подхода в области качества программного обеспечения:

• Европейский подход TickIT, рассмотривающий общую системы менеджмента качества ISO 9001 в приложении к программным проектам и представленный, также, в виде специальных рекомендаций ISO 90003-04.

• Американский подход CMMI предоставляющий рекомендации по совершенствованию (повышению зрелости) отдельных процессов.

4.2.2CMM/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

Название стандарта	Описание
System Engineering CMM (SE-CMM)	Ориентирован на вопросы системного инжиниринга – разработку продуктов (анализ требований, проектирование систем продукта и их интеграция) и их производство (планирование производственных линий и функционирование)
Trusted CMM (T-CMM)	Предназначен для обслуживания чувствительных и закрытых программных систем, которые требуют гарантии высокого качества ПО
System Security Engineering CMM (SSE-CMM)	Сфокусирован на аспектах безопасности программной инженерии, обеспечивает безопасный процесс разработки, в том числе и безопасность членов команды создателей
People CMM (P-CMM)	Рассматривает вопросы развития персонала в софтверных организациях
Software Acquisition CMM (SA-CMM)	Охватывает вопросы приобретения программных продуктов у внешних организаций
Integrated Product Development CMM (IPD-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

№ уровня	Уровень зрелости CMM	Уровень зрелости многоуровневого представления CMMI	Уровень возможностей непрерывного представления CMMI
0	–	–	Незавершенный
1	Начальный	Начальный	Выполнимый
2	Повторяющийся	Управляемый	Управляемый
3	Определенный	Определенный	Определенный
4	Управляемый	Управляемый количественно	Управляемый количественно
5	Оптимизируемый	Оптимизируемый	Оптимизируемый

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

4.2.3TickIT

TickIT – схема сертификации систем менеджмента качества ИТ–компаний на основе стандартов ISO серии 9000, предложенная группой ведущих фирм и некоммерческих организаций Великобритании, работающих в области информатики.

Стандарты 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:2004. «Информационные технологии. Оценка процессов» (в 5 частях). Стандарт ISO/IEC 15504 предназначен для оценки процесса разработки информационных систем, в частности, программного обеспечения. Он изначально был спроектирован таким образом, чтобы в значительной степени соответствовать существующим в отрасли стандартам оценки процесса создания ПО. Именно это требование определило схожесть стандарта с основными принципами CMM/CMMI. Его текущая версия предусматривает шесть уровней возможностей (от нулевого до пятого), которые соответствуют уровням возможностей непрерывного представления стандарта CMMI (табл. 4).

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

№ уровня	Название уровня возможностей стандарта ISO/IEC 15504	Название уровня возможностей непрерывного представления CMMI
0	Незавершенный	Незавершенный
1	Выполнимый	Выполнимый
2	Управляемый	Управляемый
3	Установленный	Определенный
4	Предсказуемый	Управляемый количественно
5	Оптимизируемый	Оптимизируемый

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

Качество программного продукта регламентирует стандарт ISO/IEC 9126, состоящий из отдельных частей, которые выпускаются независимо. ISO/IEC 9126 предлагает комплексную иерархическую структуру для описания качественных характеристик ПО.

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