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

314
Весьма общие данные опубликованы в виде широких диапазонов производительности труда [20]: для простых ПС – 8 SLOC (Source Lines of Code) на человек-день, и 4 SLOC на человек-день – для сложных ПС.
Там же приведены широкие диапазоны производительности труда при разработке программ на ассемблере – 60 – 500 SLOC на человеко-месяц, и 50 – 300 SLOC на человеко-месяц для языков высокого уровня. По- добные оценки можно использовать ориентировочно при первичных определениях ТЭП. Более точные оценки производительности при раз- работке программ различного размера и классов на основе обобщения статистических данных множества проектов можно получить в базовой и модифицированных моделях COCOMO [5, 6. 8, 12, 19]: для встроенных комплексов программ (систем реального времени) размером 30 тыс. строк рекомендуется для оценок использовать про- изводительность около 140 строк на человеко-месяц, а для крупных
ПС размером 500 тыс. строк предлагается значение производитель- ности около 80 строк на человеко-месяц; для программ административных систем размером 30 тыс. строк оценка производительности составляет около 200 строк на человеко- месяц, а для ПС размером 500 тыс. строк – 160 строк на человеко- месяц.
Эти данные находятся в середине приведенных выше диапазонов и их целесообразно использовать при экспертной оценке полной трудоем- кости разработки соответствующих новых ПС.
При использовании готовых повторно используемых компонентов
(ПИК) обобщенная производительность труда возрастает и зависит от доли таких компонентов в программной системе. Для такой ситуации можно использовать коэффициенты снижения трудоемкости и длитель- ности разработки за счет применения ПИК, приведенные в [12]. Эффек- тивность выделения компонентов для повторного использования зави- сит от размера создаваемой ПС и кратности возможного их применения.
При разработке ПС небольшого объема (тысячи строк исходного текста) поиск и подбор готовых компонентов для их применения в новой ПС чаще всего нерентабельно. Таким образом, существует некоторый диа- пазон размеров программных систем, для которых нецелесообразно ис- кать готовые компоненты и применять сборочное программирование из таких компонентов. Разработка на базе ПИК становится особенно рен- табельной для сложных ПС, содержащих сотни или тысячи модулей
(100 – 1000 тыс. строк текста).
В исследованиях по программе ПРОМЕТЕЙ [12] при разработке ПС класса СРВ, преимущественно на ассемблере, получена производитель- ность 60 – 80 строк на человеко-месяц. Для относительно небольших комплексов программ административных систем (в значительной сте- пени на языках высокого уровня) производительность составила около
260 строк на человека-месяц. Таким образом, в зависимости от характе- ристик объекта и условий разработки возможен экспертный выбор ве- личин производительности труда для последующего прогноза полной трудоемкости создания ПС.

315
Эти данные можно использовать для оценки полной стоимости про- екта конкретной ПС. При этом, однако, необходимы данные удельных стоимостей труда одного человеко-месяца специалистов в конкретном предприятии с учетом всех накладных расходов, которые могут разли- чаться в несколько раз. Такие сведения обычно являются коммерческой тайной, и при использовании данной методики для определенного про- екта ПС их следует запрашивать у экономических служб конкретного предприятия. Тем не менее, опубликованы ориентиры стоимости разра- ботки одной строки текста программ реального времени – коло 100$ и более, а для административных систем около 20 – 50$.
Экспертная оценка длительности разработки сложных ПС может ба- зироваться на экспериментальных графиках, разработанных Липаевым
В.В. [12], а также на различных моделях, из которых наиболее распро- страненная – COCOMO (Constructive Cost Model) [6, 8, 19]. Основой для расчета длительности является рассчитанная трудоемкость разработки проекта ПС, от которой нелинейно зависит длительность разработки.
Например, крупные проекты ПС реального времени размером 500 тыс. строк требуют реализации около трех с половиной лет. Небольшие про- екты, размером 30 тыс. строк – примерно один год. Полная длитель- ность разработки ПС может быть структурирована на затраты по техно- логическим этапам с использованием экспериментальных таблиц и гра- фиков, приведенных в [12].
Экспертная оценка необходимого числа специалистов рассчитывает- ся путем деления полной трудоемкости разработки ПС на длительность ее реализации. Для примера крупного проекта ПС реального времени, размером в 500 тыс. строк, необходимое число специалистов достигает
160 человек, а для относительно небольшого проекта в 30 тыс. строк – в десять раз меньше – 16 человек. Аналогично можно получить оценки необходимого числа специалистов на выделенных крупных этапах раз- работки ПС, что полезно для первичного формирования коллектива и оценки возможности реализации им конкретного проекта ПС.
На основе анализа результатов и оценивания рассчитанных характе- ристик следует выполнить заключительное технико-экономическое обоснование проекта ПС и определить целесообразность продолжения работ над проектом. Если окажется, что имеющихся ресурсов, специа- листов и времени недостаточно или трудоемкость разработки чрезмерно велика, проект следует прекратить. В противном случае следует провес- ти маркетинговое исследование для определения рентабельности полно- го выполнения проекта ПС и создания программного продукта для по- ставки на рынок.

