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

309 граммирования, системы сетевых протоколов и др. Перечисленные классы ПС различаются не только спецификой решаемых задач, но и сложностью.
С позиции технико-экономического анализа жизненный цикл пере- численных классов ПС можно разделить на две существенно различаю- щиеся процессами части. В первой части ЖЦ проводится системный анализ, проектирование, разработка, тестирование и испытание первой базовой версии. Номенклатура работ, их трудоемкость, длительность и другие характеристики на этих этапах ЖЦ существенно зависят от клас- са ПС, места (объекта) ее использования и требуемых показателей ка- чества, внешней и технологической среды разработки.
Вторая часть ЖЦ, отражающая эксплуатацию и сопровождение ПС, слабо связана с характеристиками объекта ее использования и среды разработки.
7.2. Первичное технико-экономическое обоснование
разработки ПС
При технико-экономическом обосновании проекта ПС на любом уровне целесообразно применять методы и методики, адекватные целям и этапам его реализации. Сначала следует провести реалистичную оценку возможного масштаба проекта – поставленных целей, ресурсов проекта и выделенного времени [11]. Задача управления масштабом состоит в задании базовых требований, которые включают разбитое на компоненты ограниченное множество функций и требований, намечен- ных для реализации в конкретной версии проекта.
Базовый уровень масштаба должен обеспечивать: приемлемый для заказчика минимум функций и требований к проек- ту; разумную вероятность успеха с точки зрения возможностей коллек- тива разработчиков.
При оценивании масштаба следует определить приоритеты функций для установления состава работ, согласованного между заказчиком и разработчиком, которые обязательно должны быть выполнены, и для определения базового уровня масштаба конкретного проекта с допус- тимым уровнем риска неуспешной реализации. Сокращение масштаба проекта до размеров, адекватных выделенному времени и ресурсам, может привести к конфликтам заказчиков и разработчиков. Для умень- шения вероятности таких конфликтов целесообразно активно привле- кать заказчиков к управлению их требованиями и масштабом проекта, чтобы обеспечить как качество. Так и своевременность разработки ПС.
При этом следует учитывать следующее: именно заказчики несут финансовую ответственность за выполнение обязательств перед внешними клиентами и пользователями (пусть в несколько сокращенном, при необходимости, масштабе);

310 программная система, ее важнейшие функции и удовлетворяемые требования принадлежат заказчику, а не коллективу разработчиков или поставщику.
Привлечение заказчика помогает менее болезненно решать пробле- мы управления масштабом проекта и реализуемыми функциями с уче- том ограничений ресурсов. Любые дополнительные функции за преде- лами базовых, которые реализует разработчик, будут восприняты заказ- чиком как превзошедшие ожидания. В зависимости от этапа разработки сложной ПС и достоверности исходных данных о характеристиках и особенностях проекта ПС целесообразно выбирать и применять разные методики и сценарии технико-экономического обоснования проекта и прогнозирования ТЭП. С самого начала работы над проектом ПС важно вести постоянный учет данных о его действительной трудоемкости, стоимости и развитии затрат, и сравнивать эти данные с реальными оценками характеристик проекта по следующим причинам: несовершенство исходных данных для оценивания ТЭП (оценки размера, рейтинги влияния факторов) определяют необходимость для руководителя проекта пересматривать их оценки, учитывая но- вую информацию, чтобы обеспечить более реальную основу для дальнейшего управления проектом; вследствие несовершенства методов оценивания ПС следует сравни- вать оценки с действительными значениями и использовать эти ре- зультаты для улучшения методов оценивания ТЭП; проекты ПС имеют тенденцию к изменению характеристик и эконо- мических факторов и руководителю проекта необходимо идентифи- цировать эти изменения и выполнять реалистичное обновление оце- нок затрат.
Следует согласовывать цели оценивания с потребностями в инфор- мации, способствующей принятию решений для планирования затрат труда и других ресурсов. В общем случае необходимо достигать сба- лансированного состава целей оценивания разных характеристик, кото- рый бы давал примерно одинаковую абсолютную величину уровня не- определенности для всех компонентов ПС. Кроме того, каждая оценка
ТЭП должна сопровождаться указанием степени ее неопределенности.
Это означает, что абсолютная величина уровня неопределенности для каждого компонента должна быть примерно одинаковой, если в процессе принятия решения все компоненты имеют одинаковый вес. По мере разработки проекта их необходимо пересматривать и изменять, когда это становится выгодным. Бюджетные решения, принимаемые на ранних фазах, должны влиять лишь на следующую фазу. Для этого ав- тор монографии [12] рекомендует три методики: первичная оценка ТЭП при подготовке концепции и технического задания на новую программную систему на основе экспертных дан- ных размера ПС, производительности труда или стоимости разра- ботки одной строки текста программ-прототипов; прогнозирование ТЭП при предварительном и детальном проектиро- вании ПС на базе расчетных значений трудоемкости и длительности

