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

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

Глава 3

154

SQFD концентрирует внимание на повышении качества процесса разработки

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

ределения исходных требований в ЖЦ разработки.

SQFD адаптируется к любой существующей методологии программной ин-

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

требований заказчика. Ее применение приводит к повышению производительности

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

в проект, снижению числа ошибок, распространяющихся с одной стадии ЖЦ на

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

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

SQFD адаптирует к условиям разработки ПС наиболее часто используемую

матрицу QFD - Дом Качества. Базовая модель SQFD представлена на рисунке 3.15.

Корреляционная

матрица

Техническая

спецификация

продукта

Пользовательские

требования

Приоритеты

пользовательских

требований

Приоритеты

технических

спецификаций

продукта

Оценка продукта

Оценка конкурентов

Индекс цен

Индекс улучшения

Стоимость

Трудоемкость

Гафик

Рис. 3.15. Базовая модель SQFD

В этой модели присутствуют такие компоненты:

• требования пользователя. Извлекаемые при анализе проблемной области

пользовательские требования (к которым относятся требования конечных пользо-

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

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

вождаются подробными определениями, образующими словарь SQFD;

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

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

продукту и фиксируются над осью x. Одному пользовательскому требованию мо-

жет соответствовать несколько технических спецификаций;

• корреляционная матрица. Пользователям предлагается идентифициро-

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

ми и техническими спецификациями продукта (сильная, средняя, слабая корреля-

ция) и заполнить корреляционную матрицу. При этом должны быть учтены мнения

всех категорий пользователей;

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

данных выстраиваются приоритеты установленных требований и перечисляются

Глава 3 155

справа по оси y. В ходе определения приоритетов может использоваться дополни-

тельная информация о конкурирующих продуктах;

• приоритеты технических спецификаций продукта. Приоритеты техниче-

ских спецификаций определяются путем суммирования произведений приоритетов

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

осью x. Веса полученной строки приоритетов технических спецификаций затем

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

оритетов. Могут использоваться дополнительные данные об адресных (целевых)

мерах технических спецификаций с учетом оценок стоимости, сложности и графи-

ка работ;

• конечный продукт. Конечный продукт процесса SQFD будет, как мини-

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

процентном соотношении и адресные (частные) меры.

Методология SQFD (как и QFD) имеет как достоинства, так и недостатки.

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

ляет сосредоточиться на тщательном планировании и снизить изменяемость требо-

ваний. Она обеспечивает «встраивание» качества в процесс проектирования, что

приводит к предупреждению распространения дефектов на более поздние стадии

ЖЦ, а это, в свою очередь, сокращает продолжительность и стоимость проекта, по-

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

В числе недостатков SQFD - существенная стоимость и сложность методоло-

гии. Для успешного применения она требует полной поддержки со стороны руко-

водства и автоматизации процессов принятия решений.

Такие фирмы, как DEC, AT&T, Hewlett-Packard, IBM разрабатывают свои

собственные модели SQFD и стратегии сбора и обработки данных.

Более подробная информация о методологии SQFD, ее достоинствах и недос-

татках, а также примерах применения содержится в [28, 29, 30]. Для широкого

применения модель SQFD нуждается в стандартизации.

Литература к главе 3

1. ISO/IEC 9126-2:2003. Software Engineering - Product Quality - Part 2: External Metrics.

2. ISO/IEC 9126-3:2003. Software Engineering - Product Quality - Part 3:Internal Metrics.

3. ISO/IEC 9126-4:2004. Software Engineering – Software Product Quality - Part 4: Quality In

Use Metrics.

4. ISO/IEC 9126-1:2001. Software Engineering - Product quality - Part 1: Quality model.

5. ДСТУ 2850-94. Програмні засоби ЕОМ. Показники і методи оцінювання якості.

6. ISO/IEC 14143-1:1998. Information technologies - Software measurement - Functional size

measurement - Part 1: Definition of concepts.

7. ISO/IEC 14756:1999. Information technologies – Measurement and rating of performance of

computer-based software systems.

8. McCall J.A., Richards P.K., Walters G.F. Concepts and definitions of software quality // Fac-

tors in Software Quality, NTIS. - v. 1. - nov. 1977.

9. В. В. Кулямин, О. Л. Петренко. Место тестирования среди методов оценки качества ПО.

– http:/software-testing.ru/lib/ispras/testing_in_various_models.htm

10. Boehm B.W., J. R. Brown, H. Kaspar, M. Lipow, G. MacLeod, and M. J. Merritt. Characteris-

tics of Software Quality // TRW series of Software Technology. North Holland. Amsterdam. –

1978.

Глава 3

156

11. Watts R. Measuring Software Quality // Manchester: NCC Publications. – 1987.

12. Abel D.E., Rout T.P. Determining and Specifying the Quality Attributes of Software Products

// Austral. Comput. J. - V. 25. - N. 3. - aug. - 1993. - P.105-112.

13. Hyatt L., Rosenberg L. A Software Quality Model and Metrics for Identifying Project Risks

and Assessing Software Quality // 8th Annual Soft. Technology Conf., Utah, april. – 1996.

14. Gilb T. Principles of Software Engineering Management, Addison-Wesley.- 1988. – 442 p.

15. Musson T. The evaluation of Instructional Software Quality // Software Quality Management

III, v.1: Managing Quality Systems, Ed. M.Ross. - Computational Mechanics Publications. -

1994. - P. 311 – 321.

16. R.Geoff Dromey. A model for software product quality. // IEEE Trans. On Softw. Eng. – V.

21. – N.2. – febr. – 1995. – P. 146-162.

17. Boegh J. et al. A Method for Software Quality Planning, Control and Evaluation // IEEE

Software. - march/april. - 1999. - P. 69 – 77.

18. Devani-Chulani S. Incorporating Bayessian Analysis to Improve the Accuracy of COCOMO

II and its Quality Model Extension // Univ. of South. Calif., Los Angeles, CA.- 1997.

19. Buglione L., Abran A., Geometrical and statistical Foundations of a Three-dimensional Model

of Performance // International Journal of Advanced in Engineering Software. - 30. - 1999.

20. Kececi N. Abran A. Analysing. Measuring and assessing software quality in a logic based

graphical model // Qualita2001 (4

International Congress on Quality and Reliability), An-

