На какие группы можно разбить метрики при оценке качества программного обеспечения

Обновлено: 30.06.2024

Модель МакКола

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

• использование (корректность, надежность, эффективность, целостность, практич­ность);

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

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

3.1.2. Модель Боэма

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

Рисунок 1. Модель качества программного обещания МакКола

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

Рисунок 2. Модель качества программного продукта Боэма

3.1.2. Модель FURPS/FURPS+

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

• Functionality (Функциональность) /особенности, возможности, безопасность/;

• Usability (Практичность) /человеческий фактор, эргономичность, пользовательская документация/;

• Reliability (Надежность) /частота отказов, восстановление информации, прогнози- руемость/;

• Performance (Производительность) /время отклика, пропускная способность, точ­ность, доступность, использование ресурсов/;

• Supportability (Эксплуатационная пригодность) /тестируемость, расширяемость, адаптируемость, сопровождаемость, совместимость, конфигурируемость, обслужи­ваемость, требования к установке, локализуемость/.

• ограничения проекта (ограничения по ресурсам, требования к языкам и средствам разработки, требования к аппаратному обеспечению);

• интерфейс (ограничения накладываемые на взаимодействие с внешними система­ми);

• требования к выполнению,

• требования к лицензированию.

FURPS модель качества [8], предложенная Грейди и Hewlett Packard, построена схожим образом с моделями МакКола и Боэма, но в отличие от них состоит из двух слоев, первый определяет характеристики, а второй связанные с ними атрибуты. Ос­новной концепцией, лежащей в основе FURPS модели качества, является декомпозиция характеристик программного обеспечения на две категории требований, а именно, функциональные (F) и нефункциональные (URPS) требования. Эти выделенные катего­рии могут быть использованы как в качестве требований к программному продукту, так и в оценке качества НИ. В настоящее время модель FURPS+ широко используется в разработке программного обеспечения и при идентификации требований к разрабаты­ваемой системе целесообразно использование FURPS+ модели в качестве универсаль­ного контрольного перечня характеристик НО.

Модель Гецци

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

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

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

Модель качества SATC

В Центре обеспечения качества программного обеспечения NASA (Software Assur­ance Technology Center, SATC) была разработана программа метрик [11], обеспечи­вающая оценку рисков проекта, качества продукции и эффективности процессов. Нро- грамма SATC рекомендует отдельно отслеживать качество требований, качество про­граммного обеспечения и других продуктов (документации), качество тестирования и качество выполнения процессов. Модель качества SATC определяет набор целей, свя­занных с программным продуктом и атрибуты процессов в соответствии со структурой модели качества программного обеспечения ISO 9126-1.

Модель качества ISO 9126

Качество программного обеспечения определяется в стандарте ISO 9126-1 [2] как всякая совокупность его характеристик, относящихся к возможности удовлетворять высказанные или подразумеваемые потребности всех заинтересованных лиц.

Модель качества ISO 9126-1 различает понятия внутреннего качества, связанного с характеристиками ПО самого по себе, без учета его поведения; внешнего качества, ха­рактеризующего ПО с точки зрения его поведения; и качества ПО при использовании в различных контекстах - того качества, которое ощущается пользователями при кон­кретных сценариях работы ПО. Для всех этих аспектов качества введены метрики, по­зволяющие оценить их. Кроме того, для создания надежного ПО существенно качество технологических процессов его разработки. Взаимоотношения между этими аспектами качества по схеме, принятой ISO/IEC 9126 (ISO/IEC 9126-1:2001 [2]; ISO/IEC TR 9126­2:2003 [12], ISO/IEC TR 9126-3:2003 [13], ISO/IEC TR 9126-4:2004 [14]), показано на Рис 3.

Рисунок 3. Основные аспекты качества программного обеспечения

На рис. 4 представлены факторы и атрибуты внешнего и внутреннего качества программного обес­печения в соответствии с ISO/IEC 9126.

Рисунок 4. Факторы и атрибуты внешнего и внутреннего качества программного обеспечения

На рис. 5 приведена модель оценивания согласно ISO/IEC 9126.

Рисунок 5. Модель оценивания надежности программного обеспечения согласно стандарта ISO / IEC 9126

Модель качества QMOOD

