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

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

444 Глава 9

Каждому уровню оценок каждого интегрального атрибута масштаба соответ-

ствует числовой коэффициент масштаба Ф

(таблица 9.5). Шкала оценок атрибутов

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

Таблица 9.5. Значения коэффициентов масштаба

Уровень оценки

Интеграль-

ный атрибут

масштаба

Очень

низкий

Низкий Номи-

нальный

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

высокий

Сверх

высокий

НОВ 6.20 4.96 3.72 2.48 1.24 0.00

СОГЛ 5.07 4.05 3.04 2.03 1.01 0.00

УР 7.07 5.65 4.24 2.83 1.41 0.00

КОЛЛ 5.48 4.38 3.29 2.19 1.20 0.00

ТЗР 7.8 6.24 4.68 3.12 1.56 0.00

Для учета атрибутов масштаба в показателе степени В (формула 1) необхо-

димо выполнить следующую процедуру.

Процедура определения коэффициентов масштаба разработки:

Шаг 1. Экспертным методом оценить каждый интегральный атрибут

масштаба.

Если какой-либо интегральный атрибут определить сложно, - следует оце-

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

ные оценки интегрального атрибута.

Шаг 2. Для каждого интегрального атрибута по таблице 9.5 определить

соответствующий коэффициент масштаба

Шаг 3. Просуммировать коэффициенты и вычислить параметр В.

Так как атрибуты масштаба, перечисленные в таблице 9.4, являются инте-

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

Описание интегральных атрибутов масштаба.

Новизна проекта (НОВ)- отражает степень влияния на трудозатраты уровня

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

предметной области (таблица 9.6).

Таблица 9.6. Единичные атрибуты интегрального атрибута НОВ

Уровень оценки

Новизна проекта

Очень

низкий

Номинальный-

высокий

Очень

высокий

Понимание целей ПС в организации Общее Значительное Полное

Опыт в разработке данного типа ПС Умеренный Значительный Большой

Необходимость разработки новых архи-

тектур и методов (алгоритмов) обработки

данных

Большая Умеренная Мини-

мальная

Необходимость одновременной разработ-

ки нового аппаратного обеспечения и

операционных процедур

Большая Умеренная Незначи-

тельная

Глава 9 445

Жесткость (согласованность) проекта (СОГЛ)- этот атрибут отражает

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

Оценивать этот атрибут можно непосредственно либо по единичным атрибутам,

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

Таблица 9.7. Единичные атрибуты интегрального атрибута СОГЛ

Уровень оценки

Жесткость (согласованность) проекта

Очень

низкий

Номиналь-

ный-высокий

Очень высо-

кий

Необходимость строгой согласованности с

предопределенными требованиями к ПС

Полная Значительная Небольшая

Необходимость строгого соответствия спе-

цификациям внешних интерфейсов

Полная Значительная Небольшая

Материальное стимулирование досрочного

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

Высокое Среднее Малое

Управление риском/архитектурой (УР)- этот атрибут отражает влияние на

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

Таблица 9.8. Единичные атрибуты интегрального атрибута УР

Уровень оценки

Управление рис-

ком/архитектурой

Очень

низ-

кий

Низ-

кий

Номи-

наль-

ный

Высо-

кий

Очень

высо-

кий

Сверх

высо-

кий

Идентифицирует ли план

управления риском (при

наличии) критические к рис-

ку элементы ПС, устанавли-

вает ли контрольные точки в

ЖЦ ПС для проверок и уст-

ранения риска

Нет Слабо В не-

кото-

рой

степе-

ни

В значи-

тельной

степени

Почти

полно-

стью

Пол-

ностью

Соответствуют ли плану

управления риском продол-

жительность, бюджет и сро-

ки проверок и устранения

риска

Нет Слабо В не-

кото-

рой

степе-

ни

В значи-

тельной

степени

Почти

Пол-

ностью

Пол-

ностью

Доля (процент) в продолжи-

тельности разработки, при-

ходящаяся на обоснование

архитектуры ПС (проектных

решений) при заданных об-

щих целях проекта

5% 10% 17% 25% 33% 40%

Доля (процент) разработчи-

ков высокой квалификации

(аналитиков), которыми

располагает проект

20% 40% 60% 80% 100% 120

Существует ли инструмен-

тальная поддержка для уст-