311 разработки ПС по данным модели COCOMO [8, 19] с учетом влия- ния различных дополнительных факторов; определение технико-экономических показателей ПС с учетом дос- тупных оценок множества факторов и календарное планирование разработки ПС с использованием системы ПЛАПС.
В качестве основных критериев выбора методик прогнозирования
ТЭП разработки ПС целесообразно учитывать возможность их исполь- зования, как на начальных, так и на последующих этапах разработки, а также апробирование методик в отечественной и зарубежной практике.
В первой методике реализован метод прогноза ТЭП с учетом экс- пертной оценки минимального числа факторов. В [12] приведены зна- чения возможной достоверности оценки ТЭП в зависимости от основ- ных этапов разработки проекта сложной ПС и. соответственно, от воз- можной достоверности знаний о состоянии и характеристиках реализа- ции проекта. Данная методика экспертной оценки ТЭП может приме- няться, когда определены цели и общие функции проекта ПС, сформу- лированные в концепции и первичных требованиях с достоверностью около 30 – 40 %. Основная цель оценки ТЭП – подготовить возмож- ность принятия обоснованного решения о допустимости дальнейшего продвижения проекта в область системного анализа, разработки требо- ваний и предварительного (внешнего) проектирования.
Если оказывается, что рассчитанные технико-экономические показа- тели и требуемые ресурсы не могут быть обеспечены для продолжения проекта, то возможны кардинальные решения: изменение некоторых
ТЭП и выделяемых ресурсов, или прекращение проектирования данной
ПС. Учитывая полноту и достоверность доступных характеристик и требований к проекту ПС должны быть определены цели и возможная достоверность технико-экономического обоснования затрат на продол- жение проектирования ПС.
При первичном технико-экономическом обосновании сложных про- ектов ПС наибольшее значение имеют три ключевых фактора: размер – масштаб, подлежащих разработке полностью новых про- граммных; размер и относительная доля готовых компонентов, которые могут быть заимствованы из предшествующих проектов и повторно ис- пользованы в новом проекте ПС; относительные затраты ресурсов на создание проекта: труда спе- циалистов, времени или бюджета на единицу размера (на строку тек- ста программ) проектируемой ПС.
Эти факторы могут быть оценены квалифицированными экспертами на основе имеющегося у них опыта реализации предшествовавших по- добных проектов, а также использования опубликованных данных. При наличии необходимых данных важно оценить их достоверность и воз- можную точность (30 – 40%). Наименее точный из перечисленных фак- торов полностью определяет достоверность расчета технико- экономических показателей проекта ПС, поэтому желательно, чтобы

