Файл: Инфрам.pdf

337 готов создать ПС, удовлетворяющую требованиям заказчика. Достиже- ние компромисса осложняется тем, что обе стоимости – и заказчика и исполнителя – зависят как факторов, поддающиеся прямой оценке, так и от плохо определенных факторов, опосредованно влияющих на стои- мость разработки и на выгоды от владения ПС.
Приобретение ПС – инвестиционный проект, успешный для заказ- чика, если совокупность материальных и нематериальных выгод от вне- дрения ПС превысит расходы на его внедрение и эксплуатацию. Удов- летворительное значение потребительской стоимости ПС определяется заказчиком сравнением затрат на владение ПС с величиной совокупных выгод от владения ПС: материальных, связанных с увеличением объемов производства продукции (работ, услуг) или сокращением расходов; нематериальных, определяющихся набором косвенных характери- стик, влияющих на оценку стоимости компании, например рост опе- ративности принятия решений, увеличение доли охватываемого рынка, изменение позиционирования предприятия на рынке, сово- купные характеристики качества производства, подготовка трудово- го коллектива, общий образ компании и т. д.
Для сравнительной оценки материальных выгод применимы методы инвестиционного анализа, рассмотренные, например, в [7, 13]:
NPV – метод чистой приведенной стоимости;
IRR – метод внутренней нормы рентабельности;
Pay-back Period – метод приведенного срока окупаемости;
ROI – метод рентабельности инвестиций.
Расчет прибыльных составляющих, связанных с работой ПС, – неод- нозначная задача, часто источники прибыли не формализованы, а влия- ние работы программной системы на прибыль опосредовано. В процес- се предварительного проектирования исполнитель вынужден устанав- ливать потенциальные выгоды и указывать ожидаемые средние значе- ния прибылей, связанных с функционированием ПС, обосновывая, со своей стороны, приемлемую для заказчика стоимость.
Наиболее значимым источником выгоды является уменьшение из- держек на проведение бизнес-процессов, обеспечиваемое ПС. С учетом установленных законодательством налогов и иных обязательных отчис- лений, уменьшение издержек на 10% эквивалентно, по очищенной при- были, росту доходов на 18–20 % [10]. При оценке выгод от владения
ПС, следует учитывать возможность функционирования на ее платфор- ме различных специализированных приложений, использование кото- рых не предусмотрено при проектировании (потенциально доступные области автоматизации с внедрением ПС явно расширяются). При улучшении рыночной конъюнктуры, дополнительные приложения раз- рабатываются без значительных финансовых вложений, принося ком- пании дополнительную прибыль. При ухудшения конъюнктуры потери проекта ограничиваются ранее сделанными инвестициями в программ- ную платформу. Описанный механизм аналогичен опциону, тогда часть стоимости ПС следует считать затратами на хеджирование рисков не

338 получения прибыли при благоприятной конъюнктуре – такого рода оценки целесообразно брать из документов, подготовленных исполни- телем для акционеров, где расписывается сценарий развития предпри- ятия.
Вторым значимым источником материальных выгод является уве- личения доходности всех бизнес-процессов заказчика ПС за счет их расширения без привлечения дополнительных ресурсов.
Для оценки нематериальных выгод, необоснованно редко применяе- мой в отечественной практике, разработана методика Balanced Score
Card (BSC) [16, 18] – сбалансированной системы показателей, например, в версии PriceWaterhouseCooper для оценки стоимости компании. На основании методики BSC можно разработать и иной набор связных сба- лансированных показателей, однако, разработка системы сбалансиро- ванных показателей – трудоемкий процесс, требующий специальных знаний и навыков, зачастую отсутствующих у представителей планово- финансовых служб заказчика. Целесообразно, при разработке проектов
ПС, привлекать к работе независимых специалистов – оценщиков, под- тверждающих своим профессиональным авторитетом оценку выгод приобретения ИТКСС, увеличение стоимости компании, увеличение амортизационных отчислений и т. д.
С бухгалтерской точки зрения BSC-оценка показывает возрастание стоимости нематериальных активов компании, внедряющей ИТКСС, и, подкрепленная заключением независимой компании – оценщика,
BSC-оценка позволяет увеличить стоимость компании, а также амортизационные отчисления, косвенно увеличивая прибыль. Явная часть затрат на владение ПС (ТСО) определяется расходами на его при- обретение, внедрение, сопровождение, обучение персонала, админист- рирование и другие затраты. К неявной части затрат на внедрение отно- сят затраты на модификацию технологии работы предприятия, заработ- ную плату штатных работников IT-подразделения на всех этапах жиз- ненного цикла продукта на предприятии, финансовые потери из-за вре- менного снижения качества обслуживания клиентов и т. п. Размер неяв- ной части затрат может быть определен только косвенно, в рамках не- которой системы предположений. Заказчик, сравнивая сумму явной и неявной части прибыли со стоимостью владения ПС, определяет прием- лемую для себя стоимость ПС – стоимость заказчика.
7.5.2. Принципы определения стоимости исполнителем
Базовой характеристикой, величиной которой определяется большая часть составляющих затрат на создание и внедрение ПС, целесообразно избрать стоимость создания программных компонентов C
ПС
. Остальные величины выражаются либо в долях C
ПС
, либо в долях стоимости сто- ронней продукции, приобретаемой при формировании ПС.
Величина C
ПС
определяется стоимостью инструментальных средств, компьютерной и другой техники, материалов и комплектующих, зара- ботной платой, обязательными отчислениями, прочими прямыми рас-

