Поиск

Расширенный поиск

 

 
 

 
 
 

Название документа

Об утверждении временной методики расчета стоимости разработки и приобретения программного обеспечения

Тип документаПостановление
Орган, утверждающий документМинистерство по развитию информационных технологий и коммуникаций Республики Узбекистан
РазработчикМинистерство по развитию информационных технологий и коммуникаций Республики Узбекистан
Дата размещения документа12.06.2015 15:26
Дата завершения обсуждения27.06.2015 00:00
Вид документаПроект НПА
Текущее состояние документаОбсуждение прекращено
Обоснования необходимости принятия проекта(не задано)
Планируемый срок вступления в силу01.01.1970

ПОСТАНОВЛЕНИЕ

МИНИСТЕРСТВА ПО РАЗВИТИЮ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
И КОММУНИКАЦИЙ РЕСПУБЛИКИ УЗБЕКИСТАН

Об утверждении временной методики расчета стоимости разработки

и приобретения программного обеспечения


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

1.Утвердить Временную методику расчета стоимости разработки и приобретения программного обеспечения (далее – Временная методика) согласно приложению.

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

3.Настоящее постановление вступает в силу со дня его официального опубликования.

Министр по развитию

информационных технологий

и коммуникаций

Республики Узбекистан

Х. Мирзахидов

г. Ташкент

«___» __________ 2015 года

№ _______

Временная методика расчета стоимости разработки (приобретения) программного обеспечения в рамках проектов по созданию государственных информационных систем

I.Общие положения

1.Настоящая Временная методика расчета стоимости разработки (приобретения) программного обеспечения в рамках проектов по созданию государственных информационных систем (далее – Методика) в соответствии с решением Республиканской комиссии по координации реализации Комплексной программы развития Национальной информационно-коммуникационной системы Республики Узбекистан на 2013-2020 годы от _________ № __, определяет методы и порядок оценки стоимости разработки (приобретения) программного обеспечения.

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

3. Настоящая Методика разработана в соответствии с международным стандартом ISO/IEC 20926:2009 «Разработка программного обеспечения и систем. Измерения в программном обеспечении. Метод измерения функционального размера IFPUG 2009» и основывается на определении функционального размера программного обеспечения методом анализа функциональных точек.

I.Термины и определения

1.В целях настоящей Методики применяются следующие основные понятия и сокращения:

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

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

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

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

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

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

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

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

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

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

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

внешняя выходная транзакция (EO) – элементарная операция по извлечению данных или управляющей информации из ILF или EIF, предусматривающая создание производных данных путем математических и иных вычислений;

внешний запрос (EQ) – элементарная операция по извлечению данных или управляющей информации из ILF или EIF, не предусматривающая создание производных данных путем математических и иных вычислений;

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

элемент типа «запись» (RET) – выделяемая пользователем логическая подгруппа элементов данных внутри ILF или EIF, по количеству которых определяется функциональная сложность данных оцениваемого приложения;

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

III.Область применения

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

6. В настоящей Методике под разработкой программного обеспечения понимается совокупность работ по анализу требований, проектированию, программированию, сборке, тестированию, интеграции, вводу в действие и приемке программного продукта

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

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

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

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

IV.Расчет стоимости разработки программного обеспечения

10.Расчет стоимости программного обеспечения предусматривает выполнение следующей последовательности шагов:

1.Определение типа оценки.

2.Определение области и границ оцениваемого приложения.

3.Определение нескорректированного размера приложения. Данный шаг включает:

3.1.Подсчет функциональных точек, связанных с данными;

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

4.Определение скорректированного размера приложения. Данный шаг включает:

4.1.Определение значения корректирующего фактора;

4.2.Применение корректирующего фактора к нескорректированному размеру приложения.

5.Определение стоимости разработки приложения.

V.Определение типа и области оценки

11.Метод функциональных точек предусматривает три типа оценки функционального размера приложения (Таблица 1):

Таблица 1. Типы оценки размера приложения методом функциональных точек

Тип оценки

Описание

1

Проект разработки

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

2

Проект развития

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

3

Существующее приложение

Оценивается объем уже существующего и установленного приложения.

12.В зависимости от типа, область оценки может включать:

•Все разрабатываемые функции (для проекта разработки);

•Все добавляемые, изменяемые и удаляемые функции (для проекта развития);

•Только функции, реально используемые, или все функции (при оценке одного или нескольких приложений).

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

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

14.В настоящей Методике приводятся три метода определения нескорректированного размера приложения, которые отличаются объемом входной информации для проведения расчета:

а)Стандартный метод;

б)Ориентировочный метод;

в)Индикативный метод.

15.Наиболее подробные сведения об объекте оценки требуются для применения стандартного метода, далее по убыванию объема требуемой информации следуют ориентировочный и индикативный методы.

VIII.Стандартный метод оценки нескорректированного размера приложения

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

17. Метод функциональных точек выделяет пять типов функций, используемых в приложении (Таблица 2).

Таблица 2. Типы функций в рамках метода функциональных точек

Группа функций

Типы функций

Функции, связанные с данными

1.Внутренние логические файлы (ILF)

2.Внешние интерфейсные файлы (EIF)

Функции, связанные с транзакциями

3.Внешние входные транзакции (EI)

4.Внешние выходные транзакции (EO)

5.Внешние запросы (EQ)

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

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

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

21. Группа данных (блок управляющей информации) может быть отнесена к ILF при соблюдении следующих условий:

а)Данные логически связаны и идентифицируемы пользователем. Так, не все таблицы в базе данных могут быть отнесены к отдельным ILF. Например, хотя данные о заказах физически могут храниться в двух таблицах БД – заказы (Orders) и детали заказов (OrderDetails), с точки зрения пользователя это одна логическая сущность, и поэтому должны рассматриваться как один ILF с двумя RET.

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

21. Группа данных (блок управляющей информации) может быть отнесена к ILF при соблюдении следующих условий:

а)Данные логически связаны и идентифицируемы пользователем. Так, не все таблицы в базе данных могут быть отнесены к отдельным ILF. Например, хотя данные о заказах физически могут храниться в двух таблицах БД – заказы (Orders) и детали заказов (OrderDetails), с точки зрения пользователя это одна логическая сущность, и поэтому должны рассматриваться как один ILF с двумя RET.

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

