книги / Оценка затрат на разработку программных средств

му возрастанию затрат, что часто не учитывается при планирова­ нии. В результате для сложных и сверхсложных КП всегда есть риск проявления неустраненных ошибок. Стремление резко уско­ рить разработку, снизить затраты или нерационально увеличить нормативы для специалистов всегда сопряжено со снижением ка­ чества в трудно оцениваемых пределах. Приводимые ниже дан­ ные (гл. 3) и анализ факторов (гл. 2 и 4) ориентированы на опре­ деленные классы ПС с неформализованным качеством, удовлетво­ ряющим пользователей. Отдельно анализируется проблема повы­ шения затрат для достижения высокой надежности функциониро­ вания КП реального времени (см. § 4.1). При рассмотрении ТЭП разработки ПС предполагается достаточно высокое, однако не всегда зафиксированное качество программ.

Основное внимание в данной книге сосредоточено на первых двух целях анализа (гл. 2 и 3). Помимо этого, частично проводит­ ся анализ методов и средств снижения совокупных затрат и сро­ ков создания сложных КП (гл. 4). Четвертая цель пока не достиг­ нута. Имеющиеся попытки введения приблизительных нормати­ вов либо не способствуют выполнению их управляющей и регла­ ментирующей роли (если они занижены), либо приводят к сниже­ нию качества программ (если они завышены). Поэтому приводи­ мые ниже ТЭП следует использовать с учетом всех условий, для которых они получены, и нецелесообразно применять в качестве нормативов при конкретных разработках. Они могут служить только ориентирами для оценки экономических характеристик ана­ логичных КП.

Единицы измерения технико-экономических показателей про­ цесса разработки программ. Одна из сложных задач при анализе

ТЭП	разработки программ					состоит в выборе и формализации
единиц измерения объ­
екта	разработки			и за­
трат	на	его создание.
Неопределенность				еди­
ниц	измерения		значи­
тельно влияет			на	чис­
ленные значения				пока­
зателей и их разброс в
опубликованных				рабо­
тах. Этому также				спо­
собствует		неоднознач­
ность учитываемых эта­
пов	разработки			про­
грамм и категорий спе-
циалистов, трудозатра--					рис	, ,	Качест>0	программных	средств раз-
ТЫ	КОТОрЫХ		З а м е т н о		личной		сложности I	зависимости	от затрат на
влияют на ТЭП. Даже					разработку Ср

31

при одних и тех же единицах измерения объектов разработки и затрат на их создание методики определения количественных зна­ чений этих показателей пока не формализованы, что вносит допол­ нительную дисперсию в их значения, приводимые в различных ис­ следованиях. В результате могут делаться принципиально невер­ ные выводы, например об очень высокой эффективности некоторых частных технологических методов или систем [6, 48, 99]. Для умень­ шения этих неопределенностей и возможных методических ошибок в ТЭП программ необходимо определить основные понятия и еди­ ницы измерения: размера или объема программ, трудозатрат на их разработку, производительности труда специалистов и некото­ рых частных характеристик.

Размер или объем программ в настоящее время приводится в публикациях в различных единицах, что может изменять их чис­ ленные значения для одних и тех же программ в несколько раз [6, 51, 32]. В качестве таких единиц чаще всего используются чис­ ленные значения: строк на языке программирования, предложений на ассемблере, символов в тексте программы, байт или команд в объектном коде после трансляции и т. п. Каждая из этих единиц измерения имеет некоторые преимущества при определенных це­ лях исследования. Однако при технико-экономическом анализе различных проектов применение в каждом из них своих единиц для характеристики объекта разработки приводит к дополнитель­ ному разбросу численных значений объемов и к несопоставимости измеренных технико-экономических показателей. Влияние единиц

измерения объема программ на технико-экономические показате­ ли можно значительно уменьшить, если учесть их принципиальные особенности и разделить на две группы единиц измерения [32]:

группу, характеризующую объем исходных текстов программ, которые разрабатываются и анализируются человеком, отражаю­

щую сложность и трудоемкость создания ПС; группу, отражающую объем программ, размещаемых в реали­

зующей ЭВМ, и характеризующую объем памяти и производитель­

ность ЭВМ, необходимые для рабочего функционирования ПС (рис. 1.2).

