Материал: 970

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

По уровню сложности различают три типа программных продуктов [35]:

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

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

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

врежиме реального времени;

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

3)инженерные и научно-технические пакеты прикладных программ (ППП), характеризующихся четко заданным алгоритмом обработки и малыми объемами исходных данных (третий тип ПП).

3.5.2.Прямой метод определения размеров программного продукта на основе опыта экспертов

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

При декомпозиции целесообразно использовать следующие термины и определения (рис. 3.3):

2063. Финансово-экономические основы ведения бизнеса

·интегрированный программный продукт— совокуп-

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

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

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

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

Интегрированный программный продукт

Рис. 3.3. Структура интегрированного программного продукта

Размеры программного продукта определяются в виде количества строк исходного кода (Lines of code — LOC) [31].

При оценке количества строк исходного кода следует учитывать следующее:

·строка исходного кода содержит только один оператор;

·описание исходных данных учитывается один раз;

·не учитываются строки, содержащие комментарии и отладочные операторы;

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

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

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

3.7[31].

Таблица 3.7 Соответствие среднего числа строк текста программы на языке

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

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

стической оценки на 4, добавлением оптимистической и пессимистической оценок и делением полученного результата на 6:

где rijk — средняя оценка k-го эксперта j-го программного ком-

понента на i-м уровне.

Таблица 3.8 Бланк экспертного оценивания размерности

программного продукта Язык программирования _____________

1. Программный продукт

1.1.Программный компонент 1

1.2.Программный компонент 2

……………………

После оценивания всех компонентов на каждом уровне, начиная с нижнего, происходит суммирование результатов измерения по принципу «снизу-вверх»:

где k =1, q — количество экспертов;

i = 1, n — количество уровней декомпозиции программного продукта;

j = 1, m — количество программных компонентов наi-м уровне.

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

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

Этот метод целесообразно использовать на ранних стадиях

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

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

Метод функциональных точек (Function point, FP) осно-

вывается на том, что размеры программного продукта оцениваются в терминах количества и сложности бизнес-процессов(функ- ций), реализуемых в данном программном коде [31].

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

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

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

вывода и обработки, интерфейсов и структуры данных (файлов).

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

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

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

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