Збір і публікація проектних метрик в процесі розробки програмного забезпечення на базі штатних засобів IBM Rational ClearCase.

Дана стаття описує методи формування звітної інформації в процесі розробки програмного забезпечення. Стаття дає практичні навички і розповідає про те, як сформувати звітну систему на базі штатних засобів IBM Rational ClearCase.


Стаття буде цікава всім, хто користується інструментальними засобами IBM Rational, а також тим, хто хоче розпочати їх активно застосування.


Введення


Уявити сучасний світ інформаційних технологій (з його потоками інформації) без звітностей і супровідних документів практично неможливо. Багато програмні системи мають вбудовані засоби звітності, є системи професійної звітності (Crystal Reports).


ClearCase (СС), будучи складною системою конфігураційного управління, містить вбудовані засоби по створенню, модифікації і супроводу звітів довільного зразка.


На жаль, з професійними програмами-генераторами звітів Clear Case зв'язку не має, але його вбудованих можливостей більш ніж достатньо для формування звітів практично будь-якого виду.


Насправді звіт як сутність це підвид проектних метрик, які обов'язково необхідно збирати в процесі виконання проекту. Метрики – це ключові показники для різних рівнів керівництва. Метрики дозволяють тримати руку на пульсі і приймати потрібні і правильні управлінські рішення. Погодьтеся, що менеджеру проекту необхідно знати все в деталях (хто і що робить), а більш високому начальству більш необхідні прості ключові показники, за якими можна прийняти стратегічні рішення.


У всіх процесах – починаючи від бізнес аналізу і закінчуючи супроводом, є інформація яку можна обробити і видати частину її в якості звітів і показників. У нашому випадку, в процесі розробки із застосуванням засобів конфігураційного управління ClearCase + ClearQuest, інформація може бути відібрана напівавтоматично або автоматично і представлена у зручному вигляді.


У даній статті мова піде тільки про метриках одного інструментального засобу – ClearCase, що трохи знижує цілісну картину, але дуже необхідно (звітність і метрики для засобу управління змінами ClearQuest будуть розглянуті найближчим часом).


Отже, що з точки зору менеджменту можна отримати від системи звітності в процесі розробки ПЗ:



  1. При роботі з будь-яким засобом версійного управління (ClearCase не виняток) розробник створює версії файлів (проводячи елементарні операції check-in і check-out). Дані операції необхідно коментувати в обов'язковому порядку. Відповідно. Ми маємо можливість зібрати всі коментарі, введені конкретним співробітником за певний проміжок часу. І це перший тип звіту – збір коментарів до версій файлів. Якщо говорити про ідеальний випадок, то в багатьох компаніях розробники документують свої дії … от тільки роблять вони це в кінці роботи, тобто КОЛИ ВОНА виконано! І, природно, звіт робиться недбалим з оформлення, і, часом, неправильним за своєю суттю. У нашому випадку збір може бути автоматизований.
  2. Якщо число проектами вимірюється десятками, а число розробників, тестувальників і аналітиків десятками десятків, то виникає резонне питання: хто, на момент звіту, над якими даними і в яких проектах працює. Це другий вид звітів – зайнятість персоналу в даний момент
  3. Для формування загальної дисципліни і культури роботи необхідний ще один вид звітів, мабуть, найважливіший, – що розробник зробив за звітний період. Суть звіту полягає в тому, щоб проаналізувати не тільки коментарі до версії, але й різницю між самими версіями! Це найбільш глибокий аналіз і потрібен він радше менеджеру проекту (який точно буде знати, хто і чим займається) ніж чим більш високому начальству … АЛЕ. Даний підхід дозволить різко підняти рівень якості роботи з кодом і продуктивність розробників, так як КОЖЕН знає, що БУДЬ-ЯКА інформація може бути легко перевірена та проаналізована. У даний звіт можуть входити такі метрики, як: кількість доданих сторінок, кількість вилучених сторінок, кількість змінених рядків.
    Для даного типу метрик і звітів дуже важливий правильний підхід до цифр, тому що ці цифри дуже суб'єктивні за своєю природою і повинні застосовуватися лише разом з іншими звітами і метриками (простий приклад – за тиждень розробник додав 2 рядки в 1 файл … Якщо менеджер проекту шалено підійде до даної метриці, то розробнику доведеться виправдовуватися за бездіяльність … а якщо менеджер подивиться сусідні метрики, то з'ясує, що розробник весь тиждень шукав дефект, який тестувальники знайшли минулого тижня. Це один приклад того, що не можна давати оцінку по 1 або 2 показниками – необхідно застосовувати комплексну оцінку і ClearCase + ClearQuest в цьому дуже допомагають
  4. Ще один можливий показник – активність співробітника в часі. Просто зібрати статистику активних операцій