22. 1.Группа данных (блок управляющей информации) может быть отнесена к EIF при соблюдении следующих условий:

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

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

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

Данные являются внутренним логическим файлом (ILF) другого (внешнего) приложения

23. По каждому ILF и EIF определяется его функциональная сложность путем идентификации и подсчета элементов типа «запись» (RET) и элементов типа «данные» (DET).

24.Пример: ILF «Информация о клиенте» может содержать несколько адресов и номеров телефонов клиента, что означает наличие двух RET: адрес и номер телефона. Примерами DETдля ILF и EIFмогут служить поля в таблице базы данных.

25. При подсчете элементов RETсоблюдаются следующие правила:

а)Считать элементом RET каждую логическую подгруппу данных внутри ILF и EIF.

б)Считать одним элементом RET весь ILFили EIF при отсутствии в нем подгруппы данных.

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

26.При подсчете элементов DETв ILF и EIF соблюдаются следующие правила:

а)Считать элементом DET каждое уникальное, выделяемое пользователем, неповторяемое поле, поддерживаемое в и/или считываемое из ILF/EIF в рамках элементарных процессов.

б)Считать элементом DET каждое поле данных, требуемое для установления связи с другим ILF/EIF. Например, поля внешних ключей (foreign key) принимаются в расчет.

в)Не считать элементом DET генерируемые системой технические поля в таблицах базы данных (ID, timestamps и т.д.).

27. 1.Уровень функциональной сложности по каждому файлу ILF и EIF определяется на основании матрицы сложности, приведенной в Таблице 3.

Таблица 3. Матрица оценки сложности данных (ILF и EIF)

1-19 DET

20-50 DET

50+ DET

1 RET

Низкая

Низкая

Средняя

2-5 RET

Низкая

Средняя

Высокая

6+ RET

Средняя

Высокая

Высокая

28.По каждому идентифицированному объекту данных ILF и EIF определяется его вес, выраженный в количестве функциональных точек, в зависимости от уровня сложности и типа (Таблица 4).

Таблица 4. Вес одного объекта данных (ILF, EIF) в зависимости от сложности и типа

Сложность данных

Количество функциональных точек

ILF

EIF

Низкая

7

5

Средняя

10

7

Высокая

15

10

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

В оцениваемом приложении выявлен объект «Сведения о сотруднике», который включает в себя полное имя (ФИО – 3 DET), дату рождения (1 DET), адрес (индекс, страна, область, район, город, улица, дом, корпус, квартира – 9 DET) и паспортные данные сотрудника (номер, дата выдачи, кем выдан, срок действия – 4 DET).

Данный объект содержит 4 подгруппы данных (RET), которые в совокупности состоят из 17 неповторяемых уникальных полей данных (DET). Согласно матрице в таблице 3, его сложность – низкая. Если данный объект относится к внутренним логическим файлам, то согласно таблице 4, он оценивается в 7 функциональных точек. Если же объект является внешним интерфейсным файлом, его вес составит 5 функциональных точек.

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

В оцениваемом приложении выявлен объект «Сведения о сотруднике», который включает в себя полное имя (ФИО – 3 DET), дату рождения (1 DET), адрес (индекс, страна, область, район, город, улица, дом, корпус, квартира – 9 DET) и паспортные данные сотрудника (номер, дата выдачи, кем выдан, срок действия – 4 DET).

Данный объект содержит 4 подгруппы данных (RET), которые в совокупности состоят из 17 неповторяемых уникальных полей данных (DET). Согласно матрице в таблице 3, его сложность – низкая. Если данный объект относится к внутренним логическим файлам, то согласно таблице 4, он оценивается в 7 функциональных точек. Если же объект является внешним интерфейсным файлом, его вес составит 5 функциональных точек.

30.По результатам анализа определяются элементарные операции, представляющие значение для пользователя и переводящие приложение из одного состояния в другое, которые группируются на внешние входные транзакции (EI), внешние выходные транзакции (EO) и внешние запросы (EQ).

31.Примерами EIявляются функции ввода данных пользователем, считывания данных из файлов внешних приложений. Примерами EO служат формируемые приложением отчеты, содержащие производные данные. Примерами EQ служат SQL-запросы по извлечению данных из таблиц БД, находящихся как внутри приложения, так и за его пределами

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

Таблица 5. Основные отличия между типами транзакций

Назначение

Тип транзакции

EI

EO

EQ

Изменяет поведение системы

Основное

Дополнительное

Не применима

Поддержка одного или более ILF

Основное

Дополнительное

Не применима

Представление информации пользователю

Дополнительное

Основное

Основное

33.Основным назначением EIявляется изменение поведения приложения и поддержка внутренних логических файлов (например, посредством создания, редактирования и удаления записей в таблице БД), тогда как отображение информации является вспомогательной функцией (например, путем отображения текущих значений полей формы в операции редактирования объекта данных).

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

35.Основным назначением EQ является представление информации пользователю посредством простого извлечения данных из ILFи EIF. Логика обработки не предусматривает вычислений и генерирование производных данных. Также EQне изменяют данные и поведение системы.

36.По каждой идентифицированной транзакции EI, EO и EQ определяется ее функциональная сложность путем подсчета количества ссылок на файлы (FTR) и элементов типа «данные» (DET).

37.Примерами DET для EI, EO и EQмогут служить элементы управления графического интерфейса пользователя.

38.При подсчете ссылок на файлы (FTR) в транзакциях EIсоблюдаются следующие правила:

а)Считать ссылкой FTR каждый модифицируемый в транзакции ILF.

б)Считать ссылкой FTR каждый считываемый в транзакции ILF или EIF.

в)Считать только одной ссылкой FTR каждый ILF, который и модифицируется и считывается в рамках одной транзакции.

39.При подсчете элементов DETв транзакциях EIсоблюдаются следующие правила:

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

