Размещено на http://www.allbest.ru/

Федеральное агентство по образованию Российской Федерации

ГОУ ВПО

«Челябинский государственный педагогический университет»

КАФЕДРА ИНФОРМАТИКИ И МЕТОДИКИ ПРЕПОДАВАНИЯ ИНФОРМАТИКИ

КРИТЕРИИ КАЧЕСТВА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Квалификационная работа

Руководитель: ст.п. кафедры

информатики и МПИ Боровская Е.В.

Автор работы: Студентка группы 591

Никитина Светлана Владимировна

Челябинск 2009

Содержание

Введение

1. Качество программного обеспечения

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

1.2 Стандарт ГОСТ Р ИСО МЭК 9126

1.2.1 Модель характеристик качества

1.2.2 Характеристики и атрибуты качества

1.3 Метрики

1.3.1 Основные направления применения метрик

1.3.2 Метрические шкалы

1.3.3 Метрики сложности программ

1.3.4 Объектно-ориентированные метрики

1.3.5 Метрики Холстеда

1.3.6 Метрики цикломатической сложности по Мак-Кейбу

1.3.7 Метрики Чепина

1.3.8 Размерно-ориентированные метрики (показатели оценки объема)

1.4 Альтернативные подходы к измерению качества

1.5 Оценка результата

1.5.1 Линейный подход

1.5.2 Оценка с использованием эмпирических данных

1.6 Методы контроля качества

1.7 Автоматизированные программные продукты по оценке качества ПО

1.7.1 Вычисление метрики SLOC

1.7.2 Вычисление метрик сложности

1.7.3 Оценки экономических параметров

Вывод по главе 1

2. Изучение темы критерии качества программного обеспечения

2.1 Анализ стандарта по профильному курсу информатики

2.2 Описание элективного курса «Критерии качества ПО»

2.4 Организация и проведение педагогического эксперимента

Вывод по главе 2

Заключение

Приложение

Библиографический список

Введение

программный обеспечение качество информатика

Когда вы можете измерить, то о чем вы говорите, и выразить это в числах, вы знаете кое-что об этом; но если вы не можете измерить это и выразить в числах, ваше знание скудно и неудовлетворительно.

Лорд Кельвин

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

Одним из подходов для оценки программных средств является оценка соответствующих атрибутов качества, определённых в серии международных стандартов ГОСТ Р ИСО МЭК 9126 «Информационная технология - Оценка программной продукции».

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

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

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

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

Объект исследования - методы определения качества ПО.

Предмет исследования - изучение технологий определения качества в школе.

Задачи исследования:

· рассмотреть основополагающие принципы качества;

· рассмотреть методы качества;

· выявить особенности работы методов;

· разработать учебную программу для элективного курса по теме: «Критерии качества программного обеспечения»

· создать программную поддержку курса, а именно практически реализовать критерии качества в Delphi.

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

1. Качество программного обеспечения

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

Что такое качество и почему оно должно быть столь глубоко представлено? На протяжении многих лет отдельные авторы и целые организации определяли термин “качество” по-разному. Фил Кросби (Phil Crosby) в 1979 году дал определение качеству как “соответствие пользовательским требованиям” (предполагает, что требования должны быть настолько четко определены, что они не могут быть поняты и интерпретированы некорректно.). Уотс Хемпфри (Watts Hamphrey) описывает качество как “достижение отличного уровня пригодности к использованию” (принимает во внимание требования и ожидания конечных пользователей продукта, которые ожидают, что продукт или предоставляемый сервис будет удобным для их нужд). Компания IBM, в свою очередь, ввела в оборот фразу “качество, управляемое рыночными потребностями” (“market-driven quality”). Критерий Бэлдриджа (Baldrige) для организационного качества использует похожую фразу - “качество, задаваемое потребителем” (“customer-driven quality”), рассматривая удовлетворение потребителя в качестве главного соображения в отношении качества. Чаще, понятие качества используется в соответствии с определением системы менеджмента качества ИСО 9001 как “степень соответствия присущих характеристик требованиям”.

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

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

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

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

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

