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

Подождите немного. Документ загружается.

114 Глава 2

20. Парадигмы программирования - http://schum.kiev.ua/let/

21. Оберон как эсперанто программирования – http://www.computer-museum.ru/histsoft/

ober_esp.htm

22. Ваныкина Г.В., Якушин А.В. Рекурсивные вычисления в различных парадигмах про-

граммирования - http://mech.math.msu.su/conference/nikolsky-100/Articles/Vanikina.htm

23. Капитонова Ю.В., Летичевский А.А. Об основных парадигмах программирования //

Кибернетика и системный анализ.-1994.-№6.-с.3-20.

24. Лаврищева Е.М., Грищенко В.Н. Сборочное программирование.–Киев.– Наукова Думка,

1991.–213с.

25. Липаев В.В., Позин Б.А., Штрик А.А. Технология сборочного программирования.М.: –

Радио и связь, 1992. – 275с.

26. Рыбаков А., Золотарев С. Программное обеспечение многоядерных систем -

http://old.osp.ru/os/2006/02/012.htm

27. Суперкомпьютерные кластерные системы – организация вычислительного процесса /

В.Н. Коваль, С.Г.Рябчун, И.В.Сергиенко, А.А.Якуба // Проблеми програмування.-№2-3

(спеціальний випуск за матеріалами конференції УкрПРОГ’2006).-с.197-210.

28. Дехтяренко И.А. Декларативное программирование - http://www.softcraft.ru/paradigm/

dp/dp01.shtml

29. Доказательное программирование и синтез программ - http://mail.spb.fio.ru/archive/

group43/c4wu3/proof.htm

30. Грищенко В.Н., Лаврищева Е.М. Методы и средства компонентного программирования

// Кибернетика и системный анализ.-2003.– №1.– С. 39 – 55.

31. Грищенко В.Н., Лаврищева Е.М. Компонентно-ориентированное программирование.

Состояние, направления и перспективы развития // Проблемы программирования. –

2002. - № 1–2.– С. 80–90.

32. Лаврищева Е.М. Парадигма интеграции в программной инженерии // Проблемы про-

граммирования. - 2000. – №1–2.– С.351–360

33. Бабенко Л.П. Повторное использование в программной инженерии // Кибернетика и

системный анализ.-1999.-№2.-С.37-48.

34. www.sei.cmu.edu/pub/documents/00.reports/pdf/00tr008.pdf

35. Добрынин В. Технология компонентного программирования – http://www.ict.edu.ru

36. Conney P. Web-services - // www.alistapart.com

37. Рогушина Ю.В., Гладун А.Я. Онтологическая модель интеллектуализации сервис-

ориентированных вычислений в распределенной среде Интернет // Проблеми програ-

мування.-№2-3 (спеціальний випуск за матеріалами УкрПРОГ’2006).-2006.-с.526-536.

38. Андон П., Дерецький В. Проблеми побудови сервіс-орієнтованих прикладних інформа-

ційних систем в Semantic Web середовищі на основі агентного підходу // там же.-с.493-

502.

39. Аспектно ориентированное программирование

–

http://www.javable.com/columns/aop/

workshop/02/index1.pdf

40. Elrad T., Filman R.E. Aspect-oriented programming // Communications of the ACM.–2001.–

vol.44.– N 10.– P.33–38

41. Богатырев Р. Глядя в будущее // Мир ПК. - 2003.- №1 (www.osp.ru/pcworld/2003/01/

142_3.htm)

42. Чистяков В. R# - метапрограммирование в .NET // RDSN Magazine.-2004.-№5

(www.rsdn.ru/projects/rsharp/article/rsharp_mag.xml)

Глава 2 115

43. Чернецки К., Айзенекер У. Порождающее программирование. Методы, инструменты,

применение // Издательский дом «Питер».–2005.–730с.

44. Плескач В.Л., Рогушина Ю.В. Агентні технології // Київ.- КНТЕУ.–2005.–337с.

