Лекция 1 5

Вид материала

Лекция

Содержание 3. Характеристики качества и его цена 7 3.2. Цена качества 12 4.2. Качество процесса разработки 15 5.3. Метрики требований 18 6.2. Методология создания проектно-ориентированных метрик качества 21 7.2. Методы статистического анализа 23 Лекция 1 1. Введение 2. Понятие  качества и его многомерность 2.1. Понятие качества 2.2. Многомерность качества 3. Характеристики качества и его цена 3.1. Понятие характеристик качества 3.1.2. Дерево характеристик качества 3.1.3. Шкала измерения характеристик(ISO 12207) – введение в метрики 3.1.4. Пример графического изображения качества 3.2. Цена качества Лекция 2 4. Качество продукта, качество процесса и его измерение 4.1. Качество программного продукта 4.1.1. Представление пользователя 4.1.2. Представление разработчика 4.1.3. Представление руководителя 4.1.4. Оценка качества программного продукта 4.2. Качество процесса разработки ... Полное содержание

Подобный материал:

• «Социальная стратификация и социальная мобильность», 46.19kb.
• Первая лекция. Введение 6 Вторая лекция, 30.95kb.
• Лекция Сионизм в оценке Торы Лекция Государство Израиль испытание на прочность, 2876.59kb.
• Текст лекций н. О. Воскресенская Оглавление Лекция 1: Введение в дисциплину. Предмет, 1185.25kb.
• Собрание 8-511 13. 20 Лекция 2ч режимы работы эл оборудования Пушков ап 8-511 (ррэо), 73.36kb.
• Концепция тренажера уровня установки. Требования к тренажеру (лекция 3, стр. 2-5), 34.9kb.
• Лекция по физической культуре (15. 02.; 22. 02; 01. 03), Лекция по современным технологиям, 31.38kb.
• Тема Лекция, 34.13kb.
• Лекция посвящена определению термина «транскриптом», 219.05kb.
• А. И. Мицкевич Догматика Оглавление Введение Лекция, 2083.65kb.

Нижегородский государственный университет им. Н.И. Лобачевского

Факультет вычислительной математики и кибернетики ННГУ

Учебно-исследовательская лаборатория
"Математические и программные технологии для современных компьютерных систем (Информационные технологии)"


Метрики качества программного проекта


Разработчики: Гришин А.В.
Никонов С.Н.
Ионов А.А.


Куратор: Карпенко С.Н.


Нижний Новгород

2004 г.

Содержание

Лекция 1

1. Введение

Процессы разработки, приобретения и внедрения сложных систем, к которым относятся в частности программные комплексы, должны находится под жестким управленческим контролем. В настоящее время практически во всех организациях обеспечивается контроль важнейших характеристик, связанных с производством и использованием программных продуктов, таких как время, финансовые средства, ресурсы и т.п. Однако в большинстве случаев вне пределов сферы контроля оказывается наиболее важная характеристика программных продуктов, ради которой, собственно и осуществляются затраты времени, финансовых средств и ресурсов – это качество продукта, поскольку «невозможно контролировать то, что нельзя измерить» (“You cannot control what you cannot measure” ).

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

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

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

В данном документе представлен краткий обзор современных подходов к методам численного измерения качества программных систем.

2. Понятие  качества и его многомерность

2.1. Понятие качества

Сейчас существует несколько определений качества, которые в целом совместимы друг с другом. Приведем наиболее распространенные:

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

Определение IEEE: Качество программного обеспечения - это степень, в которой оно обладает требуемой комбинацией свойств.

2.2. Многомерность качества

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

ISQ- Information System Quality

Составляющие качества информационной системы:

• Качество инфраструктуры (infrastructure quality):  качество аппаратного и поддерживающего программного обеспечения (например, качество операционных систем, компьютерных сетей и т.п.).
  
• Качество программного обеспечения (software quality): качество программного обеспечения информационной системы.
  
• Качество данных (data quality): качество данных, использующихся информационной системой на входе.
  
• Качество информации (information quality): качество информации, продуцируемое информационной системой.
  