Джагдиш Банзия и Карл Дэвис [15] предложили иерархическую модель качества для объектно-ориентированного проектирования (QMOOD), которая расширяет мето­дологию модели качества Дроми и включает в себя четыре уровня:

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

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

3) Определение объектно-ориентированных метрик проекта: различные объектно­ориентированные метрики проекта.

4) Определение объектно-ориентированных свойств проекта: Компоненты проекта были определены для определения архитектуры объектно-ориентированного про­екта. Эта модель определяет парадигму, а также вводит ряд новых объектно­ориентированных метрик.

Другие модели качества

Модель качества, описанная в [16], представила два различных подхода к показате­лям качества на протяжении всего жизненного цикла программного обеспечения. Ха­рактеристики качества могут быть сведены к двум группам:

1) эффективность, безопасность, доступность и функциональность;

2) модифицируемость, мобильность, возможность многократного использования, на­следуемость и тестируемость.

Согласно модели качества Хосрави К. и др. [18] процесс оценки качества состоит из двух задач:

1) выбор глобальной характеристики;

2) выбор подхарактеристик, связанных с глобальной характеристикой.

Эта модель качества основана на многократном использовании программного обеспе­чения в качестве глобальной характеристики и акценте на возможности многократного использования, понятности, гибкости, модульности, надежности, масштабируемости и удобстве использования. Модель качества Хосрави и др. связала показатели качества и подхарактеристики, используя определения IEEE, ISO/IEC и некоторых других моделей качества.

Для оценки качества программного обеспечения на основе теории нечетких мно­жеств и метода анализа иерархий, Чанг и др. [18] были определены руководящие прин­ципы и это подход ими был применен к модели качества ISO 9126-1. Оценки качества программного обеспечения основаны на характеристиках и подхарактеристиках модели ISO 9126-1.

Шармой А. и др. [19] была предложена компонентно-ориентированная модель ка­чества разработки программного обеспечения, которая включает все характеристики и подхарактеристики модели качества ISO 9126-1, а также предлагает новые подхаракте­ристики, такие как пригодность к повторному использованию, гибкость, сложность, прослеживаемость, масштабируемость. Метод анализа иерархий в этой модели исполь­зуется для оценки качества проекта.

4. МНОГОУРОВНЕВЫЙ ПОДХОД К МОДЕЛЯМ КАЧЕСТВА [2]

На рисунке 6 представлены характеристики качества программных средств (по ГОСТ 28195–89. ГОСТ 28195-89 Оценка качества программных средств. Общие положения).

В основе моделей качества лежит многоуровневый подход (количество слоев мо­жет быть 2 /модели МакКола и Боэма/ или 3 слоя /включая метрики/).

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

Рисунок 6. Характеристики качества программных средств

(по ГОСТ 28195–89. ГОСТ 28195-89 Оценка качества программных средств. Общие положения).

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

Характеристики качества	МакКол	Боэм	FURPS/ FURPS+	Гецци	Дроми	ISO 9126	Казман	Хосрави	Шармоа
Корректность	+
Надежность	+	+	+	+	+	+	+	+
Корректность	+
Эффективность	+	+	+	+	+	+	+	+
Гибкость	+	+	+	+
Функциональность	+	+	+	+	+
Эргономичность проетирования	+
Целостность	+
Функциональная совместимость	+
Сопровождаемость	+	+	+	+	+	+	+	+
Модифицируемость	+
Производительность	+
Мобильность	+	+	+	+	+	+
Зрелость процесса	+
Возможность многократного использования	+	+	+
Устойчивость	+
Масштабируемость	+
Безопасность	+	+
Эксплуатационная пригодность	+
Тестируемость	+	+	+
Понятность	+	+
Практичность	+	+	+	+	+	+	+	+

5. ОПИСАНИЕ МОДЕЛЕЙ ОЦЕНКИ НАДЕЖНОСТИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ[3]

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

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

Для обеспечения качества и надежности ПС стандартами рекомендуется формулировать требования:

u к объекту разработки на данном этапе — к его программным и информационным компонентам, а также к интерфейсу между ними и внешней средой;

u к процессу, технологии и организации выполнения совокупности работ и документов каждого этапа;

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

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

Требования к инструментальным средствам автоматизации разработки надежных ПС наиболее полно изложены в стандарте IEEE 1209-1992.