На практиці кількість показників і звітів набагато більше, але вже можна зрозуміти які вигоду обіцяє правильна організація процесу розробки (тестування і супроводу) ПЗ.


Давайте далі більш детально розберемося з підходами до формування звітності.


Існує два підходи в отриманні звітів:



Вибір форми звітів залишається на плечах керівництва компанії. Структура та зміст декомпозіруется вже на більш низьких рівнях (на рівні менеджерів проектів), де до уваги приймаються такі фактори як спосіб формування звітів (автоматичний, ручний або комбінований), спосіб подання (текстовий файл, документ Word або WEB).


У кожного способу є переваги і недоліки. Ще раз нагадаємо, що мова в даному розділі йде не про формування проектної документації, а саме про звітах за станом елементів репозиторію.


Розглянемо доступні способи формування звітності:


Зовнішні:



Внутрішні:



Для отримання автоматизованої звітності, адміністратор проекту, формує необхідний набір скриптів звітності та формує засобами ClearCase розклад з їх отримання.


Використання SoDA


SoDA є макросом для Word і відповідає за формування звітів у форматі DOC і HTML на основі вбудованих шаблонів. Інструмент дозволяє користувачеві формувати власні шаблони, грунтуючись на встановлених, або створювати довільні з нуля (за допомогою модуля Template View).


Базуючись на шаблонах, SoDA підтримує можливість стандартизації типів документів в рамках проекту або компанії. IBM / Rational SoDA може забезпечити відповідність проектної документації таким міжнародним стандартам, як ISO, SEI CMM, IEEE, а також популярним вітчизняним ГОСТ 19 і ГОСТ 34.


Звітність, створювану SoDA неможливо автоматизувати, тому для неї потрібне окреме ручне керування для формування події побудови звіту або звітів. Перевага підходу полягає в тому, що даним інструментом в тій чи іншій мірі володіють багато учасників проекту, як наслідок процес створення оригінальних шаблонів дещо спрощується.


Розглянемо стандартні форми звітів:



Стандартні звіти, що формуються за допомогою SoDA, є вкрай простими, які вимагають істотних коригувань для використання в реальних проектах. Наприклад, в стандартних звітах відсутня звіт за всіма елементами сховища, звіт за станом елементів згідно з ім'ям користувача (звіт по співробітнику) … і т.д. Ставитися до стандартних шаблонів звітів слід як до підручника, на базі якого будуються більш складні і більш інформативні звіти.


Звіти SoDA вигідно застосовувати для проектної документації, для одержання особливо важливих документів, як Концепція системи, але для структурного аналізу стану елементів репозиторію ClearCase, є більш ефективні способи.


Використання вбудованої системи звітності із збереженням у вигляді Html


ClearCase має вбудовану систему звітності, засновану на конструкторі звітів. У свою чергу, конструктор є відкритим і дозволяє додавати нові форми звітів до існуючих.


Модуль, що відповідає за звітність, називається ClearCase Report Builder. Викликати його можна з командного рядка на ім'я ccreportbuilder (з директорії RationalClearCaseeports), або з меню ОС. CCRB також можна викликати з браузера ClearCase Explorer.


