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

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

ГОУ ВПО

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

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

РАБОТА ПРОВЕРЕНА Рецензент ……………. /Лебедева Т.Н./ « …. » ……………….. 2009 г.

ДОПУСТИТЬ К ЗАЩИТЕ Заведующий кафедрой …………….. /Леонова Е. А./ « …. » ……………… 2009 г.

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

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

Руководитель: ст.п. кафедры информатики и МПИ …………… / Боровская Е.В./ « …. » …………….…. 2009 г.

Автор работы: Студентка группы 591 Никитина Светлана Владимировна Работа защищена с оценкой ……………………… « …. » ……………….. 2009 г.

Челябинск

2009

СОДЕРЖАНИЕ

Введение. 3

ГЛАВА 1. Качество программного обеспечения. 6

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

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

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

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

1.3 Метрики. 19

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение. 94

Приложение. 95

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

Введение

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

Лорд Кельвин

Требования к качеству программных средств всё время повышаются. Процессы разработки, приобретения и внедрения сложных систем, к которым относятся в частности программные комплексы, должны находится под жестким управленческим контролем. В настоящее время практически во всех организациях обеспечивается контроль важнейших характеристик, связанных с производством и использованием программных продуктов, таких как время, финансовые средства, ресурсы и т.п. Однако в большинстве случаев вне пределов сферы контроля оказывается наиболее важная характеристика программных продуктов, ради которой, собственно и осуществляются затраты времени, финансовых средств и ресурсов - это качество продукта, поскольку «невозможно контролировать то, что нельзя измерить» (“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).

Рис. 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).

Рис. 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 = (n1 N2 ) (2n2 ) = 1/ L* λ * = V/ D2 = V/ L* 2 I = V / D M = n2 * /6
Метрики Джилба - количество операторов цикла;	L1oop
Продолжение таблицы 1
1	2
- количество операторов условия; - число модулей или подсистем; - отношение числа связей между модулями к числу модулей; - отношение числа ненормальных выходов из множества операторов к общему числу операторов;	L IF L mod f = N4 SV / 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 )
Метрика Вудворда - узловая мера (число узлов передач управления);	Y x
Метрика Кулика - нормальное число (число	Norm (P)
Продолжение таблицы 1
1	2
простейших циклов в нормальной схеме программы);
Метрика Хура - цикломатическое число сети Петри, отражающей управляющую структуру программы;	l (G* р )
Метрики Витворфа, Зулевского -мера сложности потока управления -мера сложности потока данных;	g (Р) W (Р)
Метрика Петерсона - число многовходовых циклов;	Nm 1 0 0 p
Метрики Харрисона, Мэйджела - функциональное число (сумма приведенных сложностей всех вершин управляющего графа); - функциональное отношение (отношение числа вершин графа к функциональному числу); - регулярные выражения (число операндов, операторов и скобок в регулярном выражении управляющего графа программы);	f1 = S c 1 f* = N c1 / f1 p(G) = N + L + Sk
Метрика Пивоварского - модифицированная цикломатическая мера сложности;	N(G) = n* (G) + S Pi
Метрика Пратта - тестирующая мера;	Test (Pr)
Продолжение таблицы 1
1	2
Метрика Кантоне - характеристические числа полиномов, описывающих	PCN*
управляющий граф программы;
Метрика Мак-Клура - мера сложности, основанная на числе возможных путей выполнения программы, числе управляющих конструкций и переменных;	C(V) = D(V) ´ J(V) / N
Метрика Кафура - мера на основе концепции информационных потоков;	I(G)
Метрика Схуттса, Моханти - энтропийные меры;	e (G)
Метрика Коллофело - мера логической стабильности программ;	h (G)
Метрика Зольновского, Симмонса, Тейера Взвешенная сумма различных индикаторов: - (структура, взаимодействие, объем, данные); - (сложность интерфейса, вычислительная сложность, сложность ввода/вывода, читабельность);	å (a , b , g , n ) å (c , C , u , p )
Продолжение таблицы 1
1	2
Метрика Берлингера - информационная мера;	I(R) = m (F* (R) ´ F- (R))2
Метрика Шумана - сложность с позиции статистической теории языка;	X (Y)
Метрика Янгера - логическая сложность с учетом истории вычислений; Сложность проектирования Насыщенность комментариями Число внешних обращений Число операторов	L ( w ) 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 = ½ å l i (D Zij 2 + D Nij 2 ) ln (D Zij 2 + D Nij 2 ) + a + b Zi + g N1
ОЦЕНОЧНЫЕ МОДЕЛИ
Джелински - Моранды	R(t) = e - (Т - 1 + 1) F t
Вейса-Байеса	R1 (t) = ò òe- l - ( i -1) F ) t Y(l, F/t1 , ..., ti -1 ) dl dФ
Шика-Волвертона	R1 (t) = e - F( N - 1 + 1) t i 2 / 2
Литтлвуда	R1 (t) = (b+ t/b+ t + t)- F (N - i + 1) a
Нельсона	Rj (t) = exp { åln (1 - Pj )}
Халецкого	Rj (t) = Pµ- a(1- g nj ) / nj
Окончание таблицы 1
1	2
Модель отлаженности	Rj (t) =Pµ- r fj (t, l ,p)
Мозаичная модель	Rj (t) = 1 - b( a - wj - 1 )

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

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

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

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

Дж. Майерс предложил в качестве меры сложности интервал [n 1
¸
n 2
], где n 1- цикломатическая мера, а n 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) = n *(G) + S Pi
, где n *
(G) - модифицированная цикломатическая сложность, вычисленная так же, как и V(G), но с одним отличием: оператор CASE с n- выходами рассматривается как один логический оператор, а не как n-1 операторов. Рi
- глубина вложенности i - той предикатной вершины.

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

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

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

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

2. М ({F1; F2; ┘;Fn}) = еi
n
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. Когда управляющий граф программы имеет только одну компоненту связности, мера Чена совпадает с цикломатической мерой Мак-Кейба.

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

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

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

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

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

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

Таблица 2

Метрика	Описание
1	2
Взвешенная насыщенность класса 1 (Weighted Methods Per Class (WMC))	Отражает относительную меру сложности класса на основе цикломатической сложности каждого его метода. Класс с более сложными методами и большим количеством методов считается более сложным. При вычислении метрики родительские классы не учитываются.
Взвешенная насыщенность	Мера сложности класса, основанная на том, что класс с большим числом методов, является более сложным, и что
Окончание таблицы 2
1	2
класса 2 (Weighted Methods Per Class (WMC2))	метод с большим количеством параметров также является более сложным. При вычислении метрики родительские классы не учитываются.
Глубина дерева наследования (Depth of inheritance tree)	Длина самого длинного пути наследования, заканчивающегося на данном модуле. Чем глубже дерево наследования модуля, тем может оказаться сложнее предсказать его поведение. С другой стороны, увеличение глубины даёт больший потенциал повторного использования данным модулем поведения, определённого для классов-предков.
Количество детей (Number of children)	Число модулей, непосредственно наследующих данный модуль. Большие значения этой метрики указывают на широкие возможности повторного использования; при этом слишком большое значение может свидетельствовать о плохо выбранной абстракции.
Связность объектов (Coupling between objects)	Количество модулей, связанных с данным модулем в роли клиента или поставщика. Чрезмерная связность говорит о слабости модульной инкапсуляции и может препятствовать повторному использованию кода.
Отклик на класс (Response For Class)	Количество методов, которые могут вызываться экземплярами класса; вычисляется как сумма количества локальных методов, так и количества удаленных методов

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

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

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