Рисунок 8 График соотношения между обнаруженными и необнаруженными ошибками

Модель Шумана

Модель Шумана строится на основе нескольких критериев:

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

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

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

¾ интенсивность отказов программы пропорциональна числу остаточных ошибок.

Предполагается, что до начала тестирования (т.е. в момент t=0) имеется M ошибок. В течение времени тестирования τ обнаруживается ε₁(t) ошибок в расчете на одну команду в машинном языке.

Тогда удельное число ошибок на одну машинную команду, оставшихся в системе после времени тестирования τ, равно:

(1)

где I -- общее число машинных команд, которое предполагается постоянным в рамках этапа тестирования.

Предполагается, что значение функции количества ошибок Z(t) пропорционально числу ошибок, оставшихся в программе после израсходованного на тестирование времени τ.

где С -- некоторая постоянная, t - время работы программы без отказов.

Тогда, если время работы программы без отказа t отсчитывается от точки t = 0, а τ остается фиксированным, функция надежности, или вероятность безотказной работы на интервале от 0 до t, равна

(2)

(3)

Нам необходимо найти начальное значение ошибок M и коэффициент пропорциональности С. Эти неизвестные оцениваются путем пропуска функционального теста в двух точках переменной оси отладки t_a и t_в, выбранных так, что ε₁(t_a) * и C * , можно рассчитать надежность программы по формуле (2).

Пример 1.

Программа содержит 2 000 командных строк, из них, до начала эксплуатации (после периода отладки), 15 командных строк содержат ошибки. После 20 дней работы обнаружена 1 ошибка. Найти среднее время безошибочной работы программы и интенсивность отказов программы при коэффициенте пропорциональности, равном 0,7.

ГОСТ Р ИСО/МЭК 9126-93

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ОЦЕНКА ПРОГРАММНОЙ ПРОДУКЦИИ

Характеристики качества и руководства по их применению

Information technology. Software product evaluation. Quality characteristics and guidelines for their use

Дата введения 1994-07-01

Предисловие

1 ПОДГОТОВЛЕН И ВНЕСЕН Техническим комитетом по стандартизации (TK 22) "Информационная технология"

2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 28 декабря 1993 г. N 267

3 Стандарт подготовлен на основе применения аутентичного текста международного стандарта ИСО/МЭК 9126-91* "Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению"

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

3 ВВЕДЕН ВПЕРВЫЕ

4 ПЕРЕИЗДАНИЕ. Ноябрь 2004 г.

1 Область применения

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

Настоящий стандарт не определяет подхарактеристики (комплексные показатели) и показатели, а также методы измерения, ранжирования и оценки. Данный стандарт придерживается определения качества по ИСО 8402.

Примечание - Предложения по определению комплексных показателей приведены в приложении А.

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

Эти характеристики могут применяться к любому виду программного обеспечения, включая программы ЭВМ и данные, входящие в программно-технические средства (встроенные программы).

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

2 Нормативные ссылки

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

ИСО/МЭК 2382-20-90 Информационная технология. Словарь. Часть 20. Разработка системы

ИСО 8402-86 Качество. Словарь

Примечание - До прямого применения данных международных стандартов в качестве Государственных стандартов Российской Федерации они могут быть получены по запросам из ВНИИКИ Госстандарта России.

3 Определения

В настоящем стандарте применяются следующие термины.

3.1 оценка (assessment): Действие по применению конкретного задокументированного критерия оценки к конкретному программному модулю, пакету или продукции с целью обусловленной приемки или выпуска программного модуля, пакета или продукции.

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

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

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

3.4 уровень качества функционирования (level of performance): Степень, в которой удовлетворяются потребности, представленные конкретным набором значений для характеристик качества.

3.5 измерение (measurement): Действие по применению показателя качества программного обеспечения к конкретной программной продукции.

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

Примечание - В сфере контракта потребности определены, тогда как в других сферах предполагаемые потребности должны быть установлены и определены (ИСО 8402, примечание 1).

3.7 ранжирование (рейтинг) (rating): Действие по отнесению измеренного значения к соответствующему уровню ранжирования. Используется для определения уровня ранжирования программного обеспечения по конкретной характеристике качества.

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