• Качество организации (administrative quality) – качество менеджмента, включая качество бюджетирования, планирования и календарного контроля.
  
• Качество сервиса (service quality) – качество обучения, системной поддержки и т.п.
  

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

Анализ всех составляющих качества должен проводится с учетом сфер ответственности заинтересованных сторон, как внутренних участников исполняемого процесса (in-process stakeholder), так и пользователей процесса (end-of-process stakeholders).

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

3. Характеристики качества и его цена

3.1. Понятие характеристик качества

3.1.1. Введение

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

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

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

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

3.1.2. Дерево характеристик качества

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

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

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

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



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

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

3.1.3. Шкала измерения характеристик(ISO 12207) – введение в метрики

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

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

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

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

Оценка защищенности программных средств включает определение полноты использования доступных методов и средств защиты программного средства от потенциальных угроз и достигнутой при этом безопасности функционирования информационной системы. Наиболее широко и детально методологические и системные задачи оценки комплексной защиты информационных систем изложены в трех частях стандарта ISO 15408:1999-1--3 "Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий".

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

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

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

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

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

3.1.4. Пример графического изображения качества

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


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

3.2. Цена качества

Понятие цены качества первоначально была введена Джураном (J.M. Juran) и Грином (F.M. Gryna) как стоимость в составе продукта, которая может быть сэкономлена, если все исполнители работают безупречно.

Цена качества – важная категория, поскольку фактически она отражает стоимость работ на доработку, увеличенную стоимость сопровождения.

Цена качества может быть разделена на два главных типа: согласованная (conformance)  и несогласованная (non-conformance).

Согласованная цена качества - это  сумма, затраченная на достижение качества продукта.  Она делится на цену предупреждения  (Prevention cost) и цену контроля (Appraisal cost). Затраты предупреждения связаны с предупреждением дефектов прежде чем они произойдут. При разработке ПО примером затрат предупреждения являются затраты на обучение коллектива базовым методологиям, переход на современные технологии разработки, использование автоматизированных средств проектирования и разработки.

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

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

Внутренние издержки связаны с проблемами, выявленными до того, как продукт отправлен заказчику. Для разработки программного обеспечения сюда включены затраты на переработку программ, повторную инспекцию и тестирование. Затраты связанные с ошибками, проявившимися при эксплуатации продукта у заказчика, относятся к внешним издержкам. Для программного обеспечения, например, сюда включены затраты на сопровождение и поддержку, убытки от простоев и некорректного функционирования.

Статистические исследования влияния процессов разработки на качество результирующего продукта показывают, что:

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

Лекция 2

4. Качество продукта, качество процесса и его измерение

4.1. Качество программного продукта

Качество программного продукта (soft­ware quality) — весь объем признаков и характеристик программ­ной продукции, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.

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

Важность каждой характеристики качества также меняется в зависимости от принятых точек зрения.

Рассмотрим различные представления о качестве программного обеспечения:

4.1.1. Представление пользователя

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

Пользователя могут интересовать следующие вопросы:

— Имеются ли требуемые функции в программном обеспече­нии?

— Насколько надежно программное обеспечение?

— Насколько эффективно программное обеспечение?

— Является ли программное обеспечение удобным для исполь­зования?

— Насколько просто переносится программное обеспечение и другую среду?

4.1.2. Представление разработчика

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

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

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

4.1.3. Представление руководителя

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

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

4.1.4. Оценка качества программного продукта

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

Рис. «Модель процесса оценивания»


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

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

Целью второй стадии является подготовка основы для оцени­вания.

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

4.2. Качество процесса разработки

4.2.1. Модель качества процесса

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




Рис. «Концептуальная модель качества процесса разработки»


Отсюда вытекают следующие следствия:

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

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

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

4.2.2. Измерение качества процесса

Идея качества процесса разработки программного обеспечения пришла в область информационных технологий из промышленности в ответ на программный кризис 60 –годов. Внедрение процессов обеспечения качества в программировании связано с работами таких экспертов по качеству как: Kaoru Ishikawa, Joseph M. Juran, Lennart Sandholm, W. Edwards Deming, Philip Crosby, - и реализует подход тотального управления качеством (TQM – Total Quality Management). Он заключается в том, что качество является неотъемлемой частью процесса, это реализовано в различных стандартах.