· NUOprtr (Number of Unique Operators) — число уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов);

· NUOprnd (Number of Unique Operands) — число уникальных операндов программы (словарь операндов);

· Noprtr (Number of Operators) — общее число операторов в программе;

· Noprnd (Number of Operands) — общее число операндов в программе.

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

n1 - количество различных операторов программы;

n2 - количество различных операндов программы;

N1 - общее количество операторов программы;

N2 - общее количество операндов программы.

На их основе Холстед определяет следующие метрики:

· словарь программы (в условных единицах)

n = n1+n2, (1)

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

n*
= n1*
+ n2*

· длина программы (в условных единицах)

N = N1+N2 (2)

· теоретическая длина программы (в условных единицах)

Ñ = (n1 ´ log2
n1)+(n2´log2
´ n2), (3)

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

Несовершенствами можно считать следующие ситуации:

o последующая операция уничтожает результаты предыдущей без их использования;

o присутствуют тождественные выражения, решающие совершенно одинаковые задачи;

o одной и той же переменной назначаются различные имена и т. п.

Подобные ситуации приводят к изменению N без изменения n.

Холстед утверждает, что для стилистически корректных программ отклонение в оценке теоретической длины Ñ от реальной N не превышает 10%.

Предлагается использовать Ñ как эталонное значение длины программы со словарем n. Длина корректно составленной программы N, т. е. программы, свободной от избыточности и имеющей словарь n, не должна отклоняться от теоретической длины программы Ñ более чем на 10%. Таким образом, измеряя n1, n2, N1 и N2 и сопоставляя значения N и Ñ для некоторой программы, при более чем 10%-ном отклонении можно говорить о наличии в программе стилистических ошибок, т. е. несовершенств.

На практике N и Ñ часто существенно различаются.

· объем программы (в битах, определение объема программы предполагает, что обозначение операндов и операторов требует не более одного символа).

V = N´ log2
(n) (4)

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

V*
= n*
´ log2
n*
(5)

где n2* - общее число входных и выходных параметров.

· уровень качества программы (в условных единицах, если n2*=2)

L = V*
/ V (6)

Исходным для введения этой характеристики является предположение о том, что при снижении стилистического качества программирования уменьшается содержательная нагрузка на каждый компонент программы и, как следствие, расширяется объем реализации исходного алгоритма. Учитывая это, можно оценить качество программирования на основании степени расширения текста относительно потенциального объема V*. Очевидно, для идеальной программы L=1, а для реальной - всегда L<1.

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

L*
= 2 ´ n2 / (n1 ´ N2)

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

l=L ´ V*
(7)

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

I=L*
´ V (8)

Преобразуя выражение (8) с учетом (6), получаем

I = L*
´ V = L´V = V*
´V/V = V*
.

Эквивалентность I и V* свидетельствует о том, что мы имеем дело с характеристикой информативности программы.

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

1) осмысление предложения известного алгоритма;

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

Используя эту формализацию в методике Холстеда, можно сказать, что написание программы по заранее известному алгоритму есть N^-кратная выборка операторов и операндов из словаря программы n, причем число сравнений (по аналогии с алгоритмами сортировки) составит log2(n).

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

· оценка интеллектуальных усилий (в условных единицах)

E = N*
´ log2
(n / L) (9)

E характеризует число требуемых элементарных решений при написании программы.

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

Суть интерпретации этой характеристики состоит в оценке не затрат на разработку программы, а затрат на восприятие готовой программы. При этом вместо теоретической длины программы N*
используется ее реальная длина:

E*
= N ´ log2
(n / L)

Характеристика E*
введена, исходя из предположения, что интеллектуальные усилия на написание и восприятие программы очень близки по своей природе. Однако если при написании программы стилистические погрешности в тексте практически не должны отражаться на интеллектуальной трудоемкости процесса, то при попытке понять такую программу их присутствие может привести к серьезным осложнениям. Эта посылка достаточно хорошо согласуется с нашими выводами относительно взаимосвязи N и N^, изложенными выше.

Преобразуя формулу (9) с учетом выражений (4) и (6), получаем

E = V ´ V / V*

Такое представление E', а соответственно и E, так как E=E', наглядно иллюстрирует целесообразность разбиения программ на отдельные модули, поскольку интеллектуальные затраты оказываются пропорциональными квадрату объема программы, который всегда больше суммы квадратов объемов отдельных модулей.

· время на программирование (в условных единицах)

T = E/S, (10)

или Т@(n1´N2´log2n´(n1´log2n1+n2´log2n2))/(2´n2´S), (11)

где S - число Страуда (5<S<20).

Число Страуда Холстед принял равным 18 - число умственных операций в единицу времени.

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

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

Число Страуда S определяется как число «страудовских моментов» в секунду. «Страудовский момент» - это время, необходимое человеку для выполнения элементарного различения объектов, подобно различению кадров фильма. Страуд обнаружил, что человек способен различать от 5 до 20 объектов в секунду.

Уровень программы L£1 характеризует эффективность реализации алгоритма относительно затрат памяти. Только для наиболее сжатой формы реализации алгоритма (V=V*) уровень программы имеет значение 1. Всем другим вариантам реализации соответствуют значения L<1.

Интеллектуальное содержание характеризует меру «сказанного» в программе, или ее «информативность». Интеллектуальное содержание (уровень) программы сильно коррелирует с потенциальным объемом (L»V*) и тоже не зависит от языка реализации.

Работа по программированию (уравнение мысленной работы) характеризует величину умственной работы, связанной с написанием программного кода. Так как сумма квадратов двух величин всегда меньше квадрата их суммы, уравнение работы дает основание для разбиения программы на составные части - модули. Модульность снижает работу по программированию. Исследования возможностей оперативного мышления человека дают основания считать, что наиболее продуктивна ситуация, при которой для получения одного результата используется не более пяти объектов. В прикладном отношении этот результат называют гипотезой о «шести объектах». Для определения количества модулей M в программе Холстед рекомендует использовать выражение

M= n2*/6, (12)

где n2* - общее количество входных и выходных переменных в программе.

Из уравнения работы получено следующее уравнение ошибок в программе

B=L´E/E0, (13)

где В - количество ошибок в программе,

Е0 - среднее число элементарных отличий между возможными ошибками программирования.

Используя преобразованное уравнение работы

Е= (V*)3/l2, (14)

значение уровня английского языка (l=2,16) в качестве аналога языка программирования и гипотезу о «шести объектах» идеальной по затратам памяти программы (n1=n1*=2, n2=n2*=6), Холстед вывел следующее уравнение для прогноза количества ошибок в программе:

