Засоби конфігураційного управління

Мета конфігураційного управління (КУ) - забезпечити керованість і контрольованість процесів розробки і супроводу ПО. Для цього необхідна точна і достовірна інформація про стан ПО і його компонент в кожний момент часу, а також про всі передбачувані і виконані зміни.

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

Найпоширенішим засобом КУ є PVCS фірми Intersolv (США), включаюче ряд самостійних продуктів: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder і PVCS Notify.

PVCS Version Manager [18] призначений для управління всіма компонентами проекту і ведення планомірної багатоверсійної і багатоплатформної розробки силами команди розробників в умовах однієї або декількох локальних мереж. Поняття "проект" трактує як сукупність файлів. В процесі роботи над проектом проміжний стан файлів періодично зберігається в архіві проекту, ведуться записи про час збереження, відповідність один одному декількох варіантів різних файлів проекту. Окрім цього, фіксуються імена розробників, відповідальних за той або інший файл, склад файлів проміжних версій проекту і ін. Це дозволяє повернутися при необхідності до якого-небудь з попередніх станів файлу (наприклад, при виявленні помилки, яку в даний момент важко виправити).

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

Доступ до архівів PVCS Version Manager можливий не тільки через сам Version Manager, але і із понад 50 інструментальних засобів, у тому числі MS Visual З і MS Visual Basic, Uniface, PowerBuilder, SQL Windows, JAM, Delphi, Paradox і ін.

Результатом роботи PVCS Version Manager є створений засобами файлової системи репозиторій, що береже в компактній формі всі робочі версії програмного продукту разом з необхідними коментарями і мітками.

PVCS Version Manager функціонує в середовищі MS Windows, Windows 95, Windows NT, OS/2, SunOS, Solaris, HP-UX, AIX і SCO UNIX і може виконуватися на будь-якому персональному комп'ютері з процесором 80386 або вище, робочих станціях Sun, HP і IBM (RS-6000).

Іншим засобом конфігураційного управління є PVCS Tracker [19] - спеціалізована надбудова над офісною електронною поштою, призначена для обробки повідомлень про помилки в продукті, доставці їх виконавцям і контролю за виконанням. Інтеграція з PVCS Version Manager дає можливість пов'язувати з повідомленнями ті або інші компоненти проекту. Звітні можливості PVCS Tracker включають безліч різновидів графіків і діаграм, що відображають стан проекту і процесу його відладки, зрізи по різних компонентах проекту, розробниках і тестувальниках. З їх допомогою можна наочно показати поточний стан роботи над проектом і її тимчасові тенденції.

Персонал, що працює з PVCS Tracker ділиться на п'ять груп залежно від їх обов'язків: користувачі, розробники, група тестування і контролю якості, група технічної підтримки і супроводи, управлінський персонал. Цим п'яти групам персоналу відповідають п'ять приречених груп PVCS Tracker:

• користувачі (Submitters) - мають обмежені права на внесення зауважень і повідомлень про помилки в базу даних PVCS Tracker;
• розробники (Development Engineers) - мають право проводити основні операції з вимогами і зауваженнями в базі даних PVCS Tracker. Якщо розробники діляться на підгрупи, то для кожної підгрупи можуть бути задані окремі списки прав доступу;
• тестувальники (Quality Engineers) - мають право проводити основні операції з вимогами і зауваженнями;
• супровід (Support Engineers) - мають право вносити будь-які зауваження, вимоги і рекомендації в базу даних, та не мають прав по розподілу робіт і зміні їх пріоритетності і термінів виконання;
• керівники (Managers) - мають право розподіляти роботи між виконавцями і ухвалювати рішення про їх належне виконання. Керівникам різних груп можуть задані різні права доступу до бази даних PVCS Tracker.

На додаток до цих п'яти приречених груп, існує група адміністратора бази даних і 11 додаткових груп, які можуть бути набудовані відповідно до специфічних посадових обов'язків співробітників, використовуючих PVCS Tracker.