312 значения точности экспертного оценивания перечисленных факторов были сбалансированы.
При наличии перечисленных исходных данных и положительной оценке целесообразности экспертного анализа ТЭП проекта может быть реализована методика, состоящая из следующих шагов [12]: экспертная оценка размера – масштаба, числа строк предполагаемого текста разрабатываемых программ, с учетом размера повторно ис- пользуемых компонентов и характеристик возможного языка про- граммирования; экспертная оценка возможной средней производительности труда специалистов при разработке программ и/или стоимости разработки одной строки текста программы проекта ПС; расчет возможной полной трудоемкости длительности разработки проекта ПС, а также среднего числа специалистов, необходимых для его реализации; обобщение основных технико-экономических показателей и полной стоимости разработки проекта ПС, анализ результатов и технико- экономическое обоснование рентабельности продолжения проекти- рования ПС.
Достоверность прогнозов ТЭП зависит, прежде всего, от точности экспертной оценки исходных данных: размера-масштаба ПС и от досто- верности экспертной оценки производительности труда специалистов или оценки стоимости разработки одной строки программы. Однако, хорошо известны особенности и недостатки экспертных оценок ТЭП.
Они позволяют использовать опыт прошлых разработок и их отличия от новых методов, предусмотренных в конкретных проектах, а также ин- дивидуальные возможности коллектива разработчиков или другие осо- бенности уникальных проектов.
В то же время экспертные оценки зависят от компетентности и объ- ективности экспертов, их оптимистичности, пессимистичности и знания существенных особенностей проекта. Оценки одного эксперта трудно проверять и контролировать на достоверность. Из-за индивидуальных особенностей экспертов предпочтительным является оценивание харак- теристик несколькими экспертами и получение средних оценок на со- вещании группы экспертов для формирования единой оценки. При этом возможно отсеивание оценок, связанных с неосведомленностью, но, с другой стороны, группа экспертов может попасть под влияние автори- тетной личности или ситуации.
Экспертная оценка размера проекта ПС наиболее сложная задача.
Точность оценок должна быть сбалансирована с достоверностью экс- пертного определения или выбора характеристик других компонентов, используемых при расчете ТЭП (удельной трудоемкостью или стоимо- стью строки текста программы). Все методы оценивания основываются в основном на опыте прошлых разработок. Однако они не всегда могут обладать чертами чаще всего используемого в настоящее время струк- турного программирования, использовать автоматизированные инстру- ментальные средства, языки спецификаций или распределенную обра-

313 ботку данных. В этом случае для ближайших и перспективных целей важно осознавать отличия влияния дополнительных факторов [8].
Исходными данными является концепция проекта ПС и комплекс требований к иерархическому набору приоритетов функций, которые могут быть разбиты на предполагаемые фактические компоненты ПС. В дальнейшем разбиение может детализироваться, формируя упрощенный или более точный уровень абстракции и взаимодействия компонентов.
Наиболее низкий и глубокий уровень детализации, как правило, редко формируется во время первоначальной экспертной оценки размера ПС.
Обычно несколько уровней абстракции могут определяться на весьма ранних стадиях планирования проектов. Следует учитывать, что в мак- симальной степени детализированная структура ПС может принести пользу на стадии предварительных измерений размера ПС, за которой следует стадия более точных оценок по методикам, предложенным в [1,
5, 9, 16, 19].
Следует иметь ввиду, что, по мнению многих специалистов, несмот- ря на появление новых методов и инструментальных средств разработки сложных ПС, средняя производительность труда при их создании за последние двадцать лет осталась почти неизменной. Она составляет около 3000 строк кода на одного разработчика в год (порядка 250 строк на человеко-месяц) [20]. Это отражает тот факт, что уменьшение време- ни, затрачиваемого на цикл разработки, не может быть достигнуто за счет увеличения производительности труда отдельных специалистов.
Причем это практически не зависит от усовершенствования языка про- граммирования, организационных усилий со стороны менеджеров, от наличия или отсутствия некоторых видов инструментария и автомати- зации работ, хотя значительную роль играет увеличившаяся доля по- вторно используемых компонентов.
В качестве ориентиров при экспертной оценке ТЭП можно исполь- зовать следующие данные средней трудоемкости разработки сложных
ПС [12]: отдельные разрозненные сведения в публикациях о методах и техно- логиях разработки комплексов программ; результаты статистических исследований ТЭП проектов ПС, обоб- щенные в базовой модели COCOMO; результаты исследований экономических характеристик разработки отечественных проектов ПС, выполненных по программе ПРОМЕ-
ТЕЙ.
Так как разработчики сложных программных систем не заинтересо- ваны раскрывать реальную экономику выполненных проектов, и эти данные склонны относить к коммерческой тайне, опубликованные ТЭП носят отрывочный, не упорядоченный и не всегда достоверный харак- тер. Кроме того, обычно не представляются детальные сведения об осо- бенностях и требованиях к качеству объекта разработки, применявшей- ся технологии и инструментальных средствах, характеристиках коллек- тива специалистов и других факторах. Поэтому эти данные трудно обобщать и использовать для прогнозирования новых проектов.