Если вам доводилось руководить проектом разработки программного обеспечения (программных комплексов, информационных систем), то вы, несомненно, сталкивались с вопросом оценки трудозатрат и трудового вклада разработчиков и понимаете нетривиальность этой задачи. В отличие от большинства отраслей материального производства, в вопросах проектов создания ПО недопустимы простые подходы, основанные на умножении трудоемкости на среднюю производительность труда. Это вызвано, прежде всего, тем, что экономические показатели проекта нелинейно зависят от объема работ, а при вычислении трудоемкости допускается большая погрешность. Поэтому для решения этой задачи используются комплексные и достаточно сложные методики. К ним, в частности, относятся метрики исходного кода - метрики размера, сложности и понятности программ.
Метрики сложности программ принято разделять на четыре основные группы:
- метрики размера программ;
- метрики стилистики и понятности программ;
- метрики сложности потока управления программ;
- метрики сложности потока данных программ.
Метрики первой группы базируются на определении количественных характеристик, связанных с размером программы, и отличаются относительной простотой. К наиболее известным метрикам данной группы относятся число операторов программы, число строк исходного текста, набор метрик Холстеда. Метрики этой группы ориентированы на анализ исходного текста программ, поэтому они могут использоваться для оценки сложности промежуточных продуктов разработки.
Метрики второй группы показывают полноту комментирования исходного кода. При этом учитывается не просто число строк комментариев, а насколько плотно комментирован исходный код. Например, код сначала был документирован хорошо, затем - плохо; или так: шапка функции или класса документирована и комментирована, а код - нет. Суть метрики проста: код разбивается на n-равные куски и для каждого из них определяется коэффициент.
Метрики третьей группы базируются на анализе управляющего графа программы. Представителем данной группы является метрика Мак-Кейба. Управляющий граф программы, который используют метрики данной группы, может быть построен на основе алгоритмов модулей. В процессе автоматизированного вычисления показателя цикломатической сложности, как правило, применяется упрощенный подход, в соответствии с которым построение графа не осуществляется, а вычисление показателя производится на основании подсчета числа операторов управляющей логики (if, switch и т.д.) и возможного количества путей исполнения программы. Цикломатическое число Мак-Кейба показывает требуемое число проходов для покрытия всех контуров сильносвязанного графа или число тестовых прогонов программы, необходимых для исчерпывающего тестирования по принципу "работает каждая ветвь".
Метрики четвёртой группы базируются на оценке использования, конфигурации и размещения данных в программе. В первую очередь это касается глобальных переменных. К данной группе относятся метрики Чепина.
Здесь мы считаем необходимым заметить, что применение любых метрик должно выполнятся с учётом контекста. Другими словами, сами по себе метрики не являются законченными и универсальными средствами оценки трудоёмкости, применение которых всегда давало бы однозначный результат. Скорее, они указывают, в каком направлении необходимо провести детальный анализ. Или используются в конкретном случае, когда их применение твёрдо обосновано.
Итак, далее речь пойдёт собственно о получении отчётов по изменённым версиям исходного кода и вычислении метрик по ним. В ClearCase есть инструмент формирования отчётности - Report Builder. Он содержит ряд предустановленных отчётов, позволяет экспортировать полученные отчёты в различных форматах. Инструмент Report Builder вполне удовлетворяет потребности в начале использования ClearCase. Но со временем, рано или поздно, появится потребность расширения возможностей системы отчётности, например, понадобится получать метрики размера и сложности исходного кода.
Архитектура описываемого решения изображена на рисунке 1.
Рисунок 1. Архитектура решения
Инициацию формирования отчёта мы выполняем из контекстного меню версии каталога ClearCase. Из контекстного меню происходит запуск скрипта, выполняющего, собственно, запрос остальных входных данных (путь к каталогу уже введён - им является тот самый каталог, из контекстного меню которого запущен отчёт). Скрипт размещаем в каталоге с общим доступом, например на сервере ClearCase. Это избавит от необходимости обновления на клиентских местах в случае дальнейших доработок и изменений.
Скрипт выполняет следующие функции:
- собирает входящую информацию для отчёта (временной промежуток, метки, обозначающие базовые линии, список разработчиков);
- формирует строку запроса cleartool find для выборки нужных версий;
- производит анализ выбранных версий - описание, подсчёт числа изменённых версий, рассчитывает метрики, создаёт атрибуты со значениями полученных метрик на обработанных версиях;
- формирует результат отчёта в удобочитаемом виде (мы будем использовать формат MS Excel).
Для расчёта метрик мы используем бесплатно распространяемую утилиту сссс.exe. Для получения метрик необходимо запустить утилиту с указанием в аргументах пути к анализируемому файлу (версии элемента в нашем случае). Результат работы утилиты выводится в xml-файл.
Для создания атрибутов на элементах версионного хранилища необходимо предварительно создать типы атрибутов. Для этого переходим к списку типов версионного хранилища и открываем каталог attribute types. Создаём типы атрибутов (рисунок 2).
Рисунок 2. Создание типов атрибутов