316 оценка – это количество строк в программном продукте [8, 15, 17, 19].
Результаты, получаемые на основе количества строк кода, бывают за- частую противоречивыми, особенно когда их применяют некорректно.
Эксперименты многократно подтвердили тот факт, что данная метрика хорошо коррелирует с трудозатратами – программы с большим количе- ством строк кода требуют больше времени на разработку. Поэтому, применение этой метрики в процессе оценки трудозатрат представляет- ся оправданным. Однако, корреляция с функциональностью уже не столь явная. Опытные программисты, как правило, предпочитают пи- сать меньше кода, достигая того же самого результата. И если при оцен- ке производительности достаточно большой команды разница в классе разработчиков может нивелироваться, то применение этой метрики для оценки производительности индивидуума представляется неадекват- ным.
Сравнительно недавно появился ещё один аспект данной проблемы – разница между программным кодом, написанным вручную, и сгенери- рованным автоматически. Современные средства разработки предостав- ляют возможность автоматически создавать большие объёмы кода не- сколькими кликами мыши. Ярким представителем данных систем явля- ются средства визуальной разработки графического пользовательского интерфейса. Объём работы, затраченный при создании такого кода, не может сравниваться с объёмом работы, например, по написанию драй- вера устройства. С другой стороны, может оказаться, что на написание вручную специализированного компонента пользовательского интер- фейса со сложным поведением времени может быть потрачено гораздо больше, чем на простой драйвер.
Размер одной и той же программы, написанной на разных языках программирования, может существенно варьироваться. В приведённом ниже примере сравнивается программа «Hello world» на языках С и
COBOL (известный своей «многословностью»).
C
COBOL
#include int main(void) { printf("Hello
World"); return 0;
}
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300 000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900 001000 DATA DIVISION.
001100 FILE SECTION.
001200 100000 PROCEDURE DIVISION.
100100 100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 PO-

317
SITION 1 ERASE EOS.
100500 DISPLAY "Hello world!"
LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
Строк кода: 5
(исключая пустые)
Строк кода: 17
(исключая пустые)
Обычно исходные данные для расчета этих метрик сводятся в табли- цу (табл. 7.1).
Таблица 7.1
Представление метрик для расчета показателей программных проектов
Проект Затраты, чел.-мес
Стоимость, тыс. $
KLOC, тыс. LOC
Прогр. док- ты, стра- ниц
Ошибки Люди ааа01 24 168 12,1 365 29 3 bbb02 62 440 27,2 1224 86 5 ссс03 43 314 20,2 1050 64 6
Таблица содержит данные о проектах за последние несколько лет.
Например, запись о проекте aaa01 показывает: 12 100 строк программы были разработаны за 24 человеко-месяца и стоили $168 000. Кроме того, по проекту aaa01 было разработано 365 страниц документации, а в те- чение первого года эксплуатации было зарегистрировано 29 ошибок.
Разрабатывали проект aaa01 три человека. На основе таблицы вычисля- ются размерно-ориентированные метрики производительности и каче- ства (для каждого проекта):
Производительность = Длина/Затраты [тыс. LOC/чел.-мес.];
Качество = Ошибки/Длина [Единиц/ тыс. LOC];
Удельная стоимость = Стоимость/ Длина [Тыс.$/ тыс. LOC];
Документированность = Страниц документа/Длина [Страниц/ тыс.
LOC].
Таким образом, достоинствами размерно-ориентированных метрик являются широкое распространение, простота и легкость вычисления.
Недостатками размерно-ориентированных метрик является зависимость от языка программирования, трудность получения исходных данных на начальной стадии проекта, не приспособленность к непроцедурным языкам программирования.
7.3.2. Функционально-ориентированные метрики
Функционально-ориентированные метрики косвенно измеряют про- граммный продукт и процесс его разработки. Вместо подсчета LOC-