45. Трахтенгерц Э.А. Взаимодействие агентов в многоагентных средах //Автоматика и те-

лемеханика.– М.: Наука .–1998.–№8.– с.3-52.

46. Рогушина Ю.В. Разработка средств интеллектуализации поиска информации в Интер-

нет // Проблемы программирования.-№1-2 (специальный выпуск по материалам конфе-

ренции УкрПРОГ’2002). -2002.-с.378-385.

47. Автоматное программирование - http://ru.wikipedia.org/wiki

48. Глушков В.М. Теория автоматов и формальные преобразования микропрограмм // Ки-

бернетика.-1965.-№5.-С.1-10.

49. Цейтлин Г.Е. Теория алгоритмических метаалгебр и ее приложения // Проблемы про-

граммирования.-1999.-№1.-С.4-15.

50. Глушков В.М., Цейтлин Г.Е., Ющенко Е.Л. Алгебра. Языки. Программирование – 3-е

изд., перераб. и доп.- Киев: Наукова думка, 1989.-376с.

51. Капитонова Ю.В., Летичевский А.А. Методы и средства алгебраического программи-

рования // Кибернетика.-1993.-№3.-С.7-12.

52. Летичевский А.А., Маринченко В.Г. Объекты в системе алгебраического программиро-

вания // Кибернетика и системный анализ. –1997.– N2. – С.160–180.

53. Инсерционное программирование / Летичевский А.А., Капитонова Ю.В., Волков В.А.,

Вышемирский В.В., Летичевский А.А. (мл.) // Кибернетика и системный анализ.– 2003,

№1.– 19-32.

54. Letichevsky A.A., Gilbert D.R. A model for interaction of agents and environments //Recent

trends in algebra's development technique Language.–2000. – P.311 – 329.

55. Капитонова Ю.В., Летичевский А.А., Волков В.А. Дедуктивные средства системы ал-

гебраического программирования // Кибернетика и системный анализ. –2000. – №1.–

С.17 – 34.

56. Letichevsky A.A., Gilbert D.R. A General Theory of Action Language // Кибернетика и сис-

темный анализ. –1998. – №1.– С.16 – 36.

57. Редько В.Н. Композиционная структура программологии // Кибернетика и системный

анализ. – 1998. –№4. – С. 47–66.

58. Редько В.Н. Основания программологии // Кибернетика и системный анализ. – 2000.–

№ 1.– С. 35–57.

59. Редько В.Н., Брона Ю.Й., Буй Д.Б. Реляційні бази даних: табличні алгебри та SQL–

подібні мови //Видав. дім “Академперіодика”, Київ, 2001.–195с.

60. Редько В.Н. Композиции программ и композиционное программирование // Програм-

мирование.-1978.-№5.-С.3-24.

61. Редько В.Н. Основания композиционного программирования // Программирование.-

1979.-№3.-С.3-13.

62. Никитченко Н.С. Композиционно-номинативный подход к уточнению понятия про-

граммы // Проблемы программирования. –1999.– №1.– С. 16–31.

63. Редько В.Н. Экспликативное программирование: ретроспективы и перспективы // Про-

блемы программирования.– 1998. – №2.–С. 22 – 41.

64. Редько В.Н., Гришко Н.В., Редько И.В. Эталонное программирование: ретроспективы и

перспективы // Проблемы программирования.– 2000. – №1-2.–С. 13– 28.

116

Глава 3. МОДЕЛИ И МЕТРИКИ КАЧЕСТВА

3.1. Метрики качества программных систем

3.1.1. Метрика как основа измерения

Атрибуты программной системы, характеризующие ее качество, измеряются

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

