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

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

Глава 3

124

Таблица 3.2. Характеристики качества ПС

№ Наименование ха-

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

Определение характеризуемых свойств ПС

Функциональность

(functionality)

Свойства ПС, обусловливающие ее способность выполнять

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

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

виях

Надежность

(reliability)

Свойства ПС, обусловливающие ее способность сохранять

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

виях

Удобство

применения

(usability)

Свойства ПС, обусловливающие ее способность быть легко

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

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

Эффективность

(efficiency)

Свойства ПС, обусловливающие ее способность обеспечи-

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

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

Сопровождаемость

(maintainability)

Свойства ПС, обусловливающие возможность ее эффектив-

ной модификации. Модификация может включать корректи-

ровку, усовершенствование или адаптацию ПС к из

менениям

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

Переносность

(portability)

Свойства ПС, обусловливающие ее способность быть пере-

носимой из одной среды в другую

Характеристики качества ПС подразделяются на подхарактеристики. Их пе-

речень представлен в таблице 3.3

Таблица 3.3. Подхарактеристики характеристик качества ПС

№ Наименование под

характеристики

Определение характеризуемых свойств ПС

1 Подхарактеристики функциональности

1.1

Функциональная

пригодность

(suitability)

Свойства ПС, обусловливающие ее способность предостав-

лять надлежащее множество функций для решения специ-

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

1.2

Точность

(accuracy)

Свойства ПС, обусловливающие ее способность обеспечи-

вать правильные или согласованные результаты или воз-

действия с необходимой степенью точности

1.3

Способность к

взаимодействию

(interoperability)

Свойства ПС, обусловливающие ее способность взаимодей-

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

ми

1.4

Защищенность

(security)

Свойства ПС, обусловливающие ее способность обеспечи-

вать защиту информации от несанкционированного доступа

лиц или систем на чтение и модификацию, и ее доступность

для лиц и систем, обладающих правами доступа

Данный перечень подхарактеристик соответствует стандарту ISO/IEC 9126-1 и от-

личается от приведенного в стандарте ДСТУ 2850, который гармонизирован с более ранней

версией стандарта ISO/IEC 9126 (версией 1991 года).

Глава 3 125

№ Наименование под

характеристики

Определение характеризуемых свойств ПС

2 Подхарактеристики надежности

2.1

Завершенность

(maturity)

Свойства ПС, обусловливающие ее способность избежать

отказа из-за содержащихся в ней дефектов

2.2

Отказоустойчи-

вость

(fault tolerance)

Свойства ПС, обусловливающие ее способность поддержи-

вать установленный уровень функционирования в условиях

проявления дефектов в ПС, ошибок в данных или наруше-

ний специфицированного интерфейса

2.3

Восстановимость

(recoverability)

Свойства ПС, обусловливающие ее способность возобнов-

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

вать поврежденные программы и данные

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

3.1

Понятность

(understandability)

Свойства ПС, обеспечивающие пользователю возможности

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

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

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

3.2

Изучаемость

(learnability)

Свойства ПС, обеспечивающие пользователю возможность

освоить приемы ее применения

3.3

Управляемость

(operability)

Свойства ПС, обеспечивающие пользователю возможность

управлять или контролировать ее действия

3.4

Привлекатель-

ность

(attractiveness)

Свойства ПС, обеспечивающие ее притягательность для

пользователя

4 Подхарактеристики эффективности

4.1

Временная эффек-

тивность

(time behaviour)

Свойства ПС, обусловливающие ее способность обеспечи-

вать надлежащее время отклика (ответа) и обработки зада-

ний, а также уровень пропускной способности при выпол-

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

4.2

Используемость

ресурсов

(resource utilization)

Свойства ПС, обусловливающие ее способность использо-

вать надлежащие ресурсы в нужные периоды времени при

выполнении своих функций в установленных условиях

применения

5 Подхарактеристики сопровождаемости

5.1

Анализируемость

(analyzability)

Свойства ПС, обусловливающие возможность диагностиро-

вания ее недостатков или причин отказов, а также иденти-

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

5.2

Изменяемость

(changeability)

Свойства ПС, обусловливающие возможность выполнения

установленных видов модификации

5.3

Стабильность

(stability)

Свойства ПС, обусловливающие ее способность минимизи-

ровать неожиданные эффекты модификаций

5.4

Тестируемость

(testability)

Свойства ПС, обеспечивающие ее способность содейство-

вать проверке модифицированного ПО

6 Подхарактеристики переносности

6.1

Адаптируемость

(adaptability)

Свойства ПС, обусловливающие ее способность адаптиро-

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

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

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

Глава 3

126

№ Наименование под

характеристики

Определение характеризуемых свойств ПС

6.2

