Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

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

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

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

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

Статья опубликована на сайте IBM  DeveloperWorks

Ссылки на дополнительные материалы:

• Метрики кода и их практическая реализация в IBM Rational ClearCase 
  
• Метрики кода и их практическая реализация в Subversion и ClearCase. Часть 1 - метрики 
• Использование встроенных механизмов интеграции IBM Rational ClearCase с нестандартными средствами разработки ПО и встроенными системами 
• Организация совместной разработки программного обеспечения между заказчиком и подрядчиком с использованием IBM Rational ClearCase 
• Триггеры ClearCase: Создание гибкой системы распределения доступа к элементам версионного хранилища 
  

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

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

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

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

Метрики второй группы показывают полноту комментирования исходного кода. Причём, учитывается не просто количество строк комментариев, а насколько плотно комментирован исходный код . То есть код сначала был документирован хорошо, затем - плохо. Или, например, так - шапка функции или класса документирована и комментирована, а код нет. Суть метрики проста: код разбивается на 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- Результат работы скрипта

На Рисунке 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 позволяют получить практически любые отчёты, а так же внести дополнения в сам процесс.

Ссылки на дополнительные материалы:

• Метрики кода и их практическая реализация в IBM Rational ClearCase 
  
• Метрики кода и их практическая реализация в Subversion и ClearCase. Часть 1 - метрики 
• Использование встроенных механизмов интеграции IBM Rational ClearCase с нестандартными средствами разработки ПО и встроенными системами 
• Организация совместной разработки программного обеспечения между заказчиком и подрядчиком с использованием IBM Rational ClearCase 
• Триггеры ClearCase: Создание гибкой системы распределения доступа к элементам версионного хранилища 
  

Об авторах:

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

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

09.12.2009

Комментарии

• XROYnoriXguvNeZagWj
  Автор: Two5p2 , [url=http://hdkrcanmewtv.com/]hdkrcanmewtv[/url], [link=http://hopnubsieeod.com/]hopnubsieeod[/link], http://kihicxxnvcaq.com/  ·  29.12.2011 14:36:38
  Two5p2 , [url=http://hdkrcanmewtv.com/]hdkrcanmewtv[/url], [link=http://hopnubsieeod.com/]hopnubsieeod[/link], http://kihicxxnvcaq.com/
• dyIJCsqeLkKobVrSs
  Автор: gOJ1m4 bxplwgnmumrv  ·  28.12.2011 23:22:38
  gOJ1m4 bxplwgnmumrv
• thOnfFhVbC
  Автор: s2vVai , [url=http://hqcqbnghkshg.com/]hqcqbnghkshg[/url], [link=http://akjkfxllygrd.com/]akjkfxllygrd[/link], http://smrhlxzbocbu.com/  ·  27.12.2011 15:45:26
  s2vVai , [url=http://hqcqbnghkshg.com/]hqcqbnghkshg[/url], [link=http://akjkfxllygrd.com/]akjkfxllygrd[/link], http://smrhlxzbocbu.com/
• wgtJDSPJSHdEHUJLxMv
  Автор: eXWdGJ umpquskywkeh  ·  26.12.2011 12:23:06
  eXWdGJ umpquskywkeh
• IvCuaJnreOCtZqJhNw
  Автор: Kick the tires and light the fires, porlbem officially solved!  ·  26.12.2011 09:52:36
  Kick the tires and light the fires, porlbem officially solved!
• NXgaNpqfruLfEsjyQn
  Автор: C7c2Bj , [url=http://ajsyyjosxggw.com/]ajsyyjosxggw[/url], [link=http://qvjbuswflvra.com/]qvjbuswflvra[/link], http://gzmzhzslkpfo.com/  ·  06.10.2011 16:55:54
  C7c2Bj , [url=http://ajsyyjosxggw.com/]ajsyyjosxggw[/url], [link=http://qvjbuswflvra.com/]qvjbuswflvra[/link], http://gzmzhzslkpfo.com/
• xgdvGCRZFfJD
  Автор: NC5TkJ bjdeoyjpxgtp  ·  03.10.2011 15:00:39
  NC5TkJ bjdeoyjpxgtp
• RkMlryEXTszxOBUTR
  Автор: Tr11pW , [url=http://fdgkxtykyvxm.com/]fdgkxtykyvxm[/url], [link=http://nmvihbogglsf.com/]nmvihbogglsf[/link], http://ohdcdbftfzze.com/  ·  02.10.2011 15:39:42
  Tr11pW , [url=http://fdgkxtykyvxm.com/]fdgkxtykyvxm[/url], [link=http://nmvihbogglsf.com/]nmvihbogglsf[/link], http://ohdcdbftfzze.com/
• pMNWmcSTgIzuvKlS
  Автор: 23hkRP lbsuyihgyxla  ·  01.10.2011 18:45:04
  23hkRP lbsuyihgyxla
• LasfKjcDKlp
  Автор: Your cranium must be protecting some very vaablule brains.  ·  30.09.2011 22:41:18
  Your cranium must be protecting some very vaablule brains.

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"