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

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

454 Глава 9

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

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

Таблица 9.21. Рейтинги атрибутов разработчиков

Уровень оценки Атрибуты разработчи-

ков

Очень

низкий

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

ный

Высо-

кий

Очень

высо-

кий

Квалификация аналитика 15 проц 35 проц 55 проц 75 проц 90 проц

Квалификация програм-

миста

15 проц 35 проц 55 проц 75 проц 90 проц

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

ной области

2 мес 6 мес 1 год 3 года 6 лет

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

работки

2 мес 6 мес 1 год 3 года 6 лет

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

программирования и ин-

струментами

2 мес 6 мес 1 год 3 6

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

проекте

48% 24% 12% 6% 3%

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

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

торам:

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

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

- способность к общению и сотрудничеству (в составе группы).

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

тывается отдельно.

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

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

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

типа систем или подсистем.

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

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

ческий интерфейс пользователя, СУБД, средства распределенных сред и сетевые

возможности.

Опыт работы с языками программирования и инструментами. Разработка

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

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

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

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

Постоянство коллектива - отражает негативное влияние на затраты текуче-

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

вых изменений.

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

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

Глава 9 455

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

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

исправлением на этапах системного тестирования. В Детальной модели эти атрибу-

ты рассматриваются отдельно. Рейтинги этих атрибутов представлены в таблице

9.22.

Таблица 9.22. Рейтинги атрибутов среды

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

среды

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

высокий

Сверх

высокий

Ограничения

по времени

выполнения

< 50% 50% 70% 95%

Ограничения

по оператив-

ной памяти

- <=50% 70% 85% 95%

Изменчи-

вость среды

разработки

Большие из-

менения ка-

ждые 12 ме-

сяцев, небо-

льшие – каж-

дый месяц

Большие изме-

нения каждые 6

месяцев, не-

большие – че-

рез 2 недели

Большие

изменения –

2 месяца,

небольшие

– каждую

неделю

Большие –

2 недели,

неболь-

шие – ка-

ждые 2дня

Атрибуты разработки. Перечень атрибутов представлен в таблице 9.23.

Таблица 9.23. Рейтинги атрибутов разработки

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

разработки

Очень низ-

кий

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

ный

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

кий

Инструмен-

тальная

поддержка

Простые ин-

струменты

редактирова-

ния, кодиро-

вания и от-

ладки

Простые

CASE-ин-

струмен-

ты, слабая

интегра-

ция

Базовые

инструмен-

ты ЖЦ,

умеренно

интегриро-

ванные

Мощные ин-

струменты

для всего

ЖЦ, умерен-

но интегри-

рованные

Ограниче-

ние сроков

разработки

75% 85% 100% 130% 160%

Распреде-

ление раз-

работки

Телефон, эле-

ктронная по-

чта

Телефон,

FAX

Эл. почта

через узко-

полосный

канал связи

Связь через

широкопо-

лосный канал

связи

Широкопо-

лосный ка-

нал, видео-

конференции

В Детальной модели COCOMO II введен новый атрибут «Распределение раз-

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

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

полнителей) на трудозатраты.

Атрибуты программного продукта. В Детальной модели рассматривается

отдельно влияние на трудозатраты каждого из факторов продукта (таблица 9.24).

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

456 Глава 9

Таблица 9.24. Рейтинги атрибутов продукта в Детальной модели

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

продукта

Очень

низкий

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

ный

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

высокий

Сверх

высо-

кий

Требуемая

надежность

Некото-

рое не-

удобс-

тво

Небольие,

легко уст-

ранимые

потери

Средние,

легко уст-

ранимые

потери

Большие

финансовые

потери

Риск че-

ловече-

ской жиз-

ни

Сложность

По таблице 9.17

Размер

базы дан-

ных

- РАБД<10 10<РАБД

<100

100<=РАБД

<1000

РАБД>=

1000

Соответст-

вие доку-

ментации

потребно-

стям ЖЦ