б)Не считать элементом DET поле, извлекаемое или производимое системой и сохраняемое в ILFв результате транзакции, если данные не пересекли границы приложения. Например, при добавлении клиентом нового заказа, цена за единицу продукции автоматически извлекается из таблицы цен и включается в накладную. Цена за единицу продукции не является элементом DETдля входной транзакции, поскольку она не пересекает границы приложения в момент, когда пользователь создает новый заказ.

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

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

д)Не считать элементом DET элемент управления графического интерфейса (кнопка, ссылка, переключатель и т.д.), который не изменяет данные и состояние системы. Например, кнопки «Отмена», «Выйти», «Далее» (если промежуточные значения формы не сохраняются), «Настройки по умолчанию» (если настройки не считываются из отдельного файла) на экранной форме не являются элементами DET.

40. При подсчете ссылок на файлы (FTR) в транзакциях EO и EQсоблюдается следующее правило – считать ссылкой FTR каждый считываемый в транзакции ILF или EIF.

41.При подсчете ссылок на файлы (FTR) в транзакциях EOсоблюдаются также следующие правила:

а)Считать ссылкой FTR каждый модифицируемый в транзакции ILF.

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

42.При подсчете элементов DET в транзакциях EOи EQсоблюдаются следующие правила:

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

б)Считать элементом DET каждое выделяемое пользователем, неповторяемое поле, которое выводится приложением. Например, главное окно приложения отображает список отделов организации в виде таблицы с тремя столбцами (код, название, начальник). Это пример транзакции EQcтремя элементами DET. Другой пример – приложение выводит отчет о кадрах организации в виде таблицы с тремя столбцами (код отдела, название отдела, количество сотрудников) и строкой итога (всего сотрудников). Это пример транзакции EOс четырьмя элементами DET.

в)Считать одним элементом DET, поле данных, которое пересекает границы приложения в обоих направлениях (вход и выход).

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

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

е)В транзакциях EO – не считать элементом DET поле, извлекаемое или производимое системой и сохраняемое в ILF в результате транзакции, если данные не пересекли границы приложения. Например, при распечатке доверенности, ее статус во внутреннем реестре приложения устанавливается как «Распечатана». Поскольку данные о статусе не пересекли границ приложения, это поле не учитывается как DET.

ж)Не считать элементами DET литералы и генерируемые системой штампы. Примерами литералов выступают названия отчетов, экранов и панелей, заголовки столбцов и названия полей. Примеры системных переменных и штампов – нумерация страниц, позиционная информация (например, «выбраны строки с 3 по 10 из 50»), навигационные команды (назад, вперед, в начало, в конец), дата и время (в колонтитулах, заголовках отчетов и т.д.).

43. Уровень функциональной сложности различных типов транзакций определяется на основании соответствующих матриц сложности (Таблицы 6 и 7).

Таблица 6. Матрица оценки сложности внешних входных транзакций (EI)

1-4 DET

5-15 DET

16+ DET

0-1 FTR

Низкая

Низкая

Средняя

2 FTR

Низкая

Средняя

Высокая

3+ FTR

Средняя

Высокая

Высокая

Таблица 7. Матрица оценки сложности внешних выходных транзакций (EO) и запросов (EQ)

1-5 DET

6-19 DET

20+ DET

0-1 FTR

Низкая

Низкая

Средняя

2-3 FTR

Низкая

Средняя

Высокая

4+ FTR

Средняя

Высокая

Высокая

44.По каждой идентифицированной транзакции определяется ее вес, выраженный в количестве функциональных точек, в зависимости от уровня сложности и типа (Таблица 8).

Таблица 8. Вес одной транзакции (EI, EO, EQ) в зависимости от сложности и типа

Сложность транзакций

Количество функциональных точек

EI

EO

EQ

Низкая

3

4

3

Средняя

4

5

4

Высокая

6

7

6

45.Общий размер оцениваемого приложения в нескорректированных функциональных точках (UFP) определяется путем суммирования функциональных точек по всем информационным объектам (ILF, EIF) и элементарным операциям (транзакциям EI, EO, EQ) по формуле:

UFP = ILF + EIF + EI + EO + EQ

VIII.Ориентировочный метод оценки нескорректированного размера приложения

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

а)Идентификацию и подсчет всех функций, связанных с данными и транзакциями (ILF, EIF, EI, EO, EQ);

б)Оценку сложности каждой функции, связанной с данными (ILF, EIF), как «Низкая»;

в)Оценку сложности каждой функции, связанной с транзакциями (EI, EO, EQ), как «Средняя»;

г)Расчет количества нескорректированных функциональных точек (UFP) по формуле:

UFP = ILF × 7 + EIF × 5 + EI × 4 + EO × 5 + EQ × 4

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

IX.Индикативный метод оценки нескорректированного размера приложения

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

а)Идентификацию и подсчет всех внутренних логических файлов (ILF) и внешних интерфейсных файлов (EIF) оцениваемого приложения;

б)Расчет количества нескорректированных функциональных точек (UFP) по формуле:

UFP = 35 × ILF + 15 × EIF

49. В индикативном методе в расчет принимаются только внутренние и внешние файлы, используемые приложением. В основе метода лежит предположение о том, что каждому внутреннему логическому файлу (ILF) будут соответствовать три внешние входные транзакции EI(добавить, изменить, удалить данные), две внешние выходные транзакции (EO) и один внешний запрос (EQ), а каждому внешнему интерфейсному файлу (EIF) – один EO и один EQ.

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

Согласно ТЗ, разрабатываемое приложение должно иметь следующие функциональные возможности:

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

2.Выводить список всех списаний со счета пластиковой карты;

3.Выводить сумму списаний за период времени (например, последний месяц).

Для выполнения этих операций, система поддерживает три ILF– «Карты», «Владельцы», «Банки» и ссылается на один EIF«Платежи» (дата, номер счета, сумма, детали), поддерживаемый внешней системой.

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

По итогам анализа, определяем – операция представляет собой внешнюю входную транзакцию (EI), которая ссылается на 3 файла FTR (карты, владельцы, банки) и использует 7 элементов DET (5 полей формы, кнопка действия ОК и сообщение об ошибке). Согласно таблицам 6 и 8, это транзакция с высоким уровнем сложности и весом в 6 функциональных точек. Аналогичный вес (6 ФТ) будет иметь операция по редактированию карты.

