Розробка стратегії впровадження CASE-засобів

Стратегія впровадження повинна забезпечувати задоволення потреб і критеріїв, визначених раніше. Стратегія включає наступні складові:

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

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

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

В загальному випадку, впровадження CASE-засобів повинне управлятися і фінансуватися таким же чином, як і будь-який проект розробки ПО. Стратегія впровадження може бути переглянутий у разі появи додаткової інформації.

Існує декілька підходів до розробки стратегії впровадження CASE-засобів. Відносні переваги того або іншого підходу перед іншими повинні розглядатися в контексті специфіки конкретної організації. Особливе значення при цьому надається персоналу організації і процесу розробки ПО.

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

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

Недоліки даного підходу полягають в наступному:

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

Щоб підвищити вірогідність успіху, потрібне ухвалення серйозних зобов'язань із сторони як керівництва, так і потенційних користувачів.

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

Переваги даного підходу полягають в наступному:

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

Недоліки даного підходу полягають в наступному:

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

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

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

Оцінка і вибір CASE-засобів

Загальні відомості

Модель процесу оцінки і вибору [17], що розглядається нижче (малюнок 4.2), описує саму загальну ситуацію оцінки і вибору, а також показує залежність між ними. Якомога бачити, оцінка і вибір можуть виконуватися незалежно один від одного або разом, кожний з цих процесів вимагає застосування певних критеріїв.

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

• оцінка декількох CASE-засобів і вибір одного або більш з них;
• оцінка одного або більш CASE-засобів і збереження результатів для подальшого використання;
• вибір одного або більш CASE-засобів з використанням результатів попередніх оцінок.

Мал. 4.2. Модель процесу оцінки і вибору

Як видно з малюнка, вхідною інформацією для процесу оцінки є:

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

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

Елементи процесу включають:

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

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

Користувач повинен визначити конкретний порядок дій і ухвалення рішень з будь-якими необхідними ітераціями. Наприклад, процес може бути представлений у вигляді дерева рішень з його послідовним обходом і вибором підмножин кандидатів для більш детальної оцінки. Опис послідовності дій повинен визначати потік даних між ними.

Визначення списку критеріїв засновано на призначених для користувача вимогах і включає:

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

Процес оцінки

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

Процес оцінки включає наступні дії:

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

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

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

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

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

Оцінка і накопичення відповідних даних може виконуватися наступними способами:

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

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

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

По суб'єктивних критеріях CASE-засіб повинен оцінюватися групою фахівців, що використовують одні і ті ж критерії. Необхідний рівень досвіду фахівців або груп повинен бути наперед визначений.

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

Звіт за наслідками оцінки повинен містити наступну інформацію:

• введення. Загальний огляд процесу і перелік основних результатів;
• передумови. Мета оцінки і бажані результати, період часу, протягом якого виконувалася оцінка, визначення ролей і відповідного досвіду фахівців, що виконували оцінку;
• підхід до оцінки. Опис загального підходу, включаючи отримані CASE-засоби, інформацію, що визначає контекст і масштаб оцінки, а також будь-які припущення і обмеження;
• інформація про CASE-засоби. Вона повинна включати наступне: 1) найменування CASE-засобу; 2) версію CASE-засобу; 3) дані про постачальника, включаючи контактну адресу і телефон; 4) конфігурацію технічних засобів; 5) вартісні дані; 6) опис CASE-засобу, що включає підтримувані даним засобом процеси створення і супроводу ПО, програмне середовище CASE-засобу (зокрема, підтримувані мови програмування, операційні системи, сумісність з базами даних), функції CASE-засобу, вхідні/вихідні дані і область застосування;
• етапи оцінки. Конкретні дії, виконувані в процесі оцінки, повинні бути описаний із ступенем деталізації, необхідної як для розуміння масштабу і глибини оцінки, так і для її повторення при необхідності;
• конкретні результати. Результати оцінки повинні бути представлений в термінах критеріїв оцінки. В тих випадках, коли звіт охоплює цілий ряд CASE-засобів або результати даної оцінки зіставлятимуться з аналогічними результатами інших оцінок, необхідно звернути особливу увагу на формат представлення результатів, сприяючий такому порівнянню. Суб'єктивні результати повинні бути відокремлений від об'єктивних і повинні супроводитися необхідними поясненнями;
• висновки;
• додатки. Формулювання задачі оцінки і уточнений список критеріїв.

Процес вибору

Процеси оцінки і вибору тісно взаємозв'язані один з одним. За наслідками оцінки мети вибору чи критерії вибору і їх ваги можуть зажадати модифікацію. В таких випадках може бути потрібно повторна оцінка. Коли аналізуються остаточні результати оцінки і до них застосовуються критерії вибору, може бути рекомендовано придбання CASE-засобу або набору CASE-засобів. Альтернативою може бути відсутність адекватних CASE-засобів, в цьому випадку рекомендується розробити новий CASE-засіб, модифікувати існуюче або відмовитися від впровадження.

