1vendrov_a_m_proektirovanie_programmnogo_obespecheniya_ekonom

Оценка трудоемкости создания программного обеспечения 441

Эксплуатационные ограничения

0Какие-либо явные или неявные ограничения отсутствуют

1Эксплуатационные офаничения присутствуют, но не требуют ника­ ких специальных усилий

2Должны учитываться некоторые ограничения, связанные с безопас­ ностью или временем реакции

3Должны учитываться конкретные требования к процессору со сто­ роны конкретных компонентов приложения

4Заданные эксплуатационные ограничения требуют специальных ог­ раничений на выполнение приложения в центральном или выделен­ ном процессоре

5То же, кроме того, специальные офаничения затрагивают распреде­ ленные компоненты системы

Частота транзакций

0Пиковых периодов не ожидается

1Ожидаются пиковые периоды (ежемесячные, ежеквартальные, еже­ годные)

2Ожидаются еженедельные пиковые периоды

3Ожидаются ежедневные пиковые периоды

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

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

Ввод данных в режиме «онлайн»

0 Все транзакции обрабатываются в пакетном режиме 1 От 1% до 7% транзакций требуют интерактивного ввода данных

2От 8% до 15% транзакций требуют интерактивного ввода данных

3От 16% до 23% транзакций требуют интерактивного ввода данных

4От 24% до 30% транзакций требуют интерактивного ввода данных

5Более 30% транзакций требуют интерактивного ввода данных

Эффективность работы конечных пользователей^

О Ни одной из перечисленных функциональных возможностей^ ^ От одной до трех функциональных возможностей

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

3Шесть или более функциональных возможностей при отсутствии конкретных пользовательских требований к эффективности

^То же, кроме того, пользовательские требования к эффективности требуют специальных проектных решений для учета эргономичес­ ких факторов (например, минимизации нажатий клавиш, максими­ зации значений по умолчанию, использования шаблонов)

442

Глава 6

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

5То же, кроме того, пользовательские требования к эффективности требуют применения специальных средств и процессов, демонстри­ рующих их выполнение

^Эффективность работы конечных пользователей определяется наличи­ ем следующих функциональных возможностей.

•Средства навигации (например, функциональные клавиши, дина­ мически генерируемые меню).

•Меню.

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

•Автоматическое перемещение курсора.

•Скроллинг.

•Удаленная печать.

•Предварительно назначенные функциональные клавиши.

•Выбор данных на экране с помощью курсора.

•Использование видеоэффектов, цветового вьщеления, подчерки­ вания и других индикаторов.

•Всплывающие окна.

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

•Поддержка двух и более языков.

Онлайновое обновление

0Отсутствует

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

2Онлайновое обновление четырех или более управляющих файлов Объем обновлений незначителен, восстановление несложно

3Онлайновое обновление основных внутренних логических файлов

4То же, плюс необходимость специальной защиты от потери данных

5То же, кроме того, большой объем данных требует учета затрат на процесс восстановления. Требуются автоматизированные процеду­ ры восстановления с минимальным вмешательством оператора

Сложная обработка^

0 Ни одной из перечисленных функциональных возможностей^

1 Любая одна из возможностей

2Любые две из возможностей

^Любые три из возможностей

^Любые четыре из возможностей

5Все пять возможностей

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

Оценка трудоемкости создания программного обеспечения 443

•повышенная реакция на внешние воздействия и (или) специаль­ ная защита от внешних воздействий;

•экстенсивная логическая обработка;

•экстенсивная математическая обработка;

•обработка большого количества исключительных ситуаций;

•поддержка разнородных типов входных/выходных данных.

	Повторное использование
0	Отсутствует
1	Повторное использование кода внутри одного приложения

2Не более 10% приложений будут использоваться более чем одним пользователем

3Более 10% приложений будут использоваться более чем одним поль­ зователем

4Приложение оформляется как продукт и (или) документируется для облегчения повторного использования. Настройка приложения вы­ полняется пользователем на уровне исходного кода.

5То же, с возможностью параметрической настройки приложений

Простота установки

0 К установке не предъявляется никаких специальных требований.

1 Для установки требуется специальная процедура

2Заданы пользовательские требования к конвертированию (переносу существующих данных и приложений в новую систему) и установке, должны быть обеспечены и проверены соответствующие руковод­ ства. Конвертированию не придается важное значение

