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

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

434 Глава 9

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

UFP (unadjusted function points)). В этом случае, для оценки размера S

применяет-

ся формула:

2.1/

)(

UFPFLS ⋅⋅=

где L – коэффициент расширения кода для определенного языка программи-

рования, F – мультипликативный параметр, учитывающий влияние на затраты

сложности и среды разработки, UFP – функциональный размер в UFP, E –

параметр, учитывающий сложность разработки ПО определенного типа (варьиру-

ется от 1.04 до 1.2).

Для оценки трудозатрат применяется следующая формула:

2.14.0

)/(

tee

CSDK ⋅=

где S

– размер ПС, D – сложность управления персоналом, рейтинг, отра-

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

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

затрат, влияющие на производительность работы (эффективность работы разработ-

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

Для оценки продолжительности разработки применяется следующая фор-

мула:

4.02.0

)/(

teed

CSDt

−

Область применения модели охватывает все фазы ЖЦ ПС, в том числе, со-

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

клиент-серверные приложения, настольные, распределенные, графические и т.п., а

также наиболее распространенные методы разработки и модели ЖЦ.

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

Galorath Associates, Inc., SEER Technologies Division (http://www.gaseer.com/).

9.1.4. Методы экспертных оценок

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

высокой степенью неопределенности.

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

методов, классического метода Delphi и его расширения (WD - Wideband Delphi)

[2,6,7]. Это «ручные» методы, их отличие заключается только в том, что расширен-

ный метод Delphi предполагает проведение групповых дискуссий экспертов, а

классический – нет. Расширенный метод Delphi использовался, в частности, для

получения начальных оценок параметров при построении модели COCOMO II и ее

расширений [2].

Далее кратко рассмотрен расширенный метод Delphi. Процесс оценивания

по этому методу подобен процессу инспекций и включает следующие шаги:

Шаг 1. Планирование. Формирование экспертной группы и назначение ее ру-

ководителя (модератора). Рекомендуемый состав группы - от 3 до 5 человек. Тре-

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

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

Шаг 2. Проведение предварительного совещания. В ходе совещания произ-

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

Глава 9 435

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

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

которых эксперты указывают 3 оценки (пессимистическую, оптимистическую и

наиболее вероятную).

Шаг 3. Индивидуальная подготовка. На этой стадии эксперты независимо

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

Шаг 4. Совещание по оцениванию. В ходе совещания эксперты пытаются

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

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

На первом совещании модератор собирает анонимные ответы экспертов, вы-

полняет первоначальную оценку и определяет отклонения. На последующих сове-

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

Итерации повторяются до достижения согласия. Результирующую оценку

получают следующей формуле:

= (E

min

+ 4E

+ E

max

)/6

где E

– номинальная оценка, E

min

– минимальная, E

- наиболее вероятная, E

max

максимально возможная.

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

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

(Work Breakdown Structure). Он хорошо сочетается с методом Delphi для определе-

ния состава работ проекта и их оценки.

Имеются разные варианты применения этого метода. Согласно [2, 7] струк-

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

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

ции (например, управление проектом, обеспечение качества и др.). С каждым эле-

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

должительность и стоимость) как прогнозируемые, так и фактические. При после-

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

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

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

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

9.1.5. Метод аналогий

В настоящее время существует ряд моделей и программных инструментов

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

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

полнению баз исторических данных о проектах.

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

ANGEL (ANaloGy softwarE tooL) [8, 9, 10], в состав которого входит БД характери-

стик промышленных проектов.

Процесс применения метода аналогий в системе ANGEL состоит из следую-

щих шагов:

1. Выбор аналогов.

2. Оценка сходств и отличий.

3. Оценка качества аналогов.

436 Глава 9

4. Рассмотрение отдельных ситуаций.

5. Оценивание.

Выбор аналогов состоит в анализе БД оценок завершенных проектов-

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

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

стик проекта, содержащихся в БД. Количество сравниваемых характеристик зави-

сит от объема БД с характеристиками проектов-аналогов. Характеристики проекта

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

рактеристика – это отдельное измерение. Наиболее сходные по характеристикам

проекты будут иметь меньшее расстояние в пространстве.

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

зоваться такие метрики:

• абсолютная ошибка предсказаний (E-A);

• относительная ошибка (RE, от Relative Error)

−

• отклонение относительной ошибки (MRE, от Magnitude of Relative Error)

%100

MRE

−

• среднее отклонение относительной ошибки (MMRE, от Median Magnitude

of Relative Error)

∑

MRE

MMRE

• качество предсказаний (PRED, от Prediction)

qPRED =)(

где А – реальное значение анализируемого показателя, Е – оцененное (про-

гнозное) значение показателя, n – количество проанализированных проектов, q –

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

проектов), для которых MMRE

≤

Необходимость рассмотрения отдельных ситуаций может возникнуть в том

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

ключить из рассмотрения.

Метод аналогий применяется также в инструменте SPR KnowledgePLAN [11].

В нем оценивание затрат и планирование работ по проекту также основано на об-

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

ляет оценивать затраты, проводить анализ причин (анализ "what if"), распределение

сроков по фазам разработки и видам работ (в частности, по методологии RUP

(Rational Unified Process)). Инструмент поддерживает оценку размера в строках

кода, единицах функционального размера (по FPА), а также расчет размера мето-

дом аналогий. Имеет интерфейс с Microsoft Project и другими промышленными

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

Глава 9 437

9.1.6. Нейронные сети

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

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

в частности, нейронные сети [2].

Согласно определению, приведенному в [12], нейронные сети представляют

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

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

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

блюдений (для этих же или других переменных) после прохождения этапа так на-

зываемого обучения на имеющихся данных».

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

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

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

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

Пример нейронной сети представлен на рисунке 9.3 (из [12]).

Рис. 9.3. Пример нейронной сети

Нейронная сеть для оценивания одной или нескольких стоимостных характе-

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

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

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

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

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

Эти данные представляют входные параметры модели (например, размер,

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

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

уточняются до получения приемлемой разницы между реальными и прогнозными

данными [13].

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

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

например, пакет STATISTICA Neural Networks [14].

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

ские сети [15].

438 Глава 9

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

в настоящее время ограничено лишь экспериментальными исследованиями [2].

9.1.7. Динамические методы

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

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

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

тяжении разработки (т.е. являются динамическими). Это существенно отличает ди-

намические методы от других методов оценивания.

В основе методов лежит классический аппарат имитационного моделирова-

ния систем. Графически имитационная модель представляется в виде модифициро-

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

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

ложительными и отрицательными циклами обратной связи [2], а математически

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

мическая модель, предложенная в [16], позволяет предсказывать изменения стои-

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

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

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

В [2] отмечено, что динамические методы хороши для планирования и кон-

троля, но их трудно настраивать (калибровать).

9.1.8. Неформальные эмпирические методы

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

шим распространение благодаря популярности методологии Extreme Programming

(глава 11), можно отнести метод Planning Game.

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

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

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

быть решены в первую очередь [17].

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

(как заказчики (пользователи), так и разработчики), которые вовлекаются в обсуж-

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

историй» (“user stories”). Функциональные аспекты этих историй описывают заказ-

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

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

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

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

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

3 недели. Каждая история, «планируемая» к выпуску, декомпозируется на несколь-

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

тестирования. Этот процесс может быть «проигран» неоднократно до достижения

компромисса заказчика и разработчиков.

Процесс планирования по методу Planning Game охватывает весь ЖЦ проек-

та, повторяясь при подготовке каждого нового выпуска ПС.

Глава 9 439

9.2. Семейство моделей оценивания затрат COCOMO

9.2.1. Обзор моделей

В настоящее время на базе известной иерархической модели COCOMO

[1]

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

типов программных систем. Поэтому сегодня можно говорить о семействе компо-

зиционных моделей COCOMO, основанных на общем подходе, и использующих

сочетание экспертного и алгоритмического методов оценивания [18].

В таблице 9.1 перечислены основные модели семейства и их назначение.

Таблица 9.1. Семейство моделей COCOMO

Краткое на-

звание

Полное название Назначение

COCOMO II Constructive Cost Model Полная трехуровневая модель оценки затрат

для новых проектов ПС (только ПО)

COINCOMO Constructive Incremental

COCOMO

Учет и распределение затрат при итеративной

разработке с интеграцией оценок для проекта

COQUALMO Constructive Quality

Model

Оценка количества оставшихся дефектов в

программных продуктах

COPROMO Constructive Productiv-

ity-Improvement Model

Оценка эффективности вложения ресурсов в

новые технологии для улучшения производи-

тельности

COPLIMO Constructive Product

Line Investment Model

Поддержка оценивания стоимости линии про-

дуктов и анализ отдачи от инвестиций

iDave Information Dependabil-

ity Attribute Value Esti-

mation

Оценка и отслеживание отдачи от инвестиций

в обеспечение надежности ПС (включая безо-

пасность, безотказность, устойчивость и др.)

COPSEMO Constructive Phased

Schedule & Effort Model

Распределение оценок затрат по стадиям раз-

работки. Применяется совместно с CORADMO

CORADMO Constructive Rapid Ap-

plication Development

Model

Оценка и распределение затрат для небольших

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

рой разработки (RAD)

COPROMO

Constructive Productiv-

ity-Improvement Model

Прогнозирование эффективности инвестиро-

вания ресурсов в новые технологии для увели-

чения производительности

COSYSMO Constructive Systems

Engineering Cost Model

Оценка затрат на протяжении полного ЖЦ (в

соответствии с ISO/IEC 15288 [19])

COCOTS

Constructive Commer-

cial-Off-The-Shelf Cost

Model

Оценка затрат, связанных с оценкой и инте-

грацией готовых программных продуктов

(COTS - Commercial-Off-The Shelf ) в единую

ПС

COSOSIMO Constructive System of

Systems Integration Cost

Model

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

интеграцией крупных интегрированных рас-

пределенных ПС

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

кованной в 1985 году. Там эта модель называется КОМОСТ. Мы же используем ее ориги-

нальное название - COCOMO.

440 Глава 9

Модели COCOMO II и COINCOMO используют одну и ту же математиче-

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

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

Независимые модели (COCOTS, COSYSMO, COSOSIMO) могут применяться

как самостоятельно, так и с СОСОМО II.

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

применения вкратце даны в таблице 9.2 [18].

Таблица 9.2. Рекомендации по применению моделей для оценивания затрат

Применять модель… Если оцениваемые работы включают…

COCOMO II Разработка программных компонентов и ПС в целом

COCOTS Выбор, настройка и интеграция готовых к использованию

продуктов (COTS-продуктов)

COSYSMO Системная инженерия (проектирование, спецификация и ин-

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

тему)

COSOSIMO Спецификация, приобретение и интеграция двух и более от-

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

аппаратные и программные)

COCOMO II и COCOTS Разработка программных компонентов и ПС с применением

COTS-продуктов.

COSYSMO и COCOMO II Системная инженерия и разработка ПО для одной системы

COSYSMO и COSOSIMO Системная инженерия отдельных систем и интеграция многих

систем

COCOMO II, COSYSMO,

COCOTS, COSOSIMO

Системная инженерия, разработка ПО, интеграция крупно-

масштабных систем и COTS-продуктов

Остальные модели представляют расширения базовой модели СОСОМО II и

применяются вместе с ней.

Основное отличие всех моделей семейства – учет разных видов работ, факто-

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

трат по стадиям и видам работ, в зависимости от модели ЖЦ. Поскольку модели

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

щее время ведутся работы по их интеграции в единую модель оценивания [18].

Более подробно в главе рассмотрена базовая модель семейства - модель оце-

нивания затрат COCOMO II. Описание назначения остальных моделей можно най-

ти на сайте по адресу: http://www.sunset.usc.edu/research/

9.2.2. Модель COCOMO II. Общая характеристика

Модель COCOMO II учитывает только те затраты, которые связаны с разра-

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

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

другими общесистемными работами).

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