Удобство

установки

(installability)

Свойства ПС, обусловливающие ее способность к инстал-

ляции в специфицированной среде

6.3

Способность к со-

существованию

(co-existence)

Свойства ПС, обусловливающие ее способность сосущест-

вовать с другими независимыми ПС в общей среде, разде-

ляя общие ресурсы

6.4

Замещающая спо-

собность

(replaceability)

Свойства ПС, обусловливающие ее способность использо-

ваться вместо других специфицированных ПС в среде их

применения

Кроме представленных в таблице подхарактеристик, с каждой из шести ха-

рактеристик качества связана подхарактеристика «Соответствие нормам и прави-

лам (compliance)». Это означает, что каждая из указанных характеристик должна

отвечать требованиям соответствующих стандартов (по обеспечению надежности,

сопровождению и др.) для определенного класса ПС.

В отличие от модели, применимой для описания внутренних и внешних ат-

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

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

тырем характеристикам (таблица 3.4).

Таблица 3.4. Характеристики эксплуатационного качества ПС

№

Наименование

характеристики

Определение характеристики

Результативность

(effectiveness)

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

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

контексте использования ПС

Продуктивность

(productivity)

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

зователями заданной эффективности решения задач в уста-

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

Безопасность

(safety)

Уровень риска нанесения ущерба (материального и морально-

го) - вреда здоровью людей, бизнесу, имуществу, окружаю-

щей среде при использовании ПС в установленном контексте

Удовлетворен-

ность

(satisfaction)

Степень, в которой пользователь удовлетворен ПС в опреде-

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

На степень удовлетворенности влияют отношение пользова-

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

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

отношение к эффективности, продуктивности и безопасности

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

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

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

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

точно для обеспечения гарантии удовлетворения критериев эксплуатационного ка-

чества. Например, надежность может быть измерена и оценена внешне, путем на-

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

ний за работой ПС, а также «измерена» внутренне, путем проведения инспекции

Глава 3 127

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

ня устойчивости к аномалиям.

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

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

особенностей продукта и процесса разработки.

В представленной модели все множество атрибутов ПС, характеризующих ее

качество, образует иерархическую структуру характеристик и подхарактеристик.

Наивысший уровень этой структуры состоит из характеристик качества, а самый

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

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

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

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