В=Е 2/3 /3000, (15)

или

В=V/3000, (16)

где V - объем программы.

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

1. Наличие последовательности дополняющих друг друга операторов к одному и тому же операнду, например, А+C-А.

2. Наличие неоднозначных операндов, например, A=D и A=С.

3. Наличие синонимичных операндов, например, А=В и Т=В.

4. Наличие общих подвыражений, например (А+В)´С+D´(А+В).

5. Ненужное присваивание, например С=А+В, если переменная С используется в программе только один раз.

6. Наличие выражений, которые не представлены в свернутом виде как произведение множителей, например X´X+2´X´Y+Y´Y не представлено как (X+Y)´(X+Y).

7. Длину реализации N (2) можно использовать для прогноза числа фактических машинных команд P с помощью выражения

(17)

или более грубо, с помощью неравенства

2´P£ N £ 4´P. (18)

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

Уровень программы 0<L£1 можно использовать для оценки сложности вариантов реализации заданного алгоритма D (чем меньше затрат памяти, тем сложнее вариант программы):

(19)

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

L ´ V = V*
= const. (20)

Вместе с тем, если язык не меняется, а меняется только алгоритм, то для любого языка произведение потенциального объема на уровень программы остается постоянной величиной, равной уровню языка [14]

L ´ V = l = const. (21)

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

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

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

Для вычисления цикломатического числа Мак-Кейба l(G) применяется формула:

l(G) = m - n + 2p,

где m - число дуг ориентированного графа G;

n - число вершин;

p - число компонентов связности графа.

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

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

Упрощенная формула вычисления цикломатической сложности представляется следующим образом:

l(G) = m - n + 2

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

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

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

В физическом смысле цикломатическое число для каждой дуги m=(v, u)| mÎM графа управления первая вершина (v) является исходной, а вторая (u) – конечной. Путь от одной вершины к другой вершине графа, если он состоит более чем из одной дуги, описывают последовательностью вершин соответствующих дуг (v, а,…, u) так, что исходная вершина будет первой в перечислении, а конечная – последней. Контур – это плоскость, ограниченная циклическим путем, в котором начальная и конечная вершина графа совпадают. Каждому контуру соответствует ограничивающий его путь, ведущий из начальной вершины графа в конечную.

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

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

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

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

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

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

Рассмотрим пример. Пусть имеется программа, которая считывает из входного потока символы до тех пор, пока не будет обнаружен символ «#». Текст программы на языке Паскаль представлен на рис 6. Соответствующий граф управления программы показан на рис 7.

Рис 6. Программа ввода данных

Для представления программы в виде графа требуются определенные соглашения о том, что считать узлом графа, так как синтаксис операторов в языках программирования довольно разнообразен. При этом обычно учитывают только исполнимые операторы, исключая операторы описания данных. Желательно подобрать такие синтаксические формы операторов, которые в наибольшей степени подходят для отображения узлом графа. Линейные участки программы можно заменить одним узлом графа. В этом отношении использование схем алгоритмов или описание программ на псевдокоде может оказаться даже более предпочтительной формой описания программы, чем текст на языке программирования. В любом случае желательно преобразовать операторы цикла в эквивалентную последовательность операторов ветвления, добавив, при необходимости, операторы суммирования (счетчики) числа повторений цикла с «верхним» или «нижним» окончанием.

Рис 7. Граф управления программы ввода данных

Рис 8. Преобразование графа управления программы ввода данных в полносвязный граф

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

l(G)=5-5+2=2

Программа организации ввода данных, имеющая граф управления с цикломатическим числом, равным 2, не обладает излишней сложностью и для ее тестирования достаточно подобрать два теста, покрывающие ветви (а, b, с) и (а, u) (рис 4). Заметим, что вершины v и а графа управления программы можно объединить, что не приведет к изменению цикломатического числа. Цикломатическое число зависит только от количества управляющих операторов, содержащих условные выражения (предикаты). При этом сложность предиката не учитывается. Если в операторе цикла while программы организации ввода данных (рис 4) усложнить условное выражение (предикат), изменив заголовок

while(s<>'#') на while(s<>'#' or s<>'*') граф управления и цикломатическое число останутся прежними.

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

M=u+1,

где u – количество операторов ветвления.

При необходимости операторы выбора или переключения с n ветвями, можно рассматривать как n операторов ветвления.

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

Модификации показателя цикломатической сложности:

· «Модифицированная» цикломатическая сложность - рассматривает не каждое ветвление оператора множественного выбора (switch), а весь оператор как единое целое.

· «Строгая» цикломатическая сложность - включает логические операторы.

· «Упрощенная» вычисление цикломатической сложности - предусматривает вычисление не на основе графа, а на основе подсчета управляющих операторов.

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

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

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

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

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

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

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

2. Множество «М» - модифицируемые или создаваемые внутри программы переменные.

3. Множество «C» - переменные, участвующие в управлении работой программного модуля (управляющие переменные).

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

Далее вводится значение метрики Чепина:

Q = a1P + a2M + a3C + a4T

где a1, a2, a3, a4 - весовые коэффициенты.

Весовые коэффициенты использованы для отражения различного влияния на сложность программы каждой функциональной группы. По мнению автора метрики наибольший вес, равный трем, имеет функциональная группа С, так как она влияет на поток управления программы. Весовые коэффициенты остальных групп распределяются следующим образом: a1=1; a2=2; a4=0.5. Весовой коэффициент группы T не равен нулю, поскольку “паразитные” переменные не увеличивают сложности потока данных программы, но иногда затрудняют ее понимание. С учетом весовых коэффициентов выражение примет вид:

Q = P + 2M + 3C + 0.5T.

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

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Самой распространенной метрикой исходного кода ПО, отражающей размер программного проекта, является показатель количества строк кода (Source Lines Of Code, SLOC). [6, 7]

1.3.8.1 SLOC -
оценка
(Source Lines Of Code)

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

показателя SLOC:

· количество «физических» SLOC (используемые аббревиатуры: LOC, SLOC, KLOC, KSLOC, DSLOC) – определяется как общее число строк исходного кода, включая комментарии и пустые строки (при измерении показателя на число пустых строк, как правило, вводится ограничение – учитывается их количество, которое не превышает 25% общего числа строк в измеряемом блоке кода);

· количество «логических» SLOC (используемые аббревиатуры: LSI, DSI, KDSI, где SI – Source Instructions) – определяется как число команд и зависит от используемого языка программирования. В том случае, если язык не допускает размещения на одной строке нескольких команд, количество «логических» SLOC будет соответствовать числу «физических» за исключением пустых строк и строк комментариев. Если же язык программирования поддерживает размещение нескольких команд на одной строке, то одна «физическая» строка должна быть учтена как несколько «логических», если она содержит более одной команды языка.

Литера «D» (Delivered) означает «поставленный» код, т. е. только вошедший в законченный программный продукт. Очень часто возникает необходимость учитывать не только поставленный код, но и вспомогательный или промежуточный, который не входит в законченный продукт, но нужен для реализации проекта и требует определенных затрат труда.

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

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

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