necy, France, March 22-23, 2001.

21. Коваль Г.І. Байєсівські мережі як засіб оцінювання та прогнозування якості програмно-

го забезпечення // Проблеми програмування. - 2005. - № 2. -С. 15 – 23

22. У. Моррис. Наука об управлении. Байесовский подход. – М.: Мир.- 1971. –304 с.

23. Капитонова Ю.В., Мищенко Н.М., Фелижанко О.Д., Щеголева Н.Н. Об использовании

байесовских сетей для мониторинга пользователей компьютеров // Кибернетика и сис-

темный анализ. –2004. -№ 6. –С. 3-14.

24. Веревка О.В., Кузьмина К.И., Семик Т.М. Байесовское прогнозирование эффективности

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

личности // Проблеми програмування. – 2005. - № 1. – С. 69 - 84.

25. Westfall L.L. Software Metrics that Meet Your Information Needs // Software Measurement

Services, Phano. – 1996.

26. ISO/IEC 14598-1:1999. Information technologies - Software product evaluation - Part 1:

General overview.

27. ISO/IEC 14598-5:1998. Information technologies - Software product evaluation - Part 5: Pro-

cess for evaluators.

28. Haag S., Raja M.K., Schkade L.L. Quality Function Deployment. Usage in Software Devel-

opment // Comm. of the ACM. – 1996.- V. 39. - N.1.

29. Ouyang S. et al. Quality Function Deployment // Department of Computer Science Univ. of

Calgary, Canada. – 1997. - http://sern.ucalgary.ca/courses/seng/613/F97/ grp2/report.htm

30. Krogstie J. Using Quality Function Deployment in Software Requirements Specification. –

http://www.ifi.uib.no/konf/refsq99/papers/krogstie.pdf

157

Глава 4. ИЗМЕРЕНИЯ В ПРОГРАММНОЙ ИНЖЕНЕРИИ

4.1. Измерение как процесс жизненного цикла

4.1.1. Цели, задачи и объекты измерения

Процесс измерения входит в группу организационных процессов ЖЦ и непо-

средственно связан с процессом верхнего уровня – процессом управления. Он мо-

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

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

внедрение, сопровождение, оценивание и улучшение процесса измерения возлага-

ется на менеджеров (руководителей) уровня организации или проекта.

Перспективы успеха в выполнении и совершенствовании всех видов дея-