При удалении карты, система выводит диалоговое окно, в котором просит пользователя подтвердить действие по удалению определенной карты определенного владельца. При нажатии кнопки «Да», система удаляет карту, при нажатии кнопки «Нет» – состояние системы не меняется.

По итогам анализа, определяем – операция представляет собой внешнюю входную транзакцию (EI), которая ссылается на 2 файла FTR (карты, владельцы) и использует 4 элементов DET (2 поля данных – номер карты и имя владельца, кнопка действия «Да» и просьба подтвердить действие). Сложность транзакции оценивается как «Низкая» и ее вес составляет 3 функциональные точки.

Список карт отображается в виде таблицы из 5 столбцов – номер счета, тип карты, срок действия, название банка, имя владельца. Поскольку логика обработки заключается в простом извлечении данных из нескольких таблиц БД и не содержит вычислений или производных данных, эта транзакция является внешним запросом (EQ). В транзакции задействовано 3 FTR и 5 DET, следовательно ее сложность – низкая и вес составляет 3 ФТ.

Список списаний по карте отображается в виде отчета, содержащего номер счета, тип карты, имя владельца карты и таблицу списаний из 3 столбцов (дата, сумма, детали платежа). Данная операция является внешним запросом (EQ), в рамках которого происходит простое извлечение информации из внутренних и внешних файлов, без математических вычислений. В транзакции задействовано 3 FTR (карты, владельцы, платежи) и 6 DET, следовательно ее сложность – средняя, вес – 4 ФТ.

Сумма списаний по карте отображается в виде отчета, содержащего номер счета, тип карты, имя владельца карты, название банка, сумма списаний за последний месяц. Поскольку отчет содержит агрегированное поле (сумму платежей), данная операция представляет собой внешнюю выходную транзакцию (EO). Транзакция имеет 4 FTR (карты, владельцы, банки, платежи) и 5 DET, следовательно ее сложность – средняя, вес – 5 ФТ.

Транзакция

Тип

FTR

DET

Сложность

Вес

1

Создать карту

EI

3

7

Высокая

6

2

Редактировать карту

EI

3

7

Высокая

6

3

Удалить карту

EI

2

4

Низкая

3

4

Вывести список карт

EQ

3

5

Низкая

3

5

Вывести список списаний по карте

EQ

3

6

Средняя

4

6

Вывести сумму списаний по карте

EO

4

5

Средняя

5

Итого

27

В целом, реализация вышеуказанных функций системы оценивается в 27 функциональных точек.

X .Определение размера корректирующего фактора

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

Таблица 9. Параметры, определяющие системные характеристики приложения

Параметр

Значение

1

Распределенная обработка данных

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

1 – клиент-серверная архитектура, веб-приложение, онлайн обработка и передача данных.

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

2

Производительность

0 – пользовательские требования по производительности не установлены; обеспечивается базовый уровень производительности.

1 – время отклика или пропускная способность имеют важное значение в часы пик или на протяжении всего рабочего времени; установлено ограничение на время отклика на внешний запрос.

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

3

Отказоустойчивость

0 – пользовательские требования по отказоустойчивости не установлены; обеспечивается базовый уровень надежности.

1 – сбои могут быть легко устранены с небольшими потерями.

2 – восстановление системы после сбоя затруднительно и влечет за собой значительные финансовые потери или опасность здоровью.

4

Работа на различных платформах

0 – приложение предназначено для эксплуатации только в гомогенной аппаратно-программной среде.

1 – приложение предназначено для эксплуатации в схожих аппаратных и программных условиях.

2 – приложение предназначено для эксплуатации в гетерогенной аппаратно-программной среде.

51.Каждый из 4 системных параметров (DI) оценивается по шкале от 0 до 2. Расчет суммарного эффекта системных характеристик (TDI) осуществляется простым суммированием:

TDI = ∑ DI

52.Расчет значения корректирующего фактора производится по формуле:

VAF = TDI × 0,025 + 1

Например, если, каждый из четырех системных параметров получил оценку 1, то их суммарный эффект составит TDI = 1 + 1 + 1 + 1 = 4. В этом случае значение корректирующего фактора будет равняться VAF = 4 × 0,025 + 1 = 1,1.

XI.Определение скорректированного размера приложения

53.Оценка размера приложения в скорректированных функциональных точках (AFP) зависит от типа оценки. Базовый функциональный размер приложения определяется по формуле:

AFP = UFP × VAF

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

54.Проект разработки приложения оценивается в DFP по формуле:

DFP = (UFP + CFP) × VAF,

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

55.Проект доработки и совершенствования приложения оценивается в EFP по формуле:

EFP = (ADD + CHGA + CFP) × VAFA + (DEL × VAFB),

где:

ADD – функциональные точки для добавленной функциональности;

CHGA – функциональные точки для измененных функций, рассчитанные после модификации;

VAFA – величина корректирующего фактора, рассчитанного после завершения проекта;

DEL – объем удаленной функциональности;

VAFB – величина корректирующего фактора, рассчитанного до начала проекта.

56.Суммарное влияние процедуры корректирования лежит в пределах 100-120% к относительному объему, рассчитанному в UFP.

XII .Периодичность оценки функционального размера приложения

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

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

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

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

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

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

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

XIII.Определение стоимости разработки приложения

64.Себестоимость разработки приложения определяется путем умножения функционального размера приложения (AFP, DFP, EFP) на рекомендованную стоимость одной функциональной точки, устанавливаемую решением Республиканской комиссии по координации реализации Комплексной программы развития Национальной информационно-коммуникационной системы Республики Узбекистан на 2013-2020 годы.

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

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

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

Мне понравилось Мне не понравилось
Нравится: 0
Не нравится: 0

Общие комментарии и ответы

Ничего не найдено
Мне понравилось Мне не понравилось
Нравится: 0
Не нравится: 0
Проект Последняя редакция

ПОСТАНОВЛЕНИЕ

МИНИСТЕРСТВА ПО РАЗВИТИЮ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
И КОММУНИКАЦИЙ РЕСПУБЛИКИ УЗБЕКИСТАН

Об утверждении временной методики расчета стоимости разработки

и приобретения программного обеспечения


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