· оценка показателя SLOC «снизу-вверх» экспертным методом. Этой методикой предусмотрено разбиение проекта на иерархическую структуру задач (Work Breakdown Structure, WBS), на основании которых производится экспертная оценка показателя, в итоге суммируемая для всего проекта. Как правило, экспертами предоставляются три оценки (наиболее вероятная, максимальная и минимальная), а далее они усредняются с помощью бета - распределения (рассчитывается сумма минимальной, максимальной и четырехкратной наиболее вероятной оценок, которая затем делится на шесть).

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

· число пустых строк (Blank Lines Of Code, BLOC);

· число строк, содержащих комментарии (Comment Lines Of Code, CLOC);

· число строк, содержащих исходный код и комментарии (Lines with Both Code and Comments, C&SLOC);

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

· число строк, содержащих императивный исходный код;

· процент комментариев (число строк комментариев, умноженное на 100 и деленное на число строк кода);

· среднее число строк для функций (методов);

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

· среднее число строк для модулей;

· среднее число строк для классов.

Также наряду со SLOC применяются другие показатели, отражающие количественную оценку отдельных составляющих проекта: число модулей, функций / методов, классов, страниц документации и пр. Однако помимо метрик, подсчитывающих число элементов проекта, к метрикам размера следует отнести также функциональные точки (Function Points, FP), их производные и разновидности, вычисляемые на базе не исходного кода, а пользовательских требований, спецификаций, описаний прецедентов (например, точки прецедентов, Use Case Points, UCP) и пр. В большинстве случаев главное предназначение этой группы метрик, независимо от способа их вычисления, состоит в том, чтобы оценить объем работ по проекту, и, соответственно, быть основой для таких показателей, как стоимость и длительность его реализации.

Потенциальные недостатки SLOC, на которые нацелена критика:

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

· Метрика не учитывает опыт сотрудников и их другие качества

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

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

И главное помнить: метрика SLOC не отражает трудоемкости по созданию программы.

1.3.8.2 Метрика стилистики и понятности программ

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

Fi = SIGN (Nкомм. i / Ni - 0,1)

Суть метрики проста: код разбивается на n-равные куски и для каждого из них определяется Fi [5]

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

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

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

· Легко использовать.

· Хорошая производительность.

· Нет ошибок.

· Не портит пользовательские данные при сбоях.

· Можно использовать на разных платформах.

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

· Легко добавлять новые возможности.

· Удовлетворяет потребности пользователей.

· Хорошо документировано.

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

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

Что делает программу высококачественной
:

Шломи Фиш (Shlomi Fish) проанализировал факторы определяющие высокое качество программного обеспечения:

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

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

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

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

· Программа должна иметь качественную веб-страницу, где легко найти всю необходимую информацию.

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

· Должны быть легко доступны готовые собранные пакеты или должно быть легко их собрать.

· Программа должна быть хорошо документирована.

· Программа должна быть переносимой (работать на как можно большем количестве распространенных платформ).

· Высококачественная программа должна быть безопасна - это означает что должно быть немного проблем с безопасностью и баги должны исправляться быстро.

· При выходе новых версий должна сохраняться совместимость со старыми.

· Высококачественная программа имеет хорошие пути поддержки пользователей - почтовые рассылки, IRC, техподдержку по email, форумы, wiki.

· Программа должна быть быстрой и не должна потреблять много ресурсов.

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

Как сделать программу высококачественной?

· Код программы должен быть модульным и хорошо написанным.

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

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

· Релизы должны быть частыми.

· Управление проектом должно быть объективным и дальновидным.

· Слишком навязчивая реклама вредна, и совершенно недопустима неправдивая реклама.

· И последнее: хорошее название программы важно.

Качество ПО по МакКолу

Первой широко известной моделью качества ПО стала предложенная в 1977 МакКолом.

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

· Факторы (factors), описывающие ПО с позиций пользователя и задаваемые требованиями.

· Критерии (criteria), описывающие ПО с позиций разработчика и задаваемые как цели.

· Метрики (metrics), используемые для количественного описания и измерения качества.

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

Рис. 9. Треугольник МакКола.

Критерии качества - это числовые уровни факторов, поставленные в качестве целей при разработке.

Объективно оценить или измерить факторы качества непосредственно довольно трудно. Поэтому, МакКол ввел метрики качества, которые с его точки зрения легче измерять и оценивать. Оценки в его шкале принимают значения от 0 до 10. Вот эти метрики качества:

· Удобство проверки на соответствие стандартам (auditability)

· Точность управления и вычислений (accuracy)

· Степень стандартности интерфейсов (communication commonality)

· Функциональная полнота (completeness)

· Однородность используемых правил проектирования и документации (consistency)

· Степень стандартности форматов данных (data commonality)

· Устойчивость к ошибкам (error tolerance)

· Эффективность работы (execution efficiency)

· Расширяемость (expandability)

· Широта области потенциального использования (generality)

· Независимость от аппаратной платформы (hardware independence)

· Полнота протоколирования ошибок и других событий (instrumentation)

· Модульность (modularity)

· Удобство работы (operability)

· Защищенность (security)

· Самодокументированность (selfdocumentation)

· Простота работы (simplicity)

· Независимость от программной платформы (software system independence)

· Возможность соотнесения проекта с требованиями (traceability)

· Удобство обучения (training)

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

Качество ПО по Боему

В 1978 Боем предложил свою модель, по существу представляющую собой расширение модели МакКола.

Атрибуты качества подразделяются по способу использования ПО (primary use).

Определено 19 промежуточных атрибутов (intermediate construct), включающих все 11 факторов качества по МакКолу. Промежуточные атрибуты разделяются на примитивные (primitive construct), которые, в свою очередь, могут быть оценены на основе метрик.

В дополнение к факторам МакКола атрибуты качества по Боему включают следующие: ясность (clarity), удобство внесения изменений (modifiability), документированность (documentation), способность к восстановлению функций (resilience), понятность (understandability), адекватность (validity), функциональность (functionality), универсальность (generality), экономическая эффективность (economy). [13]

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

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

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

В простейшем случае определить стоимость разработки ПО можно исходя из количественной оценки трудозатрат Т (в неких единицах, например человеко-месяцах или человеко-часах) и их удельной стоимости Ц:

С = Т × Ц.

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

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

Т = Р × П,

где Р - размер исходного кода ПО; П - временная производительность.

Эта примитивная формула активно применяется и по сей день, хотя ее несостоятельность была установлена довольно давно. Пожалуй, самой известной работой, в которой критикуется данный подход, является выдержавшая более двадцати изданий по-настоящему классическая книга Фредерика Брукса (Frederick Brooks) «Мифический человеко-месяц, или Как создаются программные системы», впервые увидевшая свет еще в 1977 г.

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

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

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

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

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

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

Вероятно, первой нелинейной моделью, использующей эмпирические данные и нашедшей практическое применение при оценке стоимости ПО, стала SLIM (Software Life-cycle Model), предложенная в 1978 г. Лоуренсом Патнамом (Lawrence Putnam). Согласно ей трудоемкость вычисляется по следующей формуле:

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