Размещено на http://www.allbest.ru/

Рис. 1 Основные аспекты качества ПО

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

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

1.2 Стандарт ГОСТ Р ИСО МЭК 9126

ИСО 9126 это международный стандарт, определяющий оценочные характеристики качества программного обеспечения (далее ПО). [16-19]

Стандарт разделяется на 4 части, описывающие следующие вопросы:

Часть 1: Модель качества;

Часть 2: Внешние метрики качества;

Часть 3: Внутренние метрики качества;

Часть 4: Метрики качества в использовании.

В первой части стандарта ISO 9126-1 приводится схема взаимосвязи частей стандарта ISO 9126 и частей стандарта ISO 14598, а также область применения, нормативные ссылки, термины и определения. Определяется модель характеристик качества ПС и ее связи с жизненным циклом. Модель детализируется в последующих частях стандарта. [16]

Вторая и третья части стандарта ISO 9126:2,3 посвящены формализации соответственно внешних и внутренних метрик характеристик качества сложных ПС. Взаимосвязь метрик качества в этих частях стандарта отражена одинаковыми моделями, аналогичными модели первой части стандарта. Показано, что внутреннее и внешнее качества относятся непосредственно к самому программному продукту, а метрики качества в использовании проявляются в эффекте от его применения и зависят от внешней среды. Изложены содержание и общие рекомендации по использованию соответствующих метрик и взаимосвязей между типами метрик. [17, 18]

Четвертая часть стандарта ISO 9126-4 предназначена для покупателей, поставщиков, разработчиков, сопровождающих, пользователей и менеджеров качества ПС. В ней повторена концепция трех типов метрик, а также аннотированы рекомендуемые виды измерений характеристик ПС: прямые, непрямые и индикаторы свойств (категорийные). Рассмотрена модель качества в использовании. Отмечаются необходимость идентификации назначения и специфики потребителей программного продукта, особенности выбора целей оценивания качества для различных сфер и этапов применения ПС. Обосновываются и комментируются выделенные показатели сферы (контекста) использования ПС и группы выбранных метрик для пользователей. В отличие от характеристик, описанных в предыдущих частях стандарта, в этой части для качества в использовании рекомендуется четыре: эффективность; продуктивность; удовлетворение требований и защищенность. [19]

1.2.1 Модель характеристик качества

Модель качества, установленная в первой части стандарта ИСО 9162-1, предлагает использовать для описания внутреннего и внешнего качества ПО многоуровневую модель. На верхнем уровне выделено 6 основных характеристик качества ПО. Каждая характеристика описывается при помощи нескольких входящих в нее атрибутов. Атрибут - это сущность, которая может быть проверена или измерена в программном продукте. Для каждого атрибута определяется набор метрик, позволяющих его оценить. Множество характеристик и атрибутов качества согласно ИСО 9126 показано на рис 2. [5]



Рис. 2 Характеристики и атрибуты качества ПО по ИСО 9126

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

· внутренние атрибуты качества (требования к качеству кода и внутренней архитектуре);

· внешние атрибуты качества (требования к функциональным возможностям и т.д.);

· атрибуты «качества в использовании» (данные атрибуты качества относятся не только к программному средству, а ко всей информационной системе, они характеризуют эффект для пользователя от использования ПС в разных контекстах использования); [17]

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

Рис. 3 Основные аспекты качества ПО по ИСО 9126

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

Размещено на http://www.allbest.ru/

Рис. 4 Различные подходы к качеству ПС и соответствующим метрикам качества

Модель качества ПО имеет следующие четыре уровня представления:

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

· функциональность (functionality);

· надежность (realibility);

· удобство (usability);

· эффективность (efficiency);

· сопровождаемость (maitainnability);

· переносимость (portability).

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

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