1.Утвердить Временную методику расчета стоимости разработки и приобретения программного обеспечения (далее – Временная методика) согласно приложению.

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

3.Настоящее постановление вступает в силу со дня его официального опубликования.

Министр по развитию

информационных технологий

и коммуникаций

Республики Узбекистан

Х. Мирзахидов

г. Ташкент

«___» __________ 2015 года

№ _______

Временная методика расчета стоимости разработки (приобретения) программного обеспечения в рамках проектов по созданию государственных информационных систем

I.Общие положения

1.Настоящая Временная методика расчета стоимости разработки (приобретения) программного обеспечения в рамках проектов по созданию государственных информационных систем (далее – Методика) в соответствии с решением Республиканской комиссии по координации реализации Комплексной программы развития Национальной информационно-коммуникационной системы Республики Узбекистан на 2013-2020 годы от _________ № __, определяет методы и порядок оценки стоимости разработки (приобретения) программного обеспечения.

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

3. Настоящая Методика разработана в соответствии с международным стандартом ISO/IEC 20926:2009 «Разработка программного обеспечения и систем. Измерения в программном обеспечении. Метод измерения функционального размера IFPUG 2009» и основывается на определении функционального размера программного обеспечения методом анализа функциональных точек.

I.Термины и определения

1.В целях настоящей Методики применяются следующие основные понятия и сокращения:

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

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

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

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

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

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

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

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

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

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

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

внешняя выходная транзакция (EO) – элементарная операция по извлечению данных или управляющей информации из ILF или EIF, предусматривающая создание производных данных путем математических и иных вычислений;

внешний запрос (EQ) – элементарная операция по извлечению данных или управляющей информации из ILF или EIF, не предусматривающая создание производных данных путем математических и иных вычислений;

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

элемент типа «запись» (RET) – выделяемая пользователем логическая подгруппа элементов данных внутри ILF или EIF, по количеству которых определяется функциональная сложность данных оцениваемого приложения;

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

III.Область применения

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

6. В настоящей Методике под разработкой программного обеспечения понимается совокупность работ по анализу требований, проектированию, программированию, сборке, тестированию, интеграции, вводу в действие и приемке программного продукта

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

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

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

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

IV.Расчет стоимости разработки программного обеспечения

10.Расчет стоимости программного обеспечения предусматривает выполнение следующей последовательности шагов:

1.Определение типа оценки.

2.Определение области и границ оцениваемого приложения.

3.Определение нескорректированного размера приложения. Данный шаг включает:

3.1.Подсчет функциональных точек, связанных с данными;

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

4.Определение скорректированного размера приложения. Данный шаг включает:

4.1.Определение значения корректирующего фактора;

4.2.Применение корректирующего фактора к нескорректированному размеру приложения.

5.Определение стоимости разработки приложения.

V.Определение типа и области оценки

11.Метод функциональных точек предусматривает три типа оценки функционального размера приложения (Таблица 1):

Таблица 1. Типы оценки размера приложения методом функциональных точек

Тип оценки

Описание

1

Проект разработки

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

2

Проект развития

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

3

Существующее приложение

Оценивается объем уже существующего и установленного приложения.

12.В зависимости от типа, область оценки может включать:

•Все разрабатываемые функции (для проекта разработки);

•Все добавляемые, изменяемые и удаляемые функции (для проекта развития);

•Только функции, реально используемые, или все функции (при оценке одного или нескольких приложений).

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

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

14.В настоящей Методике приводятся три метода определения нескорректированного размера приложения, которые отличаются объемом входной информации для проведения расчета:

а)Стандартный метод;

б)Ориентировочный метод;

в)Индикативный метод.

15.Наиболее подробные сведения об объекте оценки требуются для применения стандартного метода, далее по убыванию объема требуемой информации следуют ориентировочный и индикативный методы.

VIII.Стандартный метод оценки нескорректированного размера приложения

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

17. Метод функциональных точек выделяет пять типов функций, используемых в приложении (Таблица 2).

Таблица 2. Типы функций в рамках метода функциональных точек

Группа функций

Типы функций

Функции, связанные с данными

1.Внутренние логические файлы (ILF)

2.Внешние интерфейсные файлы (EIF)

Функции, связанные с транзакциями

3.Внешние входные транзакции (EI)

4.Внешние выходные транзакции (EO)

5.Внешние запросы (EQ)

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

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

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

21. Группа данных (блок управляющей информации) может быть отнесена к ILF при соблюдении следующих условий:

а)Данные логически связаны и идентифицируемы пользователем. Так, не все таблицы в базе данных могут быть отнесены к отдельным ILF. Например, хотя данные о заказах физически могут храниться в двух таблицах БД – заказы (Orders) и детали заказов (OrderDetails), с точки зрения пользователя это одна логическая сущность, и поэтому должны рассматриваться как один ILF с двумя RET.

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

21. Группа данных (блок управляющей информации) может быть отнесена к ILF при соблюдении следующих условий:

а)Данные логически связаны и идентифицируемы пользователем. Так, не все таблицы в базе данных могут быть отнесены к отдельным ILF. Например, хотя данные о заказах физически могут храниться в двух таблицах БД – заказы (Orders) и детали заказов (OrderDetails), с точки зрения пользователя это одна логическая сущность, и поэтому должны рассматриваться как один ILF с двумя RET.

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

22. 1.Группа данных (блок управляющей информации) может быть отнесена к EIF при соблюдении следующих условий:

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

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

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

Данные являются внутренним логическим файлом (ILF) другого (внешнего) приложения

23. По каждому ILF и EIF определяется его функциональная сложность путем идентификации и подсчета элементов типа «запись» (RET) и элементов типа «данные» (DET).

24.Пример: ILF «Информация о клиенте» может содержать несколько адресов и номеров телефонов клиента, что означает наличие двух RET: адрес и номер телефона. Примерами DETдля ILF и EIFмогут служить поля в таблице базы данных.

25. При подсчете элементов RETсоблюдаются следующие правила:

а)Считать элементом RET каждую логическую подгруппу данных внутри ILF и EIF.

б)Считать одним элементом RET весь ILFили EIF при отсутствии в нем подгруппы данных.

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