Глава 9 441

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

нивания на протяжении всего периода разработки ПС и является трехуровневой:

Предварительная модель (Application Composition Model). Обеспечивает

предварительную оценку трудозатрат на ПС на ранних стадиях разработки. Модель

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

с использованием интегрированных сред (ICASE).

Предпроектная модель (Early Design Model). Обеспечивает предвари-

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

граммных компонентов на предпроектных стадиях ЖЦ. Может применяться для

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

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

Детальная модель (Post Architecture Model). Уточняет оценку, выполнен-

ную по Предпроектной модели. Обеспечивает поуровневую оценку трудозатрат на

разработку ПС - от программных компонентов до программных модулей. Может

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

дении.

В числе достоинств модели СОСОМО II следует отметить:

1. Определенность. Модель включает определения основных понятий и ко-

личественных характеристик без ограничения типов ПС.

2 Точность. Точность модели согласована с большим количеством фактиче-

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

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

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

модели).

3. Объективность. Идеальная модель оценки трудозатрат характеризуется

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

уровень сложности. Однако поскольку этот уровень сложности субъективен, не-

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

тов. Данная модель повышает объективность оценок путем применения шкалы оце-

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

4. Детальность. Модель позволяет последовательно уточнять оценки трудо-

затрат по мере разработки (от предварительных, грубых оценок на уровне ПС до

детальных оценок на уровне модулей).

