2. Модель оценки трудоемкости количества функциональных точек

Для оценки ПС, разрабатываемого в рамках дипломного проекта студента рекомендуется использование конструктивной модели стоимости (Constructive Cost Model – COCOMO).

Основа COCOMO − модель, которая вычисляет стоимость разработки программного обеспечения в зависимости от оценок размера кода программы и комплекса "издержек", которые включают субъективную оценку товара, оборудования, персонала и проектных характеристик.

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

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

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

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

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

Таблица 1

Распределение сложности исполнения этапов разработки

Категория сложности ПС	разра-ботка	дополнительные требования	поддержка
Очевидное (распространенное) ПС	70	20	10
ПО с элементами уникальности	60	30	10
Уникальное ПС	40	30	30

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

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

На основании количества блоков графической модели осуществляется подсчет количества функциональных точек процесса в разрезе каждой категории, определение весовых коэффициентов сложности каждой функции, учет факторов и требований среды разработки программной системы, вычислений интегральных показателей сложности, вычисление итогового количества функциональных точек, определение размеров ПС в показателях LOC (lines of code) – среднего количества операторов конкретного языка программирования, требующихся для реализации одной функциональной точки (табл. 2), определение размеров программной системы в целом.

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

Таблица 2

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

Язык программирования	Ассемблер (LOC)	Показатель LOC на 1 функциональную точку
Basic Assembler	1	320
Macro Assembler	1,5	213
Basic	3	107
Pascal	3,5	91
C++	6	53
Java	6	53
Oracle, Sybase	8	40
Access	8,5	38
Delphi	11	29
Smalltalk	15	21
HTML 3.0	22	15
SQL (ANSI)	25	13
Excel	50	6

Расчет количества функциональных точек ПС каждому блоку графической модели рекомендуется сводить в следующую таблицу (табл. 3).

Таблица 3

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

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

В табл. 3 представлена схема расчета, которой следует руководствоваться при определении количества функциональных точек с учетом поправочных коэффициентов. В данной таблице − весовой коэффициент сложности -й функции j-й категории сложности; − количество элементов данных -й функции j-й категории сложности.

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

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

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

Таблица 4

Весовые коэффициенты сложности выводов

Количество файлов	Количество элементов данных
	от 1 до 5	от 6 до 19	20 и более
1
2-3
4 и более

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

По аналогии с выводом все вводы также рекомендуется разделять ПС категориям (табл. 5).

Таблица 5

Весовые коэффициенты сложности ввода

Количество файлов	Количество элементов данных
	от 1 до 5	от 6 до 19	20 и более
1
2-3
4 и более

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

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

Таблица 6

Весовые коэффициенты сложности опросов вывода

Количество файлов	Количество элементов данных
	от 1 до 5	от 6 до 19	20 и более
1
2-3
4 и более

Таблица 7

Весовые коэффициенты сложности опросов ввода

Количество файлов	Количество элементов данных
	от 1 до 5	от 6 до 19	20 и более
1
2-3
4 и более

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

Таблица 8

Весовые коэффициенты сложности структурных данных

Количество логических взаимосвязей	Количество элементов данных
	от 1 до 19	от 20 до 50	более 51
Одна логическая запись типа формат/взаимосвязь
От 2 до 5 записей
более 6 записей

Определение количества интерфейсов. Под интерфейсами, используемыми рассматриваемым блоком графической модели, будем понимать:

• файлы, сгенерированные другими программными системами и использующиеся в данной ПС;

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

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

Весовые коэффициенты оценки сложности интерфейсов представлены в таблице 9.

Таблица 9

Весовые коэффициенты сложности интерфейсов

Количество логических взаимосвязей	Количество элементов данных
	от 1 до 19	от 20 до 50	более 51
Одна логическая запись типа формат/взаимосвязь
От 2 до 5 записей
более 6 записей

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

(1)

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

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

Таблица 10

Факторы среды разработки

№ п/п	Факторы среды	Степень важности параметра для функционирования разрабатываемого ПС, баллов
		не важно [0-1]	важно [2-3]	очень важно [4-5]
1	Каналы передачи данных
2	Распределенные вычисления
3	Производительность системы
4	Конфигурирование
5	Частота транзакций
6	Интерактивная обработка
7	Пользовательский интерфейс
8	Интерактивное обновление БД
9	Сложность обработки запросов
10	Сложность инсталляции ПС
11	Сложность эксплуатации системы
12	Степень распределенности системы
13	Гибкость изменения функций
14	Общая сумма выставленных баллов по всем градациям

В случае если какой-либо из показателей не используется ему присваивается балльное значение «0». Выбор непосредственного значения осуществляется студентом самостоятельно на основании особенностей разрабатываемого им в дипломном проекте ПС.

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

(2)

где – суммарное значение балльных оценок факторов внешней среды приведенных в табл. 10.

Уточненное количество функциональных точек с учетом факторов внешней среды определяется ПС следующей формуле:

(3)

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

(4)