Четвертый уровень - это оценочный элемент метрики (вес), который используется для оценки количественного или качественного значения отдельного атрибута показателя ПО. В зависимости от назначения, особенностей и условий сопровождения ПО выбираются наиболее важные характеристики качества и их атрибуты (рис. 5). [1, 2, 4]

Выбранные атрибуты и их приоритеты отражаются в требованиях на разработку систем либо используется соответствующие приоритеты эталона класса ПО, к которому это ПО относится.

Рис. 5 Модель характеристик качества

1.2.2 Характеристики и атрибуты качества

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

o Функциональность (functionality) - Способность ПО в определенных условиях решать задачи, нужные пользователям. Определяет, что именно делает ПО, какие задачи оно решает.

· Функциональная пригодность (suitability). - Способность решать нужный набор задач.

· Точность (accuracy). - Способность выдавать нужные результаты.

· Способность к взаимодействию (interoperability). - Способность взаимодействовать с нужным набором других систем.

· Соответствие стандартам и правилам (compliance). - Соответствие ПО имеющимся индустриальным стандартам, нормативным и законодательным актам, другим регулирующим нормам.

· Защищенность (security). - Способность предотвращать неавторизированный, т.е. без указания лица, пытающегося его осуществить, и неразрешенный доступ к данным и программам.

o Надежность (reliability). - Способность ПО поддерживать определенную работоспособность в заданных условиях.

· Зрелость, завершенность (maturity). - Величина, обратная частоте отказов ПО. Обычно измеряется средним временем работы без сбоев и величиной, обратной вероятности возникновения отказа за данный период времени.

· Устойчивость к отказам (fault tolerance). - Способность поддерживать заданный уровень работоспособности при отказах и нарушениях правил взаимодействия с окружением.

· Способность к восстановлению (recoverability). - Способность восстанавливать определенный уровень работоспособности и целостность данных после отказа, необходимые для этого время и ресурсы.

· Соответствие стандартам надежности (reliability compliance). - Этот атрибут добавлен в 2001 году.

o Удобство применения (usability) или практичность. - Способность ПО быть удобным в обучении и использовании, а также привлекательным для пользователей.

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

· Удобство обучения (learn ability). - Показатель, обратный усилиям, затрачиваемым пользователями на обучение работе с ПО.

· Удобство работы (operability). - Показатель, обратный усилиям, предпринимаемым пользователями для решения своих задач с помощью ПО.

· Привлекательность (attractiveness). - Способность ПО быть привлекательным для пользователей. Этот атрибут добавлен в 2001 году.

· Соответствие стандартам удобства использования (usability compliance). - Этот атрибут добавлен в 2001 году.

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

· Временная эффективность (time behavior). - Способность ПО выдавать ожидаемые результаты, а также обеспечивать передачу необходимого объема данных за отведенное время.

· Эффективность использования ресурсов (resource utilization). - Способность решать нужные задачи с использованием определенных объемов ресурсов определенных видов. Имеются в виду такие ресурсы, как оперативная и долговременная память, сетевые соединения, устройства ввода и вывода и пр.

· Соответствие стандартам производительности (efficiency compliance). - Этот атрибут добавлен в 2001 году.

o Удобство сопровождения (maintainability). - Удобство проведения всех видов деятельности, связанных с сопровождение программ.

· Анализируемость (analyzability) или удобство проведения анализа. - Удобство проведения анализа ошибок, дефектов и недостатков, а также удобство анализа необходимости изменений и их возможных последствий.

· Удобство внесения изменений (changeability). - Показатель, обратный трудозатратам на выполнение необходимых изменений.

· Стабильность (stability). - Показатель, обратный риску возникновения неожиданных эффектов при внесении необходимых изменений.

· Удобство проверки (testability). - Показатель, обратный трудозатратам на проведение тестирования и других видов проверки того, что внесенные изменения привели к нужным результатам.