339 ходами, накладными расходами организации, оплатой работ сторонних организаций, а также приемлемой величиной прибыли, зависящей от общей рыночной ситуации и маркетинговых устремлений исполнителя.
В расчет стоимости программного продукта, согласно [13], включаются работы, которые перечислены ниже:
1. Организационные мероприятия проекта;
2. Изучение осуществимости проекта;
3. Предварительная разработка требований к проекту, согласование концепции;
4. Детальная разработка требований к проекту;
5. Кодирование программных компонентов проекта;
6. Рецензирование контрольных точек проекта и уточнение трудоза- трат и стоимости проекта, утверждение бюджета и сроков исполне- ния проекта;
7. Разработка архитектуры программной системы;
8. Разработка первого этапа проекта;
9. Выпуск первого этапа проекта;
10. _ _ _ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11. Выпуск последнего этапа проекта;
12. Подготовка информационного наполнения проекта;
13. Подготовка к выпуску программной системы;
14. Обучение пользователей работе с комплексом в целом;
15. Участие в опытно-промышленной эксплуатации системы;
16. Выпуск программного комплекса, включая полную версию про- граммной документации;
17. Техническая поддержка функционирования системы;
18. Авторский надзор за функционированием программной системы.
Согласно оценкам, приведенным в [13], а также в ряде других пуб- ликаций [8, 12. 19], трудозатраты на разработку программной системы, распадаются на четыре составляющих: работы подготовительного этапа составляют 10–20% трудозатрат; собственно изготовление программного продукта (кодирование) со- ставляют 35–55% трудозатрат; работы по проектированию системы, поддержанию проекта, тести- рованию и обеспечению качества составляют 35–40% трудозатрат; выпуск продукции и разработка документации составляет 5–7 % трудозатрат.
7.5.3. Положения компромиссного подхода
Учитывая, что разработка информационных систем – уникальная за- дача, сложно определить трудоемкость разработки как методом анало- гии, так и методом экспертной оценки. Определение стоимости про- граммной части сложного информационного комплекса суммой стоимо- стей его частей методически неверно из-за эффекта размерности, отме-