SLIM была создана на базе реальных данных, собранных в Министерстве обороны США, и ориентирована в первую очередь на крупные проекты. Несмотря на возможность калибровки модели на основе хронологической информации, что несколько повышает качество результатов, она не приобрела широкой популярности, хотя существуют организации, успешно использующие ее в проектном менеджменте и сегодня (qsm.com).

COCOMO
. Пожалуй, самой популярной моделью для оценки стоимости разработки ПО, которая стала стандартом, является COCOMO (COnstructive COst MOdel). Она была представлена в 1981 г. Барри Боэмом (Barry Boehm), известным ученым, внесшим огромный вклад в развитие научных подходов к управлению программными проектами - им разработаны спиральная модель проектирования ПО и Wideband Delphi, кроме того, когда-то именно он предсказал, что в будущем стоимость ПО превысит стоимость оборудования.

COCOMO создана на основе анализа статистических данных 63 проектов различных типов. Фактически под общим названием скрываются три уровня детализации: базовый, промежуточный и подробный. Также предусмотрено три режима использования модели в зависимости от размеров команды и проекта (табл. 1).

Режимы модели COCOMO

Таблица 3.

Название режима	Размер проекта	Описание
Органичный	До 50 KLOC	Некрупный проект разрабатывается небольшой командой, для которой нехарактерны нововведения, и среда остается стабильной
Сблокированный	50 - 300 KLOC	Относительно небольшая команда занимается проектом среднего размера, в процессе разработки необходимы определенные инновации, среда характеризуется незначительной нестабильностью
Внедренный	Более 300 KLOC	Большая команда разработчиков трудится над крупным проектом, необходим значительный объем инноваций, среда состоит из множества элементов, которые не характеризуются стабильностью

Для оценки трудозатрат на базовом уровне модели COCOMO применяется следующая формула:

Т = a × Р b,

где a и b - константы, которые зависят от режима использования модели.

В соответствии с этой формулой трудозатраты вообще нелинейно зависят от размера проекта и скачкообразно изменяются при смене режима (табл. 2). Другая интересная особенность COCOMO - рост трудозатрат при переходе к более высокому режиму не означает безусловного увеличения длительности (F) выполнения проекта, которая вычисляется по формуле:

F = 2,5 × Т k,

поскольку при этом изменяется значение константы k.

Значения коэффициентов модели COCOMO в зависимости от режима использования

Таблица 4

Название режима	Значение коэффициента a	Значение коэффициента b	Значение коэффициента k
Органичный	2,4	1,05	0,38
Сблокированный	3,0	1,12	0,35
Внедренный	3,6	1,20	0,32

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

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

При построении COCOMO II для обработки статистических данных использовался Байесовский анализ, который дает лучшие результаты для программных проектов, характеризующихся неполнотой и неоднозначностью, в отличие от многофакторного регрессионного, примененного в COCOMO. Также в ней допускается измерять размер проекта не только числом строк кода, но и более современными функциональными и объектными точками. Помимо прочего, при расчете показателей COCOMO II учитывает уровень зрелости процесса разработки в соответствии с моделями SEI CMM/CMMI.

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

Модель COCOMO II фактически объединяет три различные подмодели

Таблица 5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Locmetrics
- очень простой бесплатный продукт с минималистским интерфейсом. В числе поддерживаемых языков - C/C++, C#, Java, SQL - возможно вычисление не только метрики SLOC и ее разновидностей, но и цикломатической сложности. Отсутствие документации не является препятствием для использования программы, поскольку разобраться в интерфейсе из двух кнопок и двух полей ввода совсем несложно. Хуже, что нет даже описания методики расчета метрик. К недостаткам также следует отнести отсутствие хотя бы самых простых средств построения отчетности или экспорта данных в один из популярных форматов.

USC
Codecount
- бесплатный продукт с открытыми исходными кодами на языке ANSI C, разработанный Университетом Южной Калифорнии (University of Southern California, USC) - той же организацией, в которой были созданы COCOMO/COCOMO II. По этой причине USC Codecount является официальным инструментом для подсчета метрики SLOC при использовании указанных моделей. В число поддерживаемых языков входят C/C++, C#, Java, JavaScript, SQL, Perl, XML, в документации указано, что методика расчета соответствует принятой SEI для моделей CMM/CMMI.

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

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

SLOCCount
- бесплатный продукт, разработанный Дэвидом Вилером (David A. Wheeler), поставляется в виде исходных кодов на языке C по лицензии GNU GPL. Ориентирован на UNIX-платформы, хотя возможно применение и в Windows после соответствующей адаптации.

Среди рассматриваемых это, пожалуй, наиболее универсальный инструмент - в число поддерживаемых языков входят Ada, Assembler, awk, Bourne shell (включая производные: bash, ksh, zsh, pdksh), C, C++, C#, C shell (включая tcsh), COBOL, Expect, Fortran (включая Fortran 90), Haskell, Java, lex (включая flex), LISP (включая Scheme), make-файлы, Modula3, Objective-C, Pascal, Perl, PHP, Python, Ruby, sed, SQL, TCL, Yacc.

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

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

Code
Counter
Pro
- единственный коммерческий продукт, попавший в нашем обзоре в данную категорию. Впрочем, он совсем недорог ($25 за одну лицензию), зато в отличие от предыдущих имеет развитый графический интерфейс, что, безусловно, делает его использование более удобным.

Поддерживаются следующие языки программирования: Java, JSP, C/C++, VB, PHP, HTML, Delphi/Pascal, ASM, XML, COBOL, есть возможность декларировать новые.

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

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

Verisoft
Complexity
Measures
Tool
- коммерческий продукт с достаточно внушительной ценой в 1200 евро. Поддерживаются только языки C/C++ и Java (поставляется в виде двух различных редакций).

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

Borland Together - коммерческий инструмент UML-моделирования, дополненный возможностями вычисления метрик исходного кода. Цена зависит от редакции (начиная с $200).

Поддерживается обширное число различных метрик, значительная часть которых - объект-но-ориентированные: SLOC, количественные метрики классов (число атрибутов, классов, конструкторов, операций), цикломатическая сложность, метрики сложности классов (LOCOM1, LOCOM2, LOCOM3, WMPC1, WMPC2, NORM), метрики связности, Холстеда, наследования, полиморфизма, процентные соотношения (доля комментариев, приватных, публичных и защищенных членов классов), максимальные значения (уровня вложенности, числа параметров и операций).

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

Вычисляет SLOC, количественные метрики классов, цикломатическую сложность, метрики сложности классов (LOCOM1, LOCOM2, LOCOM3, WMPC, NORM, индекс специализации), метрики связности, уровень абстракции и некоторые другие.

Достаточно функциональный продукт, который вполне может дать фору многим коммерческим аналогам. [3]

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

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