ранения рисков элементов,

верификации проектных

решений

Нет Неболь

шая

Весо-

мая

Хоро-

шая

Почти

полная

Полная

446 Глава 9

Уровень оценки

Управление рис-

ком/архитектурой

Очень

низ-

кий

Низ-

кий

Номи-

наль-

ный

Высо-

кий

Очень

высо-

кий

Сверх

высо-

кий

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

при выборе ключевых эле-

ментов архитектуры проекта

(интерфейсов, технических

средств, технологии и др.)

Очень

боль-

шой

Значи-

тель-

ный

Суще-

ствен-

ный

Опреде-

ленный

Малый Совсем

малый

Число и критичность эле-

ментов, подверженных рис-

ку

>10

кри-

тичных

5-10

кри-

тичных

2-4

кри-

тичных

критич-

ный

не кри-

тичных

не кри-

тичных

Оценка «Сверх высокий» не будет учитывать влияние этого атрибута на тру-

дозатраты. Значения коэффициентов данного атрибута убывают по мере увеличе-

ния уровня оценки по шкале.

Коллективизм (КОЛЛ)- этот атрибут отражает степень влияния на трудоза-

траты слаженноcти работы коллектива разработчиков и пользователей (таблица

9.9).

Таблица 9.9. Единичные атрибуты интегрального атрибута КОЛЛ

Уровень оценки

Коллективизм Очень

низкий

Низкий Номи-

наль-

ный

Высо-

кий

Очень

высо-

кий

Сверх

высокий

Согласованность

целей коллектива

Мини-

мальная

Незна-

читель-

ная

Относи-

тельная

Значи-

тель-

ная

Большая Полная

Способность и го-

товность членов

коллектива приспо-

сабливаться к целям

других членов

Малая Незна-

читель-

ная

Относи-

тельная

Значи-

тель-

ная

Большая Полная

Опыт участников

работы в составе

данного коллектива

Нет Малый Незна-

читель-

ный

Относи

тель-

ный

Значи-

тельный

Большой

Формирование кол-

лектива по принци-

пу доверия и взаи-

модействия

Нет В очень

малой

степени

В незна-

читель-

ной сте-

пени

Относи

тельно

В значи-

тельной

степени

В боль-

шой сте-

пени

Технологическая зрелость процесса разработки (ТЗР)- это интегральный

атрибут, отражающий зависимость трудозатрат от эффективности организации и

управления процессами разработки ПС в организации.

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

ли оценки технологической зрелости СММ, которая подробно описана в главе 12.

Для оценивания атрибута «Технологическая зрелость процесса разработки»

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

Глава 9 447

вым направлениям процесса разработки (КРА). Для этого (в простейшем случае)

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

по каждому направлению (таблица 9.10.).

Таблица 9.10. Оценка уровня зрелости по КРА

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

направления

КРА

Почти

всегда

>90%

случаев

Часто

60-90%

случаев

Почти

поровну

40-60%

случаев

От слу-

чая к

случаю

10-40%

Крайне

редко

< 10%

Нико-

гда или

не знаю

Направление i

Далее уровень согласованности с КРА взвешивается и вычисляется значение

атрибута Кз (уточняющее данные в таблице 9.10) по формуле:

( )

[ ]

∑

⋅−=

18/5100/%5

КРАKз

(4)

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

Уравнение номинальных трудозатрат (1) не учитывает множества факторов,

влияющих на трудоемкость разработки ПС независимо от ее размера. Поэтому

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

татка в Предпроектную модель введено семь дополнительных параметров - стои-

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

работки ПС. Эти атрибуты являются комбинацией стоимостных атрибутов Деталь-

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

шкале оценивания, и набор соответствующих числовых коэффициентов. Эти коэф-

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

трудозатрат по Предпроектной модели.

Уточнение оценок Предпроектной модели.

Уточненное уравнение оценки трудозатрат Т

имеет вид:

ном

⋅=