тельности в процессах ЖЦ существенно расширяются, когда решения принимают-

ся на основе анализа фактической, количественной информации. Эта информация

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

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

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

поддержку деловых целей организации.

Существует четыре причины, обусловливающие измерение процессов, про-

дуктов и ресурсов в ЖЦ – это необходимость их охарактеризовать, оценить, пред-

сказать или совершенствовать.

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

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

го анализа.

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

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

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

качества и влияния усовершенствований технологии и процесса на продукты и

процессы.

Измерение с целью предсказания направлено на достижение понимания

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

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

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

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

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

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

ки стоимости, времени и качества исходя из текущих объективных данных. Проек-

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

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

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

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

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

контролировать затраты усилий на осуществление усовершенствований. Измере-

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

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

жащим образом, и какими могут быть побочные эффекты усовершенствований.

158 Глава 4

Удачно выбранные меры помогают также информировать всех участников процес-

сов о целях измерений и пояснять необходимость совершенствования.

По определению Н. Фентона «измерение – это процесс, в ходе которого атри-

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

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

вил» [1]. Таким образом, измерение предполагает наличие сущностей (объектов

интереса), атрибутов (характеристик) сущностей и правил для назначения значений

атрибутам.

Есть несколько видов сущностей, представляющих интерес с позиции изме-

рения, например:

- продукты - артефакты - организации

- процессы - действия - среды

- ресурсы - агенты - ограничения

Атрибуты определяют свойства сущностей. Искусство измерения состоит в

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

правильное представление о соответствующих сущностях.

В области программной инженерии предложено ряд таксономий для класси-

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

том, процессом или ресурсом [2], а Д. Армитеж и другие используют схему клас-

сификации, основанную на артефактах, действиях и агентах [3]. Обе схемы имеют

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

речь идет об элементах среды.

В таблице 4.1 показаны некоторые примеры сущностей наряду с атрибутами

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

чений атрибутов сущности.

Таблица 4.1. Примеры измеряемых атрибутов сущностей

Класс сущ-

ностей

Атрибуты Возможные меры

Меры продукта

Система Размер

• Число модулей

• Число петель в диаграмме потоков данных

• Число условных единиц функциональности (FP)

• Число физических строк исходного кода (SLOC)

• Количество памяти в байтах или словах (требуемых

или выделенных)

Плотность де-

фектов

• Число дефектов в SLOC

• Число дефектов в FP

Компонент Длина

• Число физических строк исходного кода

• Число логических исходных операторов

Объем повтор-

ного использо-

вания

Отношение числа неизмененных физических строк, ис-

ключая комментарии и пустые строки, к общему числу

строк

Модуль

Сложность

Число линейно независимых путевых потоков

Документ

Длина

Число страниц

Тип оператора

Имена типа Строка ко-

да

Язык програм-

мирования

Название языка

Глава 4 159

Класс сущ-

ностей

Атрибуты Возможные меры

Дефект Тип Имена типа

Место распо-

ложения

Название действия, при котором внесен

Серьезность Упорядоченное множество классов серьезности

Усилия на уст-

ранение

Человеко/часы

Возраст (для

открытых де-

фектов)

Количество времени (в днях) с момента получения отче-

та о дефекте

Меры процесса

Процесс

разработки

Истекшее вре-

мя

• Календарные дни

• Рабочие дни

Контрольные

сроки

Календарные даты

Усилия на раз-

работку

Человеко/часы, дни или месяцы

Объем локали-

зации дефектов

% общего числа дефектов, найденных на той стадии, на

которой внесены

Соответствие

стандартам

% задач, согласующихся со стандартными процедурами

или директивами

Эффективность Число успешно пройденных тестов, деленное на число

выполненных тестов

Истекшее вре-

мя

• Календарные дни

• Рабочие дни

Детальное

проектиро-

вание

Качество про-

екта

Плотность дефектов: число дефектов проекта, найден-

ных в проекте, деленное на меру размера продукта (FP,

KSLOC)

Объем Число запланированных тестов Тестирова-

ние

Прогресс

• Число выполненных тестов

• Число успешно пройденных тестов

Сопровож-

дение

Стоимость

• Объем финансирования/год

• Человеко/часы, потраченные на выполнение запроса

об изменении

Портфель

запросов об

изменении

Размер