3То же, однако конвертированию придается важное значение.

4То же, что и в случае 2, плюс наличие автоматизированных средств конвертирования и установки

5То же, что и в случае 3, плюс наличие автоматизированных средств конвертирования и установки

Простота эксплуатации

ОК эксплуатации не предъявляется никаких специальных требова­ ний, за исключением обычных процедур резервного копирования

1—4 Приложение обладает одной, несколькими или всеми из перечис­ ленных далее возможностей. Каждая возможность, за исключением второй, обладает единичным весом: 1) наличие процедур запуска, копирования и восстановления с участием оператора; 2) то же, без участия оператора; 3) минимизируется необходимость в монтирова­ нии носителей для резервного копирования; 4) минимизируется не­ обходимость в средствах подачи и укладки бумаги при печати

5Вмешательство оператора требуется только при запуске и заверше­ нии работы системы. Обеспечивается автоматическое восстановле­ ние работоспособности приложения после сбоев и ошибок

444

Глава 6

Количество возможных установок на различных платформах

0Приложение рассчитано на установку у одного пользователя

1Приложение рассчитано на много установок для строго стандартной платформы (технические средства + программное обеспечение)

2Приложение рассчитано на много установок для платформ с близ­ кими характеристиками

3Приложение рассчитано на много установок для различных плат­ форм

4То же, что в случаях 1 или 2, плюс наличие документации и планов поддержки всех установленных копий приложения

5То же, что в случае 3, плюс наличие документации и планов под­ держки всех установленных копий приложения

П|бкость^

0 Ни одной из перечисленных возможностей^

1 Любая одна из возможностей

2Любые две из возможностей

3Любые три из возможностей

4Любые четыре из возможностей

5Все пять возможностей

^Гибкость характеризуется наличием у приложения следующих воз­ можностей:

•поддержка простых запросов, например, логики и (или) в приме­ нении только к одному ILF (вес — 1);

•поддержка запросов средней сложности, например, логики и (или) в применении более чем к одному ILF (вес - 2);

•поддержка сложных запросов, например, комбинации логических связок и (или) в применении к одному или более ILF (вес — 3);

•управляющая информация хранится в таблицах, поддерживаемых пользователем в интерактивном режиме, однако эффект от ее из­ менений проявляется на следующий рабочий день;

•то же, но эффект проявляется немедленно (вес — 2).

После определения всех значений GSC и вычисления попра­ вочного коэффициента VAF вычисляется итоговая оценка коли­ чества функциональных точек (Adjusted Function Points, AFP):

AFP = UFP * VAF.

6.2.5. ОЦЕНКА ТРУДОЕМКОСТИ РАЗРАБОТКИ

Ниже в соответствии с данными SPR определяется количест­ во строк кода (SLOC) на одну функциональную точку в зависи­ мости от используемого языка программирования.

Оценка трудоемкости создания программного обеспечения 445

Количество строк кода на одну функциональную точку

Язык (средство)	Количество SLOC на FP
АВАР/4	16
Access	38
ANSI SQL	13
С++	53
Clarion	58
Data base default	40
Delphi 5	18
Excel 5	6
FoxPro 2.5	34
Oracle Developer	23
PowerBuilder	16
Smalltalk	21
Visual Basic 6	24
Visual C++	34
HTML 4	14
Java 2	46

Умножая AFP на (количество SLOC на FP), получаем количе­ ство SLOC в приложении.

Далее для оценки трудоемкости и времени разработки может использоваться один из вариантов известной модели оценки тру­ доемкости разработки ПО под названием СОСОМО и ее совре­ менной версии СОСОМО II (см. подразд. 6.3).

В табл. 6.5 приведены усредненные статистические данные размера ПО по некоторым видам приложений.

				Таблица 6.5
	Размер программного обеспечения в FP и LOC
	Тип ПО	Размер, FP	Размер,	Количество
			LOG	LOC на одну FP
	Текстовые процессоры	3500	437500	125
	Электронные таблицы	3500	437500	125	1
	Клиент-серверные приложения	7500	675000	90
	ПО баз данных	7500	937500	125
	Производственные приложе­	7500	937500	125
	ния

	446			Глава 6
				Продолжение
	Тип ПО	Размер, FP	Размер,	Количество
			ШС	LOC на одну FP
	Крупные бизнес-приложения	10000	1050000	105
	Крупные корпоративные при­	25000	2625000	105
	ложения
	Крупные приложения в госуч­	50000	5250000	105
	реждениях
	Операционные системы	75000	11250000	150
	Системы масштаба предприя­	150000	18750000	125
	тий
	Крупные оборонные системы	250000	25000000	100