Наиболее широко известным и используемым стандартом для организации процессов контроля качества является серия стандартов ISO 9000. Для процесса разработки программ используется стандарт ISO 9001, предусматривающий проектирование в процессе производства. Следует отметить, что данный стандарт затруднительно использовать непосредственно в управлении качеством разработки программного обеспечения, поскольку изначально он ориентирован на разработку промышленных изделий. Специально для обеспечения процессов разработки программных систем организацией ISO, разработано руководство ISO 9000-3, которое формулирует требования модели качества ISO 9001 к организации процесса разработки программного обеспечения.

Таким образом, для оценки качества процесса разработки в собственной организации или в организации подрядчиков могут использоваться требования руководства ISO 9000-3. В настоящее время повсеместно вводится в использование версия стандарта 2000 года, в котором во главу угла ставится управление процессом, однако в данной версии стандарта специфика, связанная с разработкой ПО отсутствует.

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

5. Метрики менеджмента, метрики требований, метрики качества

5.1. Введение

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


При выборе метрик главными показателями являются:

• адекватность метрик целям качества,
  
• прозрачность и четкость интерпретации,
  
• экономическая эффективность получения.
  

5.2. Метрики менеджмента

• Цена (Cost) – расходы на приобретение/разработку
  
• Время разработки (Time-to-market)
  
• Среда разработки (Software Engineering Environment)
  
• Использование системных ресурсов (System Resource Utilization)
  

Указанные метрики могут использоваться на этапах планирования и контроля проектов и других задач управления или использоваться в качестве параметров управления штатной ERP системы.

Метрика «cost» измеряет общую цену, включая цену анализа рынка, приобретения, интеграции и улучшения качества.

Метрика «time-to-market» - мера времени от формирования заказа на программу до поставки. При итерационной разработке данная метрика модифицируется для измерения времени, требуемого для поставки заданного объема приращения функциональности, то есть скорости поставки.

Метрика «System resource utilization» - определяет процент целевых компьютерных ресурсов, используемых системой.

«Software engineering environment» - мера способности производителя разрабатывать программное обеспечение высокого качества.

5.3. Метрики требований

Как правило, единственным доступным механизмом определения «ожиданий заказчика» являются требования (software requirement specifications). Требования технического задания определяют функции программного обеспечения и нефункциональные требования, такие как производительность, надежность и т.п. Нетехнические требования, такие как цена, сроки поставки утверждаются в контрактных документах.

Сами метрики:

• Соответствие требованиям (requirement conformance)
  
• Стабильность требований (requirement stability)
  

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

5.4. Метрики качества

• Адаптируемость (adaptability)
  
• Сложность интерфейсов и интеграции (complexity of interfaces and integration)
  
• Тестовое покрытие (test coverage)
  
• Надежность (reliability)
  
• Профили ошибок (fault profiles)
  
• Степень удовлетворения потребностей заказчика (customer satisfaction)
  

«Adaptability» - мера гибкости системы, оценивает способность системы адаптироваться к изменениям требований либо перепроектированием системы, либо интеграцией приложений.

«Complexity of interfaces and integration» - метрика, измеряющая степень сложности интерфейса или дополнительного программирования требуемого для интеграции компоненты в систему, которые требуются для тестирования, отладки и сопровождения, компенсирующего потерю качества.

Метрики «test coverage»  указывают степень полноты различных типов тестирования.

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

«Fault profiles» - метрика, измеряющая кумулятивное число обнаруженных ошибок.

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

5.5. Метрики качества, выводимые из требований

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

К числу подобных метрик относится:

• Гибкость (flexability), которая аккумулирует ряд свойств:
  
  • Модульность (Modularity)
    
  • Изменяемость (Changeability)
    
  • Сопровождаемость (Maintainability)
    
• Адаптивность (adaptability), которая подразумевает:
  
  • Настраиваемость (customizability) 
    
  • Переносимость (Portability)
    
  • Способность к взаимодействию (Interoperability)
    

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