• Число запросов об изменении, ожидающих обслу-

живания

• Оцененная трудоемкость (человеко/часы) выполне-

ния запросов

Меры ресурса

Размер бригады

• Количество назначенных людей

Назначен-

ный штат

Опыт

• Количество лет опыта в проблемной области

• Количество лет опыта программирования

Тип Название типа CASE-

инструмен-

ты

Используе-

мость

• Да/нет (двоичная классификация)

Время Дата начала,

ожидаемая дата

окончания, ис-

текшее время

• Календарные даты

• Дни

160 Глава 4

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

относительных шкалах. Начать можно с номинальных и порядковых шкал, посте-

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

ний.

Выбирая между объективными и субъективными измерениями (метриками),

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

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

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

вовать процессы или продукты. Важно постоянно совершенствовать процессы со-

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

их результатов.

4.1.2. Модель процесса измерения

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

ределены в стандарте ISO/IEC 15939 [4] и соответствуют требованиям к процессу

стандартов ISO/IEC 12207 и ISO/IEC 15504.

Исходя из положений стандарта ISO/IEC 15939, цель процесса измерения со-

стоит в том, чтобы «собирать, анализировать и сообщать о данных, имеющих от-

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

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

управление процессами и объективно демонстрировать качество продуктов. В ре-

зультате успешного выполнения процесса измерения:

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

шения (обязательства) по проведению измерений;

• будут идентифицированы информационные потребности в процессах ин-

женерии и управления;

• будет идентифицирован и/или разработан надлежащий набор мер исходя

из информационных потребностей;

• будут идентифицированы виды деятельности по измерению;

• идентифицированные виды деятельности по измерению будут спланиро-

ваны;

• необходимые данные будут собираться, сохраняться, анализироваться, а

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

• информационные продукты будут использоваться для поддержки приня-

тия решений и предоставления объективного базиса для коммуникации;

• процесс измерения и меры будет оцениваться; и

• усовершенствования будут сообщаться инициатору и спонсору процесса

измерения».

Это определение процесса измерения гораздо шире предложенного Н. Фен-

тоном (п.4.1.1) и включает действия по инициации и подготовке процесса измере-

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

цессами и созданию инфраструктуры процесса измерений.

Стандарт ISO/IEC 15939 определяет модель процесса и устанавливает требо-

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

полнения.

Модель процесса измерения представлена на рисунке 4.1.

Глава 4 161

Процессы

инженерии и

управления

Достижение

соглашений

об измерении

и поддержка

процесса

Согла-

Оценива-

ние

измерений

Требования к измерениям

Информационные

потребности

Обратная связь к пользователю измерений

Информационные продукты

Информационные

продукты и меры

эффективности

База исторических

данных измерений

Информационные продукты

и результаты измерений

Действия по совершенствованию

Планы

Планирова-

ние

процесса

измерения

Выполне-

ние

процесса

измерения

Планы

Ядро процесса измерения

шения

Рис. 4.1. Модель процесса измерения

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

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

вершенствование процесса измерения. Задачи, охватываемые каждым из видов

деятельности, также итеративны.

Ядро процесса составляют два вида деятельности: планирование процесса из-

мерения и выполнение процесса измерения. Эта деятельность в большей степени

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

гих вида деятельности – учреждение (достижение соглашений) и поддержка про-

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

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

вования. Эти виды деятельности касаются интересов лиц, ответственных за выпол-

нение процесса измерения.

Действия, составляющие ядро процесса, непосредственно связаны с инфор-

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

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

гнозирования или других деловых целей организации.

Общий перечень действий и задач процесса измерения приведен ниже в че-