26.При подсчете элементов DETв ILF и EIF соблюдаются следующие правила:

а)Считать элементом DET каждое уникальное, выделяемое пользователем, неповторяемое поле, поддерживаемое в и/или считываемое из ILF/EIF в рамках элементарных процессов.

б)Считать элементом DET каждое поле данных, требуемое для установления связи с другим ILF/EIF. Например, поля внешних ключей (foreign key) принимаются в расчет.

в)Не считать элементом DET генерируемые системой технические поля в таблицах базы данных (ID, timestamps и т.д.).

27. 1.Уровень функциональной сложности по каждому файлу ILF и EIF определяется на основании матрицы сложности, приведенной в Таблице 3.

Таблица 3. Матрица оценки сложности данных (ILF и EIF)

1-19 DET

20-50 DET

50+ DET

1 RET

Низкая

Низкая

Средняя

2-5 RET

Низкая

Средняя

Высокая

6+ RET

Средняя

Высокая

Высокая

28.По каждому идентифицированному объекту данных ILF и EIF определяется его вес, выраженный в количестве функциональных точек, в зависимости от уровня сложности и типа (Таблица 4).

Таблица 4. Вес одного объекта данных (ILF, EIF) в зависимости от сложности и типа

Сложность данных

Количество функциональных точек

ILF

EIF

Низкая

7

5

Средняя

10

7

Высокая

15

10

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

В оцениваемом приложении выявлен объект «Сведения о сотруднике», который включает в себя полное имя (ФИО – 3 DET), дату рождения (1 DET), адрес (индекс, страна, область, район, город, улица, дом, корпус, квартира – 9 DET) и паспортные данные сотрудника (номер, дата выдачи, кем выдан, срок действия – 4 DET).

Данный объект содержит 4 подгруппы данных (RET), которые в совокупности состоят из 17 неповторяемых уникальных полей данных (DET). Согласно матрице в таблице 3, его сложность – низкая. Если данный объект относится к внутренним логическим файлам, то согласно таблице 4, он оценивается в 7 функциональных точек. Если же объект является внешним интерфейсным файлом, его вес составит 5 функциональных точек.

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

В оцениваемом приложении выявлен объект «Сведения о сотруднике», который включает в себя полное имя (ФИО – 3 DET), дату рождения (1 DET), адрес (индекс, страна, область, район, город, улица, дом, корпус, квартира – 9 DET) и паспортные данные сотрудника (номер, дата выдачи, кем выдан, срок действия – 4 DET).

Данный объект содержит 4 подгруппы данных (RET), которые в совокупности состоят из 17 неповторяемых уникальных полей данных (DET). Согласно матрице в таблице 3, его сложность – низкая. Если данный объект относится к внутренним логическим файлам, то согласно таблице 4, он оценивается в 7 функциональных точек. Если же объект является внешним интерфейсным файлом, его вес составит 5 функциональных точек.

30.По результатам анализа определяются элементарные операции, представляющие значение для пользователя и переводящие приложение из одного состояния в другое, которые группируются на внешние входные транзакции (EI), внешние выходные транзакции (EO) и внешние запросы (EQ).

31.Примерами EIявляются функции ввода данных пользователем, считывания данных из файлов внешних приложений. Примерами EO служат формируемые приложением отчеты, содержащие производные данные. Примерами EQ служат SQL-запросы по извлечению данных из таблиц БД, находящихся как внутри приложения, так и за его пределами

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

Таблица 5. Основные отличия между типами транзакций

Назначение

Тип транзакции

EI

EO

EQ

Изменяет поведение системы

Основное

Дополнительное

Не применима

Поддержка одного или более ILF

Основное

Дополнительное

Не применима

Представление информации пользователю

Дополнительное

Основное

Основное

33.Основным назначением EIявляется изменение поведения приложения и поддержка внутренних логических файлов (например, посредством создания, редактирования и удаления записей в таблице БД), тогда как отображение информации является вспомогательной функцией (например, путем отображения текущих значений полей формы в операции редактирования объекта данных).

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

35.Основным назначением EQ является представление информации пользователю посредством простого извлечения данных из ILFи EIF. Логика обработки не предусматривает вычислений и генерирование производных данных. Также EQне изменяют данные и поведение системы.

36.По каждой идентифицированной транзакции EI, EO и EQ определяется ее функциональная сложность путем подсчета количества ссылок на файлы (FTR) и элементов типа «данные» (DET).

37.Примерами DET для EI, EO и EQмогут служить элементы управления графического интерфейса пользователя.

38.При подсчете ссылок на файлы (FTR) в транзакциях EIсоблюдаются следующие правила:

а)Считать ссылкой FTR каждый модифицируемый в транзакции ILF.

б)Считать ссылкой FTR каждый считываемый в транзакции ILF или EIF.

в)Считать только одной ссылкой FTR каждый ILF, который и модифицируется и считывается в рамках одной транзакции.

39.При подсчете элементов DETв транзакциях EIсоблюдаются следующие правила:

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

б)Не считать элементом DET поле, извлекаемое или производимое системой и сохраняемое в ILFв результате транзакции, если данные не пересекли границы приложения. Например, при добавлении клиентом нового заказа, цена за единицу продукции автоматически извлекается из таблицы цен и включается в накладную. Цена за единицу продукции не является элементом DETдля входной транзакции, поскольку она не пересекает границы приложения в момент, когда пользователь создает новый заказ.

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

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

д)Не считать элементом DET элемент управления графического интерфейса (кнопка, ссылка, переключатель и т.д.), который не изменяет данные и состояние системы. Например, кнопки «Отмена», «Выйти», «Далее» (если промежуточные значения формы не сохраняются), «Настройки по умолчанию» (если настройки не считываются из отдельного файла) на экранной форме не являются элементами DET.

40. При подсчете ссылок на файлы (FTR) в транзакциях EO и EQсоблюдается следующее правило – считать ссылкой FTR каждый считываемый в транзакции ILF или EIF.

41.При подсчете ссылок на файлы (FTR) в транзакциях EOсоблюдаются также следующие правила:

а)Считать ссылкой FTR каждый модифицируемый в транзакции ILF.

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

