Оценка надежности программных средств в соответствии с СТБ ИСО/МЭК 9126–2003 (продолжение подраздела 5.1)

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

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

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

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

5.3.1 Цена качества.Слагаемые затрат на качество:

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

· затраты на выявление дефектов;

· затраты на корректирующие меры (включая потери от выпуска некачественного продукта):

· внутренние:

· исправление дефектов, найденных при тестировании;

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

· внешние:

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

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

На рис. 5.5 показана цена качества по Джозефу Джурану (рис. 01.6). Из рис. 5.5 следует:

Рисунок 5.5 – Цена качества по Джозефу Джурану

· Абсолютное качество недостижимо.

· Чересчур высокое качество обходится дорого.

· Нужно искать оптимальные затраты (good enough).

5.3.2 Оценка качества по СТБ ИСО/МЭК 9126–2003 с помощью метрик. Согласно СТБ ИСО/МЭК 9126–2003 применительно к ПО можно рассматривать показатели его качества и показатели надёжности. При этом надёжность ПО – это, как и для технических объектов, комплексное его свойство, объединяющее свойства завершённости, устойчивости к ошибке, восстанавливаемости и соответствия надёжности.

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

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

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

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

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

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

Отношения между типами метрик показаны на рис. 5.6.

Рисунок 5.6 – Отношения между типами метрик

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

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

Желательные свойства метрик (ISO/IEC TR 9126–2–4:2003–2004):

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

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

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

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

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

корректность;метрика должна обладать следующими свойствами:

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

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

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

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

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

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

Метрика должна удовлетворять хотя бы одному из следующих критериев обоснованности метрики:

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

Корреля́ция (от лат. correlatio «соотношение, взаимосвязь») или корреляционная зависимость — это статистическая взаимосвязь двух или более случайных величин (либо величин, которые можно с некоторой допустимой степенью точности считать таковыми).

2) трассировка;если метрика М непосредственно связана с величиной характеристики качества Q (оперативно определенной по результатам измерения основных метрик), то изменение величины Q(T1), имеющейся в момент времени T1, к величине Q(T2), полученной в момент времени Т2, должно сопровождаться изменением значения метрики от М(T1) до М(T2) в том же направлении (например, если увеличивается Q, то М тоже увеличивается);

3) непротиворечивость;если значения характеристик качества (оперативно полученные по результатам измерения основных метрик) Q1, Q2,…, Qn, связанные с продуктами или процессами 1, 2,..., n, определяются соотношением Q1 > Q2 > ... > Qn, то соответствующие значения метрики должны удовлетворять соотношению M1 > M2 > ... > Мn;

4) предсказуемость;если метрика используется в момент времени T1 для прогноза значения (оперативно полученного по результатам измерения основных метрик) характеристики качества Q в момент времени T2, то ошибка прогнозирования, определяемая выражением (прогнозное Q(T2) – фактическое Q(T2)) / (фактическое Q(T2)),должна попадать в допустимый диапазон ошибок прогнозирования;

5) селективность;метрика должна быть способной различать высокое и низкое качество программного средства.

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

Таблицы имеют следующую структуру:

1.название метрики;

2.назначение метрики;

3.метод применения

4.способ измерения, формула, исходные и вычисляемые данные;

5.интерпретация измеренного значения (диапазон и предпочтительные значения);

6.тип шкалы, используемой при измерении метрики;

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

тип времени (например, затраченное время, необходимое пользователю время);

тип количества (например, количество изменений, количество отказов);

8.источники входных данных для измерения;

9.ссылка на СТБ 12207-2003 (ISO/IEC 12207:1995) (процессы жизненного цикла программных средств, при выполнении которых применима метрика);

10.целевая аудитория.

Метрики распределяются по категориям характеристик и подхарактеристик из СТБ ИСО/МЭК 9126–2003 (ISO/IEC 9126-1). В таблице предоставляется следующая информация для каждой метрики:

1. НАЗВАНИЕметрики (рис. 5.7): соответствующие метрики в таблице внутренних метрик и таблице внешних метрик имеют сходные имена.

Рисунок 5.7 – Вид столбца 1 Рисунок 5.8 – Вид столбца 2 Рисунок 5.9 – Вид столбца 3 таблицы метрик таблицы метрик таблицы метрик

2. ЦЕЛЬ (назначение) МЕТРИКИ (рис. 5.8): Она выражается в форме вопроса, ответ на который определяется применением метрики.

3. МЕТОД ПРИМЕНЕНИЯ (рис. 5.9): Предоставляет общую схему применения.

4. СПОСОБ ИЗМЕРЕНИЯ (формула, исходные и вычисляемые данные) (ИЗМЕРЕНИЕ, формула и расчет элементов данных) (рис. 5.10): Предоставляет формулу для измерения и объясняет значения использованных элементов данных. ПРИМЕЧАНИЕ: В некоторых случаях для метрики предлагается более одной формулы

Рисунок 5.10 – Вид столбца 4 таблицы метрик Рисунок 5.11 – Вид столбца 5 таблицы метрик

5. ИНТЕРПРЕТАЦИЯ ИЗМЕРЕННОГО ЗНАЧЕНИЯ (диапазон и предпочтительные значения) (рис. 5.11): предоставляет диапазон предпочтительных величин.

6. ТИП ШКАЛЫ (используемой при измерении) МЕТРИК (рис. 5.12): тип шкалы, который использует метрика. Используемые типы шкал: номинальная шкала (Nominal scale, НШ), порядковая шкала (Ordinal scale, ПШ), интервальная шкала (Interval scale, ИШ), шкала отношений (Ratio scale, ШО) и абсолютная шкала (Absolute scale, А).

Рисунок 5.12 – Вид столбца 6 таблицы метрик Рисунок 5.13 – Вид столбца 7 таблицы метрик

7. ТИП ИЗМЕРЕННОГО ЗНАЧЕНИЯ (ТИП ИЗМЕРЕНИЙ) (рис. 5.13): Используемые типы: размерный тип (Size type, размерный тип, РТ, например, размер функции, объем кода), временной тип (Time type, временной тип, ВТ, например, время работы пользователя), численный тип (Count type, численный тип, ЧТ, например, число изменений, число отказов).

8. ВХОДНЫЕ ДАННЫЕ ДЛЯ ИЗМЕРЕНИЯ (рис. 5.14): Источник данных, используемых в измерении.

Рисунок 5.14 – Вид столбца 8 Рисунок 5.15 – Вид столбца 9 Рисунок 5.16 – Вид

таблицы метрик таблицы метрик столбца 10 таблицы метрик

9. ССЫЛКА НА ISO/IEC 12207 SLCP (СТБ 12207-2003) (рис. 5.15): Определяет процесс(ы) жизненного цикла программного обеспечения, в котором (которых) применима данная метрика.

10. ЦЕЛЕВАЯ АУДИТОРИЯ (ЦА) (рис. 5.16): Определяет пользователя (пользователей) результатов измерений. СОКРАЩЕНИЯ (применямые в конспекте): Р – (разработчик), СС – (специалист по сопровождению), П – пользователь, Пк – поставщик, Прпи – проектировщик пользовательского интерфейса.

5.3.3 Численный расчёт (оценка) метрик.Метрики распределяются по категориям характеристик и подхарактеристик из СТБ ИСО/МЭК 9126–2003 (ISO/IEC 9126-1). Каждая подхарактеристика оценивает свой i – единичный показатель качества ПО Х_i .Оценка внутренних и внешних метрик качества ПО строится на базе одних и тех же взаимосвязанных между собой формул для разных метрик. Эти формулы имеют вид (5.1) и (5.2):

Х = А/В(6.1)