Процес вибору тісно взаємозв'язаний з процесом оцінки і включає наступні дії:

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

В процесі вибору можливо отримання двох результатів:

• рекомендацій по вибору конкретного CASE-засобу;
• запиту на отримання додаткової інформації до процесу оцінки.

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

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

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

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

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

Якщо жоден з CASE-засобів не задовольняє мінімальним критеріям, вибір (можливо, разом з оцінкою) може бути повторений для інших CASE-засобів - кандидатів.

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

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

Критерії оцінки і вибору

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

• числові заходи в широкому діапазоні значень, наприклад, об'єм необхідної пам'яті;
• числові заходи в обмеженому діапазоні значень, наприклад, простота освоєння, виражена в балах від 1 до 5;
• двійкові заходи (істина/брехня, да/нет), наприклад, здатність генерації документації у форматі Postscript;
• заходи, які можуть приймати одне або більш з кінцевої безлічі значень, наприклад, платформи, для яких підтримується CASE-засіб.

Типовий процес оцінки и/или вибору може використовувати набір критеріїв різних типів.

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

Функціональні характеристики

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

1. Середовище функціонування:
1. Проектне середовище:

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

§ область застосування. Прикладами є системи обробки транзакцій, системи реального часу, інформаційні системи і т.д.

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

1. ПО/технічеськіє засоби:

§ необхідні технічні засоби. Устаткування, необхідне для функціонування CASE-засобу, включаючи тип процесора, об'єм оперативної і дискової пам'яті.

§ підтримувані технічні засоби. Елементи устаткування, які можуть використовуватися CASE-засобом, наприклад, пристрої введення-виведення.

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

§ підтримуване ПО. Програмні продукти, які можуть використовуватися CASE-засобом.

Мал. 4.3. Структура набору критеріїв

1. Технологічне середовище:

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

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

§ підтримувана методологія. Набір методів і методик, підтримуваних CASE-засобом. Прикладами є структурний або об'єктно-орієнтований аналіз і проектування.

§ підтримувані мови. Всі мови, що використовуються CASE-засобом. Прикладами таких мов є мови програмування (Кобол, Ада, С), мови баз даних і мови запитів (DDL, SQL), графічні мови (Postscript, HPGL), мови специфікації проектних вимог і інтерфейси операційних систем (мови управління завданнями).

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

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

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

§ введення і редагування специфікацій вимог і проектних специфікацій. До специфікацій такого роду відносяться описи функцій, даних, інтерфейсів, структури, якості, продуктивності, технічних засобів, середовища, витрат і графіків.

§ мова специфікації вимог і проектних специфікацій. Можливість імпорту, експорту і редагування специфікацій з використанням формальної мови.

§ моделювання даних. Можливість введення і редагування інформації, що описує елементи даних системи і їх відношення.

§ моделювання процесів. Можливість введення і редагування інформації, що описує процеси системи і їх відношення.

§ проектування архітектури ПО. Проектування логічної структури ПО - структури модулів, інтерфейсів і ін.

§ імітаційне моделювання. Можливість динамічного моделювання різних аспектів функціонування системи на основі специфікацій вимог и/или проектних специфікацій, включаючи зовнішній інтерфейс і продуктивність (наприклад, час відгуку, коефіцієнт використання ресурсів і пропускну спроможність).

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

§ генерація екранних форм. Можливість генерації екранних форм на основі специфікацій вимог чи проектних специфікацій.

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

§ синтаксичний і семантичний контроль проектних специфікацій. Контроль синтаксису діаграм і типів їх елементів, контроль декомпозиції функцій, перевірка специфікацій на повноту і несуперечність.

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

§ автоматизоване проектування звітів.

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

§ синтаксично кероване редагування. Можливість введення і редагування початкових кодів на одному або декількох мовах з одночасним синтаксичним контролем.

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

§ компіляція коду.

§ конвертація початкового коду. Можливість перетворення коду з однієї мови в іншій.

§ аналіз надійності. Можливість кількісно оцінювати параметри надійності ПО, такі, як кількість помилок і ін.

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

§ реструктуризація початкового коду. Можливість модифікації формату чи структури існуючого початкового коду.

§ аналіз початкового коду. Прикладами такого аналізу можуть бути визначення розміру коду, обчислення показників складності, генерація перехресних посилань і перевірка на відповідність стандартам.

§ відладка. Типові функції відладки - трасування програм, виділення вузьких місць і фрагментів коду, що часто використовуються, і т.д.