Многие

этапы не

охваче-

ны

Некоторые

потребно-

сти этапов

не охваче-

ны

Соответст-

вует по-

требностям

ЖЦ

Избыточная Сверх

избыточ-

ная для

ЖЦ

Требуемое

повторное

использо-

вание

Нет Нет Для данного

проекта

Для одно-

типных

продуктов

Для одно-

го семей-

ства про-

дуктов

Для

любого

про-

дукта

Требуемая надежность. Необходимость учета требуемого уровня надежно-

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

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

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

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

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

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

Атрибут «Размер БД» введен для того, чтобы учесть дополнительные трудо-

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

РАБД = Размер БД(байт)/SLOC

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

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

ных атрибутов и уровня оценивания) и описан ниже.

1. Оценить атрибуты масштаба и определить коэффициенты масштаба Ф

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

3. Определить состав оцениваемых модулей и оценить размер каждого моду-

ля V

в показателях функционального размера, где m ={1,M}- M - количество моду-

лей в ПС, и конвертировать его в строки кода (SLOC).

4. Вычислить номинальные трудозатраты каждого модуля Т

номm

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

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

для каждого модуля.

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

каждого модуля по формуле (7):

номm

⋅

∏

)(

(7)

Глава 9 457

где Т

номm

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

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

подстановкой Т

в формулу (6).

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

делей

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

бинацией стоимостных атрибутов Детальной модели (таблица 9.25).

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

Детальной

моделей

Предпроектная модель Детальная модель

Сложность и надежность СЛНД ТНАД, СЛОЖ, РАБД, ДОКУ

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

Сложность программно-аппаратной среды СПАС ОВРМ, ОПАМ, ИЗМС

Квалификация разработчиков ПЕРС КАНЛ, КПРГ, ПКОЛ

Опыт работы ОРАБ ОРАБ, ОСРЗ, ОРЯП

Инструментальная поддержка и среда проекта ИСРП ИНСТ, РАСР

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

Оценки значений интегрального атрибута вычисляются как субъективно

средневзвешенные оценки единичных атрибутов. При этом шкала оценок инте-

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

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

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

ет между «Очень низкий» и «Низкий», следует выбирать «Низкий».

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

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

вес в такой последовательности: оценке «Очень низкий» - 1, «Низкий» - 2 и т.д.

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

грального атрибута.

3. Вычисляются усредненные значения коэффициентов интегрального атри-

бута.

Ниже для иллюстрации рассмотрен пример оценки интегрального атрибу-

та ПЕРС.

Интегральный атрибут «Квалификация разработчика» (ПЕРС) является ком-

бинацией трех единичных атрибутов, приведенных в таблице 9.26, каждый из ко-

торых имеет масштаб ранжирования от «Очень низкий» до «Очень высокий».

1. Рейтингам единичных атрибутов присваиваются веса (таблица 9.26).

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

Уровень оценки Единичные атрибуты

Очень

низкий

Низ-

кий

Номи-

нальный

Высо

кий

Очень

высокий

Вес единичного атрибута 1 2 3 4 5

Квалификация аналитика 15 35 55 75 90

Квалификация программиста 15 35 55 75 90

Постоянство коллектива в проекте 48% 24% 12% 6% 3%

458 Глава 9

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

ния от 3 до 15. Эти веса переносятся на масштаб интегрального атрибута таким об-

разом: оценка «Номинальный» 9 отвечает сумме весов (3+3+3), а соответствующий

им коэффициент равен 1.

Оценка «Сверхнизкий» соответствует сумме весов (1+1+1) или (1+1+2), и т.д.

(таблица 9.27).

Таблица 9.27. Сумма весов единичных атрибутов

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

Интегральный

атрибут

Сверх-

низ-

кий

Очень

низ-

кий

Низ-

кий

Номи-

наль-

ный

Вы-

со-

кий

Очень

высо-

кий

Сверх-

высо-

кий

Сумма весов трех еди-

ничных атрибутов

3, 4 5,6 7,8 9 10,11 12,13 14,15

3. Усредненные значения коэффициентов интегрального атрибута (таблица

9.28) вычисляются следующим образом:

Таблица 9.28. Усредненные значения коэффициентов интегрального ат-

рибута ПЕРС

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

Коэффициенты Сверх-

низкий

Очень

низкий

Низ

кий

Номи-

наль-

ный

Высо-

кий

Очень

высо-

кий

Сверх-

высо-

кий

Сумма весов трех

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

3, 4 5,6 7,8 9 10,11 12,13 14,15

Комбинация КАНЛ,

КПРГ

20 проц 39 45 55 65 75 85

ПКОЛ 45% 30% 20% 12% 9% 5% 4%

Коэффициенты инте-

грального атрибута

2.5 1.62 1.26 1.00 0.83 0.66 0.50

а) определяются комбинации всех весов, сумма которых составляет от 3 до 4;