тырех рамках (рисунок 4.2), соответствующих четырем видам деятельности (дейст-

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

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

ствует порядку их выполнения. Для каждой задачи (на третьем уровне вложенно-

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

Связь между информационными потребностями и конкретными мерами из-

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

мерения. Стандарт ISO/IEC 15939 не приводит эталонной модели и, значит, не ог-

раничивает потребителей в выборе известных или построении собственных инфор-

мационных моделей.

162 Глава 4

1. Внедрить и сопровождать (поддерживать) программу измерения

1.1. Утвердить требования по измерению

1.1.1. Идентифицируются границы измерения.

1.1.2. Утверждаются обязательства по проведению измерений.

1.1.3. Обязательства доводятся до соответствующей организационной единицы.

1.2. Распределить ресурсы

1.2.1. Устанавливается личная ответственность за выполнение процесса измере-

ния внутри организационной единицы.

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

измерения.

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

2.1.Охарактеризовать организационную единицу

2.1.1. Явно описываются особенности организационной единицы, имеющие от-

ношение к выбору мер и интерпретации информационных продуктов.

2.2. Идентифицировать информационные потребности

2.2.1. Идентифицируются информационные потребности для измерения.

2.2.2. Устанавливаются приоритеты идентифицированных потребностей.

2.2.3. Выбираются информационные потребности, которые будут дальше рас-

сматриваться.

2.2.4. Выбранные информационные потребности документируются и сообщаются

заинтересованным лицам.

2.3. Выбрать меры

2.3.1. Идентифицируются меры-кандидаты, удовлетворяющие выбранным ин-

формационным потребностям.

2.3.2. Выбираются меры из числа мер-кандидатов.

2.3.3. Выбранные меры документируются с указанием имени (названия), едини-

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

ционными потребностями.

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

2.4.1. Определяются процедуры сбора данных, включая их хранение и проверку.

2.4.2. Определяются процедуры для анализа данных и составления отчетов об

информационных продуктах.

2.4.3. Определяются процедуры управления конфигурацией.

2.5. Определить критерии для оценивания информационных продуктов и процесса

измерения

2.5.1. Определяются критерии для оценивания информационных продуктов.

2.5.2. Определяются критерии для оценивания процесса измерения.

2.6. Просмотреть, одобрить и выделить ресурсы для решения задач измерения

2.6.1. Просматриваются и утверждаются результаты планирования измерения.

2.6.2. Обеспечивается возможность использовать ресурсы для осуществления за-

планированных задач измерения.

2.7. Развернуть (внедрить) поддерживающие (вспомогательные) технологии

2.7.1. Оцениваются существующие доступные поддерживающие технологии и из

них выбираются подходящие.

2.7.2. Выбранные поддерживающие технологии приобретаются и внедряются

Глава 4 163

3. Выполнить процесс измерения

3.1. Интегрировать процедуры

3.1.1. Генерация и сбор данных интегрируются в соответствующие процессы.

3.1.2. Процедуры сбора данных доводятся до ведома поставщиков данных.

3.1.3. Анализ данных и составление отчетов интегрируются в процессы.

3.2: Сбор данных

3.2.1. Данные собираются.

3.2.2. Собираемые данные сохраняются, включая любую контекстную информа-

цию, необходимую для проверки, понимания или оценивания данных.

3.2.3. Собираемые данные проверяются.

3.3. Проанализировать данные и разработать информационные продукты

3.3.1. Собираемые данные анализируются.

3.3.2. Результаты анализа данных интерпретируются.

3.3.3. Информационные продукты просматриваются.

3.4. Сообщить о результатах

3.4.1. Информационные продукты документируются.

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

4. Оценить измерение

4.1. Оценить информационные продукты и процесс измерения

4.1.1. Информационные продукты оцениваются на соответствие специфициро-

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

4.1.2. Процесс измерения оценивается на соответствие специфицированным кри-

териям оценки и делаются заключения о достоинствах процесса измерения.

4.1.3. Извлеченные уроки сохраняются в «Хранилище опыта измерения».

4.2. Идентифицировать потенциальные усовершенствования

4.2.1. Идентифицируются потенциальные усовершенствования к информацион-

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

4.2.2. Идентифицируются потенциальные усовершенствования к процессу изме-

рения.

4.2.3. Потенциальные усовершенствования доводятся до ведома заинтересован-

ных сторон.

Рис. 4.2. Перечень действий и задач в стандарте ISO/IEC 15939

Существуют разнообразные модели и механизмы трансформации информа-

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

ния мер и метрик. К ним можно отнести, например, модель, используемую в ранее

упомянутой методологии «развертывания качества» (QFD) (глава 3), или модели,

которые могут быть построены в рамках парадигмы «цель – вопрос – метрика»

(GQM).

Подходы к измерениям, основанные на парадигме GQM, базируются на до-

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

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

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

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

данных относительно установленных целей.

Целеориентированный подход к измерениям был изначально определен для

оценивания дефектов по множеству проектов в среде NASA [5]. Теперь он широко