5. Область применения. Модель применима для оценки трудозатрат на раз-

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

6. Простота применения. Модель относительно проста для понимания и

применения. Входные данные для расчета определяются экспертным путем.

9.2.3. Оценка трудозатрат по Предварительной модели

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

в целом. Прогнозируемый размер ПС определяется методом Object Points for

ICASE (см. главу 8).

Расчет трудозатрат на разработку ПС производится по следующему алгорит-

му.

1. Вычисляется функциональный размер ПС. Для этого сначала методом Ob-

ject Points for ICASE [20] определяется общий функциональный размер ПС (ОР) по

442 Глава 9

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

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

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

тов ПС (NOP) по формуле

NOP = (OP – (100 - %Reuse))/100

где %Reuse – доля (в процентах) повторно используемых объектов (экранов, отче-

тов и модулей).

2. Оценивается уровень производительности, PROD, как среднее значений

атрибутов «Опыт работы и квалификация разработчика» и «Зрелость и возможно-

сти ICASE» (таблица 9.3).

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

формуле Т = NOP/PROD

Таблица 9.3. Связь стоимостных атрибутов и производительности

Опыт работы и квали-

фикация разработчика

Очень

низкий

Низкий Номинальный Высокий Очень

высокий

Зрелость и возможности

ICASE