· Соответствие стандартам удобства сопровождения (maintainability compliance). - Этот атрибут добавлен в 2001 году.

o Переносимость (portability). - Способность ПО сохранять работоспособность при переносе из одного окружения в другое, включая организационные, аппаратные и программные аспекты окружения.

· Адаптируемость (adaptability). - Способность ПО приспосабливаться различным окружениям без проведения для этого действий, помимо заранее предусмотренных.

· Удобство установки (install ability). - Способность ПО быть установленным или развернутым в определенном окружении.

· Способность к сосуществованию (coexistence). - Способность ПО сосуществовать с другими программами в общем окружении, деля с ними ресурсы.

· Удобство замены (replace ability) другого ПО данным. - Возможность применения данного ПО вместо других программных систем для решения тех же задач в определенном окружении.

· Соответствие стандартам переносимости (portability compliance). - Этот атрибут добавлен в 2001 году.

Перечисленные атрибуты относятся к внутреннему и внешнему качеству ПО согласно ИСО 9126. Для описания качества ПО при использовании стандарт ИСО 9126-4 предлагает другой, более узкий набор характеристик.

o Эффективность (effectiveness). - Способность ПО предоставлять пользователям возможность решать их задачи с необходимой точностью при использовании в заданном контексте.

o Продуктивность (productivity). - Способность ПО предоставлять пользователям определенные результаты в рамках ожидаемых затрат ресурсов.

o Безопасность (safety). - Способность ПО обеспечивать необходимо низкий уровень риска нанесения ущерба жизни и здоровью людей, бизнесу, собственности или окружающей среде.

o Удовлетворение пользователей (satisfaction). - Способность ПО приносить удовлетворение пользователям при использовании в заданном контексте.

Помимо перечисленных характеристик и атрибутов качества, стандарт ИСО 9126:2001 определяет наборы метрик для оценки каждого атрибута. Приведем следующие примеры таких метрик.

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

· Корректность реализации функций - правильность их реализации по отношению к требованиям. Используется для измерения функциональной пригодности.

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

· Отношение числа проведенных тестов к общему их числу. Используется для определения зрелости.

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

· Наглядность и полнота документации. Используется для оценки понятности.

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

o Что ПО должно делать, например:

· позволять клиенту оформить заказы и обеспечить их доставку;

· обеспечивать контроль качества строительства и отслеживать проблемные места;

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

o Насколько оно должно быть надежно, например:

· работать 7 дней в неделю и 24 часа в сутки;

· допускается неработоспособность в течение не более 3 часов в год;

· никакие введенные пользователями данные при отказе не должны теряться.

o Насколько им должно быть удобно пользоваться, например:

· покупатель должен, зная название товара и имея средние навыки работы в Интернет, находить нужный ему товар за не более чем 2 минуты;

· инженер по специальности "строительство мостов" должен в течение одного дня уметь разобраться в 80% функций системы.

o Насколько оно должно быть эффективно, например:

· поддерживать обслуживание до 10000 запросов в секунду;

· время отклика на запрос при максимальной загрузке не должно превышать 3 с;

· время реакции на изменение параметров процесса производства не должно превышать 0.1 с;

· на обработку одного запроса не должно тратиться более 1 MB оперативной памяти.

o Насколько удобно должно быть его сопровождение, например:

· добавление в систему нового вида запросов не должно требовать более 3 человеко-дней;

· добавление поддержки нового этапа процесса производства не должно стоить более $20000.

o Насколько оно должно быть переносимо, например:

· ПО должно работать на операционных системах Linux, Windows XP и MacOS X;

· ПО должно работать с документами в форматах MS Word 97 и HTML;

· ПО должно сохранять файлы отчетов в форматах MS Word 2000, MS Excel 2000, HTML, RTF и в виде обычного текста;

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

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

1.3 Метрики

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

Система измерения включает метрики и модели измерений, которые используются для количественной оценки качества ПО.

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

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