318 оценки при этом рассматривается не размер, а функциональность или полезность продукта [3, 6, 19].
Используется 5 информационных характеристик:
1. Количество внешних вводов. Подсчитываются все вводы пользо- вателя, по которым поступают разные прикладные данные. Вводы должны быть отделены от запросов, которые подсчитываются отдельно.
2. Количество внешних выводов. Подсчитываются все выводы, по которым к пользователю поступают результаты, вычисленные про- граммным приложением. В этом контексте выводы означают отчеты, экраны, распечатки, сообщения об ошибках. Индивидуальные единицы данных внутри отчета отдельно не подсчитываются.
3. Количество внешних запросов. Под запросом понимается диало- говый ввод, который приводит к немедленному программному ответу в форме диалогового вывода. При этом диалоговый ввод в приложении не сохраняется, а диалоговый вывод не требует выполнения вычислений.
Подсчитываются все запросы – каждый учитывается отдельно.
4. Количество внутренних логических файлов. Подсчитываются все логические файлы (то есть логические группы данных, которые могут быть частью базы данных или отдельным файлом).
5. Количество внешних интерфейсных файлов. Подсчитываются все логические файлы из других приложений, на которые ссылается данное приложение.
Вводы, выводы и запросы относят к категории транзакция. Транзак- ция – это элементарный процесс, различаемый пользователем и пере- мещающий данные между внешней средой и программным приложени- ем. В своей работе транзакции используют внутренние и внешние фай- лы. Приняты следующие определения.
Внешний ввод – элементарный процесс, перемещающий данные из внешней среды в приложение. Данные могут поступать с экрана ввода или из другого приложения. Данные могут использоваться для обновле- ния внутренних логических файлов. Данные могут содержать как управляющую, так и деловую информацию. Управляющие данные не должны модифицировать внутренний логический файл.
Внешний вывод – элементарный процесс, перемещающий данные, вычисленные в приложении, во внешнюю среду. Кроме того, в этом процессе могут обновляться внутренние логические файлы. Данные создают отчеты или выходные файлы, посылаемые другим приложени- ям. Отчеты и файлы создаются на основе внутренних логических фай- лов и внешних интерфейсных файлов. Дополнительно этот процесс мо- жет использовать вводимые данные, их образуют критерии поиска и параметры, не поддерживаемые внутренними логическими файлами.
Вводимые данные поступают извне, но носят временный характер и не сохраняются во внутреннем логическом файле.
Внешний запрос – элементарный процесс, работающий как с вводи- мыми, так и с выводимыми данными. Его результат — данные, возвра- щаемые из внутренних логических файлов и внешних интерфейсных файлов. Входная часть процесса не модифицирует внутренние логиче-

319 ские файлы, а выходная часть не несет данных, вычисляемых приложе- нием (в этом и состоит отличие запроса от вывода).
Внутренний логический файл – распознаваемая пользователем груп- па логически связанных данных, которая размещена внутри приложения и обслуживается через внешние вводы.
Внешний интерфейсный файл – распознаваемая пользователем группа логически связанных данных, которая размещена внутри другого приложения и поддерживается им. Внешний файл данного приложения является внутренним логическим файлом в другом приложении.
Каждой из выявленных характеристик ставится в соответствие сложность. Для этого характеристике назначается низкий, средний или высокий ранг, а затем формируется числовая оценка ранга. Для тран- закций ранжирование основано на количестве ссылок на файлы и коли- честве типов элементов данных. Для файлов ранжирование основано на количестве типов элементов-записей и типов элементов данных, входя- щих в файл.
Тип элемента-записи – подгруппа элементов данных, распознаваемая пользователем в пределах файла.
Тип элемента данных – уникальное не рекурсивное (неповторяемое) поле, распознаваемое пользователем.
Примеры элементов данных для различных характеристик приведе- ны в табл. 7.2, а табл. 7.3 содержит правила учета элементов данных из графического интерфейса пользователя (GUI).
Таблица 7.2
Элементы данных для расчета информационных характеристик
Информацион-
ная характери-
стика
Элементы данных
Внешние Вводы
Внешние Выво- ды
Внешние Запро- сы
Поля ввода данных, сообщения об ошибках, вычисляемые значения, кнопки
Поля данных в отчетах, вычисляемые значения, сообщения об ошибках, заголовки столбцов, которые читаются из внут- реннего файла
Вводимые элементы: поле, используемое для поиска, щелчок мыши. Выводимые элементы – отображаемые на экране по- ля
Таблица 7.3
Правила учета элементов данных для расчета
информационных характеристик
Элемент данных
Правило учета
Группа радиокнопок
Группа флажков
(переключателей)
Так как в группе пользователь выбирает только одну радиокнопку, все радиокнопки группы считаются одним элементом данных
Так как в группе пользователь может выбрать несколько флажков, каждый флажок считают элементом данных