Duvessa Estimate Easy UC
- пример довольно простого коммерческого продукта с невысокой ценой ($40-90 в зависимости от редакции). Программа предназначена для оценки трудоемкости реализации проекта на основе прецедентов. Работа с программой заключается в регистрации составляющих UML-модели: прецедентов и акторов (участников), для которых необходимо указать параметры сложности и число форм и отчетов (для прецедентов). Поддерживается возможность импорта требуемой информации из форматов Rational Rose, Rational XDE, Rational Requisite Pro, Microsoft Visio и XML. Помимо вычисления объема проекта в скорректированных точках прецедентов (UCP) и трудоемкости в человеко-часах, программа производит автоматическое преобразование количества UCP в число объектных точек (OP) и затем выполняет еще одну оценку трудоемкости реализации проекта в соответствии с композиционной прикладной моделью методики COCOMO II.

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

USC COCOMO Tool
- официальный инструмент от создателей методики COCOMO II, поставляется бесплатно. Поддерживаются две модели COCOMO II: ранней разработки проекта и постархитектурная.

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

Результаты работы программы могут быть экспортированы в формат CSV, а затем импортированы в Microsoft Excel для дальнейшей обработки - с этой целью в комплекте поставляется дополнительный инструмент COCOMO Import & Analyze Tool. Сама же программа умеет строить только итоговый отчет.

SoftStar
Systems
Costar
- один из наиболее популярных коммерческих инструментов класса Software Estimation, основанный на методиках COCOMO/COCOMO II и их различных модификациях (на текущий момент поддерживается 10 вариантов, допускается регистрировать новые). При этом программа имеет весьма серьезную цену - от 1900 до 25 000 долл. в зависимости от редакции.

Так же, как и USC COCOMO Tool, Costar охватывает только две модели COCOMO II: ранней разработки проекта и постархитектурную. Однако в остальном Costar гораздо функциональнее, в частности, поддерживает несколько различных моделей жизненного цикла программного проекта (в том числе REVIC, не предусмотренную оригинальными COCOMO/COCOMO II), инкрементную разработку компонентов (можно учитывать до двадцати итераций), обеспечивает подготовку полноценных отчетов (свыше двадцати видов) и их экспорт в различные форматы. Для тонкой настройки и калибровки моделей предоставляется отдельная программа Calico.

Construx
Estimate
- бесплатный продукт от компании Construx Software, созданной очень авторитетной личностью в сфере программной инженерии и управления программными проектами - Стивом МакКонеллом (Steve McConell), который среди прочего был признан в 1998 г. одним из трех самых влиятельных людей в софтверной индустрии (наряду с Биллом Гейтсом и Линусом Торвальдсом).

Программа Construx Estimate построена на двух методиках оценки характеристик проекта - SLIM и COCOMO II, а ее уникальность состоит в том, что обе они применяются совместно. SLIM является основной и обеспечивает оценки стоимости выполнения проекта, графика работ, требуемого персонала и вероятного количества дефектов. COCOMO II используется в качестве дополнительной и служит для уточнения оценок при вычислении затрат. В зависимости от типа проекта определяется базовая оценка производительности, которая затем корректируется в соответствии с COCOMO II.

Программе необходимо передать такие данные, как тип и подтип проекта (бизнес-системы, управляющие системы, интернет-системы, системное ПО и пр.), текущая фаза, дата начала фазы проектирования, ограничения и приоритеты отдельных параметров, приблизительный объем (в виде SLOC, FP, числа функций/процедур, классов/модулей, подсистем), используемый язык программирования. В результате будет получена оценка по методу Монте-Карло с распределением 50/50 - т. е. вероятности переоценки и недооценки проекта будут равны 50%. Затем позволяется проводить анализ по сценариям «что-если?». На заключительном этапе программа формирует готовый к печати многостраничный отчет, содержащий исчерпывающую информацию о характеристиках проекта.

С помощью Construx Estimate можно последовательно повышать точность оценки как в «тактическом» плане (т. е. в процессе реализации конкретного проекта), так и в «стратегическом» (за счет наработки опыта по выполнению многих проектов).

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

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

Borland
CaliberRM
Estimate
Professional
- коммерческий аналог программы Construx Estimate, изначально выпускаемый компанией Software Productivity Center под названием Estimate Professional. В 2004 г. данный продукт был приобретен корпорацией Borland и включен в поставку комплексного ПО для управления требованиями CaliberRM (в качестве отдельного продукта не предлагается), цена которого - от $2000.

По своей идее и принципам работы данный продукт очень похож на бесплатный аналог (полностью совпадают даже целые разделы документации). Различия касаются главным образом более удобного интерфейса, повышенной гибкости в формировании и настройке отчетности, числа примеров оценки, входящих в комплект поставки, а также интеграции с CaliberRM. Пожалуй, самое принципиальное преимущество инструмента от Borland - возможность выбора одного из двух типов оценки: на основе объема проекта или трудоемкости (Construx Estimate предусматривает только первый вариант).

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

В идеале необходимо использовать несколько инструментов, основанных на разных методиках, комбинировать и анализировать результаты, находить причины отклонений в оценках и сравнивать их с показателями, получаемыми на практике. Однако при калибровке желательно не попадать под ложное влияние больших чисел: информация о пяти своих проектах наверняка окажется гораздо полезнее для качественных оценок, чем «сборная солянка» из пяти тысяч проектов, выполненных различными компаниями в разных отраслях в разное время. [6]

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

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

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

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

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

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

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

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

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

В «Стандарте среднего (полного) общего образования по информатике и ИКТ. Профильный уровень» среди целей изучения информатики и информационно-коммуникационных технологий на профильном уровне названы в том числе:

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

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

· развитие
алгоритмического мышления, способностей к формализации, элементов системного мышления;

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

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

В разделе «Обязательный минимум содержания основных образовательных программ» базовые понятия информатики и информационных технологий в пункте «Информация и информационные процессы» упоминаются:

Системы
, компоненты, состояние и взаимодействие компонентов. Информационное взаимодействие в системе, управление, обратная связь.

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

Логика и алгоритмы. Высказывания, логические операции, кванторы, истинность высказывания. Цепочки (конечные последовательности), деревья, списки, графы,
матрицы (массивы), псевдослучайные последовательности.

Язык программирования. Типы данных
. Основные конструкции языка программирования. Система программирования. Основные этапы разработки программ. Разбиение задачи на подзадачи.

В пункте «Информационная деятельность человека» упоминаются:

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

Экономика информационной сферы. Стоимостные характеристики информационной деятельности
.

В пункте «Средства ИКТ» упоминаются:

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

В пункте «Обработка числовой информации» упоминаются:

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

В разделе «Требования к уровню подготовки выпускников» сказано, что результате изучения информатики и ИКТ на профильном уровне ученик должен:

знать/понимать:

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

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

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

· нормы информационной этики и права, информационной безопасности, принципы обеспечения информационной безопасности;

уметь

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

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

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

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

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

· соблюдения требований информационной безопасности, информационной этики и права

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

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

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

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

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

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

Основными задачами курса являются:

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

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

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

· научить оценивать программное обеспечение помощью метрик, критериев и характеристик качества.

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

Исходя из задач курса определено содержание, которое представлено в тематическом планировании курса (Таблица 6).

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

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

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

Требование к уровню подготовки учащихся

После изучения курса учащиеся должны

знать/понимать