На реализацию проектов размером в одну функциональную точку требуется один день, и они практически всегда заканчива­ ются успешно. Таковы, как правило, небольшие утилиты для вре­ менных нужд.

Объем в 10 функциональных точек — это типичный объем не­ больших приложений и дополнений, вносимых в готовые систе­ мы. Такие проекты требуют до 1 месяца работ и тоже всегда ус­ пешны.

Объем в 100 функциональных точек близок к пределам воз­ можностей программиста-одиночки. Проект доводится до конца за 6 месяцев в 85% случаев. Эти цифры верны для современных средств разработки: 15 лет назад 15 тысяч строк занимал профес­ сиональный интерпретатор Бейсика для MS-DOS, создать кото­ рый одному человеку (среднему профаммисту) было не под силу.

Объем проекта в 1000 функциональных точек характерен для большинства сегодняшних коммерческих настольных и неболь­ ших клиент-серверных приложений. Заметную долю обихего объ­ ема работы начинает занимать документация. Для разработки проекта необходима фуппа примерно из 10 профаммистов, про­ ектировщиков, специалистов по управлению качеством и около года работы. Проваливается 15% подобных фупповых проектов и 65% попыток профаммистов-одиночек. В 20% случаев не удается уложиться в срок. Перерасход средств отмечается в 25% проектов.

Для проекта объемом в 10000 функциональных точек требует­ ся около 100 разработчиков. Остро встают вопросы организации совместной работы нескольких фупп сотрудников. Работы длят­ ся от 1,5 до 5 лет, при этом запланированные сроки чаще всего не

Оценка трудоемкости создания программного обеспечения 447

вьщерживаются. Хорошее качество системы невозможно обеспе­ чить без использования формальной технологии тестирования. До 50% проектов заканчивается неудачей, а реализация таких проектов в одиночку вообще невозможна.

Объем в 100000 функциональных точек — пока что предел для большинства сегодняшних проектов. Это объем современных операционных систем, таких как MS Windows или IBM MVS, и крупнейших военных систем. На их создание уходит 5-8 лет Над проектом трудятся сотни разработчиков иногда из разных стран, и эффективно координировать их работу не удается. В закончен­ ных системах много ошибок. До 65% проектов завершается про­ валом. Во всех успешных проектах используются системы управ­ ления конфигурацией.

Табл. 6.6 иллюстрирует различия в распределении временных затрат по стадиям жизненного цикла в случае большого и малень­ кого проекта. Маленький проект (например, приложение Windows объемом 50000 строк исходного кода на Visual Basic, соз­ даваемое командой из 5 человек) может потребовать 1 месяц на начальную стадию, 2 месяца на проектирование, 5 месяцев на разработку и 2 месяца на ввод в действие. Большой, сложный проект (например, бортовая профамма для летательного аппара­ та объемом 300000 строк исходного кода, создаваемая командой из 40 человек) может потребовать 8 месяцев на начальную ста­ дию, 14 месяцев на проектирование, 20 месяцев на разработку и 8 месяцев на ввод в действие. Сравнение долей жизненного цикла, приходящихся на каждую стадию, позволяет обнаружить очевид­ ные различия.

Таблица 6.6

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

Масштаб проекта		Начальная	Проектирование, Разработка,		Ввод в
		стадия, %	%	%	действие, %
Маленький	ком­
мерческий проект		10	20	50	20
Большой,	слож­
ный проект		15	30	40	15

448

Глава 6

Самым значительным отличием является относительное вре­ мя, за которое достигается контрольная точка жизненного цикла, связанная с созданием архитектуры (завершение проектирова­ ния). Для маленьких проектов это отношение составляет 30/70; для большого проекта оно ближе к 45/55.