Вимога або зауваження поступаюче в PVCS Tracker проходить чотири етапи обробки:

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

Вимоги і зауваження, що поступають в базу даних PVCS Tracker оформляються у вигляді спеціальної форми, яка може містити до 18 полів вибору стандартних значень і до 12 довільних текстових рядків. При розробці форми слід визначити оптимальний набір інформації, характерний для всіх записів в базі даних.

Для отримання змістовної інформації про хід розробки PVCS Tracker дозволяє одержувати три типи статистичних звітів: частотні, тренди і діаграми розподілу.

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

Тренди містять інформацію про зміни того або іншого показника в часі і характеризують стабільність і безперервність процесу розробки. Вони дозволяють відповісти на питання:

• чи встигає група розробників справлятися з поступаючими зауваженнями;
• чи поліпшується якість програмного продукту і яка динаміка цього процесу;
• як вплинуло те або інше рішення (збільшення числа розробників, введення ковзаючого графіка, упровадження нового методу тестування) на роботу групи і т.п.

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

PVCS Tracker призначений для використовування в робочих групах, з'єднаних в загальну мережу. В цьому випадку центральна база або проект PVCS Tracker знаходиться на загальнодоступному сервері мережі, доступ до якого реалізується за допомогою ODBC-драйверів, що входять до складу PVCS Tracker. Головною особливістю PVCS Tracker в порівнянні із звичайним додатком СУБД є його здатність автоматично повідомляти користувача про надходження цікавить його або інформації, що відноситься до його компетенції, і гнучка система розподілу повноважень усередині робочої групи. При необхідності PVCS Tracker може використовувати для повідомлення видалених членів групи електронну пошту.

PVCS Tracker підтримує групову роботу в локальних мережах і взаємодіє з СУБД dBase, ORACLE, SQL Server і SYBASE за допомогою ODBC.

PVCS Tracker може бути інтегрований з будь-якою системою електронної пошти, що підтримує стандарти VIM, MAPI або SMTP.

PVCS Version Manager і PVCS Tracker оточені допоміжними компонентами: PVCS Configuration Builder і PVCS Notify.

PVCS Configuration Builder призначений для збірки остаточного продукту з компонент проекту. PVCS Configuration Builder дозволяє описувати процес збірки як на стандартній мові MAKE, так і на власній внутрішній мові, що має істотно великі можливості. PVCS Configuration Builder дозволяє здійснювати збірку програмного продукту на підставі файлів, що зберігаються в репозиторії PVCS Version Manager.

Звичайна процедура збірки програмного продукту за допомогою PVCS Configuration Builder складається з трьох кроків:

• будується файл залежності між початковими модулями;
• в отриманий файл вносяться зміни з метою його настройки і оптимізації;
• здійснюється збірка програмного продукту з початкових модулів.

Результатом роботи PVCS Configuration Builder є спеціальний файл, що описує оптимальний алгоритм збірки програмного продукту, побудований на основі аналізу дерева залежності між початковими модулями.

PVCS Notify забезпечує автоматичну розсилку повідомлень про помилки з бази даних пакету PVCS Tracker по робочих станціях призначення. При цьому використовується офісна система електронної пошти cc:Mail або Microsoft Mail. PVCS Notify розширює можливості PVCS Tracker і використовується тільки спільно з ним.

PVCS Notify настроюється з середовища PVCS Tracker. Настройка включає визначення інтервалу часу, через який PVCS Notify перевіряє вміст бази даних, визначення критеріїв відбору записів для розсилки повідомлень, визначення списків адрес для розсилки. Після настройки PVCS Notify починає роботу в автономному режимі, автоматично розсилаючи повідомлення про зміни в базі даних PVCS Tracker.

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

Результатом роботи PVCS Notify є оформлені відповідно до одного із стандартів поштові повідомлення, готові для розсилки за допомогою системи електронної пошти.

Засоби документування

Для створення документації в процесі розробки ІС використовуються різноманітні засоби формування звітів, а також компоненти видавничих систем. Звичайно засоби документування вбудовані в конкретні CASE-засоби. Виключенням є деякі пакети, що надають додатковий сервіс при документуванні. З них найбільш активно використовується SoDA (Software Document Аutomation).

Продукт SoDA призначений для автоматизації розробки проектної документації на всіх фазах ЖЦ ПО. Він дозволяє автоматично витягувати різноманітну інформацію, одержувану на різних стадіях розробки проекту, і включати її у вихідні документи. При цьому контролюється відповідність документації проекту, взаємозв'язок документів, забезпечується їх своєчасне оновлення. Результуюча документація автоматично формується з безлічі джерел, число яких не обмежено.

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

SoDA містить набір шаблонів документів, визначуваних стандартом на програмне забезпечення DOD 2167A. На їх основі можна без спеціального програмування створювати нові форми документів, визначувані користувачами.

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

SoDA реалізована на базі видавничої системи FrameBuilder і надає повний набір засобів по редагуванню і верстці документації, що випускається. Різні версії документації можуть бути для наочності відзначені своїми відмітними ознаками. В системі створюються таблиці вимог до проекту, по яких можна прослідити, як реалізуються ці вимоги. Різні види документації, супроводжуючі різні етапи ЖЦ, зв'язані між собою, і можна прослідити стан проекту від первинних вимог до аналізу, проектування, кодування і тестувань програмного продукту.

Підсумковим результатом роботи системи SoDA є готовий документ (або книга). Документ може зберігатися у файлі формату SoDA (Frame Builder), який виходить в результаті генерації документа. Висновок на друк цього документа (або його частини) можливий з системи SoDA.

Середовище функціонування SoDA - ОС типа UNIX на робочих станціях Sun SPARCstation, IBM RISC System/6000 або Hewlett Packard HP 9000 700/800.

SoDA вимагає принаймні 32 MB оперативної пам'яті, 100-300 MB для установки і 64 MB робочі простори на диску.

 

Засоби тестування

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

Один з найрозвиненіших засобів тестування QA (нова назва - Quality Works) [20] є інтегрованим, багатоплатформеним середовищем для розробки автоматизованих тестів будь-якого рівня, включаючи тести регресії для додатків з графічним інтерфейсом користувача.

QA дозволяє починати тестування на будь-якій фазі ЖЦ, планувати і управляти процесом тестування, відображати зміни в додатку і повторно використовувати тести для більш ніж 25 різних платформ.

Основними компонентами QA є:

• QA Partner - середовище для розробки, компіляції і виконання тестів;
• QA Planner - модуль для розробки планів тестування і обробки результатів. Для створення і виконання тестів в процесі роботи QA Planner викликається QA Partner;
• Agent - модуль, що підтримує роботу в мережі.

Процес тестування складається з наступних етапів:

• створення плану тестування;
• скріплення плану з тестами;
• помітка і виконання тестів;
• отримання звітів про тестування і управління результатами.

Створення тестового плану в QA Planner включає складання схеми тестових вимог і виділення рівнів деталізації. Для цього необхідно визначити все, що повинно бути протестовано, підготувати функціональну декомпозицію додатку, оцінити, скільки тестів необхідні для кожної функції і характеристики, визначити, скільки з них буде реалізовано залежно від доступних ресурсів і часу. Ця інформація використовується для створення схеми тестових вимог.

Для скріплення плану з тестами необхідно створити управляючі пропозиції (скрипти) на спеціальній мові 4Test і тести, які виконують вимоги плану, і зв'язати компоненти будь-яким способом. Для уникнення перевантаженості тестів використовують управління тестовими даними.

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

Одним з атрибутів тесту є ім'я його розробника, що дозволяє при необхідності виконувати тести, створені конкретним розробником.

Комплекс QA займає на жорсткому диску не більш 21МВ. Підтримувані платформи: Windows 3.x, Windows 95, Windows NT, OS/2, Macintosh, VMS, HP-UX, AIX, Solaris.