1. Тестування:
   Критерії тестування включають наступні:

§ опис тестів. Типові можливості включають генерацію тестових даних, алгоритмів тестування, необхідних результатів і т.д.

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

§ автоматичний запуск тестових прикладів.

§ регресійне тестування. Можливість повторення і модифікації раніше виконаних тестів для визначення відмінностей в системі и/или середовищі.

§ автоматизований аналіз результатів тестування. Типові можливості включають порівняння очікуваних і реальних результатів, порівняння файлів, статистичний аналіз результатів і ін.

§ аналіз тестового покриття. Оснащеність засобами контролю початкового коду і аналіз тестового покриття. Перевіряються, зокрема, звернення до операторів, процедур і змінних.

§ аналіз продуктивності. Можливість аналізу продуктивності програм. Аналізовані параметри продуктивності можуть включати використання центрального процесора, пам'яті, звернення до певних елементів даних и/или сегментів коду, тимчасові характеристики і т.д.

§ аналіз виняткових ситуацій в процесі тестування.

§ динамічне моделювання середовища. Зокрема, можливість автоматично генерувати модельовані вхідні дані системи.

1. Загальні функції:
   Приведені нижче критерії визначають функції CASE-засобів, що охоплюють всю сукупність фаз ЖЦ. Підтримка всіх цих функцій здійснюється за допомогою репозиторія.
1. Документування:

§ редагування текстів і графіки. Можливість вводити і редагувати дані в текстовому і графічному форматі.

§ редагування за допомогою форм. Можливість підтримувати форми, визначені користувачами, вводити і редагувати дані відповідно до форм.

§ можливості видавничих систем.

§ підтримка функцій і форматів гіпертексту.

§ відповідність стандартам документування.

§ автоматичне витягання даних з репозиторія і генерація документації по специфікаціях користувача.

1. Управління конфігурацією:

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

§ відстежування модифікацій. Фіксація і ведення журналу всіх модифікацій, внесених в систему в процесі розробки або супроводу.

§ управління версіями. Ведення і контроль даних про версії системи і всі її компоненти, що колективно використовуються.

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

§ генерація версій і модифікацій. Підтримка призначеного для користувача опису послідовності дій, що вимагаються для формування версій і модифікацій, і автоматичне виконання цих дій.

§ архівація. Можливість автоматичної архівації елементів даних для подальшого використання.

1. Управління проектом:

§ управління роботами і ресурсами. Контроль і управління процесом проектування ІС в термінах структури завдань і призначення виконавців, послідовності їх виконання, завершеності окремих етапів проекту і проекту в цілому. Можливість підтримки планових даних, фактичних даних і їх аналізу. Типові дані включають графіки (з урахуванням календаря, робочого годинника, вихідного і ін.), комп'ютерні ресурси, розподіл персоналу, бюджет і ін.

§ оцінка. Можливість оцінювати витрати, графік і інші проектні параметри, що вводяться користувачами.

§ управління процедурою тестування. Підтримка управління процедурами і програмою тестування, наприклад, управління розкладом планованих процедур, фіксація і запис результатів тестування, генерація звітів і т.д.

§ управління якістю. Введення відповідних даних, їх аналіз і генерація звітів.

§ коректуючі дії. Підтримка управління коректуючими діями, включаючи обробку повідомлень про проблемні ситуації.

Надійність

• адміністрування репозиторія. Контроль і забезпечення цілісності проектних даних.
• автоматичне резервування (визначуване постачальником або плановане користувачем).
• безпека. Захист від несанкціонованого доступу.
• обробка помилок. Виявлення помилок в роботі системи, сповіщення користувача, коректне завершення роботи або збереження стану до моменту переривання.
• аналіз відмов в критичних додатках.

Простота використання

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

Ефективність

• вимоги до технічних засобів. Вимоги до оптимального розміру зовнішньої і оперативної пам'яті, типу і продуктивності процесора, що забезпечує прийнятний рівень продуктивності.
• ефективність робочого навантаження. Ефективність виконання CASE-засобом своїх функцій залежно від інтенсивності роботи користувача (наприклад, кількість натиснень клавіш або кнопки миші, що вимагається для виконання певних функцій).
• продуктивність. Час, затрачуваний CASE-засобом для виконання конкретних задач (наприклад, час відповіді на запит, час аналізу 100000 рядків коду). В деяких випадках дані оцінки продуктивності можна отримати із зовнішніх джерел.

Супроводжуваність

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

Переносимість

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

Загальні критерії

Приведені нижче критерії є загальними по своїй природі і не належать до сукупності показників якості, приведеної в стандарті ISO/IEC 9126: 1991.

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