Исправления программного обеспечения может быть инициировано по следующим причинам:

• исправление программы с недостаточным уровнем качества (bug fixing),
  
• изменение программы для повышения уровня качества (enhancement),
  
• изменение программы для удовлетворения изменения в требованиях.
  

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


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

Лекция 3

6. Иерархизация метрик

6.1. Проектно-ориентированные метрики качества

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

Для обеспечения полноты измерения качества требуется  на ранних стадиях проекта на основе анализа целей проекта, области применения, ограничений и характеристик разработать проектно-ориентированные (design-oriented)
или структурные метрики (structural metrics) качества.

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

Термин «проектно-ориентированный» в данном контексте означает, что метрики разрабатываются в виде стандарта качества проекта на его ранних стадиях и представляют собой правила или нормы (guideline), которым должен удовлетворять промежуточный или конечный продукт. Термин «структурный» означает, что метрики разрабатываются структурным методом сверху - вниз (top – down) для обеспечения целостности и полноты.

6.2. Методология создания проектно-ориентированных метрик качества

Схематически методология создания метрик качества состоит из следующих шагов.

• Определение нетехнического уровня
  

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

• Формирование требований качества.
  
• Выбор свойств, установка приоритетов и связи с требованиями.
  
• Присвоение свойств факторам качества, которые отражают представление заказчика на качество.
  
• Установка измерений для факторов качества. Определение допустимых коридоров для величин качества.
  
  • Определение технического уровня
    

Второй шаг (средний уровень иерархии): Определение технического уровня (то есть уровня предназначенного для аналитиков, конструкторов, разработчиков).

• Осуществление декомпозиции факторов качества в измеряемые характеристики программного обеспечения, определяемые как субфакторы.
  

• Декомпозиция субфакторов в метрики
  

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

7. Статистический анализ

7.1. Статистический анализ

В стандарте ISO9000 отдельно выделяются

статистические методы обработки информации.

Статистические методы предназначены для

получения объективных данных, которые обеспечивают принятие эффективных решений при производстве.

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

7.1.1. Ручной сбор данных

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

7.1.2. Автоматический сбор данных.

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

Стандартный – это использование готовых датчиков от известных производителей.

Нестандартный способ – использование собственных АЦП или АЦП независимых и/или малоизвестных разработчиков. В этом случае работу по передаче данных в компьютер берут на себя драйвера вашего устройства, а SPC-программы либо импортируют файлы данных датчика, либо предоставляют драйверу информацию о СУБД данных по качеству.

7.2.3. Накопители данных.

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

7.2. Методы статистического анализа

7.2.1. Гистограмма

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


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

7.2.2. Диаграммы рассеивания

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




Положительная корреляция Отрицательная корреляция Нет корреляции

7.2.3. Контрольные карты

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

Существует четыре основных типа контрольных карт:

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

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

.

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

7.2.4. Диаграммы Парето

Диаграмма Парето - графическое представление степени важности факторов. Предназначена для определения немногочисленных существенно важных причин.

Диаграмма Парето различают:

• по результатам деятельности
  

Отражает нежелательные результаты в сферах качества, себестоимости, поставок, безопасности.

• по причинам
  

Отражает причины проблем по кадрам, оборудованию, методам работы.

Список используемой литературы

• Александр Попов «Метрики качества программного обеспечения», ссылка скрыта
  
• Владимир Липаев, «Сетевой журнал» №3.2002
  
• Владимир Липаев «Стандартизация характеристик и оценивания качества программных средств», ссылка скрыта
  
• Владимир Липаев «Сертификация систем качества предприятий, разрабатывающих программные средства для информационных систем, на соответствие стандартам серии ISO 9000», ссылка скрыта
  
• ГОСТ Р ИС09126 «Характеристики качества и руководства по их применению»
  
• Жарко Е.Ф. «Проблемы управления качеством программного обеспечения» ссылка скрыта
  
• Романов В.Ю. «Анализ программного обеспечения с использованием объектно-ориентированных метрик. Обзор метрик», ссылка скрыта
  

• ссылка скрыта
  
• ссылка скрыта