340 чаемого всеми авторами публикаций по данной теме [8, 12]. Суть эф- фекта – квадратичное возрастание количества связей между различны- ми модулями информационной системы с ростом числа модулей и, со- ответственно, почти квадратичное возрастание трудоемкости проекти- рования и разработки. Еще более сильно от масштаба проекта зависят затраты на организацию работ, трудоемкость мероприятий по контролю качества, других работ, сопровождающих проект.
Стоимость информационной системы определяется как разумный ценовой компромисс, приемлемый как для заказчика, так и для испол- нителя. Сложность достижения компромисса заключается в том, что обе стороны оперируют разными компонентами понятия стоимость, кото- рые зачастую лишь опосредованно влияющими как на стоимость заказ- чика, так и на стоимость исполнителя. При компромиссном подходе стоимость исполнителя приемлема для заказчика, если обоснована зави- симость потребительских качеств ПС от затрат исполнителя.
Для определения такого компромиссного значения трудозатрат можно использовать рассчитываемую методом функциональных баллов оценку функционально оправданной длины кода предложенную еще в
70-х годах прошлого века [2], рассмотренную в разделе 7.3.2. В рамках метода функциональных баллов (например, в версии EFP IFPUG FPA), функционально оправданная длина программного кода определяется на основании эмпирических таблиц и перечня функциональных сервисов, предоставляемых программным обеспечением. Методика функциональ- ных баллов отличается от иных методик – COCOMO, КОМОСТ,
ПЛАПС, методики Госкомтруда тем, что применима на ранних стадиях проектирования, когда большая часть детальных требований к ПО еще не сформулирована.
Объем программного кода, в совокупности с нормативным значени- ем производительности труда разработчиков, позволяет рассчитать обоснованную и с точки зрения заказчика, и с точки зрения исполнителя величину трудозатрат, которая и будет лежать в основе сбалансирован- ной оценки стоимости разработки ПС информационной системы.
В [4] на основании анализа большого числа проектов приведены эм- пирически установленные оценки трудозатрат коллектива разработчи- ков при приемлемом количестве ошибок кода на 100 000 строк (50–100 ошибок). Согласно [4], полный цикл разработки программного ком- плекса длиной в 20 000 строк требует 20 человеко-месяцев разработки, а разработка кода длиной в 100 000 строк требует 110 человеко-месяцев.
В этом же источнике приведено эмпирическое привило – возрастание размера ПО втрое увеличивает трудоемкость разработки и изготовления в семь раз. Показатель степени возрастания трудоемкости с ростом объ- ема кода равен 2,33, что совпадает с предложенным в [2] значением
2,35. Отличные от [4] оценки производительности труда разработчиков
ПО приведены в [12]. Однако там не указаны требования к качеству ПО, что затрудняет оценку исполнения программной части ИТКСС при его внедрении. Кроме того, оценки трудозатрат, используемые в [12], суще- ственно опираются на длину кода как таковую, без анализа полезности

341
ПО для заказчика, по сути являются оценками исполнителя. Примене- ние длины кода делает оценку пригодной только после окончания про- екта, когда расчет трудозатрат уже не актуален.
В отличии от [12], методика IFPUG FPA, определяет функционально оправданную длину кода на ранних стадиях проектирования. Изначаль- но методика определения потребительских требований к функциональ- ности (ПТФ), приведенная в [2], оценивала трудоемкость разработки программного обеспечения только по анкетным данным проекта, т.е. по наиболее общим характеристикам, таким как масштаб проекта, тип объ- екта проектирования, пользователи проекта. Эта оценка функциональ- ности программного комплекса позволяет рассчитать трудоемкость, сложность и стоимость будущего программного изделия еще на началь- ной фазе, когда о проекте почти ничего не известно.
Оценка функциональности в баллах производится согласно класси- фикатору, приведенному в табл. 7.21.Используя самые общие данные о проекте и приведенные в этой таблице классификаторы, можно рассчи- тать оценочное значение сложности будущего проекта в баллах функ- циональности по формуле:
FP = (C
1
+ C
2
+ C
3
)
2,35
, где FP – оценка в баллах функциональности, а C
i
– соответствую- щие значения из табл. 7.21.
Для определения функционально оправданной длины кода использу- ется таблица соответствия баллов функциональности объему кода, на- писанного с помощью разнообразных средств программирования (см. табл. 7.22)
Функционально оправданная длина кода равна
С = FP
K
i
= K
i
(C
1
+ C
2
+ C
3
)
2,35
Это – единственная методика оценки трудоемкости разработки про- граммных продуктов, применимая до начала проектирования (сейчас актуальна версия, определенная в документе IFPUG FPA Guide Manual v. 4.1) [1].
Зная усредненную производительность труда коллектива разработ- чиков (по ряду публикаций она равна 900 строкам в месяц) исполнитель определяет стоимость разработки и внедрения ПО. Методика EFP
IFPUG FPA позволяет корректировать оценку объема программного кода, трудоемкость стоимость ходе проектирования и разработки про- граммного продукта. Методика EFP IFPUG FPA оперирует с двумя ка- тегориями – информационные элементы – структуры данных, объеди- ненные логическими взаимосвязями и функциональные составляющие – действия системы, позволяющие пользователю моделировать бизнес- процессы. Обе категории классифицируются в зависимости от сложно- сти внутренней структуры на категории, каждой из которых приписано определенное количество баллов функциональности – баллов ПТФ.

342
Таблица 7.21