42.При подсчете элементов DET в транзакциях EOи EQсоблюдаются следующие правила:

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

б)Считать элементом DET каждое выделяемое пользователем, неповторяемое поле, которое выводится приложением. Например, главное окно приложения отображает список отделов организации в виде таблицы с тремя столбцами (код, название, начальник). Это пример транзакции EQcтремя элементами DET. Другой пример – приложение выводит отчет о кадрах организации в виде таблицы с тремя столбцами (код отдела, название отдела, количество сотрудников) и строкой итога (всего сотрудников). Это пример транзакции EOс четырьмя элементами DET.

в)Считать одним элементом DET, поле данных, которое пересекает границы приложения в обоих направлениях (вход и выход).

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

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

е)В транзакциях EO – не считать элементом DET поле, извлекаемое или производимое системой и сохраняемое в ILF в результате транзакции, если данные не пересекли границы приложения. Например, при распечатке доверенности, ее статус во внутреннем реестре приложения устанавливается как «Распечатана». Поскольку данные о статусе не пересекли границ приложения, это поле не учитывается как DET.

ж)Не считать элементами DET литералы и генерируемые системой штампы. Примерами литералов выступают названия отчетов, экранов и панелей, заголовки столбцов и названия полей. Примеры системных переменных и штампов – нумерация страниц, позиционная информация (например, «выбраны строки с 3 по 10 из 50»), навигационные команды (назад, вперед, в начало, в конец), дата и время (в колонтитулах, заголовках отчетов и т.д.).

43. Уровень функциональной сложности различных типов транзакций определяется на основании соответствующих матриц сложности (Таблицы 6 и 7).

Таблица 6. Матрица оценки сложности внешних входных транзакций (EI)

1-4 DET

5-15 DET

16+ DET

0-1 FTR

Низкая

Низкая

Средняя

2 FTR

Низкая

Средняя

Высокая

3+ FTR

Средняя

Высокая

Высокая

Таблица 7. Матрица оценки сложности внешних выходных транзакций (EO) и запросов (EQ)

1-5 DET

6-19 DET

20+ DET

0-1 FTR

Низкая

Низкая

Средняя

2-3 FTR

Низкая

Средняя

Высокая

4+ FTR

Средняя

Высокая

Высокая

44.По каждой идентифицированной транзакции определяется ее вес, выраженный в количестве функциональных точек, в зависимости от уровня сложности и типа (Таблица 8).

Таблица 8. Вес одной транзакции (EI, EO, EQ) в зависимости от сложности и типа

Сложность транзакций

Количество функциональных точек

EI

EO

EQ

Низкая

3

4

3

Средняя

4

5

4

Высокая

6

7

6

45.Общий размер оцениваемого приложения в нескорректированных функциональных точках (UFP) определяется путем суммирования функциональных точек по всем информационным объектам (ILF, EIF) и элементарным операциям (транзакциям EI, EO, EQ) по формуле:

UFP = ILF + EIF + EI + EO + EQ

VIII.Ориентировочный метод оценки нескорректированного размера приложения

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

а)Идентификацию и подсчет всех функций, связанных с данными и транзакциями (ILF, EIF, EI, EO, EQ);

б)Оценку сложности каждой функции, связанной с данными (ILF, EIF), как «Низкая»;

в)Оценку сложности каждой функции, связанной с транзакциями (EI, EO, EQ), как «Средняя»;

г)Расчет количества нескорректированных функциональных точек (UFP) по формуле:

UFP = ILF × 7 + EIF × 5 + EI × 4 + EO × 5 + EQ × 4

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

IX.Индикативный метод оценки нескорректированного размера приложения

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

а)Идентификацию и подсчет всех внутренних логических файлов (ILF) и внешних интерфейсных файлов (EIF) оцениваемого приложения;

б)Расчет количества нескорректированных функциональных точек (UFP) по формуле:

UFP = 35 × ILF + 15 × EIF

49. В индикативном методе в расчет принимаются только внутренние и внешние файлы, используемые приложением. В основе метода лежит предположение о том, что каждому внутреннему логическому файлу (ILF) будут соответствовать три внешние входные транзакции EI(добавить, изменить, удалить данные), две внешние выходные транзакции (EO) и один внешний запрос (EQ), а каждому внешнему интерфейсному файлу (EIF) – один EO и один EQ.

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

Согласно ТЗ, разрабатываемое приложение должно иметь следующие функциональные возможности:

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

2.Выводить список всех списаний со счета пластиковой карты;

3.Выводить сумму списаний за период времени (например, последний месяц).

Для выполнения этих операций, система поддерживает три ILF– «Карты», «Владельцы», «Банки» и ссылается на один EIF«Платежи» (дата, номер счета, сумма, детали), поддерживаемый внешней системой.

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

По итогам анализа, определяем – операция представляет собой внешнюю входную транзакцию (EI), которая ссылается на 3 файла FTR (карты, владельцы, банки) и использует 7 элементов DET (5 полей формы, кнопка действия ОК и сообщение об ошибке). Согласно таблицам 6 и 8, это транзакция с высоким уровнем сложности и весом в 6 функциональных точек. Аналогичный вес (6 ФТ) будет иметь операция по редактированию карты.

При удалении карты, система выводит диалоговое окно, в котором просит пользователя подтвердить действие по удалению определенной карты определенного владельца. При нажатии кнопки «Да», система удаляет карту, при нажатии кнопки «Нет» – состояние системы не меняется.

По итогам анализа, определяем – операция представляет собой внешнюю входную транзакцию (EI), которая ссылается на 2 файла FTR (карты, владельцы) и использует 4 элементов DET (2 поля данных – номер карты и имя владельца, кнопка действия «Да» и просьба подтвердить действие). Сложность транзакции оценивается как «Низкая» и ее вес составляет 3 функциональные точки.

Список карт отображается в виде таблицы из 5 столбцов – номер счета, тип карты, срок действия, название банка, имя владельца. Поскольку логика обработки заключается в простом извлечении данных из нескольких таблиц БД и не содержит вычислений или производных данных, эта транзакция является внешним запросом (EQ). В транзакции задействовано 3 FTR и 5 DET, следовательно ее сложность – низкая и вес составляет 3 ФТ.