∏

)(

(5)

где Т

ном

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

∏

)(

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

Требуемая продолжительность разработки Д

рассчитывается по формуле:

100/%][67.3

))01.1(2.028.0

ОСРT

⋅⋅=

−•+

(6)

где ОСР% - коэффициент сжатия продолжительности разработки по отноше-

нию к требуемой (в процентах).

Стоимостные атрибуты Предпроектной модели объединены в 4 группы

(таблица 9.11). Оценки стоимостных атрибутов упорядочены по шкале оценок. Ка-

ждой оценке соответствует числовой коэффициент (таблица 9.12).

448 Глава 9

Значение коэффициента меньше 1 означает снижение трудозатрат, 1 - не из-

меняет номинальную оценку, больше 1 - увеличивает.

Таблица 9.11. Стоимостные атрибуты Предпроектной модели

Группа Стоимостной атрибут К

Атрибуты

разработчиков

1.Квалификация разработчиков (ПЕРС)

2. Опыт работы (ОРАБ)

Атрибуты

разработки

1. Инструментальная поддержка и среда проекта

(ИСРП)

2. Ограничение сроков разработки (ОСР)

Атрибуты среды

Сложность программно-аппаратной среды (СПАС)

Атрибуты программ-

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

1. Сложность и надежность (СЛНД)

2. Требуемое повторное использование (ПИСП)

Таблица 9.12. Коэффициенты стоимостных атрибутов Предпроектной модели

Уровень оценки

Стоимостной

атрибут

Сверх

низ-

кий

Очень

низкий

Низ-

кий

Номи-

наль-

ный

Высо-

кий

Очень

высо-

кий

Сверх

высо-

кий

Квалификация

разработчиков

2.12 1.62 1.26 1.00 0.83 0.63 0.50

Опыт работы

1.59 1.33 1.12 1.00 0.87 0.71 0.62

Инструменталь-

ная поддержка и

среда проекта

1.43 1.30 1.10 1.00 0.87 0.73 0.62

Ограничение

сроков разра-

ботки К

- 1.43 1.14 1.00 1.00 1.00

Сложность про-

граммно-

аппаратной

среды К

- - 0.87 1.00 1.29 1.81 2.61

Сложность и

надежность

0.73 0.81 0.98 1.00 1.30 1.74 2.38

Требуемое по-

вторное исполь-

зование К

- - 0.95 1.00 1.07 1.15 1.24

Алгоритм оценивания стоимостных атрибутов аналогичен оцениванию ат-

рибутов масштаба и включает следующие шаги.

1. Экспертным методом оценить каждый стоимостной атрибут. Если какой-

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

2. Для каждого атрибута по таблице 9.12 определить коэффициент К

Глава 9 449

3. Перемножить коэффициенты и вычислить

∏

)(

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

бенностей коллектива разработчиков в целом (таблица 9.13).

Таблица 9.13. Атрибуты разработчиков

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

ты разра-

ботчиков

Сверх

низкий

Очень

низкий

Низкий Номи-

нальный

Высо-

кий

Очень

высо-

кий

Сверх

высо-

кий

Квалифи-

кация

разработ-

чиков

20 проц 39 проц 45 проц 55 проц 65 проц 75 проц 85 проц

Опыт ра-

боты

<3 мес 5 мес 9 мес 1 год 2 года 4 года 6 лет

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

распределения квалификации среди всех разработчиков организации. Оценивание

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

- способность к анализу и программированию;

- эффективность и тщательность выполнения работы;

- способность к общению и сотрудничеству.

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

циалисты. Опыт работы определяется средним стажем работы коллектива в данной

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

Атрибуты разработки - характеризуют влияние на трудозатраты уровня

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

на сроки разработки (таблица 9.14).

Таблица 9.14. Атрибуты разработки

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

разработки

Очень

низкий

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

кий

Инструмен-

тальная

поддержка

и среда

проекта

Простые

инстру-

менты

редакти-

рования,

кодирова-

ния и от-

ладки

Простые

CASE-

инструмен-

ты, слабая

интеграция

Базовые инст-

рументы ЖЦ,

умеренно ин-

тегрированные

Мощные

инструмен-

ты для все-

го ЖЦ,

умеренно

интегриро-

ванные

Мощные ин-

тегрирован-

ные среды

разработки

для всего ЖЦ

Ограниче-

ние сроков

разработки

75% 85% 100% 130% 160%

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

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

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

450 Глава 9

Оценки ограничения сроков разработки (ОСР) задаются в процентах от но-

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

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

значениями. Устанавливать это ограничение менее 75% от номинальной продол-

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

характеристик ПС.

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

сти программно-аппаратной среды в части ограничений по времени выполнения и

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

лица 9.15).