- сущность понятия ”Качество”

- виды критериев качества

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

уметь

- осуществлять моделирование с помощью графов;

- организовать автоматизированный доступ к файлу и провести его анализ качества;

- определять качество программ.

Уровни овладения компетенциями (для учащихся).

1. Ученик имеет представление о качестве, критериях, методах анализа ПО.

2. Ученик понимает принципы анализа качества. Строит модели на основе графов.

3. Ученик умеет создавать программу для определения качества ПО.

Тематическое планирование

Таблица 6

№	Тема	Всего часов	Теория	Практика
1	Качество ПО. Понятие качества ПО.	1	1
2	Стандарт. Модель качества. Характеристики и атрибуты качества.	2	1	1
3	Метрики, их применение, метрические шкалы.	1	1
4	Метрики сложности	2	1/2	1+1/2
5	Метрика Холстеда	1	1/2	1/2
6	Граф. Построение графа.	1	1/2	1/2
7	Метрика Мак-Кейба	2	1/2	1+1/2
8	Итоговый контроль	2	2
Всего:		12	5	7

Поурочное планирование

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

Урок 1.
Качество ПО. Понятие качества ПО.

Тип урока:
урок усвоения новых знаний и умений.

Цели:

1. Дать представление о качестве программного обеспечения, высококачественной программе, стандартах.

2. Дать определение качества программного обеспечения на основе стандартов ISO и IEEE.

Содержание:
что такое качество программного обеспечения, высококачественная программа, историческая справка.

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

Урок 2, 3.
Стандарт. Модель качества. Характеристики и атрибуты качества.

Тип урока:
урок усвоения и закрепления новых знаний и умений.

Цели:

1. Дать определение атрибута.

2. Познакомить с международным стандартом ГОСТ Р ИСО МЭК 9126, характеристиками и атрибутами качества.

3. Определить внешние, внутренние метрики качества, метрики качества в использовании.

Содержание:
внешние метрики качества, внутренние метрики качества, характеристики и атрибуты качества, что такое атрибут.

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

Урок 4.
Метрики, их применение, метрические шкалы.

Тип урока:
урок усвоения новых знаний и умений.

Цели:

1. Дать понятие метрики.

2. Определить метрические шкалы, применения метрик, типы метрик, направления метрик и направления применения метрик.

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

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

Урок 5, 6.
Метрики сложности программ.

Тип урока:
урок усвоения и закрепления новых знаний и умений.

Цели:

1. Дать основные классификации метрик сложности.

2. Познакомить с множеством метрик сложности.

Содержание:
основные классификации метрик сложности, оценочные модели.

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

Урок 7.
Метрики Холстеда.

Тип урока:
урок усвоения и закрепления новых знаний и умений.

Цели:

1. Познакомить с метриками Холстеда, его характеристиками, классами несовершенств программирования.

Содержание:
метрики Холстеда, характеристики метрик, классы несовершенств программирования.

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

Урок 8.
Граф. Построение графа.

Тип урока:
урок усвоения и закрепления новых знаний и умений.

Цели:

1. Дать определения граф, путь.

2. Познакомить с видами графов, связей, путей.

3. Научить строить граф программы.

Содержание:
граф, виды графов, виды связей, путь, виды путей.

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

Урок 9, 10.
Метрика Мак-Кейба.

Тип урока:
урок усвоения и закрепления новых знаний и умений.

Цели:

1. Познакомить с метрикой Мак-Кейба, ее модификациями и достоинствами.

Содержание:
метрика Мак-Кейба, модификации метрики, достоинства метрики, упрощенный вариант метрики.

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

Урок 11,12
. Итоговый контроль.

Тип урока
: урок применения знаний, умений, навыков.

Цели:

1. Проверить знания по разделу критерии качества программного обеспечения.

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

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

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

2.3 Описание электронной поддержки курса

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

После запуска программы появляется первое окно метрика Мак-Кейба, которое представляет работу данной метрики (Рис. А).

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

Рис А

После нажатия на вторую вкладку «Холстед» появляется окно, которое представляет работу метрики Холстеда (Рис. B). Пользователю также предлагается открыть программу для оценки ее качества. При нажатии на кнопку «Exit» программа завершает свою работу. В меню данного окна можно открыть программу для оценки ее качества, выйти из программы, просмотреть файл справки и сведения о разработчике.

Рис B

После нажатия на третью вкладку «SLOC» появляется окно, которое представляет работу метрики SLOC (Рис. C). Пользователю также предлагается открыть программу для оценки ее качества. При нажатии на кнопку «Exit» программа завершает свою работу. В меню данного окна можно открыть программу для оценки ее качества, выйти из программы, просмотреть файл справки и сведения о разработчике.

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

Педагогический эксперимент проводился во время педагогической практики в МОУ СОШ № 151 г. Челябинска. Эксперимент проводился в рамках факультативных занятий в 11-ф/м классе. В течение 3 учебных занятий по теме «Критерии качества программного обеспечения» в лекционно-практической форме были рассмотрены следующие темы:

1. Введение в менеджмент качества (1 ч.)

2. Методы оценки качества программного обеспечения (1 ч.)

3. Автоматизированные программные продукты по оценке качества ПО (1 ч.)

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

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

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

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

В данной главе подробным образом рассмотрена информация об элективном курсе «Критерии качества программного обеспечения»: тематическое и поурочное планирование, дано описание программной поддержки курса.

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

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

Заключение

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

1. Получить новые знания и опыт в области программирования, а именно объектно-ориентированного программирования;

2. Значительно облегчить усвоение новых знаний в области моделирования, так как позволяет более наглядно раскрыть тему «Моделирование с помощью графов»;

3. Получить практические навыки в оценивании качества программного обеспечения различными метриками;

4. Дополнительно развить аналитические способности и логическое мышление;

5. Совершенствовать умение работать с компьютером для дальнейшей профессиональной деятельности.

Приложение

Конспекты уроков

Урок 1

Тип: урок усвоения новых знаний

Тема урока «Качество ПО. Понятие качества ПО».

Цели образовательные:

1.
Дать представление о качестве программного обеспечения, высококачественной программе, стандартах.

2.
Дать определение качества программного обеспечения на основе стандартов ISO и IEEE.

Цели развивающие:

- развитие логического мышления

- развитие культуры высказывания собственного мнения

Цели воспитательные:

- воспитание информационной культуры

- воспитание умения слушать

Средства технические, программные, информационные (дидактический материал):

Учебный класс, оснащенный компьютерами

Мультимедийный проектор, экран.

Классная доска и маркеры

Этапы урока с указанием продолжительности:

1. Актуализация опорных знаний учащихся – 3 мин.

2. Мотивация учебной деятельности школьников – 2 мин.

3. Сообщение темы, цели и задач урока – 1 мин.

4. Восприятие и первичное осознание учащимися нового материала – 18 мин.

5. Осмысление и первичное запоминание нового материала – 10 мин.

6. Подведение итогов урока – 5 мин.

7. Сообщение домашнего задания – 1 мин.

Содержание урока:

Что такое качество и почему оно должно быть столь глубоко представлено?