Метрика качества программ - система измерений качества программ. Эти измерения могут проводиться на уровне критериев качества программ или на уровне отдельных характеристик качества. В первом случае система измерений позволяет непосредственно сравнивать программы по качеству. При этом сами измерения не могут быть проведены без субъективных оценок свойств программ. Во втором случае измерения характеристик можно выполнить объективно и достоверно, но оценка качества ПО в целом будет связана с субъективной интерпретацией получаемых оценок. [3, 12]

В исследовании метрик ПО различают два основных направления:

· поиск метрик, характеризующих наиболее специфические свойства программ, т.е. метрик оценки самого ПО;

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

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

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

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

· метрики, по которым принимается решение о соответствии конечного ПО заданным требованиям. Они позволяют оценить соответствие разработки заданным требованиям.

Существует три типа метрик:

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

· метрики процесса, которые используются при измерении свойства процесса ЖЦ создания продукта.

· метрики использования.

Метрики программного продукта включают:

· внешние метрики, обозначающие свойства продукта, видимые пользователю;

· внутренние метрики, обозначающие свойства, видимые только команде разработчиков.

Внешние метрики продукта - это метрики:

· надежности продукта, которые служат для определения числа дефектов;

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

· сопровождения, с помощью которых измеряются ресурсы продукта (скорость, память, среда);применимости продукта, которые способствуют определению степени доступности для изучения и использования;

· стоимости, которыми определяется стоимость созданного продукта.

Внутренние метрики продукта включают:

· метрики размера, необходимые для измерения продукта с помощью его внутренних характеристик;

· метрики сложности, необходимые для определения сложности продукта;

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

Внутренние метрики позволяют определить производительность продукта и являются релевантными по отношению к внешним метрикам.

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

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

· требований;

· сценариев и действующих лиц;

· объектов, включенных в сценарий, и локализация требований к каждому сценарию;

· параметров и операций объекта и др.

Стандарт ISO/IEC 9126-2 определяет следующие типы мер:

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

· мера времени (функционирования системы, выполнения компонента и др.);

· мера усилий (производительность труда, трудоемкость и др.);

· мера учета (количество ошибок, число отказов, ответов системы и др.).

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

· общее число объектов и число повторно используемых;

· общее число операций, повторно используемых и новых операций;

· число классов, наследующих специфические операции;

· число классов, от которых зависит данный класс;

· число пользователей класса или операций и др.

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

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

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

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

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

· общее время разработки и отдельно время для каждой стадии;

· время модификации моделей;

· время выполнения работ на процессе;

· число найденных ошибок при инспектировании;

· стоимость проверки качества;

· стоимость процесса разработки.

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

1.3.1 Основные направления применения метрик

В настоящее время в мировой практике используется несколько сотен метрик программ. Существующие качественные оценки программ можно сгруппировать по шести направлениям:

· оценки топологической и информационной сложности программ;

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

· оценки производительности ПО и повышения его эффективности путем выявления ошибок проектирования;

· оценки уровня языковых средств и их применения;

· оценки трудности восприятия и понимания программных текстов, ориентированные на психологические факторы, существенные для сопровождения и модификации программ;

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

1.3.2 Метрические шкалы

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

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

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

· Интервальной шкале соответствуют метрики, которые показывают не только относительное положение программ, но и то, как далеко они отстоят друг от друга.

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

· Абсолютная шкала указывает на фактическое значение величины (например, число ошибок в программе равно 10).

1.3.3 Метрики сложности программ

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

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

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

· метрики размера программ

· метрики сложности потока управления программ

· и метрики сложности потока данных программ

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

Метрики второй группы базируются на анализе управляющего графа программы. Представителем данной группы является метрика Мак-Кейба.

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

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

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

Таблица 1

Метрики