Очень

низкий

Низкий Номинальный Высокий Очень

высокий

PROD 4 7 13 25 50

9.2.4. Общие уравнения номинальных затрат

Рассматриваемые далее Предпроектная и Детальная модели COCOMO II ис-

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

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

Номинальные трудозатраты на разработку ПС (средние) рассчитываются в

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

месяц, по формуле (1).

ном

⋅=

(1)

где А = 2.45 константа, полученная по результатам статистического анализа

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

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

строк исходного кода KSLOC.

В - показатель степени при размере V, учитывающий изменение эффективно-

сти процесса разработки (производительности труда) при увеличении размера ПC.

Определяется по формуле (2):

∑

⋅+=

01.091.0

ФВ

(2)

где Ф

- значения соответствующих коэффициентов атрибутов масштаба.

Для оценок Т

ном

в других единицах измерения необходимо:

- для расчета в человеко-годах - разделить Т

ном

на 12;

- для расчета в человеко-днях - умножить на 19.

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

ровке модели COCOMO II 2000 года [21].

Глава 9 443

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

формуле (3):

ном

))01.1(2.038.0(

67.3

−⋅+

⋅=

(3)

9.2.5. Интегральные атрибуты масштаба разработки

Коэффициенты масштаба разработки ПC определяются в результате анализа

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

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

рительной, так и для Детальной модели.

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

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

емкости разработки при увеличении масштаба разработки. Например, «Очень вы-

сокий» уровень оценок (рейтинг) этих атрибутов характеризует проект ПС, разра-

батываемый относительно небольшим коллективом, обладающим большим опы-

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

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

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

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

В таблице 9.4 приведены интегральные атрибуты масштаба, упорядоченные

по шкале оценок от «Очень низкий» до «Очень высокий», и даны уровни ранжиро-

вания этих атрибутов.

Таблица 9.4. Рейтинги интегральных атрибутов масштаба

Уровень оценки Атрибут

масштаба

Очень

низкий

Низкий Номи-

нальный

Высокий Очень вы-

сокий

Сверх

высокий

Новизна

проекта

(НОВ)

Полно-

стью

новый

Во мно-

гом новый

В какой-

то степени

новый

В основ-

ном из-

вестный

В большой

степени

известный

В полной

мере из-

вестный

Жесткость

проекта

(согласо-

ванность)

(СОГЛ)

Строгая

согласо-

ванность

Допуска-

ются не-

которые

компро-

миссы

Значи-

тельная

Относи-

тельная

Незначи-

тельная

При не-

обходи-

мости

Управле-

ние рис-

ком/ архи-

тектурой

(УР)

Слабое

20%

В какой-

то мере

40%

Зачастую

60%

Как пра-

вило

75%

В основном

90%

Полное

100%

Коллекти-

визм

(КОЛЛ)

Сложное

взаимо-

действие

Затрудне-

но в неко-

торой сте-

пени

Зачастую

коллек-

тивная

работа

В основ-

ном

кол-

лективная

работа

Высокая

степень

взаимодей-

ствия

Непре-

рывное

взаимо-

действие

Технологи-

ческая зре-

лость раз-

работки

(ТЗР)

СММ

Уровень

1 (ниже

средне-

го)

СММ

Уровень 1

(выше

среднего)

СММ

Уровень 2

СММ

Уровень 3

СММ Уро-

вень 4

СММ

Уровень 5