b)- вычисляется произведение коэффициентов для этих последовательностей

(таблица 9.29):

(1.42×1.34×1.29)/2 =1.23 (1.19×1.34×1.29)/2 =1.03

(1.42×1.34×1.12)/2 =1.06 (1.42×1.15×1.29)/2 =1.05

Таблица 9.29. Коэффициенты единичных атрибутов

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

Коэффициенты еди-

ничных атрибутов

Очень

иизкий

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

ный

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

сокий

Веса 1 2 3 4 5

1.42 1.19 1.00 0.85 0.71

1.34 1.15 1.00 0.87 0.76

1.29 1.12 1.00 0.90 0.81

c) вычисляются значения интегрального коэффициента:

1.23+(1.06+1.03+1.05)/3=2.5

Для определения всех интегральных коэффициентов шаги a)-c) выполняются

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

Глава 9 459

9.2.8. Корректировка оценок модели

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

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

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

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

симистического) для принятия более обоснованного решения о продолжительности

и трудозатратах.

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

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

доверия (таблица 9.30).

Таблица 9.30. Оценки интервалов доверия оценок

Модель Оптимистическая оценка Пессимистическая оценка

Предварительная модель

0.50

Предпроектная модель

0.67

1.5

Детальная модель

0.8

1.25

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

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

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

Модель COCOMO II позволяет выполнить распределение трудозатрат по

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

В таблице 9.31 указаны укрупненные виды работ, а в таблице 9.32 – пример-

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

полняемым на стадиях (не соответствуют ГОСТ 34). Серым фоном выделены рабо-

ты и стадии, которые непосредственно не учитываются в модели COCOMO II.

Таблица 9.31. Виды работ, учитываемые в модели COCOMO II

Виды работ Оценивание

Определение требований Нет

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

Реализация Да

Интеграция и тестирование Да

Управление проектом Да

Управление конфигурацией Да

Обеспечение качества Да

Внешнее руководство проектом Нет

Виды работ «Определение требований» и «Внешнее руководство проектом»

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

мендуемая доля общих затрат (в %). В связи с этим, в таблице 9.32 общий объем

трудозатрат составляет больше 100% [22]

Указанное в таблице 9.32 распределение зависит от размера ПС, представ-

ленного в тысячах строк исходного кода (KSLOC, далее К).

460 Глава 9

Таблица 9.32. Распределение трудозатрат и продолжительности по кас-

кадной модели ЖЦ

Процент общей оценки Стадия

разработки

Оцени-

вание

Трудозатраты Продолжительность

Планирование и анализ требова-

ний (Plan&Requirement)

нет 7% (2% – 15%) Обычно от 16% - 24%

(2% - 30%)

Проектирование (Product Design) Да 17% 24% - 28%

Программирование (Programming) Да 64%-52% 56%-40%

Интеграция и тестирование

Integration & Test

Да 19%-31% 20%-32%

Передача

(Transition)

нет 12%

(0%-20%)

12.5%