Х = 1 – А/В (6.2)

При этом в (5.1), (5.2) полагается, что оценка Х=1 соответствует максимальному качеству (надёжности), а Х=0 – минимальному, а А и В – это численные значения некоторых количественно оцениваемых единичных подхарактеристик ПО.

Общий интегральный показатель качества ПО согласно ГОСТ 15467-79 «Управление качеством продукции. Термины и определения» записывается как средневзвешенное значение единичных показателей , т. е.

где – весовой коэффициент при i-ом единичном показателе качества, определяемый методом экспертных оценок, опытом работы или социологическим опросом потребителей, N – количество метрик (единичных показателей).

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

,

где «*» в предыдущем выражении – знак скалярного произведения 2-х векторов. Согласно СТБ ИСО/МЭК 9126–2003 (ISO/IEC 9126-1) все координаты вектора равнозначны, т.е.

причём

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

5.3.4 Работы в области обеспечения надёжности и качества ПО на кафедре ПОИТ. Эти работы в области обеспечения надёжности и качества программного обеспечения можно разделить на 2 группы. Обеими группами работ руководит к.т.н., доцент кафедры ПОИТ Вячеслав Вениаминович Бахтизин (рис. 5.17), автор монографий

Рисунок 5.17 – Вячеслав Вениаминович Бахтизин, Рисунок 5.18 – Лилия Александровна Глухова,

к. т. н., доцент, доцент кафедры ПОИТ, автор к. т. н., доцент, доцент кафедры ПОИТ, автор

монографий [30, 31, 42 и других], руководитель монографий [30, 31, 42 и других]

научной школы «Качество программных средств»

[30, 31 и других], руководитель научной школы «КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ». Количественный и качественный состав научной школы: 12 человек. Из них: молодых ученых – 10, кандидатов наук – 5, аспирантов – 7.

Основные направления научных исследований, проводимых в рамках научной школы:

Методы, модели и алгоритмы оценки и управления качеством программных средств:

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

- Модели и методы оценки сложности программных средств;

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

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

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

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

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

- Управление жизненным циклом программных средств.

Интеграционные решения в корпоративных сетях.

Основные научные результаты:

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

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

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

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

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

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

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

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

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

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

- Разработаны модели сложности программных средств.

- Разработан метод управления сложностью программных средств на основе модели сложности программных средств.

- Разработан метод минимизации рисков при разработке программных средств в соответствии с методологией Scrum.

- Разработаны показатели эффективности выполнения работ в Scrum-команде.

Основные научные результаты внедрены в УП «Центр банковских технологий» Национального банка Республики Беларусь, в производственный процесс СООО «Численные методы», процесс сопровождения ПС филиала ОАО МАЗ «Минский рессорный завод», процесс сопровождения ПС ЗАО «Дарасофт», учебный процесс БГУИР.

Наиболее активные члены научной школы:

1) кандидат технических наук, доцент кафедры ПОИТ БГУИР Глухова Лилия Александровна(рис. 5.18);

2 и 3) бывшие аспиранты В. В. Бахтизина (ныне кандидаты технических наук, доценты кафедры ПОИТ БГУИР) Сергей Николаевич Неборский(рис. 5.19) и Святослав Святославович Куликов (рис. 5.20);

4) бывшая аспирантка В. В. Бахтизина (ныне кандидат технических наук, бывший доцент кафедры экономики БГУИР) Бородаенко Юлия Владимировна (в настоящее время в США),

5) аспирант кафедры ПОИТ Александр Кузиков.

Рисунок 5.19 – Сергей Николаевич Неборский, Рисунок 5.20 – Святослав Святославович Куликов,

к. т. н., доцент, доцент кафедры ПОИТ, автор к. т. н., доцент, доцент кафедры ПОИТ, автор

монографий [42 и других] трудов [4, 5, 45 и других], коуч будущих тестировщиков ЭПАМа и БелХарда