Эти две группы единиц отражают объем программ с сущест­ венно разных позиций и должны использоваться в зависимости от целей анализа. Хотя между ними есть корреляция, но в общем случае объемы программы, измеренные различными группами единиц, оказываются практически несопоставимыми из-за наличия между ними промежуточного звена-преобразователя (транслято­ ра) с не полностью определенными характеристиками (/Cn2i и Кп2о

на рис. 1.2). Это обусловлено различием трансляторов, которые пре­ образуют исходные тексты программ, разработанные человеком, ft разделы памяти реализующей ЭВМ, заполненные командами, кон-

32

Рис. 1.2. Схема взаимосвязей значений объемов программ при применении различных единиц измерения объема

стентами или выделенные под переменные, а также особенностями языков программирования и машинных команд [13, 59].

Объем исходных текстов программ прежде всего отражает тру­

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

Объем программ, размещаемых в ЭВМ, влияет на характери­

стики и стоимость машин, которая зависит от необходимой памя­ ти и производительности ЭВМ. Затраты на реализацию ПС в каж­ дой ЭВМ изменяются приблизительно в таком же широком диапа­ зоне^ как и трудоемкость их разработки (на четыре порядка). Массовое тиражирование некоторых ПС может дополнительно на несколько порядков увеличивать диапазон затрат на реализующие ЭВМ (см. § 2.2).

П е р в а я г р у п п а е д и н и ц и з м е р е н и я о б ъ е м а ПС в той или иной степени отражает сложность разработанного текс­ та программ. К ним относятся:

символы в исходном тексте программы на любых языках про­ граммирования;

лексемы, объединяющие группу символов, имеющих общее смысловое содержание в тексте программы;

операторы языка программирования уровня ассемблера; строки текста программы на языке программирования высоко­

го уровня.

Основной труд специалистов вкладывается в разработку текста программ, и желательно, чтобы выбранная единица измерения была бы в наибольшей степени адекватна трудоемкости разработ­ ки. При этом должна учитываться не только трудоемкость непо­ средственной подготовки текста и разработки компонент програм­ мы, но и отражаться трудоемкость комплексного создания всего сложного ПС. Кроме того, единица измерения объема должна быть наглядной и просто измеряемой. С этих позиций применение чис­ ла лексем для характеристики объема программ пока затрудни­

тельно, тем более, что отсутствует опыт использования этого пока­ зателя.

Число символов достаточно адекватно отражает сложность раз­

работки ПС. Действительно, число символов исполняемой части текста программы непосредственно определяет умственные затра­ ты на подготовку и анализ текста, а также возможное число оши­

бок в процессе разработки [53]. Число символов	в тексте легко
и однозначно подсчитывается при любых языках	программирова­

34

ния. По мере повышения уровня языка программирования симво­ лы объединяются в группы — лексемы, каждая из которых в сово­ купности отражает некоторое понятие. Число символов в каждом таком понятии может варьироваться в широких пределах и не всегда соответствует сложности н трудоемкости использования данного понятия.

При возрастании уровня языка программирования число сим­ волов, имеющих непосредственное смысловое содержание, убыва­ ет за счет объединения их в группы, отражающие обобщенные понятия. Это усложняет оценку объема текста по числу символов. Однако большинство символов не группируется,^ а допустимое группирование обычно ограничено 6—8 символами. Поэтому пер­ вичная оценка сложности текста на языках высокого уровня мо­ жет проводиться прямым подсчетом числа символов в тексте. По­ следующее уточнение сложности текста возможно путем .введения усредненных коэффициентов, отражающих, степень объединения символов в группы. OueijKif текстов программ, написанных на

языке ПЛ-1, показывают, что для автономных модулей этот коэф­ фициент имеет значение в пределах ~ 2—3.

Число операторов на ассемблере наиболее широко применяется

на практике для оценки объема текста программ. Это определяет­ ся массовостью применения в настоящее время ассемблеров (свыше 50% по всем классам программ и до 90% для программ реального масштаба времени [52, 78]). Ассемблеры обеспечивают наилуч­ шее использование ресурсов памяти и производительности реали­ зующих ЭВМ и всегда отражают особенности архитектуры и сис­ темы команд каждой машины. Тем не менее при одном и том же алгоритме число операторов на ассемблере без учета макрорасши­ рений относительно мало зависит от особенностей систем команд для большинства современных ЭВМ. Макрокоманды могут значи­ тельно изменять объем текста программы. Поэтому целесообразно оценку объема программ на ассемблере проводить с учетом рас­ крытия макрокоманд. При этом условии число операторов в тек­ стах программ на разных ассемблерах является наиболее стабиль­ ной характеристикой их объема.