На малюнку 1 показаний фрагмент екрану з працюючим Report Builder

рис.1. Вид вікна вбудованої системи звітності


Для генерації звітів необхідно вказати в браузері на необхідний елемент, для якого буде створюватися звіт (файл, вигляд, репозиторій) і натиснути на кнопку Run Report. По введених параметрами буде здійснено пошук елементів і згенерований звіт в основному вікні. Звітні дані підлягають збереженню у вигляді Html файлу, для подальшого вбудовування під внутрішньокорпоративний сайт.


Опишемо основні типи звітів, які мають практичну цінність для проекту:


Elements


Vobs



Views



Тут наведено тільки основний набір базових звітів. Більш докладно все описано в документації по ClearCase. Одна з переваг використання CCRB в порівнянні зі стандартною SoDA полягає в більшому числі встановлених звітів і в тому, що вони є рекурсивними (тобто, можна отримати звіт по всіх елементах, що знаходяться в підтеках). Друга перевага пов'язано з тим, що SoDA є зовнішнім, по відношенню до ClearCase, продукту, що вимагає додаткового ліцензування.


CCRB формує звітні матеріали за допомогою скриптів на вбудованій мові програмування Perl (спеціальний діалект стандартного Perl версії 5.0). Це означає, що адміністратор проекту може додавати нові скрипи до складу CCRB.


Для введення нового звіту в систему звітності достатньо створити файл скрипта за певними правилами і скопіювати в директорію з іншими звітами.


Використання CCRB дозволить отримувати потрібні звіти на вимогу користувача. До звітів повинні мати відношення всі учасники проекту, а не тільки керівники, оскільки звіт – є одна з форм не тільки проектного контролю, а й локального контролю для кожного учасника даних власного робочого простору.


Використання командного рядка для формування елементарних звітів


Командний рядок наскрізь пронизує ClearCase, дозволяючи отримувати доступ до будь-яких видів даних. І, як один з наслідків, дозволяє отримувати різні звіти. У інтерпретаторі cleartool є цілий набір команд виводять інформацію про елементи, метаданих, версіях, історії зміни і т.д. (Команди з префіксом ls).


Користувач, що працює з СС, завжди може отримати найпростіший звіт, користуючись добре відомим прийомом по перенаправлення висновку: це знаки> і>>, що додаються до кінця командного рядка, наприклад:


cleartool lshistory main.cpp >> c:
eport.txt


або


cleartool lshistory-user admin-a-minor-since 20-mar-99.15: 00>> c:
eport.txt


Подібний спосіб спонтанної звітності придатний тільки для індивідуального застосування, в силу того, що звіт формується спонтанно, без використання шаблонів.


Деякі команди cleartool надають сервіс форматного виведення по перемикачу-fmt, що дозволяє отримувати швидкі звіти належної якості (команди annotate, describe). Але й цього недостатньо, в силу того, що багато команд просто не вміють виводити інформацію про групу файлів чи директорій, тобто їх функціональність обмежена одним елементом.


Для обходу даної особливості, необхідно застосовувати спеціальну команду пошуку find, яка заповнює недолік відсутності рекурсії і має у своєму арсеналі потужну мову запитів. Як варіант звітності, допустимо використовувати пошук елементів з формуванням текстових звітів. Можливості команди find дозволяють не тільки проводити пошук даних, які відповідають заданим критеріям, а й застосовувати до кожного знайденому елементу в результаті пошуку певні дії – проводити обробку (для цього, як і у випадку з тригерами, ClearCase формує змінні середовища, в яких перебувають такі основоположні змінні як, наприклад, шлях до знайденого файлу -% CLEARCASE_PN%).


Наприклад, для формування звіту Elements Created By User (наявного в стандартному Аборе) власними силами можна скористатися наступною командою:


сleartool find. -Element "{created_by (Ivanov)}"-exec "cleartool describe% CLEARCASE_PN%"


