Полная версия

Главная arrow Информатика arrow Введение в курс метрической теории и метрологии программ

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ ПОСМОТРЕТЬ ОРИГИНАЛ   >>

ПРИМЕНЕНИЕ МЕТРИЧЕСКОЙ ТЕОРИИ ПРОГРАММ

5.1. Измерение производительности труда в программировании

5.1.1. В промышленности мощность (производительность) предприятия, цеха, участка и т. п. измеряется делением количества единиц выпускаемой продукции на количество человеко-дней или человеко-часов, необходимых для производства. Аналогичным образом можно оценивать работу как отдельного человека, так и целого коллектива, занимающихся какой-либо производственной деятельностью, характеризуемой соответствующими количественными показателями.

В индустрии ПО сложились два разных подхода к выбору единиц его измерения [23]. При одном из них (традиционном) используется количество строк кода - LOC (Line of Code); при другом FP - функциональные точки (Function Points).

В первом случае производительность программиста оценивается количеством LOC, написанных за месяц (в других вариантах - за день, за год). Эта единица исторически самая известная и до недавнего времени наиболее широко используемая. Тем не менее понятие «строка кода» многими разработчиками, в силу методологически некорректного подхода к определению единиц измерения, трактуется по-разному. Одни из методов подсчета строк учитывают только выполняемые операторы; другие ведут подсчет строк независимо от их содержания. Хотя были предложены определенные стандарты (соглашения) подсчета строк, широкого применения они не нашли. Точно также применение LOC может ввести в заблуждение и при сравнении производительности программистов, использующих разные алгоритмические языки: чем выше уровень и, следовательно, выразительность последних, тем формально ниже производительность. Таким образом, корректное сравнение производительности программистов возможно только в пределах одной компании-разработчика ПО, где действуют единые правила трактовки и учета LOC. Эти трудности, однако, возникают не из-за строк кода как таковых, а обусловлены более глубокими причинами.

5.1.2. Удачный выбор единицы измерения может способствовать эмпирическому открытию количественного закона, которому подчиняется исследуемое явление или объект. Наоборот, как известно из физики, точные законы определяют масштабы и размерность производных единиц измерения. Закон Ципфа в лингвистике и его эквивалент в про- граммометрике невозможно было бы установить, если бы в качестве единицы измерения были выбраны «строки» произвольной длины вместо слов. Соотношение Холстеда справедливо для всех текстов программ, написанных на любом из универсальных алгоритмических языков, однако поиски единой конструкции планово-учетной единицы бессмысленны. Эта ситуация на практике сходна с измерением разного вида энергии: киловатт-часы, килокалории, килограммометры и т. д., так как все это только разные единицы измерения одной и той же величины, между которыми установлены точные коэффициенты пересчета (так называемые эквиваленты). Количество LOC в программах, написанных на разных языках, коррелирует с трудоемкостью их разработки, но не является достаточно точной мерой последней. Между тем, в метрической теории программ есть соотношения, аналогичные законам сохранения в физике (термин «физика программ» полнее отражает содержание и смысл этой теории). Пример:

где - разные уровни реализации одной и той же программы

(потенциальный объем V* = const). Еще пример: так как работы по программированию любой задачи на алгоритмических языках с уровнями A.J и Х2 выражаются в виде

то их отношение будет равно

а затрат времени на программирование соответственно (см. п. 2.7.2)

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

где - статистический коэффициент Кнута [4].

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

Используя приведенные выше в этом пункте формулы, а также обозначения и результаты п. 2.7.3, введем следующие коэффициенты пересчета (эквиваленты): по объему -

по производительности (времени кодирования) -

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

и

Величины также легкодоступны для измерения.

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

5.1.3. Расчет Гас производится на основе средней производительности V - числа отлаженных команд в день на одного человека. В зависимости от сложности ПО оно изменяется в довольно широких пределах:

Интервал 1,4

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

Для трансляторов, ассемблеров и другой продукции средней сложности имеет место ; для простых приложений на практике достижима . Как отмечено в [3], средняя скорость