Метрика – это комбинация конкретного метода измерения (способа получе-

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

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

Метрика определяет меру

атрибута – переменную, которой присваивается

значение в результате измерения (рисунок 3.1). Например, сущность – «отчет об

обнаруженных дефектах», атрибут – «список дефектов», метод измерения – «под-

счет количества дефектов в списке», шкала – «целые числа больше нуля», мера ат-

рибута – «общее число дефектов», имя метрики (обычно одноименное мере) – «об-

щее число дефектов».

Программная система

(рабочий продукт)

Атрибут

Множество атрибутов

(измеримых свойств)

обладает

Характеристика

Подхарактеристика

измеряется с помощью

влияет на

(представляет)

Модель

качества

выражает (измеряет)

Метрика

Метод

(способ получения

значений)

Шкала

измерений

Мера

(число / категория)

включает

Множество

значений

структурирует

определяет

(вычисляет)

получает

значение из

включает

Характеризует

Рис. 3.1. Метрика в системе измерения качества

Мера атрибута может быть непосредственной, если она не зависит от мер

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

По определению стандарта ISO/IEC 9126-2 метрика качества программной

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

теристикой качества ПС. Служит индикатором одного или многих атрибутов. Ее

можно увидеть, например, в левой части большинства уравнений X = A*B, где X

имеет не ту же шкалу, что A или B» [1].

Термин «мера» - эквивалент употребляемого в международных стандартах термина

«measure» (measure – мера, измерять, единица измерения). Понятия меры и метрики в про-

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

Глава 3 117

Метрика называется базовой, если в ее основе лежит элементарный метод

(примитив) измерения атрибута. По определению того же стандарта «базовая мет-

рика сама по себе не является индикатором характеристики или подхарактеристики

качества. Ее можно увидеть, например, в правой части большинства уравнений X =

A*B. А и В – базовые метрики». То есть базовые метрики используются только в

составе модели измерения атрибута.

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

меры нужно идентифицировать шкалу измерения.

Стандарт ISO/IEC 9126-2 рекомендует применять 5 видов шкалы измерения

значений (упорядоченных от менее строгих к более строгим):

• номинальная шкала. Это классификационная шкала, выполняющая кате-

горизацию свойств оцениваемого объекта. Категории не упорядочены. Например,

дефекты могут классифицироваться на дефекты интерфейса, логики, объявления

данных и др. Языки – Fortran, С++, Java и др.;

• порядковая шкала. Позволяет упорядочивать характеристики по возрас-

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

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

кий», «средний», «высокий», «критический». Для уровней СММ – 1, 2, 3, 4, 5. Рас-

стояние между значениями по шкале не играет роли. Характеристики, имеющие

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

категорийными). Все остальные - количественными.

• интервальная шкала. Отмечает существенные различия свойств объекта,

«дистанцию» между ними (например, календарные даты или значения плотности

дефектов - 1.5 дефекта/KSLOC, 3.5 дефекта/KSLOC и т.д.). Используется в арифме-

тических операциях и операциях сравнения (в данном примере разница равна 2 де-

фекта/KSLOC). Нулевое значение не допустимо;

• относительная шкала. Значения по этой шкале различаются по отноше-

нию к выбранной единице (например, времени, изменяющемся от 0 до бесконечно-

сти, или стоимости). Применяя эту шкалу можно рассчитать, например, время меж-

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

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

рументов измерения (гистограмм, диаграмм Парето и др.);

• абсолютная шкала. Это специальный случай относительной шкалы. В

этой шкале указывается абсолютное значение величины. Например: «размер про-

граммы равен 2К», «число обнаруженных ошибок равно 20».

Измеренное значение метрики само по себе не несет информации об уровне

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

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

требований. Примеры деления шкалы:

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

творительные значения;

• деление шкалы по четырем категориям, ограниченным тремя уровнями

значений - текущим, худшим и плановым (рисунок 3.2).

Глава 3

118

Плановый уровень

Текущий уровень

Худшие значения

Измеренное значение

Требования превышены

Область целевых значений

Минимально приемлемые

Неприемлемые значения

Удовлетворительно

Неудовлетво-

рительно

Уровни ранжированияШкала измерений

