Рубрики

Свежие записи

Отчётность IBM Rational ClearCase: модуль формирования отчётов с вычислением метрик размера и сложности программ

GD Star Rating
loading...
GD Star Rating
loading...




И снова о метриках… Это третий материал по метрикам, опубликованный в блоге. На этот раз написанный в соавторстве и опубликованный на русскоязычном сайте IBM и на сайте нашей компании СМ-Консалт.

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

(с) Блог Новичкова А.Н. – anovichkov.msk.ru

Александр Новичков, руководитель отдела внедрения и консалтинга, СМ-Консалт

Рустам Зайдуллин, ведущий инженер, «ТатАСУнефть» ОАО «Татнефть»

Метрики сложности программ принято разделять на три основные группы:

  • метрики размера программ;
  • метрики стилистики и понятности программ;
  • метрики сложности потока управления программ;
  • метрики сложности потока данных программ.

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

Метрики второй группы показывают полноту комментирования исходного кода. Причём, учитывается не просто количество строк комментариев, а насколько плотно комментирован исходный код . То есть код сначала был документирован хорошо, затем – плохо. Или, например, так — шапка функции или класса документирована и комментирована, а код нет. Суть метрики проста: код разбивается на n-равные куски и для каждого из них определяется коэффициент

Метрики третьей группы базируются на анализе управляющего графа программы. Представителем данной группы является метрика Мак-Кейба. Управляющий граф программы, который используют метрики данной группы, может быть построен на основе алгоритмов модулей. В процессе автоматизированного вычисления показателя цикломатической сложности, как правило, применяется упрощенный подход, в соответствии с которым построение графа не осуществляется, а вычисление показателя производится на основании подсчета числа операторов управляющей логики (if, switch и т.д.) и возможного количества путей исполнения программы. Цикломатическое число Мак-Кейба показывает требуемое количество проходов для покрытия всех контуров сильносвязанного графа или количества тестовых прогонов программы, необходимых для исчерпывающего тестирования по принципу «работает каждая ветвь».

Метрики четвёртой группы базируются на оценке использования, конфигурации и размещения данных в программе. В первую очередь это касается глобальных переменных. К данной группе относятся метрики Чепина.

Здесь мы считаем необходимым заметить, что применение любых метрик должно выполнятся с учётом контекста. То есть сами по себе метрики не являются законченными и универсальными средствами оценки трудоёмкости, применение которых всегда давало бы однозначный результат. Скорее, они указывают, в каком направлении необходимо провести детальный анализ. Или используются в конкретном случае, когда их применение твёрдо обосновано.

Итак, далее речь пойдёт, собственно, о получении отчётов по изменённым версиям исходного кода, и вычислении метрик по ним. В ClearCase есть инструмент формирования отчётности – Report Builder. Он содержит ряд предустановленных отчётов, позволяет экспортировать полученные отчёты в различных форматах. Инструмент Report Builder вполне удовлетворяет потребности в начале использования ClearCase. Но со временем, рано или поздно, появляется потребность расширения возможностей системы отчётности. Например, получать метрики размера и сложности исходного кода.

Архитектура описываемого решения изображена на Рисунке 1.


Рисунок 1 – Архитектура решения

Инициацию формирования отчёта мы выполняем из контекстного меню версии каталога ClearCase. Из контекстного меню происходит запуск скрипта, выполняющего, собственно, запрос остальных входных данных (путь к каталогу уже введён – им является тот самый каталог, из контекстного меню которого запущен отчёт). Скрипт размещаем в каталоге с общим доступом, например – на сервере ClearCase. Это избавит от необходимости обновления на клиентских местах в случае дальнейших доработок и изменений.

Скрипт выполняет следующие функции:

  • собирает входящую информацию для отчёта (временной промежуток, метки, обозначающие базовые линии, список разработчиков);
  • формирует строку запроса cleartool find для выборки нужных версий
  • производит анализ выбранных версий – описание, подсчёт количества изменённых версий, рассчитывает метрики, создаёт атрибуты со значениями полученных метрик на обработанных версиях;
  • формирует результат отчёта в удобочитаемом виде (мы будем использовать формат MS Excel).

Для расчёта метрик мы используем бесплатно распространяемую утилиту сссс.exe. Для получения метрик необходимо запустить утилиту с указанием в аргументах пути к анализируемому файлу (версии элемента в нашем случае). Результат работы утилиты выводится в xml-файл.

Для создания атрибутов на элементах версионного хранилища, необходимо предварительно создать типы атрибутов. Для этого переходим к списку типов версионного хранилища и открываем каталог attribute types. Создаём типы атрибутов (Рисунок 2).


Рисунок 2 – Создание типов атрибутов

Тип значения по-умолчанию задаётся Integer, для метрики L_C необходимо указать тип Real (Рисунок 3).


Рисунок 3 – Меняем тип данных значения атрибута

После того, как типы атрибутов сформированы, можно создавать сами атрибуты на версиях элементов версионного хранилища (Рисунок 4).


Рисунок 4 – Типы атрибутов для метрик

Итак, по порядку. Сначала необходимо определить дату отчётного периода. За окончание периода примем текущую дату, а начало периода введёт пользователь. Для ввода данных используем интерфейс clearprompt. Можно было бы запросить дату одной строкой, но во избежание ввода некорректной даты (ошибок в формате ввода, или ввода даты позднее текущей) организуем ввод в графическом интерфейсе, из списка. Запрашиваем дату в следующей последовательности – год, месяц, день. Для начала, определим текущую дату.

use Time::localtime;

use Time::tm;

$tm = localtime;

$cyear = $tm->year+1900;

$cmon = $tm->mon+1;

$cday = $tm->mday;

$chour = $tm->hour;

$cminutes = $tm->min;

$cdato=»$cday-$cmon-$cyear.$chour:$cminutes»;

Составляем список годов, из которых будет производиться выбор. Начало периода – год создания версионного хранилища.

for ($y = 2005; $y < $cyear+1; $y++)

{

$years=»$years,$y»;

};

$years=substr($years,1,length($years));

Далее запрашиваем выбор года отчётного периода и считываем введённое значение. В случае нажатия кнопки «Отмена» завершаем работу скрипта, при вводе пустого значения – запрашиваем ввод даных вновь.