На протяжении многих лет отдельные авторы и целые организации определяли термин “качество” по-разному:

· Фил Кросби (Phil Crosby) в 1979 году дал определение качеству как “соответствие пользовательским требованиям” (предполагает, что требования должны быть настолько четко определены, что они не могут быть поняты и интерпретированы некорректно);

· Уотс Хемпфри (Watts Hamphrey) описывает качество как “достижение отличного уровня пригодности к использованию” (принимает во внимание требования и ожидания конечных пользователей продукта, которые ожидают, что продукт или предоставляемый сервис будет удобным для их нужд);

· Компания IBM, в свою очередь, ввела в оборот фразу “качество, управляемое рыночными потребностями” (“market-driven quality”);

· Критерий Бэлдриджа (Baldrige) для организационного качества использует похожую фразу - “качество, задаваемое потребителем” (“customer-driven quality”), рассматривая удовлетворение потребителя в качестве главного соображения в отношении качества.

Чаще, понятие качества используется в соответствии с определением системы менеджмента качества ISO 9001 как “степень соответствия присущих характеристик требованиям”.

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

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

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

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

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

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

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

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

Вопросы и задания для самоконтроля:

1. Дать определение качества с точки зрения стандарта ISO и IEEE.

2. Назвать основные аспекты качества ПО.

3. Дать определение качества с вашей точки зрения.

4. Дать характеристику качественной программе

Урок 2

Тип: комбинированный из урока усвоения новых навыков и умений и урока применения знаний, навыков и умений.

Тема урока: «Стандарт. Модель характеристик качества».

Цели образовательные:

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

2.
Познакомиться со стандартом ГОСТ Р МЭК 9126.

Цели развивающие:

- развитие логического мышления

- развитие навыков самостоятельной работы

Цели воспитательные:

- воспитание информационной культуры

- воспитание уважения к одноклассникам

Средства технические, программные, информационные (дидактический материал):

Учебный класс, оснащенный компьютерами

Мультимедийный проектор, экран.

Классная доска и маркеры

Этапы урока с указанием продолжительности:

1. Актуализация опорных знаний учащихся – 3 мин.

2. Мотивация учебной деятельности школьников – 2 мин.

3. Сообщение темы, цели и задач урока – 1 мин.

4. Восприятие и первичное осознание учащимися нового материала – 18мин.

5. Осмысление и первичное запоминание нового материала – 10 мин.

6. Подведение итогов урока – 5 мин.

7. Сообщение домашнего задания – 1 мин.

Содержание урока:

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

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

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

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

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

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

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

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

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

В России принята и переведена на русский язык только первая часть стандарта.

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

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

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

Для каждого атрибута определяется набор метрик, позволяющих его оценить. Множество характеристик и атрибутов качества согласно ИСО 9126 на рис. 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы и задания для самоконтроля:

1. Сколько частей включает в себя стандарт? Назвать их.

2. Для чего предназначена каждая часть стандарта?

3. Какая часть стандарта принята в России?

4. Рассказать о модели качества.

5. Дать определение атрибута.

6. Назвать уровни представления модели качества. Для чего они предназначены?

7. Придумать свои требования к качеству.

Урок 3

Тип: комбинированный из урока усвоения новых навыков и умений и урока применения знаний, навыков и умений.

Тема урока: «Характеристики и атрибуты качества».

Цели образовательные:

3.
Рассмотреть характеристики и атрибуты качества.

4.
Дать определение характеристики качества программного обеспечения.

5.
Формирование навыков работы с характеристиками качества.

Цели развивающие:

- развитие логического мышления

- развитие навыков самостоятельной работы

Цели воспитательные:

- воспитание информационной культуры

- воспитание уважения к одноклассникам

Средства технические, программные, информационные (дидактический материал):

Учебный класс, оснащенный компьютерами

Мультимедийный проектор, экран.

Классная доска и маркеры

Этапы урока с указанием продолжительности:

1. Актуализация опорных знаний учащихся – 3 мин.

2. Мотивация учебной деятельности школьников – 2 мин.

3. Сообщение темы, цели и задач урока – 1 мин.

4. Восприятие и первичное осознание учащимися нового материала – 18мин.

5. Осмысление и первичное запоминание нового материала – 10 мин.

6. Подведение итогов урока – 5 мин.

7. Сообщение домашнего задания – 1 мин.

Вопросы и задания для самоконтроля:

1. Дать определение характеристике качества программного обеспечения.

2. Перечислить все характеристики качества.

3. Дать описание каждой характеристики и ее атрибутов.

4. Выбрать любой программный продукт и описать его на основе характеристик стандарта.

5. На основе характеристик и атрибутов качества охарактеризовать любую программу.

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

1. Андон Ф.И., Суслов В.Ю., Коваль Г.И., Коротун Т.М. Основы качества программных систем.–Киев, Академпериодика.– 2002.–502с.

2. Бабенко Л.П., Лаврищева Е.М Основы программной инженерии. Учебник Киев: Знание, 2001. – 269 с

3. Боэм Б.У. Инженерное проектирование программного обеспечения. Пер. с англ. / Под ред. А.А. Красилова. – М.: Изд-во Радио и связь, 1985. – 512 с.

4. Боэм Б.У., Браун Дж., Каспар X. и др. Характеристики качества программного обеспечения. М. Мир, 1981.

5. Воробьев В. И., Копыльцов А. В., Пальчун Б. П., Юсупов Р. Методы и модели оценивания качества программного обеспечения. М. С-Пб.: СПИИРАН.1992.-33с.

6. Колдовский В. Разработка ПО: оценка результата. Компьютерное обозрение №34 (553) 2006

7. Кулаков А.Ю. Оценка качества программ ЭВМ .–Киев: Технiка.–1984.–167с.

8. Липаев В. Качество программного обеспечения. - М.: Финансы и статистика, 1983.

9. Липаев В.В. Методы обеспечения качества крупномасштабных программных систем. – М.: СИНТЕГ.– 2003.–510 с.

10. Липаев В.В. Обеспечение качества программных средств. Методы и стандарты. – М.: Синтег, 2001. – 380 с.

11. Орлов С. Технологии разработки программного обеспечения: Учебник/ - СПб.: Питер, 2002. - 464 с.: ил.

12. Соммервил И. Инженерия программного обеспечения. 6 -издание.–Москва–Санкт– Петербург–Киев, 2002.–623 с.

13. Фокс Дж. Программное обеспечение и его разработка М.: "Мир", 1982.

14. Холстед М.Х. Начало науки о программах. - М.: Финансы и Статистика, 1981.

15. Boehm B.W. The COCOMO 2.0 Software Cost Estimation Model. – American Programmer. – 2000. – 586 p.

16. ISO/IEC 9126 Software engineering — Product quality — Part 1: Quality model, 2001

17. ISO/IEC 9126 Software engineering — Product quality — Part 2: External metrics, 2001

18. ISO/IEC 9126 Software engineering — Product quality — Part 3: Internal metrics, 2001

19. ISO/IEC 9126 Software engineering — Product quality — Part 4: Quality in use metrics, 2001