Оценка экономической эффективности программных проектов

     После проведения системного проектирования, а также предварительного распределения  ресурсов, возможна ошибка в оценке совокупных затрат на разработку программного средства с требуемым качеством, приблизительно в полтора-два раза. Разработка архитектуры комплекса программ на основе прототипов и подготовка к программированию готовых апробированных алгоритмов позволяет ее уменьшить до 20-30%. Такую достоверность можно получить, конечно, только при подробном анализе и оценке влияния важнейших факторов и требований к качеству конкретного программного средства.

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

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

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

• при создании потенциально переносимых программных средств и баз данных, когда свойства эффективной мобильности предусматриваются при их первоначальной разработке, учитываются возможные платформы и области повторного использования таких программ и данных;
• при непосредственной реализации (с соответствующими затратами) процессов переноса программных средств и баз данных, в различной степени подготовленных при проектировании для переноса на иные платформы и/или для повторного использования компонентов на той же платформе в аналогичном проекте.
• при оценивании затрат первого этапа следует учитывать, что к настоящему времени накоплен большой объем прикладных программ и информации в базах данных, при создании которых не учитывалась возможность их последующего переноса на иные платформы - так называемые "унаследованные" системы. Более того, в ряде случаев из-за ограниченных ресурсов вычислительных средств при реализации крупных функциональных задач, программы и данные в таких системах в максимальной степени адаптировались при разработке к особенностям и параметрам ЭВМ для эффективного использования их ресурсов. В зависимости от степени совместимости между аппаратными и операционными платформами соответствующих ЭВМ возможны различные условия мобильности - полной или частичной несовместимости платформ, программных интерфейсов, языков программирования или диалектов одного языка и других параметров.

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

     Кроме того, любой перенос связан с затратами, которые требуются для:

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

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

     В ряде случаев может быть целесообразна  настройка готовых компонентов  на новые условия применения. При  больших изменениях условий применения, эффективной может оказаться  сборка нового программного средства с частичным использованием апробированных компонентов и с разработкой небольшой части программных модулей, обеспечивающих новые функции, интерфейсы и условия применения программного средства. При этом относительное снижение затрат пропорционально доле использования готовых комплектующих компонентов и степени их пригодности для использования в новом программном средстве. В пределе при построении нового программного средства на 80 - 90% из готовых компонентов, суммарные затраты могут сокращаться в 3 - 5 раз. В этом случае, кроме 10 - 20% затрат на создание новых программных компонентов, необходимы ресурсы на комплексирование нового программного средства, его квалификационное тестирования, испытания и документирование.

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

     Затраты на обеспечение корректности комплекса программ зависят от полноты прослеживания реализации требований к программного средства сверху вниз, в требованиях к компонентам вплоть до объектного кода программ и от степени их покрытия тестами. Эти затраты входят непосредственно в процесс разработки и зависят от объема и детальности процессов верификации и тестирования. Для сложных программных средств при требовании их высокой корректности, они могут составлять до 30% от затрат на обеспечение первичной, функциональной пригодности. Для относительно простых комплексов программ эта величина в среднем не превышает 20%. Эти затраты приходятся на верификацию и тестирование программных компонентов, что должно обеспечивать корректность, безопасность и надежность программных средств в целом. Хотя характеристики и их атрибуты принципиально различаются, затраты на их реализацию полностью разделить невозможно. Поэтому оценивание и выделение ресурсов на решение этих задач целесообразно анализировать совместно (рис. 1).

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

     Затраты на обеспечение безопасности и надежности функционирования программного средства определяются требуемым уровнем защищенности и сложностью (размером) программ для ее реализации. При наличии особенно высоких требований к безопасности критических программных средств эти затраты могут даже в 2 - 3 раза превышать затраты на решение базовых, функциональных задач. Для типовых административных систем трудоемкость создания программных средств защиты обычно составляет 20 - 40% затрат на решение основных, функциональных задач. Однако практически, в любых системах должен присутствовать минимум программных компонентов, обеспечивающих надежность и защиту от преднамеренных и случайных угроз.

     Затраты на создание достаточно полного комплекта  документации практически пропорциональны  размеру комплекса программ. Удельные затраты на документацию зависят от класса, назначения и широты применения программ, что трудно учесть в достаточно общем виде. Эти затраты сопутствуют в некоторой степени всем этапам разработки, однако, оформление эксплуатационных документов обычно локализуется в специальном этапе работ. Затраты на разработку комплекта эксплуатационной документации для сложных программных средств на уровне продукции, подлежащей длительному сопровождению, обычно определяются затратами на объем текста документов ориентировочно 5-10 страниц на тысячу строк программы на ассемблере.[5]

     В технологической документации, обеспечивающей конфигурационное управление и многолетнее  сопровождение, необходимы тексты программ и описания алгоритмов. Это приводит к увеличению объема документации на порядок, т.е. может составлять около 100 страниц совокупности документов на тысячу строк программы. Статистический анализ объема документации для программных средств различных классов дал [8] широкий разброс числа страниц на единицу объема программ. Однако выявились некоторые средние характеристики, которые близки к указанным выше. Подтверждена наиболее высокая документированность тиражируемых программ реального времени, особенно в тех случаях, когда необходима высокая безопасность и надежность функционирования программного средства

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

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

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

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

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

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