У прикладі ведеться пошук елементів, створених користувачем Ivanov. Для кожного знайденого елемента Find викличе команду describe, підставивши в якості аргументу змінну, що містить шлях до знайденого елемента. Тепер залишається тільки передбачити перенаправлення виводу в текстовий файл і звіт готовий.


Примітивність способу компенсується його гнучкістю. Але, як завжди є одне «але», що демонструється спосіб не дозволяє, формувати якісні звіти (тобто звіти встановленого зразка з застосуванням різних стилів і форматів на зразок).


Просте копіювання результатів у файл не прийнятно з точки зору естетики. Відповідно, в силу даних причин спосіб має дуже вузьку сферу застосування.


Використання мови скриптів для створення складних форм звітів


Низька якість і погана читабельність звітів, сформованих тільки за командному рядку можна виправити, використовуючи метод розширення функціональності за допомогою мов скриптів. Оскільки, в постачання СС входить один з таких мов – Perl, то ми теж рекомендуємо його до використання в побудові звітів.


Засобами Perl можна створювати скрипти, формують Html-документи (метод заснований на тому, що всі команди взаємодіють з користувачем через стандартний висновок, а Perl є кращим мовою для роботи з потоками даних). У скрипті застосований найпростіший метод отримання інформації про елементи, заснований на командних запитах до інтерпретатору cleartool. Проте, є більш ефективний шлях – використовувати бібліотеку автоматизації (Common Automation Library – CAL). Даний спосіб дозволяє безпосередньо звертатися до функцій ядра ClearCase і вимагає додаткової підготовки, тому на сторінках книги не розглядається.


Застосування даного способу дозволить отримати звіт будь-якої складності, оформленого за всіма правилами.


До переваг способу слід віднести:



Спеціально для адміністраторів, нижче наводиться приклад скрипта, який формує звіт у вигляді набору html-файлів. Кожен з файлів містить в собі детальний опис знайденого елемента репозиторія. Звіт представляється у вигляді повноцінного набору зв'язкових файлів, які можливо включити до складу внутрішньокорпоративного сайту. Скрипт супроводжується коментарями, що дозволить швидко розібратися в його функціональності.


Опишемо дії, що виконуються скриптом:



  1. Просканувати всі елементи репозиторія.
  2. Зібрати статистику за елементами.
  3. Виділену статистику помістити в окремі файли (для збору статистики, до кожного знайденого елементу репозиторії застосовуються команди describe, lshistory і lsvtree).
  4. Підрахувати загальну кількість елементів.
  5. Підрахувати кількість файлів, що знаходяться в стані check-out.
  6. Підсвітити червоним кольором найменування елементів, що знаходяться в стані check-out.

#################################################


# Скрипт з формування звітів за елементами сховища
# Для виконання скрипта необхідно створити директорію rep
# Виправити змінну $ name так, щоб вона дивилася на
# Кореневу директорію репозиторія.
# Формат запуску скрипта: ccperl report_book.pl.
# Результатом роботи скрипта буде сформований набір пов'язаних
# HTML-сторінок по кожному елементу.
# Скрипт підраховує скільки елементів всього в репозиторії, збирає їх
# Властивості.
# Всі елементи, що знаходяться в стані Check-out підсвічуються червоним
# Кольором.
#################################################


# Визначаємо змінну для підрахунку числа версій файлів, що знаходяться в # стані check-out.


$nuco=0;
$versions=0;
# Повний шлях до кореневої директорії репозиторія.
$name=”Z:Sem”;


# Формуємо команду СС для пошуку всіх елементів з висновком даних
# На консоль.
# Список формується без виведення розширеної інформації про
# Елементі.


$arg2=”clt find $name -nxn -all -print”;


# Лічильник числа елементів в репозиторії. Рахунок ведемо з 1.


$objects=1;


# Формуємо масив із заголовком основного файлу index.htm.