Список списаний по карте отображается в виде отчета, содержащего номер счета, тип карты, имя владельца карты и таблицу списаний из 3 столбцов (дата, сумма, детали платежа). Данная операция является внешним запросом (EQ), в рамках которого происходит простое извлечение информации из внутренних и внешних файлов, без математических вычислений. В транзакции задействовано 3 FTR (карты, владельцы, платежи) и 6 DET, следовательно ее сложность – средняя, вес – 4 ФТ.

Сумма списаний по карте отображается в виде отчета, содержащего номер счета, тип карты, имя владельца карты, название банка, сумма списаний за последний месяц. Поскольку отчет содержит агрегированное поле (сумму платежей), данная операция представляет собой внешнюю выходную транзакцию (EO). Транзакция имеет 4 FTR (карты, владельцы, банки, платежи) и 5 DET, следовательно ее сложность – средняя, вес – 5 ФТ.

Транзакция

Тип

FTR

DET

Сложность

Вес

1

Создать карту

EI

3

7

Высокая

6

2

Редактировать карту

EI

3

7

Высокая

6

3

Удалить карту

EI

2

4

Низкая

3

4

Вывести список карт

EQ

3

5

Низкая

3

5

Вывести список списаний по карте

EQ

3

6

Средняя

4

6

Вывести сумму списаний по карте

EO

4

5

Средняя

5

Итого

27

В целом, реализация вышеуказанных функций системы оценивается в 27 функциональных точек.

X .Определение размера корректирующего фактора

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

Таблица 9. Параметры, определяющие системные характеристики приложения

Параметр

Значение

1

Распределенная обработка данных

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

1 – клиент-серверная архитектура, веб-приложение, онлайн обработка и передача данных.

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

2

Производительность

0 – пользовательские требования по производительности не установлены; обеспечивается базовый уровень производительности.

1 – время отклика или пропускная способность имеют важное значение в часы пик или на протяжении всего рабочего времени; установлено ограничение на время отклика на внешний запрос.

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

3

Отказоустойчивость

0 – пользовательские требования по отказоустойчивости не установлены; обеспечивается базовый уровень надежности.

1 – сбои могут быть легко устранены с небольшими потерями.

2 – восстановление системы после сбоя затруднительно и влечет за собой значительные финансовые потери или опасность здоровью.

4

Работа на различных платформах

0 – приложение предназначено для эксплуатации только в гомогенной аппаратно-программной среде.

1 – приложение предназначено для эксплуатации в схожих аппаратных и программных условиях.

2 – приложение предназначено для эксплуатации в гетерогенной аппаратно-программной среде.

51.Каждый из 4 системных параметров (DI) оценивается по шкале от 0 до 2. Расчет суммарного эффекта системных характеристик (TDI) осуществляется простым суммированием:

TDI = ∑ DI

52.Расчет значения корректирующего фактора производится по формуле:

VAF = TDI × 0,025 + 1

Например, если, каждый из четырех системных параметров получил оценку 1, то их суммарный эффект составит TDI = 1 + 1 + 1 + 1 = 4. В этом случае значение корректирующего фактора будет равняться VAF = 4 × 0,025 + 1 = 1,1.

XI.Определение скорректированного размера приложения

53.Оценка размера приложения в скорректированных функциональных точках (AFP) зависит от типа оценки. Базовый функциональный размер приложения определяется по формуле:

AFP = UFP × VAF

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

54.Проект разработки приложения оценивается в DFP по формуле:

DFP = (UFP + CFP) × VAF,

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

55.Проект доработки и совершенствования приложения оценивается в EFP по формуле:

EFP = (ADD + CHGA + CFP) × VAFA + (DEL × VAFB),

где:

ADD – функциональные точки для добавленной функциональности;

CHGA – функциональные точки для измененных функций, рассчитанные после модификации;

VAFA – величина корректирующего фактора, рассчитанного после завершения проекта;

DEL – объем удаленной функциональности;

VAFB – величина корректирующего фактора, рассчитанного до начала проекта.

56.Суммарное влияние процедуры корректирования лежит в пределах 100-120% к относительному объему, рассчитанному в UFP.

XII .Периодичность оценки функционального размера приложения

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

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

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

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

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

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

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

XIII.Определение стоимости разработки приложения

64.Себестоимость разработки приложения определяется путем умножения функционального размера приложения (AFP, DFP, EFP) на рекомендованную стоимость одной функциональной точки, устанавливаемую решением Республиканской комиссии по координации реализации Комплексной программы развития Национальной информационно-коммуникационной системы Республики Узбекистан на 2013-2020 годы.

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

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

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

Наименование мероприятияФорма реализацииСрок реализацииИсполнители
Внесение проекта нормативно-правового акта на экспертизу и регистрацию в Министерство юстиции Республики УзбекистанРегистрация в Министерстве юстиции15.08.2015Регистрация в Министерстве юстиции
Согласование проекта нормативно-правового акта с заинтересованными министерствами и ведомствамиНаправление проекта Постановления Министерства в соответствующие министерства и ведомства для согласования11.08.2015Направление проекта Постановления Министерства в соответствующие министерства и ведомства для согласования
Доработка нормативно-правового акта согласно предложениямОбобщение предложений участников обсуждения, доработка проекта и размещение окончательной редакции на Едином портале27.07.2015Обобщение предложений участников обсуждения, доработка проекта и размещение окончательной редакции на Едином портале
Проведение обсуждения нормативно-правового актаОбсуждение нормативно-правового акта на Едином портале27.06.2015Обсуждение нормативно-правового акта на Едином портале
Размещение нормативно-правового акта для обсуждения на Едином порталеРазмещение на Едином портале уведомления о проведении обсуждения, графика, проекта Постановления Министерства, опросного листа участников обсуждения12.06.2015Размещение на Едином портале уведомления о проведении обсуждения, графика, проекта Постановления Министерства, опросного листа участников обсуждения
Разработка проекта нормативно-правового актаПостановление Министерства по развитию информационных технологий и коммуникаций Республики Узбекистандо 12.06.2015Постановление Министерства по развитию информационных технологий и коммуникаций Республики Узбекистан