Таблица 9.15. Атрибуты среды

Уровень оценки Сложность программ-

но-аппаратной среды

Низкий Номиналь-

ный

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

высокий

Ограничение по време-

ни и памяти

< 50% 50% 65% 80%

Изменчивость среды

разработки

Очень ста-

бильная

Стабильная Слегка из-

менчива

Изменчива

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

сложности ПС и требований к его надежности (затраты на достижение высокого

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

дующее повторное использование компонентов.

Атрибут сложность и надежность - это интегральный атрибут, в целом

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

даемый размер баз данных (БД), требуемый уровень документирования ПС. В таб-

лице 9.16 представлены единичные атрибуты для его оценивания.

Таблица 9.16. Единичные атрибуты для атрибута Сложность и надежность

Уровень оценки Сложность и

надежность

Сверх

низкий

Очень

низкий

Низкий Номи-

наль-

ный

Высо

кий

Очень

высо-

кий

Сверх

высо-

кий

Сумма оценок

единичных

атрибутов

5, 6 7, 8 9-11 12 13-15 16-18 19-21

Акцент на на-

дежности, до-

кументации

Очень

слабый

Слабый В какой-

то сте-

пени

Доста-

точный

Силь

ный

Очень

силь-

ный

Чрезвы-

чайный

Сложность - Простой В какой-

то сте-

пени

сложный

Средне

слож-

ный

Слож

ный

Очень

слож-

ный

Сверх-

сложный

Размер БД Малый Малый Малый Сред-

ний

Боль

шой

Очень

боль-

шой

Чрезвы-

чайно

большой

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

оценок единичных атрибутов.

Глава 9 451

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

должны охватываться документами стадии ЖЦ. Номинальная оценка означает, что

состав документов соответствует потребностям ЖЦ.

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

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

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

Для оценки сложности по таблице 9.17 следует выбрать нужный критерий,

который характеризует ПС (или группу критериев - в этом случае оценка сложно-

сти - это средневзвешенное по критериям). Атрибут «Размер БД» введен для того,

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

больших объемах данных.

Таблица 9.17. Критерии сложности

Значения

оценки

Логическая сложность Сложность

интерфейса

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

Сложность

вычислений

Простой Простые алгоритмы обработ-

ки информации, простые за-

просы

Простые входные

формы, простые

генераторы отчетов

Простые арифмети-

ческие выражения

В какой-

то степе-

ни слож-

ный

ПС сравнительно несложной

логической структуры, харак-

теризуется простой формой

входных и выходных доку-

ментов, простые запросы

Использование про-

стых построителей

графического поль-

зовательского ин-

терфейса

Умеренно сложные

выражения с ис-

пользованием стан-

дартных функций

Средне-

сложный

(номи-

нальный)

ПС несложной логической

структуры, характеризуется

сложностью входных и вы-

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

той получения данных

Простое использо-

вание готовых эле-

ментов интерфейса

Стандартные мате-

матические и стати-

стические процеду-

ры

Сложный ПС сравнительно сложной

логической структуры, харак-

теризуются разнообразием

форм входных и выходных

документов

Разработка и рас-

ширение набора

элементов интер-

фейса. Простой зву-

ковой ввод

Численный анализ:

многовариантная

интерполяция. Опе-

рации усечения и

округления

Очень

сложный

Программы с очень сложной

логикой обработки данных,

сложные запросы, многосек-

ционные отчеты

Умеренно сложная

динамическая гра-

фика, мультимедиа

Сложный структу-

рированный чис-

ленный анализ.

Простая параллели-

зация

Сверх

сложный

Сложные запросы, распреде-

ленная обработка данных

Сложные мультиме-

диа

Сложный неструк-

турированный чис-

ленный анализ.

Сложное распарал-

леливание

Атрибут Требуемое повторное использование учитывает дополнительные

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

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

452 Глава 9

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

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

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

Таблица 9.18. Шкала оценок атрибута Требуемое повторное использование

Уровень оценки

Низ-

кий

Номи-

нальный

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

кий

Сверх высо-

кий

Требуемое

повторное ис-

пользование

Нет

Для

данного

проекта

Для

однотипных

продуктов

Для одного

семейства

продуктов

Для любого

продукта

Процедура оценки трудозатрат на разработку ПС по Предпроектной

модели включает следующую последовательность шагов.

Рассмотреть все атрибуты масштаба и экспертным методом определить

коэффициенты масштаба Ф

по таблице 9.5.

Вычислить показатель степени по формуле (2).

Вычислить размер V в показателях функционального размера (УЕФ) и

конвертировать его в строки кода (см. главу 8).

Вычислить номинальную трудоемкость Т

ном

по формуле (1).

Оценить 7 атрибутов стоимости экспертным путем и определить коррек-

тирующие коэффициенты этих атрибутов К

по таблице 9.12.

Вычислить уточненную трудоемкость Т

по формуле (5).

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

по

формуле (6).

9.2.7. Оценивание трудозатрат по Детальной модели

Оценивание трудозатрат по Детальной модели отличается от Предпроектной

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

дого модуля (или программного компонента) [21].

Атрибуты масштаба определяются один раз на уровне всей ПС.

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

Для более точной оценки трудозатрат в Детальной модели введено 17 стои-

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

дели (таблица 9.19). Числовые коэффициенты представлены в таблице 9.20.

Таблица 9.19. Стоимостные атрибуты Детальной модели

Группа Стоимостной атрибут К

Атрибуты разра-

ботчиков

1.Квалификация аналитика (КАНЛ)

2. Квалификация программиста (КПРГ)

3. Опыт работы в предметной области (ОРАБ)

4. Опыт работы в среде разработки (ОСРЗ)

5. Опыт работы с языками программирования (ОРЯП)

6. Постоянство коллектива в проекте

(ПКОЛ)

Атрибуты

разработки

1. Инструментальная поддержка (ИНСТ)

2. Ограничение сроков разработки (ОСР)

3. Распределение разработки (РАСР)

Глава 9 453

Группа Стоимостной атрибут К

Атрибуты среды

1. Ограничения по времени выполнения (ОВРМ)

2. Ограничения по оперативной памяти (ОПАМ)

3. Изменчивость среды разработки (ИЗМС)

Атрибуты

программного

продукта

1. Требуемая надежность (ТНАД)

2. Сложность (СЛОЖ)

3. Размер базы данных (РАБД)

4. Соответствие документации потребностям ЖЦ (ДОКУ)

5. Требуемое повторное использование (ПИСП)

Таблица 9.20. Коэффициенты стоимостных атрибутов Детальной модели

Уровень оценки

Стоимостной атрибут Очень

низкий

Низ

кий

Номи-

наль-

ный

Высо

кий

Очень

высо-

кий

Сверх

высо-

кий

Квалификация аналитика (К

) 1.42 1.19 1.00 0.85 0.71 -

Квалификация программиста (К

) 1.34 1.15 1.00 0.88 0.76 -

Опыт работы в предметной об-

ласти (К

)

1.22 1.10 1.00 0.88 0.81 -

Опыт работы в среде разработки

(К

)

1.19 1.09 1.00 0.91 0.85 -

Опыт работы с языками про-

граммирования (К

)

1.20 1.09 1.00 0.91 0.84 -

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

те (К

)

1.29 1.12 1.00 0.90 0.81 -

Инструментальная поддержка

(К

)

1.17 1.09 1.00 0.90 0.78 -

Ограничение сроков разработки

(К

)

1.43 1.14 1.00 1.00 1.00 -

Распределение разработки (К

) 1.22 1.09 1.00 0.93 0.86 0.80

Ограничения по времени выпол-

нения (К

)

- - 1.00 1.11 1.29 1.63

Ограничения по оперативной

памяти (К

)

- - 1.00 1.05 1.17 1.46

Изменчивость среды разработки

(К

)

- 0.87 1.00 1.15 1.30 -

Требуемая надежность (К

) 0.82 0.92 1.00 1.10 1.26 -

Сложность (К

) 0.73 0.87 1.00 1.17 0.34 1.74

Размер базы данных (К

) 0.90 1.00 1.14 1.28 -

Соответствие документации (К

) 0.81 0.91 1.00 1.11 1.23 -

Требуемое повторное использо-

вание (К

)

0.95 1.00 1.07 1.15 1.24

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

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

этих атрибутов представлены в таблице 9.21.

Квалификация аналитиков. Оценивание должно основываться на квалифика-

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

- способность к анализу;