Разброс числа операторов на различных ассемблерах при оди­ наковых алгоритмах зависит в основном от разрядности реализу­ ющей ЭВМ. Для двух- и 'четырехбайтных ЭВМ соотношение числа операторов изменяется не более чем на 20% относительно ассемб­ лера ЕС ЭВМ. Для однобайтных ЭВМ, например, на базе микро­ процессора КР580ИК80, число операторов в тексте программы почти в два раза больше при одинаковых алгоритмах, чем на ас­

семблере ЕС ЭВМ [29].

Подсчет числа операторов на ассемблере в тексте программы требует установления правил выделения операторов и немного сложнее, чем подсчет числа символов. Дополнительные затраты

2*

35

могут быть оправданы повышением наглядности и стабильности

оценок объема ПС.

Число строк на языках высокого уровня (ЯВУ) в значительной

степени зависит от конкретных особенностей языка. Все языки программирования высокого уровня ориентированы на определен­ ные классы задач. Благодаря этому проблемно-ориентированные языки позволяют получать компактные тексты соответствующих классов программ. Однако применение их для других классов при­ водит к расширению текста и не всегда рационально. ЯВУ значи­ тельно различаются степенью обобщенного описания содержания алгоритмов из-за проблемной ориентации, применения разных структур операторов, операндов и процедур, что может приводить к различию (в несколько раз) числа строк текста, по сути, одних и тех же программ (Кл2б2 на рис. 1.2).

Число строк текста программ на ЯВУ характеризует сложность программы для ее разработчика, однако оно не отражает функци­ ональную (потенциальную) сложность, которая значительно выше за счет применения процедур. Последняя отражается особенно сильно при комплексной отладке сложных ПС. Перечисленные факторы в совокупности .приводят к тому, что объем программ на различных ЯВУ трудно привести к некоторым унифицированным единицам. Для такой унификации необходимо выделить базовый, широко применяемый язык программирования и определить коэф­ фициенты пересчета Кп2б2 числа строк при разработке ПС на дру­

гих ЯВУ с учетом классов программ. Однако пока отсутствует ЯВУ, который мог бы претендовать на роль базового (унифи­ цированного) при расчете объемов любых ПС, а также достаточное число исследованных ПС на этом языке для обобщения их ТЭП.

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

байты, занятые текстом программ в объектном коде и пере­ менными базы данных в памяти ЭВМ;

команды (операции) реализующей ЭВМ, составляющие текст исполняемой программы в объектном коде;

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

Число байтов оперативной и постоянной памяти реализующей

ЭВМ, занятых при исполнении программы, — наболее просто

36

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

Число команд, занятых программой в реализующей ЭВМ, наи­

более полно соответствует числу исполняемых операторов на ас­ семблере в исходном тексте программы. В различных типах ЭВМ команды занимают различное число байтов или частей слова. Команды во многих машинах имеют переменную структуру по чис­ лу -занимаемых байтов в зависимости от кода операции, и могут возникать затруднения при выделении команд в машинном слове. Логическая сложность команд зависит также от методов использо­ вания в них регистров. Число команд в объектном коде програм­ мы,. функционирующей на ЭВМ, позволяет наиболее просто увязы­ вать затраты на исполнение и на разработку программ, так как Кто и Кою (см. рис. 1.2) близки к единице.

Число слов, занятых программой и данными в ЭВМ, имеет пра­

ктически те же особенности при измерении объема программ, что и число байтов. Однако следует учитывать, что реализующие СЭВМ могут значительно различаться по числу байтов в слове (ча­ ще всего в диапазоне от I до 8 байт), что дополнительно затрудня­ ет сопоставление объема различных программ при использовании этой единицы измерения и их унификацию. Для устранения этого препятствия иногда все объемы программ приводят к наиболее широко применяемой структуре слов из 4 байт.

Корреляция между объемами программ, измеренными двумя

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

качество трансляторов, преобразующих исходный текст про­ граммы в объектный код ЭВМ (КП2о и Кбго);

особенности языка программирования, на котором разрабаты­

вается исходный текст (/Спгбг и Kniei);

архитектура ЭВМ, реализующей разработанные программы

(КпОбо) •

Задача состоит в выборе базовых унифицируемых единиц изме­ рения исходного текста и исполняемых (объектных) программ, при применении которых имеется наибольшая корреляция измеряемых

37

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

лом команд в объектном коде реализующей ЭВМ Кто и Кбю, близкую к единице. В этом случае при сопоставлении измеренных