Название модели	Формула, обозначение
1	2
МЕТРИКИ СЛОЖНОСТИ
Метрики Холстеда - длина программы; - объем программы - оценка ее реализации; - трудность ее понимания; - трудоемкость кодирования; - уровень языка выражения; - информационное содержание; - оптимальная модульность;	N = n1 log1 n1 + n2 log2 n2 V = N log2 n L*= (2 n2 )/ (n1 N2) Ec = V/ L* D = (n1N2) (2n2) = 1/ L* л * = V/ D2 = V/ L* 2 I = V / D M = n2*/6
Метрики Джилба - количество операторов цикла;	L1oop
- количество операторов условия; - число модулей или подсистем; - отношение числа связей между модулями к числу модулей; - отношение числа ненормальных выходов из множества операторов к общему числу операторов;	L IF L mod f = N4SV / L mod f * = N*SV / L
Метрики Мак-Кейба- цикломатическое число; - цикломатическая сложность;	л (G) = m - n + p н (G) = л (G) +1 = m - n + 2
Метрика Чепена - мера трудности понимания программ на основе входных и выходных данных;	H = 0.5T+P+2M+3C
Метрика Шнадевида - число путей в управляющем графе	S = У Pi Ci
Метрика Майерса - интервальная мера;	[н 1 ? н 2]
Метрика Хансена - пара (цикломатическое число, число операторов)	{ н, N}
Метрика Чена - топологическая мера Чена;	M(G) = (н (G), N, Q0)
Метрика Вудворда - узловая мера (число узлов передач управления);	? ?
Метрика Кулика - нормальное число (число	Norm (P)
простейших циклов в нормальной схеме программы);
Метрика Хура - цикломатическое число сети Петри, отражающей управляющую структуру программы;	? (G*р)
Метрики Витворфа, Зулевского -мера сложности потока управления -мера сложности потока данных;	? (Р) ? (Р)
Метрика Петерсона - число многовходовых циклов;	Nm 1 0 0 p
Метрики Харрисона, Мэйджела - функциональное число (сумма приведенных сложностей всех вершин управляющего графа); - функциональное отношение (отношение числа вершин графа к функциональному числу); - регулярные выражения (число операндов, операторов и скобок в регулярном выражении управляющего графа программы);	f1 = ? ? 1 f* = N ?1 / f1 p(G) = N + L + Sk
Метрика Пивоварского - модифицированная цикломатическая мера сложности;	N(G) = n*(G) + ? Pi
Метрика Пратта - тестирующая мера;	Test (Pr)
Метрика Кантоне - характеристические числа полиномов, описывающих	PCN*
управляющий граф программы;
Метрика Мак-Клура - мера сложности, основанная на числе возможных путей выполнения программы, числе управляющих конструкций и переменных;	C(V) = D(V) ??J(V) / N
Метрика Кафура - мера на основе концепции информационных потоков;	I(G)
Метрика Схуттса, Моханти - энтропийные меры;	? (G)
Метрика Коллофело - мера логической стабильности программ;	h (G)
Метрика Зольновского, Симмонса, Тейера Взвешенная сумма различных индикаторов: - (структура, взаимодействие, объем, данные); - (сложность интерфейса, вычислительная сложность, сложность ввода/вывода, читабельность);
Метрика Берлингера - информационная мера;	I(R) = m (F* (R) ??F-(R))2
Метрика Шумана - сложность с позиции статистической теории языка;	?????
Метрика Янгера - логическая сложность с учетом истории вычислений; Сложность проектирования Насыщенность комментариями Число внешних обращений Число операторов	Cc = ? log2 (i + 1) [? n Cxy (n)] X = K/C Ci L1
ПРОГНОЗ МОДЕЛИ
Модели Холстеда - прогноз системных ресурсов; - прогноз числа ошибок. Модель фирмы IBM Модель общей сложности Модели связности Сплайн-модель	P=3/8 (Ra - 1) ? 2Ra B = Nlog2 n / 3000 B = 23M1 + M1 0 B = 21.1 + 0.1 V + COMP (S) Pij = 0.15 (Si + Sj) + 0.7 Cij Pij = Ѕ ??? i (? Zij2 + ? Nij2 ) ln (? Zij2 + ? Nij2 ) + ? + ? Zi + ? N1
ОЦЕНОЧНЫЕ МОДЕЛИ
Джелински - Моранды	R(t) = e - (Т - 1 + 1) ?t
Вейса-Байеса	R1(t) = ? ?e-l - (i-1) ?)t ?(?, F/t1,..., ti-1) d? dФ
Шика-Волвертона	R1(t) = e - F( N - 1 + 1) ti2 / 2
Литтлвуда	R1 (t) = (b+?/b+? +?)-??(N - i + 1) a
Нельсона	Rj (t) = exp { ?ln (1 - Pj)}
Халецкого	Rj (t) = P?- a(1- ? nj ) / nj
Модель отлаженности	Rj (t) =P?- ? fj (?? ????)
Мозаичная модель	Rj (t) = 1 - ?( ?????j - 1)

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

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

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