внешние подхарактеристики качества (такие как функциональная пригодность,

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

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

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

быть прослежен обратно к внешнему качеству (например, к функциональной при-

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

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

3.2.2. Метрики в обобщенной модели качества

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

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

качества и описаны в частях 2, 3 и 4 стандарта ISO/IEC 9126, соответственно.

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

формации:

• имя метрики. Соответствующие метрики внутреннего и внешнего каче-

ства имеют одинаковые имена;

• назначение метрики. Сформулировано в виде вопроса, на который дает

ответ применение метрики;

• метод применения. Содержит правила получения данных и схему их

применения в метрике;

• формула и элементы данных. Указывается формула вычисления (или

формулы) и поясняются участвующие в ней элементы данных;

• интерпретация измеренных данных. Диапазон значений и предпочти-

тельное значение;

• тип шкалы метрики. Один из типов шкалы - номинальная, порядковая,

интервальная, относительная или абсолютная;

• тип меры. Один из типов меры – мера размера, времени, счетная мера;

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

• процесс ЖЦ. Указывается наименование процесса ЖЦ ПС, в котором ре-

комендовано применение метрики при проведении измерения;

• получатель. Указываются потребители результатов измерения.

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

стик представлены в приложении 2.

Уровень определения требований к эксплуатационному, внешнему и внут-

реннему качеству, множество и тип объектов измерения и измеряемых атрибутов,

Глава 3

128

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

нения процедур измерения и оценивания качества зависит от стадии ЖЦ ПС (рису-

нок 3.4).

Реальный мир

(реальные условия

применения ПС)

Определение

потребностей в

ПС и подготовка

предложений

Поведение

системы

(внешние атрибуты

ПС)

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

требований к ПС

Проектирование

и реализация ПС

Внутренние

атрибуты ПС

определяют

Потребности

пользовате-

лей

Эксплуа-

тацион-

ное

качество

Метрики

эксплуатаци-

онного

качества

Требования

к внешнему

качеству

Внешнее

качество

показывает

Внешние

метрики

отражает

Требования

к внутрен-

нему

качеству

Внутрен-

нее

качество

Внутренние

метрики

отражает

показывает

Функционирование

Системная

интеграция и

тестирование

Проектирование

и реализация ПС

Рис.3.4. Качество в ЖЦ ПС

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

различных стадиях ЖЦ подытожены в таблице 3.5.

Метрики качества не исчерпываются указанным в данной версии стандарта

множеством. Специализированные базовые метрики размера можно найти, напри-

мер, в ISO/IEC 14143 [6], а метрики временной эффективности – в ISO/IEC 14756

[7]. Широкий спектр метрик представлен на сайте R.S.Pressman&Associates, inc.

http://www.rspa.com/spi/metrics-process.html.

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

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

иерархическими по природе.

Одна из первых иерархических моделей качества ПС была предложена Мак-

Коллом в 1977 году [8]. Наивысший уровень деления в модели отражает три аспек-

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

и взаимодействию с аппаратным обеспечением.

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

11 факторов качества и затем на 23 критерия качества.

Глава 3 129

Таблица 3.5. Использование метрик на стадиях ЖЦ

Использование внутренних метрик Использование внешних метрик

Стадии подготовки предложений и определения требований к ПС

Используются для:

• спецификации плана повышения качест-

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

• описания количественных подцелей

внутреннего качества проекта и/или проме-

жуточных продуктов ПС по характеристи-

кам, указанным в модели.

Источники данных: потребности пользовате-

лей, описания предложений, спецификации

требований

Используются для:

• спецификации требований к качест-

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

• описания количественных целей

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

указанным в модели.

Источники данных: потребности пользо-

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

фикации требований

Стадии проектирования, кодирования и автономного тестирования ПС

Используются для:

• оценивания достигнутого уровня реали-

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

ристикам, указанным в модели

• выявления отклонений от подцелей

внутреннего качества

• предсказания значений внешних метрик

и внешнего качества

Источники данных: результаты обзоров, ста-

тического анализа и измерений специфика-

ций, проекта, кода и др.

Используются для:

• предсказания качества при исполь-

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

Источники данных: результаты анализа

сценариев использования ПС, исполняе-

мых прототипов приложений в ходе их

тестирования, отчеты о результатах тес-

тирования

Стадии интеграции, системного тестирования, инсталляции, приемки ПС

Используются для:

• оценивания достигнутого уровня реали-

зации плана повышения качества проекта

и/или промежуточных продуктов

Источники данных: результаты обзоров, ста-

тического анализа и измерений специфика-

ций, проекта, программного кода и др.

Используются для:

• представления характеристик каче-

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

• подтверждения того, что достигну-

тое качество удовлетворяет пользовате-

ля

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

качества

Источники данных: сценарии использо-

вания ПС при тестировании и эксплуата-

ции, а также совместно с другими про-

граммными системами

Стадия эксплуатации ПС

Используются для:

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

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

Источники данных: результаты обзоров, ста-

тического анализа и измерений специфика-

ций, проекта, программного кода и др.

Используются для:

• представления характеристик экс-

плуатационного качества ПС, опреде-

ленных в модели

• подтверждения того, что имеющийся

уровень качества все еще удовлетворяет

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

Источники данных: сценарии использо-

вания ПС и сценарии ее поведения в хо-

де эксплуатации, отчеты о претензиях

пользователей

Глава 3

130

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

качества, оцениваемые по шкале от 0 до 10. Для оценивания факторов используют-

ся следующие метрики качества [9]:

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

• точность управления и вычислений,

• степень стандартности интерфейсов,

• функциональная полнота,

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

• степень стандартности форматов данных,

• устойчивость к ошибкам,

• эффективность работы,

• расширяемость,

• широта области потенциального использования,

• независимость от аппаратной платформы,

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

• модульность,

• удобство работы,

• защищенность,

• самодокументированность,

• простота работы,

• независимость от программной платформы,

• возможность соотнесения проекта с требованиями,

• удобство обучения.

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

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

иерархическая структура.

В 1978 году Боэм предложил иерархическую модель, подобную по природе

модели МакКолла [10]. Начальные разделения по иерархии в двух моделях схожи,

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

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

щие критерии качества. В пределах этих уровней устанавливается в целом 19 кри-

териев качества. Критерии в этой модели не независимы и их взаимодействие друг

с другом часто вызывает конфликты.

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

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

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

нию качества ПС.

В 1987 году Ваттсом [11] была предложена модель, развивающая модель

МакКолла, а за ней в 1988 году появилась модель Дьюча и Виллиса [12]. Эта мо-

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

связываться с факторами качества и критериями качества, соответственно.

Наконец, в 1991 году Международная организация по стандартизации (ISO)

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

щую 6 характеристик качества: функциональность, надежность, эффективность,

удобство применения, сопровождаемость и переносимость (стандарт ISO 9126,

1991 год). Слабость этой модели состоит в том, что не все подхарактеристики оп-

Глава 3 131

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

интерпретаций. Эти недостатки устранены в новой модели ISO/IEC 9126, которая

обсуждалась выше (раздел 3.2).

Существуют трудности в применении иерархических моделей качества [13].

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

теристик качества) было бы естественнее включать в функциональные требования

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

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

левого требования к интерфейсу ПС, а ее достижение - проверяться путем тестиро-

вания. Таким же образом можно поступить с характеристикой «переносимость» и

рядом других.

Во-вторых, иерархические модели являются статическими по природе, то

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

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

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

Эти модели вообще не дают менеджерам проекта никаких указаний о том,

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

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

Как альтернативу классическим иерархическим моделям, Джилб [14] пред-

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

ристик качества, но имеет важные отличия:

• модель локально адаптируема (в масштабе организации);

• характеристики ресурсов включены в модель наряду с характеристиками

качества;

• модель связана с эволюционной моделью процесса разработки.

В рамках этой модели Джилб выделил четыре характеристики качества и че-

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

процесса настройки модели. Предложенные характеристики качества таковы: рабо-

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

ристики ресурсов - время, деньги, люди и инструменты.

Еще одна известная модель качества - конструктивная модель качества

(COQUAMO), которая была разработана Китченхем. Эта модель использует неко-

торые факторы качества из классических моделей Джилба, МакКолла и Боэма и

затем помещает их в рамки соответствующих категорий конкретного проекта [15].

Отряд иерархических моделей продолжил пополняться и в последующие го-

ды. Так в 1996 году Дромей предложил гибкую модель, которая позволяет в боль-

шей степени учесть особенности разрабатываемой ПС [16]. Для построения моде-

ли нужно:

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

использовать для оценивания;

2) построить список всех компонентов или модулей системы;