$head=”<HTML>
<HEAD>
<TITLE>Allo</TITLE>
<META Http-equiv="Content-Type" content="text/html; charset=windows-1251"> </ HEAD> <BODY bgcolor=#f3fff>
<CENTER> <b> Perl Script REPORT </ b> </ font> </ center> ";


# Формуємо масив із заголовком для файлів, що описують властивості
# Елементів.


$head2=”<HTML>
<HEAD>
<TITLE>Allo</TITLE>
<META Http-equiv="Content-Type" content="text/html; charset=windows-1251"> </ HEAD> <BODY bgcolor=#f3fff>
<CENTER> **** FILE **** </font></center> “;


# Формуємо масив із закінченням файлу.


$end=”</BODY></HTML>”;


# Створюємо Index.htm для запису.


open(INDEX, “>Index.htm”);


# Вписуємо шапку html-файлу.


print INDEX $head;


# Формуємо горизонтальну роздільну лінію.


print INDEX “<HR>
“;


# Формуємо таблицю. Задаємо тип ліній і даємо найменування
# Стовпчиках.


print INDEX "<TABLE width="100%" class=borderall cellspacing=3>
“;
print INDEX “<tr>
“;
print INDEX “<td> <b>ELEMENT</b>
“;
print INDEX “<td> <b>VERSIONS</b>
“;
print INDEX “<td> <b>NUM of CHECKOUTS</b>
“;


# Виконуємо команду, що знаходиться в масиві. Команда open
# Перехоплює висновок сну консоль.


open (FILE, “$arg2 /”);


# Обробляємо відповідь, виведений командою.


while( <FILE> )
{


# Отримуємо порядково дані з потоку і поміщаємо їх в
# Стрінговую змінну.


chomp;
@_ = split;
$buffer=”@_”;


# Формуємо в тимчасовому стрінги гіперпосилання на файл
# З детальним звітом
# По знайденому зараз елементу.


$temper=”<a href=”.
ep$objects.htm”> $objects). $buffer </a>
“; 


# Відкриваємо для створення і запису файл для детального
# Звіту.


open (OUT,”>.
ep$objects.htm”);


# Вписуємо в нього заголовок.


print OUT $head2;


# Формуємо лінію.


print OUT “<HR>
“;


# Збільшуємо індекс об'єктів.


$objects++;


# Записуємо опис блоку.


print OUT “<b>DESCRIBE ELEMENT</b>
“;
print OUT “<br>
“;


# Виконуємо команду отримання опису елемента, адреса
# Якого був знайдений у попередніх кроках (стринг – $ buffer).


open (DESC, “cleartool desc -l $buffer /”);


# Отримуємо дані за рядком.


while( <DESC> ) {
chomp;
@_ = split;


# Вписуємо в файл прогалини. Робимо примусові
# Відступи


print OUT ”      
“; 


# Пишемо в нього текщую рядок.


print OUT “@_
“;
print OUT “<br>
“;
}


# Формуємо следущий заголовок.


print OUT “<br>
“;
print OUT “<b>VERSION TREE</b>
“;
print OUT “<br>
“;


# Даємо команду отримання дерева версій елемента.


open (DESC, “cleartool lsvtree -a $buffer /”);


# Обнуляємо лічильники версій.


$versions=0; 
$nuco=0;
while( <DESC> ) {
chomp;
@_ = split;
print OUT
”      
“; 


# Ставимо умова. Якщо в рядку є
# Слово CHECKEDOUT,
# Значить, що даний елемент виведений в
# Даний стан
# Наше завдання підрахувати число CO.


if ( “@_” =~ “CHECKEDOUT” )
{


# Збільшуємо лічильник числа СО на 1.


$nuco++;


# Робимо рядок червоного кольору,
# Напівжирної і виводимо її у файл.


print OUT “<font color=”red”>
“;
print OUT “<b>
“;
print OUT “@_
“;
print OUT “</b><font color=”black”>
“; 
}else{


# Якщо умова не співпало, то
# Виводимо дані без виділень.


print OUT “@_
“;
}
print OUT “<br>
“;
$versions++;
}