Время разработки может быть изменено с учетом статистичес­ ких данных, накопленных в реальных проектах и отраженных в табл. 6.7, где сопоставлены планируемый и реальный сроки вы­ полнения проекта в зависимости от его размера, выраженного в количестве функциональных точек. Частично это отставание объ­ ясняется неточной оценкой, частично — ростом количества тре­ бований к системе после того, как выполнена начальная оценка.

			Таблица 6.7
	Статистические данные
Размер проекта	< 100 FP	100 - 1000 FP	1000 - 10000	> 10000 FP
			FP
Планируемый		12		24
срок (мес.)	6		18
Реальный срок			24
(мес.)	8	16		36
Отставание	2	4	6	12

6.3. АЛГОРИТМИЧЕСКОЕ МОДЕЛИРОВАНИЕ ТРУДОЕМКОСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

6 . 3 . 1 . ТЕОРЕТИЧЕСКИЕ (МАТЕМАТИЧЕСКИЕ) МОДЕЛИ

Математическое моделирование трудоемкости разработки ПО основано на сопоставлении экспериментальных данных с формой существующей математической функции. В начале 1960-х годов Питер Норден из фирмы IBM пришел к выводу, что в про­ ектах по исследованию и разработке может применяться хорошо прогнозируемое распределение трудовых ресурсов, основанное на распределении вероятности, называемом кривой Рэлея

Оценка трудоемкости создания программного обеспечения 449

(Rayleigh distribution). Позднее, в 1970-х годах Лоуренс Патнэм^ из компании Quantitative Systems Management применил резуль­ таты Нордена к разработке ПО. Используя статистический ана­ лиз проектов, Патнэм обнаружил, что взаимосвязь между тремя основными параметрами проекта (размером, временем и трудо­ емкостью) напоминает функцию Нордена-Рэлея (рис. 6.9), отра­ жающую распределение трудовых ресурсов проекта в зависимос­ ти от времени.

dy/dt = aKate-*"

t=0

1*18

Время Рис. 6.9. Функция Рэлея

Функция Рэлея моделируется дифференциальным уравнением: rfvM= 2*^*a*/*ex/?(-fl/^).

где dy/dt — скорость роста персонала проекта; / — время, прошед­ шее от начала проекта до изъятия продукта из эксплуатации; К — область под кривой ~ представляет полную трудоемкость в тече­ ние всего жизненного цикла (включая сопровождение), выра­ женную в человеко-годах; а — константа, которая определяет форму кривой (фактор ускорения) и вычисляется по формуле

a=\/2t,

где t^ - время разработки.

^ Putnam L.H. А General Empirical Solution to the Macro Software Sizing and Estimating Problem ," IEEE Transactions on Software Engineering, 1978, July. — P 345-361.

450

Глава 6

Приняв ряд допущений, Патнэм получил следующее уравне­ ние:

j^=0.4*[^/q'*l/(//,

где Е — трудоемкость разработки ПО, S — размер ПО в LOC, t^ — планируемый срок разработки, С — технологический фактор, учитывающий различные аппаратные ограничения, опыт персо­ нала и характеристики среды профаммирования. Он определяет­ ся на основе хронологических данных по прошлым проектам и, согласно рекомендациям Патнэма определяется для различных типов проектов следующим образом:

•проект, внедренный в сжатые сроки без детальной прора­ ботки, - 1500;

•проект, выполненный в соответствии с четким планом, — 5000;

•проект, предусматривающий оптимальную организацию и поддержку, — 10000.

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

что хорошо согласуется с большинством статистических моделей. Более подробное описание модели Патнэма приведено в кни­ ге Фатрелл Р., Шафер Д., Шафер Л. Управление программными

проектами: достижение оптимального качества при минимуме затрат: Пер. с англ. — М.: Вильяме, 2003.

6.3.2. СТАТИСТИЧЕСКИЕ (РЕГРЕССИОННЫЕ) МОДЕЛИ

Статистические модели используют накопленные хронологи­ ческие данные, чтобы получить значения для коэффициентов модели. Для определения соотношений между параметрами мо­ дели и трудоемкостью разработки ПО используется рефессионный анализ. Существуют две формы статистических моделей: ли­ нейные и нелинейные.

Линейные статистические модели имеют следующий вид:

Трудоемкость = Ль + S А- ^^t

/=1