(0%-20%)

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

затрат в зависимости от размера ПС.

Изменение процентного соотношения затрат с ростом размера объясняется

тем, что большие ПС требуют большей доли затрат на интеграцию и тестирование.

Если вычисленный размер ПС находится между значениями, представленными в

таблице 9.33, соответствующее долевое распределение получается путем линейной

интерполяции данных из таблицы по формуле (8):

y=y

+ [(x-x

)/(x

-x

)]·(y

-y

)

(8)

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

) и

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

Таблица 9.33. Распределение трудозатрат по стадиям разработки (в %)

Размер (тыс. строк) Стадия

разработки

8К 16К 32К 64К 128К 256К 512К 1024К

Планирование и

анализ требований

7 7 7 7 7 7 7 7

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

Программирование,

из них:

- детальное проек-

тирование

- кодирование и ав-

тономное тестиро-

вание

25.3

34.7

25.7

34,3

24.5

33.5

24.7

32.3

54.9

23.9

30.9

54.8

23.9

30.9

54.4

23.8

30.6

Интеграция и тести-

рование

24 23 25.8 26 28.1 28.1 28.2 28.6

Для моделей ЖЦ итеративного типа (спиральной, с приращениями) пред-

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

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

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

модели COCOMO II.

Кроме COINCOMO для итеративного ЖЦ можно использовать модель

MBASE (Model-Based Architecting & Software Engineering), предложенную

Б.Боэмом в [23].

Глава 9 461

В таблице 9.34 представлены результаты распределения трудозатрат и про-

должительности для моделей ЖЦ этого типа. Стадии разработки модели MBASE

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

пользуемой в RUP (Rational Unified Process) [24]. Указанное распределение (как и

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

возможностям итерации).

Таблица 9.34. Распределение трудозатрат и продолжительности для мо-

делей ЖЦ итеративного типа

Процент общей оценки

MBASE RUP

Стадия

Разработки

Оце-

нива-

ние

Трудоза-

траты

Продолжи-

тельность

Трудоза-

траты

Продолжи-

тельность

Начало

(Inception)

Нет 6%

(2% - 15%)

12.5%

(2% -30%)

5% 10%

Уточнение

(Elaboration)

Да 24%

(20% - 28%)

37.5%

(24% -28%)

20% 20%

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

(Construction)

Да 76%