Примечание - Данные уровни ранжирования отличны от "классов", определенных ИСО 8402.

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

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

3.11 качество программного обеспечения (software quality): Весь объем признаков и характеристик программной продукции, который относится к ее способности удовлетворять установленным или предполагаемым потребностям.

3.12 критерии оценки качества программного обеспечения (software quality assessment criteria): Набор определенных и задокументированных правил и условий, которые используются для решения о приемлемости общего качества конкретной программной продукции. Качество представляется набором установленных уровней, связанных с программной продукцией.

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

3.14 метрика качества программного обеспечения (software quality metric): Количественный масштаб и метод, которые могут быть использованы для определения значения признака, принятого для конкретной программной продукции.

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

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

4.1 Функциональные возможности (Functionality)

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

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

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

4.2 Надежность (Reliability)

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

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

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

4.3 Практичность (Usability)

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

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

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

4.4 Эффективность (Efficiences)

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

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

4.5 Сопровождаемость (Maintainability)

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

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

4.6 Мобильность (Portability)

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

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

5 Руководство по применению характеристик качества

5.1 Применяемость

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

- определение требований к качеству программной продукции;

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

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

- оценивание разработанного программного обеспечения перед его поставкой;

- оценивание программного обеспечения перед приемкой.

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

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

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

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

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

5.2 Представления о качестве программного обеспечения

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

В данной работе рассматриваются вопросы формирования метрик качества программных продуктов. Материал полезен для проведения занятий по дисциплине МДК.04.01." Моделирование и анализ программного обеспечения" специальности 09.02.03 "Программирование в компьютерных системах" СПО углубленной подготовки

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

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

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

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

3. Исследование характеристик и связанных метрик, для определения корреляции, значимости, степени автоматизируемости.

4. Исследование корреляции между метриками, степени перекрытия, зависимости и недостатков.

5. Рафинирование множества метрик в целом во множество метрик, которые в совокупности адекватно отражают качество программного обеспечения.

6. Корректировка каждой метрики в итоговом множестве в контексте зафиксированных множеств характеристик и метрик.

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

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

Качество программных компонент

Разработка современных больших программных систем в настоящее время все более базируется на компонентной разработке (Component Base System - CBS). Технология построения CBS позволяет значительно снизить стоимость и время разработки. В то же время возрастает риск, связанный с использованием в системе программных компонент разработанных различными производителями.

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

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

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

Примерами метрик могут служить следующие показатели:

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

- Цена (Cost) - расходы на приобретение/разработку. Измеряет общую цену, включая цену анализа рынка, приобретения, интеграции и улучшения качества.

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

- Среда разработки (Software Engineering Environment). Процент целевых компьютерных ресурсов, используемых системой.

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

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

- Соответствие требованиям (requirement conformance)

- Стабильность требований (requirement stability)

- Изменяемость требований(Requirement Convertibility)

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

3. Метрики качества ПП/ПС в целом:

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

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

- Тестовое покрытие (test coverage). Степень полноты различных типов тестирования.

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

- Профили ошибок (fault profiles). Метрика, измеряющая кумулятивное число обнаруженных ошибок.

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

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

- Гибкость (flexability), которая аккумулирует ряд свойств:

- Адаптивность (adaptability), которая подразумевает:

- Способность к взаимодействию (Interoperability)

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

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

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

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

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

Оглавление

1 Введение
2 Метрики
2.1 Размерно-ориентированные метрики (показатели оценки объема)
2.1.1 LOC-оценка (Lines Of Code)
2.1.1.1 Метрика стилистики и понятности программ
2.1.2 Итого по SLOC
2.2 Метрики сложности
2.2.1 Объектно-ориентированные метрики
2.2.2 Метрики Холстеда
2.2.3 Метрики цикломатической сложности по Мак-Кейбу
2.2.4 Метрики Чепина
2.3 Предварительная оценка на основе статистических методов в зависимости от этапов разработки программы
2.3.1 Предварительная оценка сложности программы на этапе разработки спецификации требований к программе
2.3.2 Предварительная оценка сложности на этапе определения архитектуры
2.4 Общий списочный состав метрик
2.4 Подведение итогов
6 Ресурсы интернет

2. Метрики

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

• метрики размера программ;
  
• метрики сложности потока управления программ;
  