Рис. 3.2. Уровни ранжирования метрик

По мере накопления практики измерений и знаний об измеряемых атрибутах

шкалы их измерения могут эволюционировать от менее информативных (номи-

нальной и порядковой) к более информативным (относительной или абсолютной).

3.1.2. Классификация мер качества

Для разработки процедур сбора данных, интерпретации мер и их нормализа-

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

риками.

• меры размера. Представляют размер ПС в разных единицах измерения,

например:

– функциональный размер (учет функциональных возможностей ПС. Значе-

ние представлено в условных единицах функциональности (глава 8));

– размер программы (учет числа строк исходного кода, количества модулей,

количества операторов на языке программирования);

– объем ресурсов, используемых работающей программой (учет объема опе-

ративной памяти, дисковой памяти или сетевого трафика, загруженности процессо-

ра - количества обрабатываемых инструкций в секунду и др.);

• меры времени. Представляют периоды реального времени (в секундах,

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

процессора) или календарного времени (в рабочих часах, календарных днях, меся-

цах, годах), например:

– время функционирования системы с непрерывной или дискретной работой

компонентов программного обеспечения (учет истекшего времени (при работе про-

граммного обеспечения в системе в течение установленного периода времени),

учет времени с момента включения (при непрерывном использовании встроенного

программного обеспечения системы реального времени), учет нормализованного

времени (при совместной работе нескольких компьютеров, обменивающихся дан-

ными);

– время выполнения (время, необходимое работающему программному ком-

поненту системы для завершения решения определенной задачи в определенных

условиях);

Глава 3 119

– время использования (время, затрачиваемое определенным пользователем

на решение задач с помощью ПС), например: время сеанса работы (от начала до

завершения), время решения задачи и др.;

• меры усилий. Представляют полезное (продуктивное) время, связанное с

определенной задачей проекта, например:

– производительность труда (при индивидуальной работе);

– трудоемкость (при коллективной работе);

• меры интервалов между событиями. Представляют интервалы времени

между наступлением событий, происходящих в определенный период наблюдения,

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

использоваться частота наступления событий;

• счетные меры. Представляют собой статические счетчики (для учета

определенных элементов в рабочих продуктах ПС (документах)) или кинетические

(динамические) счетчики (для учета событий или действий человека), например:

– количество обнаруженных ошибок (учет ошибок в ходе инспекции, тести-

рования, функционирования или сопровождения ПС);

– структурная сложность программы (количество путей в программе, цик-

ломатическая сложность и др.);

– число несовместимых элементов (учет ошибок согласования (требований,

стандартов, форматов и др.), учет ответов типа «да»/«нет» в вопросниках);

– число изменений (учет элементов конфигурации, в которых произошли из-

менения):

– число обнаруженных отказов (учет отказов при тестировании, функцио-

нировании или сопровождении ПС);

– число попыток (учет попыток корректировки дефектов или ошибок);

– эргономические счетчики – число нажатий клавиш, щелчков на кнопках и

др.

– счетчики-оценки (-очки, -баллы) (учет результатов, представленных в во-

просниках, контрольных листах и др.).

При выполнении измерений базовые меры размера, времени и счета могут

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

и обеспечивают возможность сопоставления метрик. Примеры стилей композиции

мер представлены в таблице 3.1.

Таблица 3.1. Стили композиции мер

Стиль компози-

ции мер

Описание Примеры

Стиль нормализации по размеру

(Время) / (Размер) Подходит для представления

временной эффективности или

производственных усилий на

единицу размера

• Время выполнения на инст-

рукцию исходного кода

• Время исправления на инст-

рукцию исходного кода

(Количество) /

(Размер)

Подходит для представления

плотности

• Плотность ошибок

• Тестовое покрытие

Глава 3

120

Стиль компози-

ции мер

Описание Примеры

(Размер) / (Раз-

мер)

Подходит для представления

отношения размера определен-

ного фрагмента к размеру цело-

го

• Цикломатическое число мо-

дуля

• Процентиль

объема моду-

лей, предрасположенных к

ошибкам, к общему объему

Стиль нормализации по времени

(Размер) / (Время) Подходит для представления

трендов величин во времени

• Число строк разработанного

кода в месяц

(Количество) /

(Время)

Подходит для представления

частоты в единицу времени

• Число транзакций в секунду

• Число измененных инструк-

ций исходного кода в месяц

(Время) / (Время) Подходит для представления

отношения времени наблюдае-

мых событий к общему времени

наблюдения

• Отношение полезного вре-

мени работы ко времени функ-

ционирования системы

Стиль нормализации по количеству

(Размер) / (Коли-

чество)

Подходит для представления

сферы охвата (диапазона изме-

нений)

• Среднее покрытие тестами

выполняемых инструкций про-

граммы

(Время) / (Коли-

чество)

Подходит для представления

интервала времени

• Среднее время между отка-

зами

• Среднее время исправления

одной ошибки

(Количество) /

(Количество)

Подходит для представления

отношения числа определенных

событий к их общему числу

• Число успешных попыток

пользователя выполнить дейст-

вие к общему числу попыток

3.1.3. Классификация метрик качества

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

сифицируют как:

• объективные/субъективные. Объективные метрики включают подсчеты

элементов, которые могут быть независимо проверены (число строк кода, число

ошибок, сложность и др.). Они снижают влияние личного мнения на вычисление и

анализ метрик. Субъективные метрики основываются на индивидуальном или кол-

лективном понимании или предпочтении определенных характеристик или условий

(уровень сложности проблем, стоимостные коэффициенты и др.);

• примитивные/вычисляемые. Примитивные (базовые) метрики можно не-

посредственно наблюдать (размер программы в KSLOC, число дефектов, найден-

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

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

приходящихся на SLOC, трудоемкость и др.);

• динамические/статические. Динамическим метрикам свойственен ком-

понент времени. Значения изменяются с течением времени, начиная с момента сбо-

Процентиль – единица относительной градации на участке шкалы от 1 до 100.

Глава 3 121

ра данных (например, число ошибок в месяц). Статические метрики инвариантны

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

• предсказывающие/объясняющие. Значения предсказывающих (прогнози-

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

ность отказов). Значения объясняющих метрик появляются пост-фактум (реальная

интенсивность отказов).

По отношению к виду объекта измерения (работающая программа или сово-

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

ние, внутренние и метрики использования ПС.

Внешние метрики используют меры работающего на компьютере программ-

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

вания и функционирования [1].

Внешние метрики разрабатываются с целью:

• демонстрации качества программного продукта, представленного харак-

теристиками и подхарактеристиками качества, на стадии тестирования и эксплуа-

тации;

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

продукт удовлетворяет внешним требованиям к качеству;

• предсказания реального эксплуатационного качества;

• определения степени, в которой программный продукт будет удовлетво-

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

ной эксплуатации.

Можно сказать, что совокупность внешних метрик предназначена для оцени-

вания внешнего качества - степени, в которой продукт удовлетворяет установлен-

ным (заявленным) и подразумеваемым потребностям при использовании в опреде-

ленных условиях.

Разработка внешних метрик основывается на выполнении следующих изме-

рений:

• поведения программного продукта при тестировании и функционирова-

нии в сочетании с другими программными продуктами, аппаратным обеспечением

или системой обработки информации в целом;

• поведения пользователя (сценариев использования ПС).

Под измерением (оценкой) поведения понимается оценка масштабов воз-

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

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

гласованности или недостоверности информации, потере безопасности, деградации

сервиса (услуг), экономическим потерям и др.

Примерами внешних метрик для такой характеристики качества как надеж-

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

тестировании, интенсивность отказов и др.

Внутренние метрики обеспечивают возможность пользователям, разработ-

чикам, тестировщикам и менеджерам оценивать качество промежуточных и конеч-

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

тере [2].

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

• представлять (отражать) качество не выполняющихся на компьютере

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

Глава 3

122

подхарактеристикам качества, которые определены в модели качества ПС (раздел

3.2);

• служить руководством к действию при планировании и улучшении про-

цессов, которые воздействуют на промежуточные и конечные продукты;

• использоваться при верификации того, что промежуточные и конечные

продукты удовлетворяют требованиям к внутреннему качеству ПС, предусмотрен-

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

• предсказывать внешние метрики качества.

Можно сказать, что совокупность внутренних метрик предназначена для оце-

нивания внутреннего качества - множества атрибутов продукта, которое определя-

ет его способность удовлетворять установленным или реальным потребностям при

использовании в определенных условиях.

Разработка внутренних метрик основывается на выполнении измерений ста-

тических атрибутов, которые определены и могут быть оценены по тексту исходно-

го кода, графическому или табличному представлению потоков управления и дан-

ных, структур перехода состояний или по документам ПС.

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

найденных при инспекции кода, число устраненных дефектов в результате инспек-

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

Метрики качества в использовании (метрики эксплуатационного качества)

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

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

тивном, продуктивном и безопасном решении задач [3].

Метрики качества в использовании помогают оценить не свойства самой ПС,

а видимые результаты ее эксплуатации - эксплуатационное качество.

Очевидно, что для правильного измерения эксплуатационного качества важ-

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

специфику решаемых ими задач, а также физические и социальные факторы среды

их работы.

Примерами эксплуатационных метрик качества могут быть точность и пол-

нота достижения целей пользователей, производительность труда, ресурсы, потра-

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

относительно свойств ПС и др.

Внутренние, внешние и эксплуатационные метрики качества взаимосвязаны.

Достижение эксплуатационного качества зависит от удовлетворения критериев

внешнего качества, основанных на внешних мерах и метриках качества, которые, в

свою очередь, зависят от удовлетворения соответствующих критериев внутреннего

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

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

внешних метрик и эксплуатационных метрик качества, а внутренние метрики вы-

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

ний внешних метрик.

Построить строгую теоретическую модель, устанавливающую взаимосвязь

внешних и внутренних метрик, сложно, поэтому, как правило, строится гипотети-

ческая модель, взаимосвязь метрик в которой моделируется статистически в ходе

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

Глава 3 123

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

3.2.1. Обобщенная модель качества

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

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

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

Как эталон при решении вопросов, связанных с качеством, характеризуемым

внутренними и внешними атрибутами ПС, стандарт ISO/IEC 9126-1 предлагает

двухуровневую иерархическую модель (рисунок 3.3) [4, 5].

Внешнее и внутреннее

качество ПС

Характеристика 1

Характеристика i

Характеристика

Подхарактеристика 1

Подхарактеристика j

Подхарактеристика

Внешние метрики Внутренние метрики

Базовые метрики

Атрибуты

процесса

разработки ПС

Внутренние

атрибуты ПС

Внешние

атрибуты ПС

... ...

измеряются с помощью измеряются с помощью

влияют на

основываются на основываются на

измеряют измеряют

Рис.3.3. Обобщенная модель качества

Эта модель качества может использоваться для:

• идентификации требований к качеству ПС (внешнему и внутреннему);

• подтверждения полноты определения требований к качеству;

• идентификации целей проекта;

• идентификации целей тестирования;

• идентификации пользовательских критериев приемки завершенного

программного продукта.

В соответствии с моделью качества, предложенной в стандарте ISO/IEC 9126-

1, свойства (или атрибуты) ПС, характеризующие ее качество, укладываются в

шесть категорий, каждая из которых ассоциируется с одной из характеристик каче-

ства, приведенных в таблице 3.2

Приводятся наименования характеристик, установленные стандартом ДСТУ 2850

[5], и их эквиваленты по стандарту ISO/IEC 9126-1 [4].