Первой топологической мерой сложности является цикломатическая мера Мак-Кейба. В ее основе лежит идея оценки сложности ПО по числу базисных путей в ее управляющем графе, т.е. таких путей, компонуя которые можно получить всевозможные пути из входа графа в выходы. Цикломатическое число ?(G) орграфа G с n-вершинами, m-дугами и p-компонентами связности есть величина ?(G) = m - n + p. Практически цикломатическая сложность ПО равна числу предикатов плюс единица, что позволяет вычислять ее без построения управляющего графа простым подсчетом предикатов. Данная мера отражает психологическую сложность ПО.

Дж. Майерс предложил в качестве меры сложности интервал [? _{1 ?} ? ₂], где ? 1- цикломатическая мера, а ??2 - число отдельных условий плюс единица. При этом, оператор DO считается за одно условие, а CASE c n - исходами за n-1- условий. Введенная мера получила название интервальной мерой.

У. Хансену принадлежит идея брать в качестве меры сложности ПО пару (цикломатической число, число операторов). Известна топологическая мера Z(G), чувствительная к структурированности ПО. При этом, она Z(G) = V(G) (равна цикломатической сложности) для структурированных программ и Z(G) > V(G) для неструктурированных. К вариантам цикломатической меры сложности относят также меру М(G) = (V(G),C,Q), где С - количество условий, необходимых для покрытия управляющего графа минимальным числом маршрутов, а Q - степень связности структуры графа программы и ее протяженность.

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

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

Мера Пивоварского ставит целью учесть в оценке сложности ПО различия не только между последовательными и вложенными управляющими конструкциями, но и между структурированными и неструктурированными программами. Она выражается отношением N(G) = ??*(G) + ? P_i, где ? ^*(G) - модифицированная цикломатическая сложность, вычисленная так же, как и V(G), но с одним отличием: оператор CASE с n- выходами рассматривается как один логический оператор, а не как n-1 операторов. Р_i - глубина вложенности i - той предикатной вершины.

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

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

Тестирующей мерой М называется мера сложности, удовлетворяющая следующим условиям:

1. Мера сложности простого оператора равна 1;

2. М ({F1; F2; -;Fn}) = е_iⁿ M(Fi);

3. М (if P then F1 else F2) = 2 MAX (M (F1), M (F2));

4. М (while P do F) = 2 M(F).

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

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

Топологическая мера Чена выражает сложность программы числа пересечений границ между областями, образуемыми блок - схемой программы. Этот подход применим только к структурированным программам, допускающим лишь последовательное соединение управляющих конструкций. Для неструктурированных программ мера Чена существенно зависит от условных и безусловных переходов. В этом случае можно указать верхнюю и нижнюю границы меры. Верхняя - есть m+1, где m - число логических операторов при их гнездовой вложенности. Нижняя - равна 2. Когда управляющий граф программы имеет только одну компоненту связности, мера Чена совпадает с цикломатической мерой Мак-Кейба.

...