(72% - 80%

62.5%

(58% - 67%)

65% 50%

Передача

(Transition)

Нет 12%

(0% - 20%)

12.5%

(0% - 20%)

10% 10%

Всего 118%

(102% -

135%)

125%

(102% -

150%)

100% 100%

В таблице 9.34 серым фоном выделены стадии, которые непосредственно не

учитываются в модели COCOMO II. В связи с этим общая оценка по модели

MBASE превышает 100%.

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

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

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

9.35-9.37 сопоставлены русские и английские наименования и обозначения атрибу-

тов модели СOCOMO II.

Таблица 9.35. Сопоставление наименований атрибутов масштаба

№

пп

Русское наименование Обозна-

чение

Английское наименование Обозна-

чение

1 Новизна проекта НОВ Precedentedness PREC

2 Жесткость проекта (со-

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

СОГЛ Development Flexibility FLEX

3 Управление риском/ ар-

хитектурой

УР Architecture / Risk Resolution RESL

4 Коллективизм КОЛЛ Team Cohesion TEAM

5 Технологическая зрелость

процесса разработки

ТЗР Process Maturity PMAT

462 Глава 9

Таблица 9.36. Сопоставление наименований атрибутов стоимости в

Предпроектной модели

№

пп

Русское наименование Сокра-

щение

Английское наимено-

вание

Сокра-

щение

1 Квалификация разработчиков ПЕРС Personnel Capability PERS

2 Опыт работы ОРАБ Personnel Experience PREX

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

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

ИСРП

Facilities FCIL

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

ОСР Schedule SCED

5 Сложность программно-

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

СПАС Platform Difficulty PDIF

6 Сложность и надежность СЛНД Product Reliability and

Complexity

RCPX

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

вание

ПИСП Developed for Reusability REUSE

Таблица 9.37. Сопоставление наименований атрибутов стоимости в

Детальной модели

№

пп

Русское наименование Сокра-

щение

Английское наименова-

ние

Сокра-

щение

1 Квалификация аналитика КАНЛ Analyst Capability ACAP

2 Квалификация программиста КПРГ Programmer Capability PCAP

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

области

ОРАБ Applications Experience APEX

4 Опыт работы в среде разра-

ботки

ОСРЗ Platform Experience PLEX

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

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

ОРЯП Language and Tool Experi-

ence

LTEX

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

проекте

ПКОЛ Programmer Capability PCAP

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

ка

ИНСТ Use of Software Tools TOOL

8 Ограничение сроков разра-

ботки

ОСР Required Development

Schedule

SCED

9 Распределение разработки РАСР Multisite Development SITE

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

выполнения

ОВРМ Execution Time Constraint TIME

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

памяти

ОПАМ Main Storage Constraint STOR

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

ботки

ИЗМС Platform Volatility PVOL

13 Требуемая надежность ТНАД Required Software Reliabil-

ity

RELY

14 Сложность СЛОЖ Product Complexity CPLX

15 Размер базы данных РАБД Data Base Size DATA

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

потребностям ЖЦ

ДОКУ Documentation Match to

Life-Cycle Needs

DOCU

17 Требуемое повторное ис-

пользование

ПИСП Developed for Reusability RUSE

Глава 9 463

9.3. Оценка затрат на разработку Web-приложений

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

и другие интерпретации данного подхода, учитывающие специфику ПС.

В работе [25] Д.Рифер предложил модель WEBMO для оценки трудозатрат и

продолжительности разработки Web-приложений, разработанную с помощью экс-

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

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

бинации параметров моделей

COCOMO II и SoftCost-OO [26]. Соотношение для

оценки трудоемкости T (в человеко-месяцах) представлено уравнением (9), а

для оценки продолжительности D (в календарных месяцах) – уравнением (10).

VkAT ⋅⋅=

∏

(9)

⋅

(10)

где А и B – константы, k

– коэффициенты стоимостных атрибутов, p

, p

–

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

ти типов Web-проектов, V – размер приложения, измеряемый методом Web Objects

(см. п.8.3.2). Полученные эмпирически значения параметров А, B, p

и p

представ-

лены в таблице 9.38.

Таблица 9.38. Значения постоянных параметров модели WEBMO

Тип Web-приложения А В p

Электронная коммерция 2.3 2.0 1.03 0.5 или 0.32

Финансовые приложения 2.7 2.2 1.05 0.5 или 0.32

Бизнес-приложения 2.0 1.5 1.00 0.5 или 0.32

Web-порталы 2.1 1.8 1.00 0.5 или 0.32

Поиск и использование информации 2.1 2.0 1.00 0.5 или 0.32

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

COCOMO II. Следует отметить, что атрибут КОЛЛ (Коллективизм) в COCOMO II

используется как атрибут масштаба, а атрибут ЭФПР (Эффективность процесса) по

своему смыслу соответствует атрибуту масштаба ТЗР (Технологическая зрелость

процесса разработки).

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

9.39. Значения коэффициентов стоимостных атрибутов отличаются от значений

модели COCOMO II.

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

жет использоваться простой метод, представленный Д.Клиэри в работе [27]. Со-

гласно этому методу размер сайта V определяется в единицах Web Points (см.

п.8.3.3), а трудоемкость рассчитывается по формуле

VPDRT

⋅

, где PDR – ин-

тенсивность разработки (количество Web Points, «выпускаемых» специалистами

проекта за один час). Например, для проектов CHARISMATEK, inc. PDR=0.5. Учи-

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

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

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

ков (файлов) должна рассчитываться отдельно.