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

⇐ ПредыдущаяСтр 4 из 16Следующая ⇒

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ISO/IEC определяет три связанных модели качества программного обеспечения – внутреннее качество, внешнее качество и качество в процессе эксплуатации, а также набор соответствующих работ по оценке качества программного обеспечения (ISO/IEC 14598 [7, 8]).

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

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

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

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

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

Название стандарта	Описание
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
	–	–	Незавершенный
	Начальный	Начальный	Выполнимый
	Повторяющийся	Управляемый	Управляемый
	Определенный	Определенный	Определенный
	Управляемый	Управляемый количественно	Управляемый количественно
	Оптимизируемый	Оптимизируемый	Оптимизируемый

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

TickIT

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

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

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

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

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

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

Библиотека состоит из семи книг, в которых изложен комплекс вопросов по всем аспектам управления ИТ ресурсами предприятия [45]:

– Предоставление сервисов (Service Delivery) – содержит описание процессов, направленных на выявление требований заказчиков в качестве ИТ сервисов и согласование этих требований с возможностями информационной инфраструктуры.

– Поддержка сервисов (Service Support) – содержит описание процессов, направленных на обеспечение поддержки качества предоставления сервисов на согласованном с заказчиками уровне.

– Управление ИТ инфраструктурой (ICT Infrastructure Management) – описывает деятельность, связанную с организацией эффективного управления информационной и телеком-муникационной инфраструктурой, служащей основой для предоставления ИТ сервисов, включая функциональные области дизайна и планирования, разработки и внедрения, эксплуатации, поддержки.

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

– Управление безопасностью (Security Management) – детализирует подходы к планированию и управлению безопасностью информации и ИТ сервисов.

– Бизнес–перспектива (The Business Perspective) – описывает подходы к организации деятельности ИТ подразделений как бизнес–подразделений, охватывает вопросы организации взаимоотношений с потребителями и поставщиками, вопросы коммуникаций и обмена знаниями, согласования на стратегическом уровне потребностей бизнеса и возможностей ИТ.

– Планирование внедрения сервисного подхода (Planning to Implement Service Management) – содержит описание подходов к планированию, реализации и совершенствованию процессов управления ИТ сервисами в организациях.

Новая третья версия библиотеки ITIL сосредотачивается главным образом на ИТ-стратегии в рамках организации и на постоянном улучшении сервисов. Библиотека состоит из трёх частей: ядро (core), дополнительные книги (complementary) и интернет-часть (Web). Идеологическая часть ITIL® v3 - ядро - включает пять книг: по сервисной стратегии (service strategy), проектированию сервисов (service design), передаче сервисов (service transition), эксплуатации сервисов (service operation) и их постоянному улучшению (continual service improvement).

ITIL хорошо согласуется со стандартами серии ISO 9000 и может служить основой для проведения по ним последующей сертификации.

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

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

⇐ Предыдущая 1 2 345 6 7 8 9 10 Следующая ⇒