prompty: $lab=system(«clearprompt list -outfile date -items \»$years\» -prompt \»Выберите год начала периода (дд-мм-гггг)\»");

if ($lab != 0)

{

Win32::MsgBox(«Операция прервана пользователем»);

exit(1);

};

open(FL, «date») || die «Can’t open file \n»;

$i=0;

while (<FL>)

{

@pas[$i]=split(FL);

$i=$i+1;

};

close FL;

$year=$pas[0];

if ($year eq «»)

{

goto prompty ;

}

else

{

chop($year);

};

@pas[0]=»";

Описанное диалоговое окно имеет следующий вид:


Рисунок 5 — Диалог ввода даты

Сразу выполняем проверку, является ли введённый год високосным. Эта информация будет нужна далее, при выводе диалога выбора дня текущего периода.

@mdays = qw(31 28 31 30 31 30 31 31 30 31 30 31);

if (($year % 4) == 0)

{

if ($year % 100 != 0)

{

$mdays[1] = 29;

}

elsif ($year % 400 == 0)

{

$mdays[1] = 29;

}

};

Далее выводим диалог выбора месяца отчётного периода. Если ранее был введён текущий год – выводим список месяцев включительно текущий.

promptm: @mons=(‘january’,'february’,'march’,'april’,'may’,'june’,'july’,'august’,'september’,'october’,'november’,'december’);

$monses=»";

if ($year == $cyear)

{

$#mons=$cmon-1;

};

foreach $mons (@mons)

{

$monses=$monses.$mons.»,»;

};

chop($monses);

$lab=system(«clearprompt list -outfile date -items \»$monses\» -prompt \»Выберите месяц начала периода (дд-мм-$year)\»");

if ($lab != 0)

{

Win32::MsgBox(«Операция прервана пользователем»);

exit(1);

};


Рисунок 6 — Диалог ввода даты

Далее таким же образом считываем введённое значение из файла. Затем по выбранному месяцу определяем количество дней в месяце

if ($mon eq «january»)

{

$days=@mdays[0]; $imon=1;

}

elsif ($mon eq «february»)

{

$days=@mdays[1]; $imon=2;

}

elsif ($mon eq «march»)

{

$days=@mdays[2]; $imon=3;

}

elsif ($mon eq «april»)

{

$days=@mdays[3]; $imon=4;

}

elsif ($mon eq «may»)

{

$days=@mdays[4]; $imon=5;

}

elsif ($mon eq «june»)

{

$days=@mdays[5]; $imon=6;

}

elsif ($mon eq «july»)

{

$days=@mdays[6]; $imon=7;

}

elsif ($mon eq «august»)

{

$days=@mdays[7]; $imon=8;

}

elsif ($mon eq «september»)

{

$days=@mdays[8]; $imon=9;

}

elsif ($mon eq «october»)

{

$days=@mdays[9]; $imon=10;

}

elsif ($mon eq «november»)

{

$days=@mdays[10]; $imon=11;

}

elsif ($mon eq «december»)

{

$days=@mdays[11]; $imon=12;

};

После этого запрашиваем день отчётного периода. Если ранее были введены текущие год и месяц – ограничиваем список текущим днём.

if (($year == $cyear) && ($imon == $cmon))

{

for ($d = 1; $d < $cday+1; $d++)

{

$dayso=»$dayso,$d»;

};

$dayso=substr($dayso,1,length($dayso));

}

else

{

for ($d = 1; $d < $days+1; $d++)

{

$dayso=»$dayso,$d»;

};

$dayso=substr($dayso,1,length($dayso));

};

Форма этого диалога выглядит следующим образом


Рисунок 7 – Диалог ввода даты

После считывания из файла введённого значения дня начала отчётного периода, формируем строки даты. Одну из них создаём со словесным обозначением месяца (например, «april»"), другую – с числовым (соответственно, «4″). Далее пригодятся оба варианта.

Дата отчётного периода определена. Кроме этого, мы хотим видеть изменения в разрезе по разработчикам, которые создали эти новые версии. Для этого необходимо передать скрипту с входными параметрами список разработчиков, по которым производится анализ. Здесь мы не будем выводить дополнительные формы, а поступим проще, и, на наш взгляд, эффективнее. Передачу списка персоналий проекта, по которым производится анализ, производим, как и путь к анализируемому каталогу, из самого контекстного меню – Рисунок 8.


Рисунок 8 – Контекстное меню ClearCase с внесёнными дополнениями

Настройки пункта «Отчёт по группе интеграции» контекстного меню приведены на следующем рисунке. По второму аргументу — «integr» – скрипт определит имя файла со списком персоналий (Рисунок 9).


Рисунок 9 – Настройка контекстного меню

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

$otdel = $ARGV[1];

$path = «\\\\clearcase\\addins\\context_menu\\reports\\»;

$file=$path.$otdel.».txt»;

open(FL, $file) || die «Can’t open file \n»;

$i=0;

while (<FL>)

{

@users[$i]=split(FL);

$i=$i+1;

};

close FL;

Теперь вся информация для поиска версий подготовлена, и остаётся выполнить запрос, получить выборку нужных версий, и рассчитать для них метрики. Для расчета метрик мы используем бесплатно распространяемую утилиту cccc.exe. Чтобы получить метрики по исходному коду, необходимо запустить утилиту с путём к файлу, содержащему исходный код. В нашем случае, это будет путь к версии элемента версионного хранилища.

Остаётся выполнить еще одно подготовительное действие. Так как результат мы хотим получить в таблицу MS Excel, нужно инициировать для этого новую книгу.

Добавим библиотеки работы с OLE-объектами, и с объектами MS-Excel в заголовок скрипта.

use Win32;

use Win32::OLE;

use Win32::OLE::Const ‘Microsoft Excel’;

Ловим открытое приложение MS Excel, если таковое имеется, в противном случае создаём новое. Создаём новую книгу

$Excel = Win32::OLE->GetActiveObject(‘Excel.Application’) || Win32::OLE->new(‘Excel.Application’);

$Excel->{Visible} = 1;

$Book = $Excel->Workbooks->Add;

$Sheet = $Book->Worksheets(1);

Запишем в файл заголовок – название отчёта, и шапку формируемой таблицы

$Sheet->Range(«A1″)->{Value} = «Отчёт за период с $idato по $cdato в каталоге $where»;

$Sheet->Range(«A2″)->{Value} = «Разработчик»;

$Sheet->Range(«B2″)->{Value} = «Версия файла»;

$Sheet->Range(«C2″)->{Value} = «LOC»;

$Sheet->Range(«D2″)->{Value} = «MVG»;

$Sheet->Range(«F2″)->{Value} = «L_C»;

$row=2;

Далее описана процедура, которая ищет по заданным критериям версии и рассчитывает для них метрики. Здесь мы должны сделать небольшое отступление, так как на этом этапе возникает вопрос обработки файлов формата XML. Скрипт, который мы пишем, будет выполняться встроенным в ClearCase языком Perl — ccperl. В поставку ccperl не включены распространённые библиотеки для обработки XML – XML::SAX и XML::Parser. Данные модули являются свободно распространяемыми, найти их можно на сайте CPAN. Там же находятся инструкции по установке дополнительных модулей, сведения о зависимых модулях и вся необходимая информация. Но при установке дополнительных модулей в ccperl возникают проблемы. Можно использовать обычный Perl, но в этом случае возникает необходимость установки его на все рабочие станции, на которых будет выполняться скрипт. Другой вариант – самостоятельно описать анализ XML-файла в скрипте, который, собственно, по своему содержанию является обычным текстовым файлом. В данном примере мы поступим именно таким образом.

Для начала проанализируем файл с исходным кодом и посмотрим, что собственно, выдаст нам утилита. Для этого выбираем файл, и выполняем строку cccc.exe <путь_к_файлу>. Для того, чтобы не запускать используемую утилиту без указания полного пути к ней, мы прописали этот путь в переменную среды окружения PATH. Утилита формирует несколько файлов, нас интересует файл с именем анализируемого файла и расширением XML. Нас интересуют следующие метрики – количество строк кода (LOC), метрика цикломатической сложности по Мак-Кейбу для всей программы (MVG), и метрика качества комментирования программы – отношение количества строк кода к количеству строк комментариев (L_C). Ниже приведён фрагмент полученного XML-файла, упомянутые метрики выделены маркером.

  1. <?xml version=»1.0″ encoding=»utf-8″?>
  2. <!—Detailed report on module BackingBean—>
  3. <CCCC_Project>
  4. <module_summary>
  5. <lines_of_code value=»425″ level=»0″ />
  6. <lines_of_code_per_member_function value=»******» level=»0″ />
  7. <McCabes_cyclomatic_complexity value=»18″ level=»0″ />
  8. <McCabes_cyclomatic_complexity_per_member_function value=»******» level=»2″ />
  9. <lines_of_code value=»112″ level=»0″ />
  10. <lines_of_code_per_member_function value=»********» level=»2″ />
  11. <lines_of_code_per_line_of_comment value=»3.795″ level=»0″ />
  12. <McCabes_cyclomatic_complexity_per_line_of_comment value=»0.161″ level=»0″ />
  13. <weighted_methods_per_class_unity value=»13″ level=»0″ />
  14. <weighted_methods_per_class_visibility value=»0″ level=»0″ />
  15. <depth_of_inheritance_tree value=»0″ level=»0″ />
  16. <number_of_children value=»0″ level=»0″ />
  17. <coupling_between_objects value=»8″ level=»0″ />
  18. <IF4 value=»0″ level=»0″ />
  19. <IF4_per_member_function value=»********» level=»0″ />
  20. <IF4_visible value=»0″ level=»0″ />
  21. <IF4_visible_per_member_function value=»********» level=»0″ />
  22. <IF4_concrete value=»0″ level=»0″ />
  23. <IF4_concrete_per_member_function value=»********» level=»0″ />
  24. </module_summary>

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

    foreach $user (@users)

    {

    chop($user);

    $row++;

    $Sheet->Range(«A$row»)->{Value} = $user;

    DoCommand(«cleartool find . -name \»*.java\» -version \»created_since(25-march-2007)&&
    created_by($user)\» -print»);

    $row++;

    };

    Мы записали в таблицу имя разработчика, и выполняем поиск в выбранном каталоге версионного хранилища ClearCase версий созданных данным специалистом в течение указанного срока. Поиск выполняется описанной ниже процедурой, она же анализирует полученный результат и записывает его в созданную книгу MS Excel.

    sub DoCommand

    {

    my $cmd = shift;

    $count=0;

    my $line;

    open(CMD, «$cmd 2>&1 |»);

    foreach $line (<CMD>)

    Мы выполнили поиск, и перехватываем результат из консоли в переменную $line. Обрабатываем полученное значение

    {

    chop($line);

    $end = substr ($line, length($line)-2, length($line));

    if ($end ne «\\0″)

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

    {

    $tmpname = substr ($line, 0, index($line, «@@»));

    В переменной $tmpname мы сформировали стандартное имя файла, то есть завершающееся расширением. Используемая в примере утилита расчета метрик не может оперировать названиями файлов, содержащими полный путь ClearCase – то есть, названиями версий.

    system(«cleartool co -unr -nc -version $line «);

    system («cccc.exe \»$tmpname\» —xml_outfile=c:\\temp\\cccc\\tmp.xml —outdir=c:\\temp\\cccc»);

    Мы выполнили операцию CheckOut для обрабатываемой версии, чтобы увидеть её в текущем представлении ClearCase, и вычисляем метрики. Операция CheckOut выполняется без резервирования версии – на тот случай, если в настоящее время кто-то работает с данным элементом. Результат сохраняется во временном файле – c:\temp\cccc\tmp.xls

    open(FL, «c:\\temp\\cccc\\tmp.xml») || die «Can’t open file \n»;

    $i=1;

    while (<FL>)

    {

    @lines[$i]=split(FL);

    $i=$i+1;

    };

    close FL;

    Содержимое файла считано в массив построчно. Далее, находим в нужных нам строках значения метрик (см. выше).

    $LOC=substr(@lines[5],index(@lines[5],»=\»")+2,index(@lines[5],»\» level»)-index(@lines[5],»=\»")-1);

    $MVG=substr(@lines[7],index(@lines[7],»=\»")+2,index(@lines[7],»\» level»)-index(@lines[7],»=\»")-1);

    $L_C=substr(@lines[11],index(@lines[11],»=\»")+2,index(@lines[11],»\» level»)-index(@lines[11],»=\»")-1);

    Значения метрик записаны в переменные, и нам остаётся только сохранить полученные результаты в таблицу. Записываем название версии (здесь – полное имя, включая номер версии), и вычисленные метрики.

    $Sheet->Range(«B$row»)->{Value} = $line;

    $Sheet->Range(«C$row»)->{Value} = $LOC;

    $Sheet->Range(«D$row»)->{Value} = $MVG;

    $Sheet->Range(«E$row»)->{Value} = $L_C;

    Далее отменяем CheckOut, создаём на версии атрибуты, содержащие соответствующие значения метрик и добавляем приращение к переменной указателя строки таблицы.

    system(«cleartool unco -rm $line «);


    system(«cleartool mkattr LOC $LOC \»$line \»");

    system(«cleartool mkattr MVG $MVG \»$line \»");

    system(«cleartool mkattr L_C $L_C \»$line \»");

    $row++;

    };

    }

    close CMD;

    }

    Результат работы скрипта представлен ниже в таблице. После завершения работы скрипта книга MS Excel остаётся открытой, для дальнейшей работы. Можно настроить сохранение сформированной таблицы и рассылку по электронной почте – как угодно, в зависимости от потребностей.

    Таблица 1- Результат работы скрипта

    Разработчик Версия файла LOC MVG L_C
    pavel .\controller\BackingBean.java@@\main\dev\12

    428

    16

    3.927

    .\controller\BackingBean.java@@\main\dev\11

    439

    19

    3.658

    .\controller\BackingBean.java@@\main\dev\10

    439

    19

    3.658

    .\controller\BackingBean.java@@\main\dev\9

    435

    19

    3.884

    .\controller\BackingBean.java@@\main\dev\8

    435

    19

    3.884

    .\controller\BackingBean.java@@\main\dev\7

    425

    18

    3.795

    .\controller\Mail.java@@\main\dev\4

    338

    37

    5.541

    .\controller\Mail.java@@\main\dev\3

    320

    37

    5.246

    .\controller\Mail.java@@\main\dev\2

    316

    36

    5.097

    .\controller\Mail.java@@\main\dev\1

    314

    36

    4.906

    .\controller\MenuSearch.java@@\main\dev\3

    109

    18

    5.737

    andrey .\controller\ShuttleAuthCheck.java@@\main\dev\4

    93

    11

    3.207

    .\controller\ShuttleAuthCheck.java@@\main\dev\3

    93

    11

    3.207

    .\controller\ShuttleAuthCheck.java@@\main\dev\2

    94

    11

    3.357

    .\model\KEntity.java@@\main\dev\2

    205

    33

    8.542

    .\ProcessThread.java@@\main\dev\6

    49

    1

    3.500

    .\ProcessThread.java@@\main\dev\5

    48

    1

    16.000

    .\servlet\Crystal.java@@\main\dev\5

    545

    31

    3.893

    .\servlet\Crystal.java@@\main\dev\4

    545

    31

    3.865

    .\servlet\Crystal.java@@\main\dev\3

    535

    29

    3.794

    .\servlet\SecurityFilter.java@@\main\dev\9

    65

    10

    9.286

    .\servlet\SecurityFilter.java@@\main\dev\8

    65

    10

    9.286

    На Рисунке 10 – отображение на дереве версий атрибутов с метками. В дальнейшем при анализе метрики могут быть считаны из атрибутов.


    Рисунок 10 – Дерево версий с атрибутами

    Так же, может быть интересен результат сравнения исходных кодов по метрикам в различных потоках разработки. Например, в случае, когда ведётся совместная работа нескольких подразделений, или, например, к проекту привлечён субподрядчик, и разрабатываемые им исходные коды хранятся в отдельном потоке версионного хранилища. Причём, в этом случае, анализ в разрезе версий, созданных каждым отдельным разработчиком, скорее всего уже не интересен (хотя если нужно получить информацию и с учётом вклада каждого из разработчиков – ничто этому не препятствует, это будет означать всего лишь добавление второго вложенного цикла). Если мы рассматриваем первый вариант – то просто заменяем в критериях поиска привязку к имени пользователя на параметр – название потока разработки. То есть строка принимает следующий вид:

    cleartool find . -name \»*.java\» -version \»created_since(25-march-2007)&&
    brtype($branch)\» –print

    Так же, для удобочитаемости скрипта, массив @users везде по тексту скрипта заменяем на @branches.

    Полученные данные можно далее интерпретировать средствами самого инструмента MS Excel. Например, строить диаграммы (Рисунок 11, 12).


    Рисунок 11 – Диаграмма изменения метрики LOC


    Рисунок 12 — Диаграмма изменения метрики MVG

    Как мы видим, диаграммы на рисунках 11 и 12 коррелируются – был дописан определённый код, причем именно в плане усложнения логики выполнения модуля, но в дальнейшем были внесены корректировки, после которых исполняемый код сократился, но сложность логики по сравнению с начальным состоянием усложнилась. Можно сделать вывод, что на данном этапе было произведено расширение модуля с последующей оптимизацией.

    Метрики, полученные с разных потоков разработки, так же очень удобно просматривать в графическом виде. На рисунке 13 – сравнение метрики количества строк исполняемого кода для версий, найденных на потоках разработки dev и sub.


    Рисунок 13 – Диаграмма сравнения метрики LOC для двух потоков разработки

    Подведём итог — плюсы решения очевидны – нет необходимости запускать отдельное приложение для создания отчёта, интересующий фрагмент исходного кода подвергается анализу непосредственно из браузера ClearCase Explorer. В стандартных отчётах Report Builder нет возможности формирования отчёта по группе разработчиков, хотя зачастую потребность такая возникает. В описанном решении она реализована (собственно, это и послужило толчком к разработке собственной системы отчётности). Централизованное хранение скрипта избавляет от необходимости обновления модуля отчётности на клиентских местах в случае его изменения. Навыки программирования на Perl позволяют получить практически любые отчёты, а так же внести дополнения в сам процесс.

    Об авторах:

    Новичков Александр работает в области информационных технологий с 1994 года. Является руководителем отдела консалтинга и внедрения IBM Rational. Участвовал более чем в 20 успешных проектах внедрения IBM Rational в таких организациях как Банк внешней торговли, ОАО «Татнефть», Национальный банк «ТРАСТ», Банк «Русский стандарт», ОАО «Иркут Авиа», ЗАО «АйТи», ЗАО «Аплана», Сбербанк России, Центральный банк Российской Федерации, ОАО «Русский алюминий» и многих других. Имеет более 30 публикаций научных и научно-популярных материалов. Является сертифицированным специалистом по следующим продуктам IBM Rational: ClearCase for Windows, ClearQuest for Windows и UCM Essentials. За время работы в консалтинге им обучено более 500 специалистов ведущих IT-компаний России и СНГ. Является руководителем отдела внедрения и консалтинга в компании СМ-Консалт (www.cmcons.com).

    Зайдуллин Рустам работает в области информационных технологий с 2005 года. Имеет опыт адаптации и внедрения RUP и инструментальных средств IBM Rational. Сертифицированный специалист по следующим продуктам и направлениям: IBM Rational ClearCase, Requirements Management with Use Cases, Rational Unified Process, Microsoft Project 2003. Является ведущим инженером группы контроля качества процессов разработки программного обеспечения управления «ТатАСУнефть» ОАО «Татнефть».

    Использованные источники и ресурсы:

    http://www.ibm.com/developerworks/ru/edu/dw-0108novich-i.html/

    http://cccc.sourceforge.net/

    http://cmcons.com/

Отчётность IBM Rational ClearCase: модуль формирования отчётов с вычислением метрик размера и сложности программ, 10.0 out of 10 based on 3 ratings

Связные и просто интересные записи:

Метки:clearcase, ibm, loc, rational, sloc, джилб, код, маккейб, метрики, программа, программирование, сложность, цикломатичность, чепин

6 comments to Отчётность IBM Rational ClearCase: модуль формирования отчётов с вычислением метрик размера и сложности программ

  • User

    Clearcase позволяет эффективно загубить проект. IBM продают его а сами сидят на SVN.

    GD Star Rating
    loading...
    GD Star Rating
    loading...
    • Отнесусь как к новогодней шутке. Интересно, а откуда такие «осведомленные» познания, как в области пагубности СС, так и про IBM.
      Давай, чтоль, ссылки на первоисточники :)

      GD Star Rating
      loading...
      GD Star Rating
      loading...
  • User

    Насчет СС — научен горьким опытом (нашу фирму купили и навязали нам СС — после чего проект быстро загнулся, не без помощи СС т.к последний не позволяет эффективно работать), а про IBM знакомые рассказывали (кто работал там).
    А мое личное мнение — по сравнению с SVN конкуренты рядом не стояли, а СС — это хучший из них.
    Давно хотел высказать то что наболело.

    GD Star Rating
    loading...
    GD Star Rating
    loading...
    • Голословное утверждение. Если вы в состоянии описать что и как произошло, то я готов опубликовать статью на тему недостатков СС. На сегодняшний момент у него на российском рынке только две проблемы
      1 — стоимость лицензии
      2 — СС требует ВЫСОКОЙ культуры организации процесса разработки и сопровождения ПО
      Последнего в у нас просто нет. Я в консалтинге 10 лет и за это время насмотрелся и навиделся неэффективных процессов.
      Ну нельзя автоматизировать строгим инструментом бардак, НУ не бывает чудес :)
      С SVN гораздо проще — он не имеет претензий на строгость, потому его и легко внедрять в отсутствие процессов и «царя» в головах сотрудников.
      Жду от вас детального описания того, как СС провалил проект и заранее зову в соавторы будущей статьи.

      GD Star Rating
      loading...
      GD Star Rating
      loading...
  • User

    Абсолютно согласен с 2. Это и есть недостаток! (невозможно иметь всех идеальных работников)
    Единственное что мог бы добавить — с СС можно жить когда большой проект четко поделен на части которые друг другу особо не мешают.
    Однако это не всегда реально можно сделать. В spagetti-applications (a lot of shortcuts) работать с СС практически невозможно, количество людей становится бесполезным. Контролировать процесс очень сложно и ситуация периодически выходит из под контроля.
    Каждый разработчит живет в своем мире и не чувствует общей ситуации, а merge-monkey вешается.

    SVN использует собершенно другой подход, который позволяет работать и в такой ситуации, даже виновных найти и прижучить не составляет труда, да и merge-monkey не нужен (каждый убирает за собой).

    Это мое субъективное мнение…

    GD Star Rating
    loading...
    GD Star Rating
    loading...
    • Мне этого мало :)
      Нужно смотреть на процесс разработки и давать рекомендации. Если совсем обобщить, то если сама компания чисто разработческая, то в таких местах СС в России практически не приживается — дай Бог, если десяток наберется. Все потому, что в таких компаниях не уделяют внимание строгости следования процессу. От этого и все беды. Просто если брать ту же Моторолу или Сименс, где четко регламентированные процессы, то у них по несколько тысяч только лицензий (!!) на СС. Видимо, не совсем бесполезная штука.
      SVN же отлично нашел свою нишу:
      Во первых к процессу не притязателен, во-вторых оттянул на себя всех, кто говорит, что ClearCase (PVCS и другие коммерческие) это ДОРОГО, и это СЛОЖНО.
      Разумеется любая компания исходит из своих возможностей при покупке инструмента — если SVN делает все почти тоже самое, можно не вкладывать деньги в «железо» для его развертывания и у команды нет негатива к нему… В чем вопрос — маст хэв :)
      Я работаю в обеих системах — в СС 10 лет, в SVN 2 года. Мне трудно сказать что лучше. Для локальных, домашних проектов я давно использую SVN (вопрос цены — домой СС я точно брать не буду :)
      Так что если сможете показать из рук процесс разработки, то можно будет понять, как минимум, что было не так во внедрении СС.

      GD Star Rating
      loading...
      GD Star Rating
      loading...

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam protection by WP Captcha-Free