• метрики сложности потока данных программ.
  

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

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

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

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

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

2.1.1 LOC-оценка (Lines Of Code)

Размерно-ориентированные метрики прямо измеряют программный продукт и процесс его разработки. Основываются такие метрики на LOC-оценках.

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

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

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

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

Эти метрики не универсальны и спорны, особенно это относится к такому показателю как LOC, который существенно зависит от используемого языка программирования.

Пример из жизни: На наш взгляд оценка по количеству строк в коде влечёт за собой соблазн написать побольше строк, дабы взять побольше денег. Разумеется, об оптимизации в таком продукте никто уже думать не станет. Вспомним историю о том, как планетарный центр аутсорсинга — Индия, после того, как заказчики вменили им метрику LOC, на второй день показал удвоение и утроение строк кода.

Количество строк исходного кода (Lines of Code – LOC, Source Lines of Code – SLOC) является наиболее простым и распространенным способом оценки объема работ по проекту.

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

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

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

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

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

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

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

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

2.1.2 Итого по SLOC

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

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

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

Пример из жизни : В одной из компаний при внедрении мы применили данную метрику – считали строки кода. Руководитель организации был в отпуске, но по возвращении из него решил воспользоваться прозрачностью и трассируемостью изменений и посмотреть, как же идут дела в проектах у его менеджеров. И чтоб полностью войти в курс, опустился на самый низкий уровень (то есть не стал оценивать плотность дефектов, количество исправленных багов) – на уровень исходных текстов. Решил посчитать, кто и сколько строк написал. А чтоб было совсем весело – соотнести количество рабочих дней в неделю и количество написанного кода (логика проста: человек работал 40 часов в неделю, значит, должен много чего написать). Естественно, нашелся человек, который за неделю написал всего одну строку, даже не написал, а только откорректировал существующую… Гневу руководителя не было предела – нашел бездельника! И плохо было бы программисту, если бы менеджер проекта не объяснил, что: была найдена ошибка в программе, нашел ее VIP- клиент, ошибка влияет на бизнес клиента и ее нужно было срочно устранить, для этого был выбран вот этот конкретный исполнитель, который развернул стенд, залил среду клиента, подтвердил проявление ошибки и начал ее искать и устранять. Естественно, в конце концов, он поменял фрагмент кода, в котором было неправильное условие и все заработало.

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

2.2 Метрики сложности

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

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

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

Метрика

Описание

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

Связность объектов (Coupling between objects)

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

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

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

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

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

На основании этих характеристик рассчитываются оценки:

• Словарь программы
  (Halstead Program Vocabulary, HPVoc): HPVoc = NUOprtr + NUOprnd;
  
• Длина программы
  (Halstead Program Length, HPLen): HPLen = Noprtr + Noprnd;
  
• Объем программы
  (Halstead Program Volume, HPVol): HPVol = HPLen log2 HPVoc;
  
• Сложность программы
  (Halstead Difficulty, HDiff): HDiff = (NUOprtr/2) × (NOprnd / NUOprnd);
  
• На основе показателя HDiff предлагается оценивать усилия программиста при разработке при помощи показателя HEff (Halstead Effort): HEff = HDiff × HPVol.
  

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

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

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

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

C = e – n + 2,

где e – число ребер, а n – число узлов
на графе управляющей логики.

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

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

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

Существует значительное количество модификаций показателя цикломатической сложности.

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

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

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

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

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

Q = a1P + a2M + a3C + a4T, где a1, a2, a3, a4 – весовые коэффициенты.

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

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

Выделим типовые этапы в разработке программ:

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

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

2.3.1 Предварительная оценка сложности программы на этапе разработки спецификации требований к программе

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

Nпрогн =NF*Nед

Где: NF – количество функций или требований в спецификации требований к разрабатываемой программе;
Nед – единичное значение количества операторов (среднее число операторов, приходящихся на одну среднюю функцию или требование). Значение Nед — статистическое.

2.3.2 Предварительная оценка сложности на этапе определения архитектуры

Си = NI / (NF * NI ед * Ксл)

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

2.4 Общий списочный состав метрик

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

Также отметим, что цель этой статьи показать принцип, а не описать все возможные метрики во множестве комбинаций.

Читайте также:

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