получения отлаженных «строк» в год на одного человека за последние двадцать лет составляет 3000, что соответствует примерно

. Приведенные данные позволяют убедиться в справедливости правила Брукса [1]: «...трансляторы в три раза сложнее обычных прикладных программ, а операционные системы в три раза

сложнее трансляторов» |для операционных систем ;

трансляторов - ; простых приложений - до

)?

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

Модель надежности ПО, рассмотренная в п. 4.2, позволяет оценить величину отношения т/тпр. Из выражения для средней начальной наработки на отказ (проявление ошибок)

следует, что для данной программы

так как В0 зависит только от ее объема. Поэтому, если положить /н = тпр’ то Должно иметь место равенство

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

значений В§ (100...200 ошибок) 1п?0 «5, что хорошо согласуется с опытом [20], т. е.

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

Теперь можно записать:

т. е. эмпирическое правило заменяется более точным и

обоснованным, из которого следует

и

5.1.4. Практически одновременно с работами М. Холстеда в фирме IBM был предложен другой подход к метрике программ: вместо размеров (строк кода - LOC) А. Альбрехт предложил использовать количество «функций» ПО, поставляемых заказчику. Эта характеристика инвариантна относительно технологии разработки и языка программирования и в содержательном плане понятна пользователю на ранних этапах создания системы.

Данный подход основан на понятии так называемых функциональных типов, выявленных и классифицированных в процессе содержательного и статистического анализа программных продуктов различного назначения. Каждый функциональный тип (function type) в свою очередь состоит из элементарных (далее неделимых) программных единиц и называемых функциональными точками (function point, FP). Они имеют определенную (с точки зрения пользователя) семантику и

по своим размерам (количество LOC) соответствуют модулю с

$

ц2 =6...8 слов.

Ниже дано изложение основных принципов метода функциональных точек. Это способ измерения трудоемкости и производительности программирования, основанный на дифференцированном учете функциональных типов [3, 23]. Их перечень включает следующее.

  • 1. Внутренний логический файл (internel logical file, ILF), т. e. совокупность логически взаимосвязанных записей данных, поддерживаемая в приложении посредством элементарного процесса.
  • 2. Внешний интерфейсный файл (external interface file, EIF), т. e. совокупность логически взаимосвязанных данных, которыми обмениваются приложения, сами их не поддерживая.
  • 3. Входной элемент приложения (external input, EI), т. е. элементарный процесс, связанный с обработкой входных документов или экранных форм.
  • 4. Выходной элемент приложения (external output, ЕО), т. е. элементарный процесс, формирующий выходные отчеты, документы, экранные формы.
  • 5. Внешний запрос (external query, EQ), т. е. элементарный процесс типа «запрос-ответ» без вычисления или обновления базы данных.

На стадии постановок задач, используя эмпирические правила и статистические критерии, оценивают сложность всех выявленных функциональных типов по шкале «низкая», «средняя», «высокая». Далее, в соответствии с табл. 8 находят количество FP в каждом из них.

Таблица 8

Функциональный

тип

Сложность

низкая

средняя

высокая

ILF

7

10

15

EIF

5

7

10

EI

3

4

6

EO

4

5

7

EQ

3

4

6

Суммирование FP по всем функциональным типам дает общее их количество (UFP, т. е. Unadjusted Function Points) без учета поправочного коэффициента, учитывающего общую сложность проекта (VAF, т. е. Value Adjustment Factor). Он определяется перечнем 14 общих характеристик системы (GSC, т. е. Genelal System Characteristics) и вычисляется по формуле

при этом значения GSC изменяются в диапазоне от 0 до 5.

После определения всех GSC и VAF вычисляется итоговая оценка функциональных точек (Adjusted Function Points, AFP):

Наконец, для оценки трудоемкости и времени разработки может использоваться статистическая модель СОСОМОН (Constructive COst MOdel - конструктивная модель стоимости) [3].

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

 
<<   СОДЕРЖАНИЕ ПОСМОТРЕТЬ ОРИГИНАЛ   >>