# Формуємо останній заголовок.


print OUT “<br>
“;
print OUT “<b>ELEMENTS HISTORY</b>
“;
print OUT “<br>
“;


# Даємо команду.


open (DESC, “cleartool lshis -l $buffer /”);


# Отримуємо відповідь і просто вписуємо в файл.


while( <DESC> ) {
chomp;
@_ = split;
print OUT ”      
“; 
print OUT “@_
“;
print OUT “<br>
“;
}


# Продовжуємо формування таблиці для файлу з індексами.


print INDEX “<tr>
“;


# Умова: якщо було підраховано, що check-out більше
# Нуля, то ці рядки
# Цілком підсвічуються червоним тлом (колір символів не
# Міняємо).
# В іншому випадку виводимо в файл дані відповідно
# Зі стандартними настройками.


if ($nuco>0){
print INDEX “<td bgcolor=”red”>
“;
print INDEX $temper;
print INDEX “<td bgcolor=”red”>
“;
print INDEX “$versions”;
print INDEX “<td bgcolor=”red”>
“;
print INDEX “$nuco”;


}else{


print INDEX “<td>
“;
print INDEX $temper;
print INDEX “<td>
“;
print INDEX “$versions”;
print INDEX “<td>
“; 
print INDEX “$nuco”;
}


print INDEX “</tr>
“;
print OUT “<HR>
“;
print OUT $end;
close (OUT);
}


print INDEX “</table>”;
print INDEX $end;
close(INDEX)


В результаті виконання скрипта ми отримуємо повноцінний звіт у Html вигляді звітом по всіх елементах репозиторія. Надалі, набір автоматизованих звітів ClearCase можна вбудовувати у вигляді розділів внутрішньокорпоративного сайту.


Для використання даного скрипта в реальному проекті необхідно лише перевизначити змінну $ name і створити директорію rep, в яку будуть міститися файли зі статистикою по знайденим елементам.


Виконання скрипта – ccperl [report.pl]


Де report.pl – скрипт.


Наступні малюнки демонструють вигляд вікна Internet Explorer (IE), з звітів за елементами сховища Sem.

рис.2. Зовнішній вигляд вікна IE із завантаженою основний сторінкою звіту.


Як, бачите, файл, що знаходиться в стані check-out підсвічений червоним кольором. Праворуч ведеться підрахунок загального числа версій для елемента і кількість check-out

рис.3. Зібрана статистика за описом елемента, дереву версій та історії змін.


Ніяких кольорових виділень в тексті немає, оскільки це простий файл, ні ода з версій якої не перебуває в стані check-out

мал.4. Статистика сheck-out для вибраного файлу.


Вказується який користувач і де зробив операцію виводу в стан check-out


У відповідності з корпоративними стандартами на звітність, можна на базі наведеного скрипта створити власний, більш докладний і структурований.


Будь-яка операція над даними в СС потребує ліцензування, відповідно, учасники колективу, які бажають переглянути статистичну інформацію про стан елементів проекту, будуть змушені «вилучити» її для проведення різних ревізій. Формування ж оновлюваного звіту, з розміщенням його на сайті дозволить заощадити ліцензію на не дуже суттєвою операції, наприклад, проводячи генерацію звіту на сервері в кінці робочого дня або вночі.


Процес звітності відноситься до одного з найважливіших в процесі розробки інформаційних систем. Для того щоб звіт не був відписки, СС має механізми коментування ключових дій (Тобто учасник проекту при виконанні певних дій зобов'язаний коментувати мета власних дій). У результаті чого, в кінці (днянеделімесяца) система здатна сама сформувати докладний звіт за наявними в репозиторії коментарям.


Висновок


Якою має бути ідеальна система збору та публікації проектних метрик:


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*