Звітність IBM Rational ClearCase.Часть 1

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


Метрики складності програм прийнято розділяти на чотири основні групи:



  1. метрики розміру програм;
  2. метрики стилістики та зрозумілості програм;
  3. метрики складності потоку управління програм;
  4. метрики складності потоку даних програм.

Метрики першої групи базуються на визначенні кількісних характеристик, пов'язаних з розміром програми, і відрізняються відносною простотою. До найбільш відомих метриках даної групи відносяться число операторів програми, число рядків вихідного тексту, набір метрик Холстед. Метрики цієї групи орієнтовані на аналіз вихідного тексту програм, тому вони можуть використовуватися для оцінки складності проміжних продуктів розробки.


Метрики другої групи показують повноту коментування вихідного коду. При цьому враховується не просто число рядків коментарів, а наскільки щільно коментував вихідний код. Наприклад, код спочатку був документований добре, потім – погано, або так: шапка функції або класу документована і коментувати, а код – ні. Суть метрики проста: код розбивається на n-рівні шматки і для кожного з них визначається коефіцієнт.


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


Метрики четвертої групи базуються на оцінці використання, конфігурації і розміщення даних у програмі. У першу чергу це стосується глобальних змінних. До даної групи відносяться метрики Чепін.


Тут ми вважаємо за необхідне зауважити, що застосування будь-яких метрик повинно виконуватися з урахуванням контексту. Іншими словами, самі по собі метрики не є закінченими і універсальними засобами оцінки трудомісткості, застосування яких завжди давало б однозначний результат. Швидше, вони вказують, у якому напрямку необхідно провести детальний аналіз. Або використовуються в конкретному випадку, коли їх застосування твердо обгрунтовано.


Отже, далі мова піде власне про отримання звітів за зміненими версіями вихідного коду та обчисленні метрик по них. У ClearCase є інструмент формування звітності – Report Builder. Він містить ряд попередньо встановлених звітів, дозволяє експортувати отримані звіти в різних форматах. Інструмент Report Builder цілком задовольняє потреби на початку використання ClearCase. Але з часом, рано чи пізно, з'явиться потреба розширення можливостей системи звітності, наприклад, знадобиться отримувати метрики розміру та складності вихідного коду.


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


Малюнок 1. Архітектура рішення

Ініціацію формування звіту ми виконуємо з контекстного меню версії каталогу ClearCase. З контекстного меню відбувається запуск скрипта, що виконує, власне, запит інших вхідних даних (шлях до каталогу вже запроваджено – ним є той самий каталог, з контекстного меню якого запущений звіт). Скрипт розміщуємо в каталозі з загальним доступом, наприклад на сервері ClearCase. Це позбавить від необхідності поновлення на клієнтських місцях у разі подальших доробок і змін.


Скрипт виконує наступні функції:



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


Для створення атрибутів на елементах версійного сховища необхідно попередньо створити типи атрибутів. Для цього переходимо до списку типів версійного сховища і відкриваємо каталог attribute types. Створюємо типи атрибутів (малюнок 2).


Малюнок 2. Створення типів атрибутів


Читати частина 2

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


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

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

Ваш отзыв

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

*

*