ВУЗ: Алтайский Государственный Университет
Категория: Учебное пособие
Дисциплина: Управление проектами
Добавлен: 23.10.2018
Просмотров: 3302
Скачиваний: 12
Оглавление
1.
ОБЩИЕ ПОЛОЖЕНИЯ
2
1.1. Содержание экономического раздела проекта
2
1.2. Описание программного продукта
2
1.3. Резюме
3
2.
ТЕХНИКО-ЭКОНОМИЧЕСКОЕ
ОБОСНОВАНИЕ
ДОГОВОРНОЙ ЦЕНЫ
4
2.1. Общие положения
4
2.2. Типы и основные требования к программным системам
5
2.3. Методы определения размеров программной системы
5
2.3.1. Прямой метод определения технико-экономических показателей
проекта
5
2.3.2. Определение технико-экономических показателей программной
системы с использованием метода функциональных точек
8
2.3.3. Определение технико-экономических показателей проекта на ос-
нове размерности базы данных программной системы
17
2.4. Определение стоимости программной системы
18
2.4.1. Определение фонда оплаты труда на разработку и комплексные
испытания программной системы
18
2.4.2. Определение фонда оплаты труда на проведение опытной эксплуа-
тации программной системы
19
2.4.3. Структура договорной цены на программное обеспечение
20
2.4.4. Краткие рекомендации по подготовке раздела «Технико-
экономическое обоснование договорной цены
22
3.
ОПРЕДЕЛЕНИЕ И АНАЛИЗ РЫНОЧНОЙ СТОИМОСТИ
ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
24
3.1. Концепция безубыточности
24
3.2. Виды и составляющие издержек
24
3.3. Определение точки безубыточности
25
Литература
28
Приложение 1. Пример расчета договорной цены на разработку автома-
тизированной информационной системы
29
Приложение
2.
Пример
анализа
рыночной
стоимости
программного продукта
53
2
1.
ОБЩИЕ ПОЛОЖЕНИЯ
1.1.
Содержание экономического раздела проекта
Структура экономической части должна состоять из следующих разделов:
−
описание программного продукта;
−
технико-экономическое обоснование договорной цены;
−
определение и анализ рыночной стоимости прикладного программного обеспечения;
−
резюме.
1.2.
Описание программного продукта
Первым разделом экономической части ДП является описание программного продукта.
Программное обеспечение должно быть представлено как объект продажи и поставки и ори-
ентировано на конкретного покупателя. При этом потенциальные покупатели могут сравнивать
свои требования к программному продукту с возможностями, описанными в документе, проводить
анализ конкурентных преимуществ с другими (аналогичными) программными системами.
Описание программного продукта должно соответствовать базовому Российскому стандарту в
области информационных технологий ГОСТ Р ИСО/МЭК 12119-2000 «Информационная техноло-
гия. Пакеты программ. Требование к качеству и тестирование», в котором даны соответствующие
рекомендации по структуре документа «Описание программного продукта» [1].
Вышеуказанный документ должен содержать следующие основные разделы.
Обозначения и указания:
− обозначение описания продукта (описанию продукта присваивается индивидуальное обозна-
чение - как документу, оно может иметь наименование, отличное от «описания продукта», например
«Описание функциональных возможностей», «Информация о продукте», «Формуляр продукта»,
«Карта описания продукта»).
− обозначение продукта - по крайней мере должно включать наименование продукта и обозна-
чение его версии или даты выпуска;
− поставщик (наименование и адрес по крайней мере одного поставщика);
− рабочая задача (возможности программного продукта, доступные конечному пользователю, а
также предусмотренный результат функционирования рабочей системы.);
− соответствие нормативным документам;
− необходимая программно-аппаратная платформа;
− интерфейсы с другими продуктами;
− объекты поставки (определяется каждый физический компонент поставляемого продукта, в
частности техническая документация и все носители данных, в обязательном порядке необходимо
установить вид поставляемых программ, например исходные программы, объектные (рабочие) моду-
ли или загрузочные модули);
− ввод в действие (инсталляция) – указывается, будет ли инсталляция продукта проводиться
пользователем, или нет;
− поддержка (предлагается ли поддержка при эксплуатации продукта);
− сопровождение (предлагается ли сопровождение продукта).
Функциональные возможности:
− пригодность и согласованность (приводится набор функций, реализуемых в данной версии,
при этом необходимо указать соответствие этих функций стандартам, соглашениям, положениям за-
конов, методическим рекомендациям);
− граничные значения (если использование продукта ограничено конкретными граничными
значениями: минимальные или максимальные значения; длины ключей; максимальное число записей
в файле; максимальное число критериев поиска; минимальный объем выборки и т.д.);
− защита (информация по средствам предотвращения случайного или преднамеренного несанк-
ционированного доступа к программам и данным).
Надежность -
набор атрибутов, относящихся к способности программного средства сохранять
свой уровень качества функционирования при установленных условиях за установленный период
времени.
В описание продукта должна быть включена информация по процедурам сохранения данных.
Данную информацию можно привести, указав, например, возможности резервирования данных с по-
мощью функций операционной системы. Могут быть описаны дополнительные характеристики про-
дукта, которые обеспечивают его функциональные возможности (проверки достоверности исходных
3
данных; зашита против серьезных последствий ошибки пользователя; восстановление работоспособ-
ности программной системы при ошибках).
Практичность - набор
атрибутов, относящихся к объему работ, требуемых для использования и
индивидуальной оценки такого использования определенным или предполагаемым кругом пользова-
телей, в том числе:
− интерфейс пользователя (тип интерфейса, например, строка команд, меню, окна, функцио-
нальная клавиша, функция подсказки);
− требуемая квалификация пользователя (конкретные знания, которые необходимо усвоить
пользователю для применения соответствующего продукта: знание соответствующей технической
области; знание операционной системы; знания, получаемые в результате специального обучения и
т.д.);
− адаптация к требованиям пользователя (если продукт может настраиваться пользователем, то
должны быть указаны инструментальные средства для проведения такой настройки и условия их
применения: изменение параметров, алгоритмов вычислений; назначение функциональных клавиш и
т.д.);
− защита от нарушения авторских прав (техническая защита от копирования; запрограммиро-
ванные даты окончания использования продукта; интерактивные напоминания об оплате за копии и
пр.).
Эффективность -
набор атрибутов, относящихся к соотношению между уровнем качества
функционирования программного средства и объемом используемых ресурсов при установленных
условиях (информация о характере поведения продукта, например времена ответа и оценки произво-
дительности при реализации заданных функций при установленных условиях - для заданных конфи-
гураций системы и профилей загрузки; информация по эффективности применения продукта и удов-
летворению им потребностей пользователя).
Сопровождаемость подразумевает
: возможность диагностики в случае отказов; определение
условий для модификации, либо изменения режимов эксплуатации; возможность тестирования мо-
дифицированных частей программного продукта.
Мобильность (переносимость) - возможность
адаптации продукта к различным условиям экс-
плуатации без применения дополнительных сервисов, простота внедрения в новых условиях; взаимо-
заменяемость с другим (аналогичным) программным продуктом.
Примечание: разделы надежность, практичность, эффективность, сопровождаемость,
мобильность
должны соответствовать ГОСТ 28195-89 Оценка качества программных средств. Об-
щие положения.
Пример описания программного продукта приведен в Приложении 1.
1.3.
Резюме
Резюме – завершающий раздел экономической части ДП, который является своеобразной ви-
зитной карточкой всего проекта.
Цель этого раздела: кратко изложить содержание проекта для обоснования его возможности,
целесообразности и основных преимуществ. Подготовка краткого содержания особенно сложна.
Квалифицированно это можно сделать только тогда, когда программный продукт уже разработан и
уже очевидны основные мероприятия, которые необходимо выполнить по его внедрению (тиражи-
рованию) и проведены основные финансово-экономические расчеты. Поэтому разрабатывать его
следует после завершения всей работы.
В резюме в предельно краткой форме излагаются следующие моменты (положения):
−
суть проекта;
−
возможности реализации проекта в конкретных рыночных условиях;
−
назначение программного продукта, его функциональные особенности;
−
основные технико-эксплуатационные параметры;
−
сроки выполнения проекта;
−
необходимый объем финансирования;
−
срок окупаемости проекта;
−
потенциальные выгоды от инвестирования в проект.
Излагать резюме следует в предельно короткой, но вместе с тем не лишенной эмоционально-
сти форме, исключая сложную техническую терминологию, упрощенные бытовые термины, эко-
номические и другие штампы.
4
Следует подчеркнуть инвестиционную привлекательность, актуальность, социальную значи-
мость предлагаемого проекта. Именно этот раздел должен вызвать интерес у потенциальных парт-
неров и инвесторов, убедить их в высоком уровне компетентности и профессионализме автора
проекта.
Резюме должно быть кратким – не более одной страницы и должно трактоваться как само-
стоятельный документ, т.к. в нем содержатся все основные ключевые положения, характеризую-
щие представленный программный продукт.
2.
ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ДОГОВОРНОЙ ЦЕНЫ
2.1.
Общие положения
Под технико-экономическим обоснованием стоимости (договорной цены) программной сис-
темы будем понимать методику оценивания трудовых, временных и финансовых ресурсов по созда-
нию программной системы, соответствующей требованиям заказчика.
В основу определения требуемых объемов ресурсов должны быть положены:
−
совокупность бизнес-процессов, реализуемых в будущей программной системе и их относи-
тельная важность (приоритет) для заказчика;
−
требования к функциональной полноте и качеству реализации каждого бизнес-процесса.
В качестве основных показателей оценки стоимости программной системы используются:
−
сложность (размеры) программной системы;
−
трудозатраты на разработку;
−
длительность разработки программной системы в целом и ее отдельных этапов;
−
численность и квалификация специалистов, привлекаемых к созданию программной систе-
мы;
−
фонд оплаты труда специалистов на создание программной системы в целом и по конкрет-
ному этапу жизненного цикла;
−
прочие прямые затраты и накладные расходы, связанные с созданием программной систе-
мы.
В основу определения размеров программной системы положено понятие «сложности», под ко-
торой понимается количество элементов программной системы (программных компонент, файлов,
входных и выходных документов) и взаимосвязей между ними.
Под термином трудозатраты будем понимать суммарный объем труда специалистов для соз-
дания программного продукта.
В качестве универсального измерителя трудозатрат используется показатель – человеко-месяц.
Каждый человеко-месяц содержит 160 человеко-часов (четыре недели, пять рабочих дней, восьмича-
совой рабочий день).
Длительность разработки и численность специалистов определяются на основе трудозатрат и
нормативной производительности труда программиста, выражаемой в количестве строк кода, созда-
ваемых программистом в единицу времени. При этом выделяются следующие этапы жизненного
цикла программной системы:
−
анализ предметной области и разработка требований к программной системе;
−
проектирование;
−
программирование;
−
тестирование и комплексные испытания;
−
опытная эксплуатация.
В реализации проекта на каждом этапе принимает участие три группы специалистов:
−
руководитель проекта, системные аналитики;
−
непосредственные разработчики программных систем и специалисты по комплексирова-
нию;
−
технический персонал, обеспечивающий тестирование, документирование и опытную экс-
плуатацию программного обеспечения.
Фонд оплаты труда на реализацию проекта определяется исходя из производительности труда
специалиста и согласованной базовой месячной заработной платы.
Все нормативы и другие статистические данные, используемые в методиках технико-
экономического обоснования стоимости основываются на статистических данных, обобщающих за-
рубежный и российский опыт разработки программных систем [2].
5
2.2.
Типы и основные требования к программным системам
По уровню сложности все множество программных систем (ПС) следует разбить на три типа.
К первому типу относятся:
−
комплексные программные системы (КПС) и технологии, отдельные части которых реали-
зованы на различных платформах;
−
территориально-распределенные программные системы и технологии;
−
системы автоматизированного либо автоматического управления, функционирующие в ре-
жиме реального времени.
Второй тип
составляют программные информационно-справочные системы (ИCС), обеспечи-
вающие информационную поддержку основных бизнес-процессов организации с большим количест-
вом типов исходной информации.
К третьему типу относятся инженерные и научно-технические пакеты программ (ППП) и тех-
нологий, характеризующихся четко заданным алгоритмом обработки и малыми объемами исходных
данных.
При формировании требований к программной системе необходимо использование стандарта
ISO/IEC 9126-1:2001 [3].
С учетом этого, системы первого и второго типа должны удовлетворять следующим требовани-
ям:
−
архитектура системы должна соответствовать текущим и перспективным целям и стратеги-
ческим, функциональным задачам создаваемой системы;
−
в структуре и компонентах следует предусматривать обеспечение максимально возможной
сохранности капитальных вложений заказчика в аппаратные и программные средства, а также в
базы данных при длительном развитии, сопровождении и модернизации системы;
−
для обеспечения перспективы развития системы должны быть предусмотрены возможность
интеграции компонентов и мобильность ПС на различные аппаратные и операционные платформы
на основе концепции и стандартов Открытых систем;
−
архитектура информационной системы должна быть достаточно гибкой и допускать про-
стое, без коренных структурных изменений, развитие и наращивание функций и ресурсов системы
в соответствии с расширением сфер и задач ее применения;
−
необходимо обеспечить эффективное использование ресурсов системы и минимизировать
интегральные затраты на обработку данных в типовых режимах ее функционирования с учетом те-
кущих эксплуатационных затрат и капитальных вложений в создание ПС;
−
следует обеспечить комфортный, максимально упрощенный доступ конечных пользовате-
лей к управлению и результатам функционирования системы на основе современных графических
средств и наглядных пользовательских интерфейсов.
2.3.
Методы определения размеров программной системы
2.3.1.
Прямой метод определения технико-экономических показателей проекта
Прямой метод определения технико-экономических параметров программной системы основан
на использовании метода экспертных оценок.
Будущую программную систему следует декомпозировать до уровня элементарных компонент, а
для оценки размеров каждого из компонент использовать либо внешних экспертов, имеющих опыт
разработки подобных систем и готовые прототипы, либо, в качестве экспертов могут выступать спе-
циалисты разработчика и заказчика [4].
При декомпозиции целесообразно использовать следующие термины и определения, изложен-
ные в [5] (рис. 2.1):
− интегрированная программная система – совокупность двух и более программных систем,
в которых функционирование одной из них зависит от результатов функционирования другой;
− программная система – совокупность программных комплексов, реализующих множество
бизнес-процессов организации;
− программный комплекс – совокупность программных компонент, реализующих конкретный
бизнес-процесс;
− сложная программная компонента – совокупность программных кодов, реализующих
сложную функцию бизнес-процесса;