объемов программ	влияет	единственный фактор — архитектура
реализующих ЭВМ. Этот фактор			может учитываться		путем не­
больших коэффициентов перевода			(Кщб1~1,1— 1,3), определяемых
путем анализа особенностей		структуры		и системы команд ЭВМ,
а также конкретного	ассемблера. Для			сопоставления	численных
значений объемов программ		следует выделить базовый, наиболее

широко применяемый и известный в стране ассемблер. В этом ка­ честве наиболее целесообразно использовать ассемблер ЕС ЭВМ, который ниже рассматривается как базовый. Однако при анализе единиц измерения объема программ для оценки ТЭП следует учи­ тывать некоторые парадоксальные ситуации.

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

тор с ЯВУ и чем ниже его оптимизирующие характеристики (уве­ личивается Кп2о или Кого)» тем больше объем программ в реализу­

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

коду реализующей ЭВМ	для программ, разработанных на ЯВУ.
В т о р о й п а р а д о к с .	При использовании числа строк исход­

ного текста программы на ЯВУ для анализа производительности труда разработчиков необходимо учитывать сжатие текста при повышении уровня языка (Кпгбг). Изменение числа строк в тексте

38

программы и трудозатрат на его разработку в зависимости от уровня языка подчиняется разным законам. В частности, число строк программы зависит от конкретных правил формирования строк на ЯВУ, что практически не отражается на трудоемкости. Она не зависит от того, как упорядочивается текст по вертикали и по горизонтали и как операторы объединяются в строки текста.

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

том, что рассчитанная по этим данным производительность труда в строках ЯВУ на единицу времени оказывается тем ниже, чем выше уровень языка программирования [69].

Для разрешения этого парадокса при анализе производитель­ ности целесообразно пересчитывать число строк на ЯВУ в экви­ валентное число операторов на ассемблере. Коэффициенты пере­ счета Kn2i для каждого ЯВУ могут быть оценены эксперименталь­

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

Т р е т и й п а р а д о к с . Одним из наиболее эффективных мето­ дов повышения производительности труда при разработке сложных ПС является применение сборочного программирования [15, 81].

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

39

Расчет показателей производительности труда с учетом полно­ го объема ПС, в том числе ранее обработанных и испытанных программ, в этом случае неправомерен, так как не учитывается труд, затраченный ранее на готовые компоненты, используемые при сборке. Возможный выход для уменьшения парадоксальности численных оценок производительности труда при сборочном про­ граммировании состоит в учете объема и затрат на комплексирование только вновь разработанных программ [23]. В этом случае

затраты на комплексирование уже ранее отлаженных программ учитываются только в полной трудоемкости разработки.

П р и м е р э к с п е р и м е н т а л ь н ы х о ц е н о к и с о п о ­

с т а в л е н и я	е д и н и ц	и з м е р е н и я	о б ъ е м а	ПС. На основе
проведенного	анализа	можно сделать	вывод о	целесообразности

применения в качестве базовых единиц измерения объема ПС чис­ ла операторов Пб1 на наиболее распространенном ассемблере. Для

обобщения технико-экономических показателей любых разработок ПС необходимо обеспечить [32]:

расчет числа строк на применяемых ЯВУ ПП2 и определение среднестатистических коэффициентов Kn2i Для их приведения (без

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

отношения числа команд	в объектном	коде реализующей ЭВМ
Поп, эквивалентного числу	операторов	соответствующего ассемб­

лера, к числу строк на ЯВУ в тексте программ П„2 (полное рас­ ширение транслированного текста в объектном коде реализующей ЭВМ относительно текста на ЯВУ — Кого);

пересчет числа операторов программ, написанных на ассембле­ рах для различных типов ЭВМ ПП1, к числу операторов на базо­ вом ассемблере Пб1 (расширение ассемблеров относительно базо­

вого — Kni6i).

Разнообразие ЯВУ, ассемблеров и архитектуры реализующих ЭВМ не позволяет заранее определить перечисленные коэффици­ енты для всех важных условий. Поэтому ниже приводятся только примеры таких оценок [32], которые могут служить ориентирами при анализе ТЭП конкретных разработок КП, а также демонст­ рируют методику определения коэффициентов пересчета единиц измерения объемов программ. Для решения перечисленных выше задач проводился анализ ранее разработанных программ и спе­ циальное опытное программирование одних и тех же алгоритмов на различных языках.

Для оценки сжатия текста на ЯВУ относительно текста на ас­ семблере— коэффициент Кб21 в качестве базовых были приняты

одни из наиболее распространенных в стране языков: язык верх­

40