3) идентифицировать определяющие (главные) свойства каждого компонен-

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

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

чества;

5) оценить правильность модели;

Глава 3

132

6) установить слабые места и устранить их (возвращаясь в цикле на один из

предыдущих шагов 1 - 5).

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

между атрибутами (характеристиками) и суб-атрибутами (подхарактеристиками)

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

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

В рамках программы ESPRIT разработан метод и инструмент Squid (Software

quality in Development) для управления, оценки и предсказания качества продукта и

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

низации и базироваться на своей собственной базе данных [17]. Squid специфици-

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

тех пор, пока не станут непосредственно измеримыми (атрибутами). Как и в модели

по стандарту ISO/IEC 9126-1, характеристики и атрибуты качества могут быть

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

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

данных.

Достоинство модели состоит в том, что она учитывает большинство факто-

ров, влияющих на качество ПС (глава 1), помогая избежать конфликтов между раз-

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

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

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

измерений.

Своеобразную модель качества COQUALMO (COnstructive QUALity MOdel)

недавно предложил Боэм, продолжая развитие модели COCOMO для определения

трудоемкости и стоимости разработки ПС [18]. Эта модель ориентирована на дос-

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

лей. Модель позволяет определить «цену ошибки», своевременное устранение ко-

торой приводит к повышению качества.

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

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

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

ности). Именно эта точка зрения учтена, например, при разработке модели в SATC

(Software Assurance Technology Center) [13]. Предложенная модель поддерживает

классификацию рисков и последующую полную оценку риска проекта. Она описы-

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

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

щих менеджера.

3.2.4. Не иерархические модели качества

Стандарт ISO/IEC 9126 включает большое количество мер, однако они не от-

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

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

их прямых и косвенных мер.

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

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

чества ПС.

Глава 3 133

В 1999 году А.Абраном и Л.Буглионе была предложена модель QEST (Qual-

ity Factor + Economic, Social and Technical dimensions) [19]. Это трехмерная струк-

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

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

ния на продукт).

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

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

измеренных величин по каждому из измерений, а вершина - нормализованное оп-

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

Рис. 3.5. Модель QEST для оценивания качества ПС в ходе проекта

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

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

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

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

Три измерения модели отражают:

Экономический аспект (E). Точка зрения менеджеров на стоимость и гра-

фик разработки (поставки) продукта.

Социальный аспект (S). Точка зрения пользователей на характеристики

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

Технический аспект (T). Точка зрения разработчиков на обеспечение, из-

мерение и оценивание достижения требований к качеству продукта.

Вершина (P) тетраэдра описывает максимальный уровень качества продукта

(эффективности проекта).

Стороны правильного тетраэдра (пирамиды) равны единице. Все три измере-

ния нормализованы на интервале {0,1}. Значения по каждому измерению представ-

ляют собой взвешенные суммы списка n значений нормализованных коэффициен-

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

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

, Q

}. Полу-

ченные точки соединяются линиями. Образуется сечение пирамиды, «отделяю-

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

формируются «реальные срезы» эффективности проекта.

Эффективность проекта измеряется с помощью любого из трех геометриче-

ских объектов: