Общее описание метода оценки

Функционально-ориентированные метрики - это косвенные меры для оценки программного продукта и процесса его разработки; они фокусируют внимание на "функциональности" программного изделия или "полезности" про­граммы. В 1979 г был предложен подход к измерению производительности труда разработчиков программного обеспечения, названный методом функ­циональной точки (FP - function point method ).

Оценка числа функциональных точек (ФТ) для программного продукта выводится на основе данных, которые определяются в результате анализа информационной области программного изделия и изучения особенностей его будущего функционирования.

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

Таблица 7

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

Измеряемый параметр		Весовой коэффициент
Входы пользо­вателей
Выходы пользо­вателей
Запросы поль­зователей
Внешние ин­терфейсы
Общий итог

Информационные параметры определяются следующим образом.

Число входов пользователей. Подсчитывается каждый вход пользо­вателя, который дает отличающиеся от других данные, ориентированные на определенное приложение. Входы должны отличаться от запросов пользователей, которые подсчитываются отдельно.

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

Число запросов пользователей. Подсчитывается каждый запрос,рассматриваемый как отдельный онлайновый вход, который дает в результате генерацию немедленного ответа программного продукта в форме он­-лайнового выхода.

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

Число внешних интерфейсов. Подсчитываются всё машиночитаемые интерфейсы (например, обращения к файлам данных на внешних носителях, которые используются для передачи информации к другим системам).

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

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

Нет влияния - 0.

Случайное влияние -1.

Умеренное влияние - 2.

Среднее влияние - 3.

Значительное влияние - 4.

Существенное влияние - 5.

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

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

Требуется ли передача данных?

Имеются ли функции распределенной обработки?

Критична ли производительность программного продукта?

5. Будет ли система функционировать в существующей или в более сложной операционной обстановке?

6.Требует ли система онлайнового ввода данных?

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

Осуществляется ли обновление главного файла в онлайновом ре­жиме?

Являются ли сложными входы, выходы, файлы или запросы?

10.Являются ли сложными алгоритмы обработки данных?

Предназначены ли созданные программы для повторного использования?

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

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

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

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

Задание 4. Определение числа функциональных то­чек для программного продукта

Методические указания к выполнению задания 4

На основе требований пользователя и схем потоков данных будущей программной системы провести подсчет числа функциональных точек ФТ. С этой целью провести анализ информационной области проектируемого про­граммного продукта и определить 5 ее информационных параметров (см. табл. 7), оценив важность каждого. Проанализировать и оценить каждый из перечисленных выше 14 факторов, характеризующих особенности функцио­нирования разрабатываемой информационной системы.

Примечание . Задание выполняется при курсовом проектировании информационной системы студентами специальности "Информационный ме-неджемент".

Последовательность выполнения задания.

1. Составить табл. 7 для заполнения экспертными оценками и после­дующего определения основных параметров программного продукта.

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

2. После того, как все эти данные собраны, каждому числовому значению параметра присвоить соответствующий весовой" коэффициент, который учитывает, насколько сложно или просто можно реализовать рассматривае­мый параметр. Затем для каждого параметра вычислить итоговое значение, которое записать в последний столбец данной строки таблицы.

Определить общий итог по пяти параметрам информационной об­ласти, просуммировав значения по всем строкам последнего столбца.

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

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

ФТ = общий итог*(0.65+ 0.01* сумма коэффициентов),

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

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

Развитие функционального подхода.

Мера функциональной точки, первоначально предложенная для приме­нения к приложениям в области деловых информационных систем, была за­тем распространена с некоторыми модификациями на другие приложения. Развитие этого метода оценки программных продуктов получило название метода характерных точек (feature points ). Этот метод может быть применен для оценки проектов более широкого круга приложений. Мера характерных то­чек особенно пригодна для приложений с высокой степенью алгоритмической сложности, которая присуща системам реального времени, управленческим процессам и встроенным системам, поэтому именно для них целесообразно применять меру характерной точки (XT).

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

Следует отметить, что оба метода (ФТ и XT) отражают одну и туже сторону программного продукта - его "функциональность" и "полезность". И тот и другой подходы дают близкие результаты для обычных инженерных вычислительных задач и информационных систем. Для более сложных систем осо­бенно реального времени итоговое значение для XT на 20-35% выше, чем итог, определенный с использованием ФТ.

Согласование размеро-ориентированных и функционально-ориентированных подходов к оценке программных проектов.

Методы оценки по числу строк кода и по функциональной точке отли­чаются по уровню детализации проблемы автоматизации, который требуется для функциональной декомпозиции. Когда используется оценка на основе чис­ла строк кода, то функциональная декомпозиция абсолютно необходима и часто с большим числом уровней детализации. В то же время данные, необ­ходимые для оценки функциональной точки, более макроскопические и сте­пень детализации может быть существенно меньше Следует также отметить, что число строк кода оценивается непосредственно для каждого блока, а чис­ло функциональных точек ФТ вычисляется косвенно, путем определения чис­ла входов, выходов, файлов данных, запросов и внешних интерфейсов, а так­же 14 коэффициентов корректировки сложности.

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

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

Таблица 8.

Соотношение метрик функциональных точек и строк кода

Язык программирования
Ассемблер
Объектно-ориентированные языки
Языки 4-го поколения
Генераторы кода

Очевидно, что обе метрики не совершенны и при их определении много субъективных оценок экспертов. Защитники функционально-ориентированного подхода считают его более прогрессивным по сравнению с методом, основан­ным на оценке размеров программного продукта, поскольку ФТ не зависит от языка программирования. Кроме этого, поскольку функционально-ориентированная метрика основана на данных, вытекающих из анализа пред­метной области, то меру ФТ более просто определить уже на ранних этапах разработки проекта. В результате оценка ресурсов при планировании разра­ботки оказывается более обоснованной. Оппоненты этого метода утверждают, что функционально-ориентированный подход основан в большей степени на субъективных оценках, а мера функциональных точек не имеет физического смысла, т.к. выражается абстрактным числом. Несмотря на критические заме­чания оба подхода дают менеджеру полезную информацию, позволяющую уже на начальных этапах получить оценки проекта с достоверностью, соот­ветствующей начальному этапу проектирования.

Этот метод используется для измерения производительности взамен устаревшего линейного подхода, где производительность измерялась количеством строк программного кода. Впервые функциональные точки (function points) были предложены сотрудником IBM Аланом Альбрехтом в 1979 г. .

Преимуществом данного метода является то, что поскольку применение функциональных точек основано на изучении требований, то оценка необходимых трудозатрат может быть выполнена на самых ранних стадиях работы над проектом. Для поддержки и развития данного метода в 1986 г. была создана Международная группа пользователей функционального измерения (IFPUG - International Function Point User Group).

Метод заключается в следующем.

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

Следующим шагом метода будет подсчет количества факторов, приведенных ниже:

• внешние входы. Различаются только те входы, которые по-разному влияют на функцию. Функция выбор метода имеет один внешний вход;
• внешние выходы. Различными считаются выходы для различных алгоритмов. Представим, что наша функция выдает сообщение - текстовое описание выбранного метода, и вызывает другую функцию, непосредственно реализующую выбранный алгоритм сортировки, следовательно, она имеет два выхода;
• внешние запросы. В нашем примере таковых нет;
• внутренние логические файлы - группа данных, которая создается или поддерживается функцией, считается за единицу. В качестве внутреннего логического файла для нашей функции примем текстовый файл, содержащий описания алгоритмов;
• внешние логические файлы - пользовательские данные, находящиеся во внешних по отношению к данной функции файлах. Каждая группа данных принимается за единицу. Внешним по отношению к нашей функции является файл с результатом обработки.

Далее полученные значения умножаются на коэффициенты сложности для каждого фактора (по данным 1РР1Ю) и суммируются для получения полного размера программного продукта. Значения этих коэффициентов приведены в табл. 9.1.

Таблица 9.1. Значения коэффициентов сложности

Для рассматриваемого нами примера возьмем значения, приведенные в табл. 9.2.

Размер нашей функции составит:

ФР =1хЗ+1х4+1х5+1х7+1х7 = 26.

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

Таблица 9.2. Пример коэффициентов сложности

Параметр
Внешние входы
Внешние выходы
Внешние запросы
Внутренние логические файлы
Внешние логические файлы

Следующим шагом в определении размера программного кода методом функциональных точек является присвоение веса (от 0 до 5) каждой характеристике проекта. Перечислим эти характеристики:

• 1. Требуется ли резервное копирование данных?
• 2. Требуется обмен данными?
• 3. Используются распределенные вычисления?
• 4. Важна ли производительность?
• 5. Программа выполняется на сильно загруженном оборудовании?
• 6. Требуется ли оперативный ввод данных?
• 7. Используется много форм для ввода данных?
• 8. Поля базы данных обновляются оперативно?
• 9. Ввод, вывод, запросы являются сложными?
• 10. Внутренние вычисления сложны?
• 11. Код предназначен для повторного использования?
• 12. Требуется преобразование данных и установка программы?
• 13. Требуется много установок в различных организациях?
• 14. Требуется поддерживать возможность настройки и простоту использования?

Значения для данных характеристик определяются следующим образом: 0 - никогда; 1 - иногда; 2 - редко; 3 - средне; 4 - часто; 5 - всегда.

Эти характеристики для примера функции сведены в табл. 9.3.

Таблица 9.3. Пример характеристик проектов

Характеристика	Значение в примере	Характеристика	Значение в примере

Определяется 5 - сумма всех весов.

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

УФР = ФР X (0,65 + 0,01 X 5). (9.3)

Уточненный функциональный размер функции выбор метода будет следующим:

УФР = 26 х (0,65 + 0,01 х 29)= 17,19.

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

В настоящее время существует несколько модификаций метода функциональных точек .

Точки свойств

В случае, если вышеописанные характеристики не отражают истинной сложности реализации (например, при разработке операционных систем), вместо метода функциональных точек применяют его усовершенствованный вариант, предложенный в 1988 г. Кейперсом Джонсом, - метод точек свойств. Этот метод корректирует оценки, полученные методом функциональных точек с учетом алгоритмической сложности программного продукта.

Метод Mark II

Метод Mark II был представлен Чарльзом Саймонсом также в 1988 г. Этот метод более пригоден для оценки сложных систем, чем классический метод функциональных точек. Он позволяет добиться одного и того же результата как при оценке системы в целом, так и при суммировании оценок, полученных для составляющих ее подсистем.

Трехмерные функциональные точки

В 1991 г. софтверным подразделением корпорации Boeing было предложено еще одно решение - метод трехмерных функциональных точек. Отличием от классического метода является то, что сложность программного продукта оценивается по трем направлениям - данные, функции и управление. Достоинством метода является его применимость не только к оценке программных проектов, но и к оценке трудоемкости задач в других сферах деятельности.

Объектные точки

Метод объектных точек адаптирует оригинальный метод функциональных точек к объектно-ориентированной технологии программирования.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

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

Размещено на http://www.allbest.ru/

Модели COCOMO, COCOMO II, метод функциональных точек. Их сравнительный анализ и область применения

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

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

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

Вследствие этого в широких пределах могут изменяться трудоемкость и число специалистов, необходимое для поддержки этих этапов ЖЦ. Это затрудняет статистическое обобщение ТЭП различных проектов и прогнозирование на их основе аналогичных характеристик новой разработки. Поэтому планы на этих этапах имеют характер общих взаимосвязей содержания работ, которые требуют распределения во времени, индивидуально для каждого проекта. В результате прогнозирование и планирование трудоемкости и длительности данных этапов приходится производить итерационно на базе накопления опыта и анализа развития конкретных версий ПС, а также с учетом от их успеха на рынке.

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

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

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

Совместная, корректная обработка исходных данных этих двух типов позволяет при проектировании оценивать и получать новые, прогнозируемые характеристики процессов, планов и экономических показателей создания ПС. Исходные данные первого типа отражают характеристики конкретного создаваемого объекта или процесса, доступные методы и инструментальные средства автоматизации труда при их создании. Эти данные последовательно детализируются и уточняются в процессе проектирования и дальнейшей реализации, что, в частности, позволяет уточнять выбор компонентов аналогичных объектов и их характеристик для исходных данных второго типа.

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

При технико-экономическом обосновании программного проекта на любом уровне целесообразно применять методы и методики адекватные целям и этапам его реализации. Следует согласовывать цели оценивания ТЭП с потребностями в информации, способствующей принятию решений для планирования затрат труда и других ресурсов. В общем случае необходимо достигать сбалансированного состава целей оценивания разных характеристик, которые бы давали примерно одинаковую абсолютную величину уровня неопределенности оценок для всех компонентов ПС. Кроме того, каждая оценка технико-экономических показателей должна сопровождаться, указанием степени ее неопределенности. По мере разработки проекта эти оценки необходимо пересматривать и изменять, когда это становится выгодным.

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

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

· вследствие несовершенства методов оценивания ПС следует сравнивать оценки с действительными значениями технико-экономических показателей и использовать эти результаты для улучшения методов оценивания;

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

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

· допустимые трудозатраты (стоимость) на разработку ПО с требуемым качеством;

· время - длительность полного цикла создания программного продукта;

· необходимое и доступное число специалистов соответствующей квалификации.

Потребность в этих ресурсах в наибольшей степени зависит от размера (масштаба) и сложности разрабатываемого программного средства. Уточнения размеров программного средства и его компонентов могут быть решены последовательно к концу детального проектирования, однако при этом сохраняется неопределенность оценки размера комплекса программ и его трудоемкости порядка 5 - 10%, связанная с тем, насколько хорошо программисты понимают спецификации, в соответствии с которыми они должны кодировать программу. При этом целесообразно учитывать, что:

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

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

· следует возвращаться к предшествующим целям оценивания технико-экономических показателей и изменять их, когда это необходимо для ответственных бюджетных решений, принимаемых на ранних этапах и влияющих на следующие этапы.

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

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

Оценивание размера ПО

Действия по определению размеров и оценке программного обеспечения включаются в последовательность задач по планированию программного проекта. Им предшествует определение целей и области действия проекта, создание структуры выполнения работ (WBS), а также идентификация задач и действий. После задач по прогнозированию размеров ПО следуют задачи по оценке длительности и стоимости разработки, в процессе выполнения которых происходит распределение ресурсов, учет зависимостей, а также составление рабочего графика.

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

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

В настоящее время при оценке размера ПО чаще всего пользуются двумя основными единицами измерения - строками программного кода (Lines of code, LOC) и функциональными точками.

В качестве единиц измерения также можно использовать точки свойств, количество «жирных точек» на диаграмме потока данных (Data flow diagram, DFD), количество сущностей на диаграмме сущностей, объем документации, количество объектов, атрибутов и служб на объектной диаграмме. Вне зависимости от того, оценивается ли конечный продукт, как в случае использования LOC, либо его некоторая абстракция или модель, оценке подвергается то, чего еще нет в природе. Поэтому оценивание размеров представляет значительные трудности.

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

LOC оценка представляет собой наиболее универсальную метрику, поскольку может использоваться при создании любых программных продуктов. Она проще и понятнее как для специалистов, так и для заказчиков и инвесторов. Например, если утверждается, что один компонент программной системы, состоящей из n компонентов, в среднем потребует написания около 1000 строк программного кода, то каждый в состоянии прикинуть ее общий размер и хотя бы примерно оценить трудозатраты, требующиеся для ее создания, исходя из предположения, что средняя производительность одного программиста по-прежнему составляет около 3000 строк кода в год.

Однако многие эксперты в области разработки программного обеспечения утверждают, что это плохая единица измерения. Наиболее существенный вопрос, который возникает при использовании LOC оценок, заключается в том, что же собой представляет одна строка программного кода? Кроме того, при использовании LOC в качестве единицы измерения возникают сомнения в достоверности результатов, так как не учитывается следующее:

· число строк исходного кода зависит от уровня мастерства программиста. Фактически, чем выше мастерство программиста, тем меньшим количеством строк кода ему удастся обойтись для реализации определенной функциональной возможности (или функциональности) ПС;

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

· фактическое число LOC остается неизвестным до тех пор, пока проект не будет почти завершен. Поэтому LOC нельзя использовать для предварительной оценки усилий на разработку и построения плана-графика проекта;

· в программистском сообществе не достигнуто соглашения о методе подсчета строк кода. Языковые конструкции, используемые, например, в Visual C++, Ассемблере, Коболе или SQL, абсолютно различны. Метод же остается общим для любых приложений, в том числе использующих комбинацию различных языков;

· заказчику сложно понять, каково соотношение указанных им функциональных и нефункциональных (технических) требований к ПС и объемов программистской работы.

В то же время для повышения достоверности оценок есть несколько достаточно простых рекомендаций:

· Убедитесь, что каждая учитываемая строка исходного кода содержит лишь один оператор. Если в одной строке содержатся два выполняемых оператора, разделенных точкой с запятой, то они должны учитываться как две строки. Если же один оператор разбит на несколько «физических» строк, он будет учитываться как одна строка. В языках программирования допускаются различные правила кодирования, но обычно проще определять в строке один оператор, обрабатываемый компилятором или интерпретатором.

· Учитывайте все выполняемые операторы. Конечный пользователь может не иметь возможности практически использовать каждый оператор, но все операторы должны поддерживаться данным продуктом, в том числе и утилитами.

· Определения данных учитывайте лишь один раз.

· Не учитывайте строки, содержащие комментарии.

· Не учитывайте отладочный код либо другой временный код (пробное ПО, средства тестирования и пр.).

· Учитывайте каждую инициализацию, вызов или включение макроса (директивы компилятора) в качестве части исходного кода, в которой осуществляется какое-либо действие. Не учитывайте повторно используемые операторы.

На практике при оценке размера больших программных систем чаще пользуются показателем тысяч строк исходного кода KSLOC. Эта метрика чаще всего используется при оценках производительности, которая рассчитывается как KSLOC/SM, где SM - staff-month (человеко-месяцы).

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

Если предположить, что структура WBS для разрабатываемого программного средства разбита на несколько уровней декомпозиции, которые позволяют выделить фактические компоненты программной системы, а также дают основания для дальнейшей детализации, то возможно создание некоторого «статистического» показателя размера, который может быть получен с использованием процессов измерения и суммирования.

Величина размера каждого компонента может быть получена путем опроса экспертов, разрабатывавших такие системы, либо путем опроса потенциальных разработчиков подобных систем. В результате становится возможно оценить размер каждого блока на нижнем уровне структуры WBS. После сложения предполагаемых оценок появляется представление о размере программной системы в целом. Такой способ называется оценкой размера «снизу - вверх».

Этот показатель можно улучшить, если каждый оценщик укажет не одно, а три возможных значения размера: пессимистическое, оптимистическое и более или менее реалистическое. Затем к реалистическому значению, умноженному на 4, добавляется оптимистическая и пессимистическая оценки, и вся сумма делится на 6.

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

Например, если некоторый объект, отображенный на структуре WBS, может занимать от 200 до 400 строк кода и скорее всего его размер ближе к 200, то используя предложенный подход можно получить следующую оценку: (200+(250*4)+400)/6 = 266 LOC.

Оценка количества LOC по аналогии

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

Например, у нас имеется уже готовый модуль А, размер которого составляет 2345 LOC. Мы хотим создать новый модуль, который будет во многом схож с модулем А, но в него будут добавлены некоторые дополнительные свойства. Кроме того, мы придумали как сделать программный код более компактным. В результате этого размер модуля А" может быть оценен в 3000 LOC.

Конечно данный метод не является очень точным, так как при написании модуля А могли использоваться различные языки программирования, применяться алгоритмы с различными уровнями сложности, использоваться различный объем моделирования (моделирование, эмуляция, реальное приложение), но такая оценка все-таки имеет под собой какое-то количественное обоснование.

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

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

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

· Непосредственно связаны с конечным продуктом.

· Единицы LOC могут быть оценены еще до завершения проекта.

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

· Действия по непрерывному улучшения базируются на количественных оценках. При этом спрогнозированный размер может быть легко сопоставлен с реальным размером на этапе постпроектного анализа. Это позволяет экспертам накапливать опыт и улучшать сами методы оценки.

· Знание размера программного продуктам в LOC - единицах позволяет применять большинство существующих методов оценки технико-экономических показателей проекта (таких как трудозатраты, длительность проекта, его стоимость и др.).

Недостатки, связанные с применением LOC - оценок

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

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

· Применение методов оценки с помощью количества строк не регламентируется промышленными стандартами, например ISO.

· Разработка ПО может быть связана с большими затратами, которые напрямую не зависят от размеров программного кода. Это так называемые фиксированные затраты, связанные с разработкой спецификации требований, подготовкой пользовательской документации и пр., которые не включены в прямые затраты на кодирование.

· Программисты могут быть незаслуженно премированы за достижение высоких показателей LOC, если служба менеджмента посчитает это высоким признаком продуктивности. Хотя иногда большой объем кодирования является свидетельством недостаточно тщательного проектирования программы. Исходный код не является самоцелью при создании готового продукта, гораздо важнее обеспечить требуемую функциональность программного средства и добиться высоких показателей производительности команды.

· При подсчете LOC - единиц следует различать автоматически сгенерированный код и написанный вручную. Это сильно затрудняет применение автоматических методов подсчета.

· Показатели LOC не могут осуществляться при нормализации в случае, если использовались разные платформы или типы языков программирования.

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

· Генераторы кода зачастую провоцируют избыточный его объем, что может привести к значительным погрешностям в оценке размера ПС.

Часто производительность труда программистов оценивается по числу производимых строк кода, а это не всегда верно. Если программист вместо 200 строк в месяц напишет 250, то это не значит, что он точно стал лучше работать и заслуживает поощрения. Более правильно было бы учитывать не только количество написанного кода, но и его качество, что можно сделать с помощью применения следующей формулы:

Количество дефектов / количество строк кода

Фаза кодирования в большинстве проектов занимает от 7% до 20% трудозатрат, поэтому более важным является качество кода, а не его объем.

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

Первой и наиболее удачной альтернативой методу подсчета исходных строк кода стала разработанная в 1979 году Алланом Альбрехтом из IBМ методология, названная «Анализ показателей функциональности» (FPA, от Function Points Analysis). В ее основе лежит взгляд на ПС извне, с позиций пользователя системы, а не «со стороны» ее внутренних свойств (таких, как LOC). В результате анализа исходных требований к ПС и выяснения реальных потребностей пользователей определяется объем функциональных возможностей системы, показателями которых служат функции обработки информации настолько низкого уровня, насколько они укладываются в систему мышления пользователей, а кроме функций - данные, которые эти функции обрабатывают. Таким образом, методология FPA базируется на идее декомпозиции функций и данных до предельно допустимого (с точки зрения пользователя) уровня. Объем функциональных возможностей ПС (далее просто функциональный размер) определяется в так называемых условных единицах функциональности FP - от Function Points.

В течение пяти лет с момента появления, методология FPA и метод расчета размера отшлифовывались А. Альбрехтом и проходили практическую апробацию, а в середине 80-х годов была создана Международная группа пользователей показателей функциональности (IFPUG, от International Function Points User Group), которая и поддерживает дальнейшую эволюцию метода.

Метод функциональных точек позволяет решать следующие задачи:

· Разрешить проблему, связанную с трудностью получения LOC - оценок на ранних стадиях жизненного цикла.

· Определять количество и сложность входных и выходных данных, их структуру, а также внешние интерфейсы, связанные с программной системой.

В методе функциональных точек используется 5 информационных характеристик.

1. Количество внешних вводов. Подсчитываются все вводы пользователя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.

2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные программным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются.

3. Количество внешних запросов. Под запросом понимается диалоговый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует выполнения вычислений. Подсчитываются все запросы - каждый учитывается отдельно.

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

5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.

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

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

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

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

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

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

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

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

Размещено на Allbest.ru

...

Подобные документы

Целесообразность применения модели жизненных циклов как инструмента управления изменениями на предприятиях. Анализ видов жизненных циклов, исследование их взаимосвязи на соответствующих уровнях управления экономикой. Динамика процессов изменений.

контрольная работа , добавлен 12.11.2008


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

презентация , добавлен 09.02.2015


Назначение программного продукта. Требования к функциональным характеристикам. Исследование рынка сбыта продукта. Жизненный цикл изделия. Расчет трудоемкости разработки программы. Формирование цены предложения разработчика, расчет капитальных затрат.

курсовая работа , добавлен 28.12.2012


Жизненный цикл проекта и его фазы. Оценка устойчивости проекта (рисков и уровня безубыточности). Факторы потерь времени в ходе его реализации. Планирование работ по проекту создания бильярдного клуба за 51 неделю, с затратами не более 3,5 млн. руб.

курсовая работа , добавлен 22.12.2011


Жизненный цикл организации как совокупность стадий развития, которые проходит фирма за период своего существования. Особенности этапа коллегиальности, формализации деятельности, реструктуризации, спада. Возможности и ограничения модели жизненных циклов.

презентация , добавлен 28.11.2013


Понятие жизненного цикла организации, его различные модели и основные этапы. Действия руководителя на различных стадиях развития организации, перспективные модели ее эволюции. Анализ жизненных циклов, пройденных компанией на примере ООО "Лекрус Урал".

курсовая работа , добавлен 28.02.2012


Сущность и структура жизненного цикла организации, его основные этапы и значение. Методика анализа жизненного цикла организации. Механизм управления организацией по стадиям ее жизненного цикла. Факторы, влияющие на продолжительность жизни организации.

курсовая работа , добавлен 10.11.2010


Организация основного производства. Понятие и классификация производственных процессов. Технологическая цепочка производства изделий. Расчет длительности производственного цикла простого процесса. Пути сокращения длительности производственных циклов.

презентация , добавлен 06.11.2012


Общее понятие о жизненном цикле проекта. Основные процессы управления проектом. Анализ жизненного цикла и процессов нефтегазового проекта на примере проекта деятельности ОАО "ЛУКОЙЛ". Оценка фазы жизненного цикла проекта и рекомендации по управлению ним.

курсовая работа , добавлен 13.01.2014


Организационная структура управления проектом открытия ресторана. Разбиение работ по проекту. Матрица разделения административных задач управления. Определение относительных показателей внутренней трудоемкости. Сравнение трудоемкости и полезности.

ЛАБОРАТОРНАЯ РАБОТА № 4

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

Цель работы

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

Расчет по методу функциональных точек

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

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

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

2. В ПС имеется один внутренний логический файл (ILF) для хранения информации справочника. Причем, данные могут храниться как в обычном файле, так и в таблице СУБД.

Рис. 1. Экранная форма телефонного справочника

Число типов элементов записей (RET) для этого файла может быть равно единице, если данные в файле хранятся в виде однотипных записей: «Телефон», «Фамилия» и «Адрес», допустим, представлены в символьном формате. В случае же, если номер телефона будет представлен, как целое число, а фамилия и адрес в символьном формате, то тогда внутренний логический файл будет иметь два RET. Для определенности далее будем считать, что внутренний логический файл имеет два RET.

Число типов элементов данных (DET) внутреннего логического файла будет равно трем вне зависимости от формата представления номера телефона («Телефон», «Фамилия», «Адрес»). Таким образом, уровень сложности внутреннего логического файла – низкий.

Внешних интерфейсных файлов (EIF) данное ПС не имеет.

3. В ПС имеются два внешних ввода (EI): «Добавление записи» и «Удаление записи», поскольку именно эти две функции ПС модифицируют данные во внутреннем логическом файле. Так как внешний ввод «Добавление записи» ссылается на один внутренний логический файл и имеет пять элементов данных (поля «Телефон», «Фамилия», «Адрес», кнопка «Добавить» и сообщение, подтверждающее факт добавления записи), то уровень сложности этого ввода низкий (см. табл. 4.2). Аналогично, уровень сложности внешнего ввода «Удаление записи» также низкий, поскольку имеется один FTR и пять DET (поля «Телефон», «Фамилия», «Адрес», кнопка «Удалить» и сообщение, подтверждающее факт удаления записи).

В программе имеются два внешних запроса (EQ): «Вывод списка» отсортированных записей и «Поиск записи» в справочнике. Внешний запрос «Вывод списка» имеет низкий уровень сложности, так как ссылается на один внутренний логический файл и имеет четыре элемента данных («Телефон», «Фамилия», «Адрес» и группа радио-кнопок «Сортировка»). Уровень сложности «Поиска записи» в справочнике также низкий (один внутренний логический файл и пять элементов данных: «Телефон», «Фамилия», «Адрес», кнопка «Поиск», сообщение об отсутствии искомой информации).

В ПС имеется также один внешний вывод (EO): вывод уведомляющего сообщения при попытке добавить запись с существующим номером телефона. Уровень сложности этого внешнего вывода – низкий, так как он имеет один FTR и два DET: номер телефона и само сообщение.

Полученные данные сведем в табл. 1. и рассчитаем ненормированное количество функциональных точек UFPC по формуле 1.

Таблица 1. Данные для расчета числа UFPC телефонного справочника

4. Подсчитаем теперь с помощью табл. 2. и формулы (2) итоговую степень влияния (TDI) общих характеристик системы и нормирующий фактор (VAF).

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

· «Диалоговый ввод данных», который оценивается с весом – 5, поскольку все 100% транзакций в ПС являются интерактивными;

· «Эффективность для конечного пользователя», которая оценивается с весом – 1, поскольку в ПС имеются функции автоматической установки курсора, скроллинга и интерфейс с мышью;

· «Простота использования», которая оценивается с весом – 5, поскольку в ПС все функции автоматизированы за исключением загрузки/выключения и имеется автоматическое восстановление после ошибок;

· «Распространенность», которая оценивается с весом – 2, поскольку ПС рассчитано на работу на совместимом аппаратном/программном обеспечении;

· «Легкость изменения», которая оценивается с весом – 2, поскольку ПС хранит информацию в таблицах, поддерживаемых пользователем в диалоговом режиме.

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

Нормирующий фактор (VAF) определится как

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

В заключение, оценим количество строк исходного кода с использованием бэкфайер-метода, исходя из того, что программу необходимо разработать с использованием языка программирования C++:

Таким образом, законченная программа телефонного справочника будет содержать примерно 975 строк исходного кода на языке программирования C++.

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

Например, измерение времени, проводимого служащим на рабочем месте в качестве меры интенсивности его труда и вклада в процветание организации, не вполне адекватно: человек может занять себя на работе и другими вещами. Соответственно, введение административных мер по поощрению "много работающих" и наказанию "мало работающих" только на основании таких измерений может иметь "неожиданные" последствия - показатели "хорошей работы" будут расти, а реальная работа не станет выполняться быстрее или лучше.

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

Одна из первых идей, которая приходит в голову при оценке трудоемкости и времени разработки ПО, - оценить сначала сложность или размер программы, а потом умножить полученную оценку на производительность исполнителей. Похоже, однако, что природа разработки программ такова, что ее трудоемкость слабо связана с размерами результата (например, приводимая ниже модель COCOMO , выражает эту связь в достаточно сложном виде). Часто оказывается, что оценить сразу трудоемкость по аналогии с имеющимся примерами можно точнее, чем оценив сначала размер. Тем не менее, метрики размера и сложности ПО часто используются для оценки трудоемкости разработки.

Самой простой и наиболее широко используемой метрикой является размер программы в строках ее кода (lines of code, LOC) . Ее основное достоинство - понятность и простота вычисления. Ее недостатки - не очень хорошая адекватность в качестве метрики трудоемкости разработки программы, зависимость от используемых языков и технологий и трудность предварительной оценки размера ПО. Практика показывает, что качественная программа часто имеет несколько меньший объем, чем программа с теми же функциями, но менее удобная для сопровождения или совершающая больше ошибок. В то же время, на разработку первой программы может уйти в два-три раза больше усилий.

С другой стороны, производительность разных разработчиков очень сильно отличается, но обычно руководители групп и организаций примерно представляют себе среднее значение по группе или организации. В терминах строк кода она обычно лежит в пределах от 5000 до 50000 строк хорошо отлаженного кода без учета комментариев за 1 человеко-год.

Более хитрой метрикой сложности программы являются функциональные точки (functional points, FP) , . Количество функциональных точек в программной системе вычисляется примерно следующим образом.

• Выделяются обращения к системе с целью ввода данных, с целью получения каких-то уже имеющихся в ней данных (отчеты), и с запросами, в ходе которых данные вводятся в систему, перерабатываются и выдаются какие-то результаты. Дополнительно определяются группы взаимосвязанных данных (называемые файлами) внутри системы и аналогичные группы, лежащие вне ее, но используемые в ее работе.
• Для всех данных из перечисленных пяти категорий оценивается их сложность (по шкале "низкая"–"средняя"–"высокая").
• Итоговая сложность программной системы вычисляется как сумма сложностей выявленных отдельных представителей этих пяти категорий. Сложность ввода, вывода, запроса или группы данных вычисляется умножением оценки сложности составляющих данных на весовой коэффициент, который можно найти в стандартах , или определить на основе собственного опыта. Обычно весовые коэффициенты групп данных больше, чем коэффициенты для вводов, выводов или запросов.

Количество строк кода, приходящихся на одну функциональную точку, зависит от используемых технологий и языка программирования и меняется от 300 для программирования на ассемблере до 5–10 для компонентных технологий на базе языков высокого уровня.

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

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

Наиболее известным методом оценки трудоемкости и времени проекта, основанным на большом количестве данных из проведенных ранее проектов, является конструктивная модель стоимости версии II (Constructive Cost Model II , COCOMO II ) , , .

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

• На самых ранних этапах, когда примерно известны только общие требования, а проектирование еще не начиналось, используется модель состава приложения (Application Composition Model) . В ее рамках трудоемкость проекта оценивается в человеко-месяцах по формуле

  Effort = A*Size.

  • Size представляет собой оценку размера в терминах экранов, форм, отчетов, компонентов и модулей будущей системы. Каждый такой элемент оценивается с коэффициентом от 1 до 10 в зависимости от своей сложности.
  • Коэффициент A учитывает возможное переиспользование части компонентов и производительность разработки, зависящую от опытности команды и используемых инструментов и оцениваемую числом от 4 до 50.

    A = (100 – (процент переиспользования))/производительность.

• На следующих этапах, когда требования уже в основном известны и начинается разработка архитектуры ПО, используется модель этапа предварительного проектирования (Early Design Model) и следующие формулы.

  Для трудоемкости (в человеко-месяцах):

  Effort = A*(Size) B *M E + (трудозатраты на автоматически генерируемый код)

  Для времени (в месяцах):

• После того, как разработана архитектура ПО, оценки должны выполняться с использованием постархитектурной модели (Post-Architecture Model) .

  Формула для трудоемкости (в человеко-месяцах):

  Effort= A*(K req *Size) B *M P + (трудозатраты на автоматически генерируемый код)

  Для времени - та же формула, что и в предыдущей модели (в месяцах):

  Time = T*Effort S (0.28+0.2*(B-1.01)) *Sced.

  • Size = (размер нового кода в тыс. строк) + RSize , где

    RSize = (размер переиспользуемого кода в тыс. строк) * (100 – AT)/100 * (AA + 0,4*DM + 0,3*CM + 0,3*IM + SU)/100

    • AT - процент автоматически генерируемого кода;
    • AA - фактор трудоемкости перевода компонентов в повторно используемые, от 0 до 8;
    • DM - процент модифицируемых для переиспользования проектных моделей;
    • CM - процент модифицируемого для переиспользования кода;
    • IM - процент затрат на интеграцию и тестирование повторно используемых компонентов;
    • SU - фактор понятности переиспользуемого кода, от 10 для простого, хорошо структурированного, до 50 для сложного и непонятного; равен 0 , если CM = DM = 0 .
  • Все коэффициенты, кроме K req и M P , имеют те же значения, что и в предыдущей модели.
  • Коэффициент K req вычисляется как (1 + (процент кода, выброшенного из-за изменений в требованиях)/100).
  • Коэффициент M P является произведением 17 коэффициентов затрат, имеющих значения от 1 до 6:
    • надежность продукта;
    • сложность продукта;
    • размер базы данных разрабатываемого приложения;
    • требуемый уровень повторного использования;
    • требуемый уровень документированности;
    • уровень производительности по времени;
    • уровень требований к занимаемой оперативной памяти;
    • изменчивость платформы;
    • возможности аналитика проекта;
    • возможности программистов;
    • опыт работы команды в данной предметной области;
    • опыт работы команды с используемыми платформами;
    • опыт работы команды с используемыми языками и инструментами;
    • уровень текучести персонала в команде ;
    • возможности используемых инструментов;
    • возможности общения между членами команды ;
    • фактор сжатия графика проекта.

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