Очерки истории отечественной программной инженерии в 1940-е – 80-е годы - Владимир Липаев
Шрифт:
Интервал:
Закладка:
5.7. Методики технико-экономического обоснования производства комплексов программ – 1985-е годы
На базе выполненных исследований было разработано методическое руководство для оценки и согласования с заказчиками ТЭП и стоимости разработки крупных комплексов программ, что позволило сократить конфликты при подготовке договоров на создание программных продуктов в конце 80-х годов. Методика прогнозирования технико-экономических показателей разработки программных средств была, одобрена в 1990 году Ученым советом Центрального бюро нормативов по труду Госкомтруда СССР и рекомендована для применения в научно-производственных объединениях, на предприятиях и в организациях науки и научно-технического обслуживания отраслей народного хозяйства. На основе этой методики был разработан технологический пакет прикладных программ ПЛАПС, предназначенный для автоматизированного прогнозирования технико-экономических показателей разработки программных средств, а также обеспечивающий функции планирования и методической поддержки проектов.
Наиболее полные исследования, обобщения и экономические характеристики реализованных проектов за рубежом отражены в книге Б. Боэма [15, 11], которая стала доступной отечественным специалистам в середине 80-х годов. Приступая к разработке комплекса программ, как в любой промышленной деятельности, в методиках рекомендовалось проводить реалистическую оценку возможного масштаба проекта — поставленных целей, ресурсов проекта и выделенного времени. Задача управления масштабом состояла в задании базовых требований, которые включали разбитое на компоненты ограниченное множество функций и требований, намеченных для реализации в конкретной версии проекта. Базовый уровень масштаба, должен был обеспечивать приемлемый для заказчика минимум функций и требований к продукту, а также разумную вероятность успеха проекта с точки зрения возможностей коллектива разработчиков.
При оценивании масштаба следовало определить приоритеты реализуемых функций для установления состава работ, согласованного между заказчиком и разработчиком, которые обязательно должны быть выполнены и для определения базового уровня масштаба конкретного проекта с допустимым риском неуспешной реализации. В общем случае необходимо было достигать сбалансированного состава целей оценивания разных характеристик, которые давали бы примерно одинаковую величину уровня неопределенности для всех компонентов комплекса. Кроме того, каждая оценка ТЭП должна была сопровождаться, указанием степени ее неопределенности. По мере разработки проекта их необходимо было пересматривать и изменять, когда это становится выгодным. Для этого в 80-е годы рекомендовались методики [29]:
• первичная оценка ТЭП при подготовке концепции и технического задания на новый комплекс программ, на основе экспертных данных размера комплекса, производительности труда или стоимости разработки одной строки текста программ – прототипов;
• прогнозирование ТЭП при детальном проектировании комплекса программ на базе расчетных значений трудоемкости и длительности его разработки с учетом влияния различных факторов.
В первой методике был реализован метод прогноза ТЭП с учетом экспертной оценки минимального числа факторов. Данная методика могла применяться, когда определены цели и общие функции проекта, сформулированы концепция и первичные требования с достоверностью около 30–40 %. Основная цель оценки ТЭП — подготовить возможность принять обоснованное решение о допустимости дальнейшего продвижения проекта в область системного анализа, разработки требований и предварительного проектирования. Если оказывалось, что рассчитанные технико-экономические показатели и требуемые ресурсы не могут быть обеспечены для продолжения проекта, то возможны были кардинальные решения: либо изменение некоторых требований, ТЭП и выделяемых ресурсов, либо прекращение проектирования данного продукта. Учитывая полноту и достоверность доступных характеристик и требований к проекту продукта должны были определены цели и возможная достоверность технико-экономического обоснования затрат на продолжение проектирования и производства программного продукта. При первичном технико-экономическом обосновании сложных проектов программных продуктов наибольшее значение имели три ключевых фактора:
• размер – масштаб, подлежащих разработке полностью новых программных компонентов;
• размер и относительная доля готовых программных компонентов, которые могут быть заимствованы из предшествовавших проектов и повторно использованы в новом программном продукте;
• относительные затраты ресурсов на создание проекта: труда специалистов, времени и бюджета на единицу размера (на строку текста программ) создаваемого продукта.
Эти факторы могли быть оценены квалифицированными экспертами на основе имеющегося у них опыта реализации предшествовавших подобных проектов, а также использования опубликованных, статистических данных. Достоверность прогнозов ТЭП зависела, прежде всего, от точности экспертной оценки исходных данных, размера – масштаба комплекса программ, от достоверности экспертной оценки производительности труда специалистов или от стоимости разработки одной строки текста программы.
Основными исходными данными для оценок ТЭП являлись концепция проекта и комплекс требований к иерархическому набору функций, которые могут быть разбиты на предполагаемые фактические компоненты. В дальнейшем разбиение могло детализироваться, формируя упрощенный или более точный уровень абстракции и взаимодействия компонентов. Наиболее глубокий уровень детализации, как правило, редко формируется ко времени первоначальной экспертной оценки размера комплекса.
Экспертная оценка удельных затрат на строку текста программ в методике приводилась для некоторых примеров программных продуктов. При этом подчеркивалось, что оценки относятся к полному циклу разработки крупных комплексов программ, начиная от создания концепции и требований до завершения испытаний, и передачи программного продукта заказчику или пользователям. В составе участников проекта учитывались все категории специалистов, обеспечивавших реализацию программного продукта.
Так как разработчики сложных комплексов программ были не заинтересованы раскрывать реальную экономику выполненных проектов, и эти данные склонны относить к коммерческой тайне, опубликованные ТЭП носят отрывочный, не упорядоченный и не всегда достоверный характер. Кроме того, обычно не представлялись детальные сведения об особенностях и требованиях к качеству объекта разработки, применявшейся технологии и инструментальных средствах, характеристиках коллектива специалистов и других факторах. Поэтому такие данные трудно было обобщать и использовать для прогнозирования новых проектов.
В исследованиях [15] при разработке программных продуктов реального времени в 80-е годы, преимущественно на ассемблере, была получена средняя производительность 60–80 строк на человеко-месяц. Для относительно небольших комплексов программ административных систем (в значительной степени на языках высокого уровня) производительность составила около 260 строк на человеко-месяц. Таким образом, в зависимости от характеристик объекта и условий разработки был возможен экспертный выбор величин производительности труда для последующего прогноза полной трудоемкости создания программных продуктов.
Экспертная оценка, длительности разработки сложного программного продукта могла оцениваться на базе рассчитанной ранее трудоемкости разработки, от которой нелинейно зависит длительность. Например, крупные продукты реального времени размером около 500 тысяч строк требовали для реализации около 3,5 лет, а небольшие (30 тысяч строк) – около одного года.
Экспертная оценка необходимого числа специалистов рассчитывалась путем деления полной трудоемкости разработки на длительность ее реализации. Для примера крупного продукта реального времени, размером 500 тысяч строк, необходимое число специалистов достигало 160 человек [15], а для относительно небольшого проекта (30 тысяч строк) – в десять раз меньше (16 человек). Аналогично можно было получить оценки необходимого числа специалистов на выделенных крупных этапах разработки, что полезно для первичного формирования коллектива и оценки возможности реализации ими конкретного проекта.
