Оцінка і вибір CASE-засобів 1. Загальні відомості

Модель процесу оцінки і вибору [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-засоби. Вони у свою чергу підрозділяються на ряд груп і підгруп.  Середа функціонування:     Проектна Середа:       підтримка процесів життєвого циклу. Визначає набір процесів ЖЦ, які        підтримує CASE-засіб. Прикладами таких процесів є аналіз        вимог, проектування, реалізація, тестування й оцінка,        супроводження, забезпечення якості, управління конфігурацією і        управління проектом, причому вони залежать від прийнятої користувачем моделі        ЖЦ.    область застосування. Прикладами є системи обробки        транзакцій, системи реального часу, інформаційні системи і т.д.    розмір програм, які підтримуються. Визначає обмеження на такі величини, як        кількість рядків коду, рівнів вкладеності, розмір бази даних,        кількість елементів даних, кількість об'єктів конфігураційного        управління.      ПЗ/технічні засоби:       необхідні технічні засоби. Обладнання, необхідне для        функціонування CASE-засоби, включаючи тип процесора, об'єм        оперативної і дискової пам'яті.    підтримувані технічні засоби. Елементи обладнання, які можуть        використовуватися CASE-засобом, наприклад, пристрої введення/виводу.    потрібного ПЗ. ПЗ, необхідне для функціонування CASE-засоби, включаючи        операційні системи та графічні оболонки.    підтримуване ПЗ. Програмні продукти, які можуть        використовуватися CASE-засобом.     

Рис. 4.3. Структура набору критеріїв     Технологічна Середа:       відповідність стандартам технологічного середовища. Такі стандарти стосуються мови, бази даних,        репозиторію, комунікацій, графічного інтерфейсу користувача,        документації, розробки, управління конфігурацією, безпеки,        стандартів обміну інформацією та інтеграції за даними, з управління і по        для користувача інтерфейсу.    сумісність з іншими засобами. Здатність до взаємодії з іншими        засобами, включаючи безпосередній обмін даними (прикладами таких        коштів є текстові процесори, бази даних та інші CASE-засоби).        Можливість перетворення сховища або його частини в стандартний        формат для обробки іншими засобами.    підтримувана методологія. Набір методів і методик,підтримуваних        CASE-засобом. Прикладами є структурний або об'єктно-орієнтований        аналіз і проектування.    підтримувані мови. Всі мови, що використовуються CASE-засобом.        Прикладами таких мов є мови програмування (Кобол, Ада, С),        мови баз даних і мови запитів (DDL, SQL), графічні мови        (Postscript, HPGL), мови специфікації проектних вимог і інтерфейси        операційних систем (мови управління завданнями).       Функції, орієнтовані на фази життєвого циклу:     Моделювання:
      Дані критерії визначають спроможність виконання функцій, необхідних       для специфікації вимог до ПЗ і перетворення їх у проект:       побудова діаграм. Можливість створення і редагування        діаграм різних типів, що представляють інтерес для користувача.        Найбільш поширені типи діаграм описані в розділі 2.    графічний аналіз. Можливість аналізу графічних об'єктів, а        також зберігання та подання проектної інформації в графічному        поданні. У більшості випадків графічні аналізатори        інтегровані із засобами побудови діаграм.    введення і редагування специфікацій вимог і        проектних специфікацій. До        специфікаціям такого роду відносяться опису функцій, даних,        інтерфейсів, структури, якості, продуктивності, технічних        коштів, середовища, витрат і графіків.    мова специфікації вимог і проектних специфікацій. Можливість імпорту, експорту та        редагування специфікацій з використанням формальної мови.    моделювання даних. Можливість введення і редагування        інформації, яка описує елементи даних системи і їх відносини.    моделювання процесів. Можливість введення і редагування        інформації, яка описує процеси системи та їх відносини.    проектування архітектури ПЗ. Проектування логічної структури ПЗ --        структури модулів, інтерфейсів та ін    імітаційне моделювання. Можливість динамічного моделювання        різних аспектів функціонування системи на основі специфікацій        вимог та/або проектних специфікацій, включаючи зовнішній інтерфейс і        продуктивність (наприклад, час відгуку, коефіцієнт використання        ресурсів і пропускну здатність).    Прототипування. Можливість проектування і генерації        попереднього варіанту всієї системи або її окремих компонентів на        основі специфікацій вимог і/або проектних специфікацій.        Прототипування в основному стосується зовнішнього користувача        інтерфейсу і здійснюється при безпосередній участі користувачів.    генерація екранних форм. Можливість створення екранних форм на основі        специфікацій вимог і/або проектних специфікацій.    можливість трасування. Можливість наскрізного аналізу        функціонування системи від специфікації вимог до кінцевих        результатів (встановлення і відстеження відповідностей та зв'язків між        функціональними та іншими зовнішніми вимогами до ІС, технічними        рішеннями і результатами проектування). Пряма трасування (перевірка        врахування всіх вимог) та зворотній трасування (пошук проектних рішень,        не пов'язані ні з якими зовнішніми вимогами).    синтаксичний і семантичний контроль        проектних специфікацій. Контроль        синтаксису діаграм і типів їх елементів, контроль декомпозиції функцій,        перевірка специфікацій на повноту і несуперечність.    інші види аналізу. Конкретні додаткові види аналізу можуть        включати алгоритми, потоки даних, нормалізацію даних, використання        даних, призначений для користувача інтерфейс.    автоматизоване проектування звітів.      Реалізація:
      Реалізація зачіпає функції, пов'язані зі створенням виконуваних       елементів системи (програмних кодів) та змін існуючої       системи. Багато хто з перерахованих нижче критеріїв залежать від конкретних       мов і включають наступні:       синтаксично кероване редагування. Можливість введення і редагування вихідних        кодів на одному або декількох мовах з одночасним синтаксичним        контролем.    генерація коду. Можливість генерації кодів на одному або        кількома мовами на основі проектних специфікацій. Типи що генерується        коду можуть включати звичайний програмний код, схему бази даних, запити,        екрани/меню.    компіляція коду.    конвертування вихідного коду. Можливість перетворення коду з одного        мови в іншу.    аналіз надійності. Можливість кількісно оцінювати параметри        надійності ПЗ, такі, як кількість помилок та ін    реверсний інжиніринг. Можливість аналізу існуючих вихідних        кодів і формування на їх основі проектних специфікацій.    реструктуризація вихідного коду. Можливість модифікації формату та/або        структури існуючого вихідного коду.    аналіз початкового коду. Прикладами такого аналізу можуть бути        визначення розміру коду, обчислення показників складності, генерація        перехресних посилань і перевірка на відповідність стандартам.    налагодження.        Типові функції налагодження - трасування програм, виділення вузьких місць і        найбільш часто використовуваних фрагментів коду і т.д.      Тестування:
      Критерії тестування включають наступні:       опис тестів. Типові можливості включають генерацію        тестових даних, алгоритмів тестування, необхідних результатів і т.д.    фіксація і повторення дій оператора. Можливість фіксувати дані, що вводяться        оператором за допомогою клавіатури, миші і т.д., редагувати їх і        відтворювати в тестових прикладах.    автоматичний запуск тестових прикладів.    регресійного тестування. Можливість повторення і модифікації раніше        виконаних тестів для визначення розходжень у системі та/або середовищі.    автоматизований аналіз результатів        тестування. Типові        можливості включають порівняння очікуваних і реальних результатів,        порівняння файлів, статистичний аналіз результатів та ін    аналіз тестового покриття. Оснащення засобами контролю вихідного        коду та аналіз тестового покриття. Перевіряються, зокрема, звернення до        операторам, процедур і змінним.    аналіз продуктивності. Можливість аналізу продуктивності        програм. Аналізовані параметри продуктивності можуть включати        використання центрального процесора, пам'яті, звернення до певних        елементів даних і/або сегментів коду, тимчасові характеристики і т.д.    аналіз виняткових ситуацій у процесі        тестування.    динамічне моделювання середовища. Зокрема, можливість автоматично        генерувати модельований вхідні дані системи.       Загальні функції:
     Наведені нижче критерії визначають функції CASE-засобів, що охоплюють      всю сукупність фаз ЖЦ. Підтримка всіх цих функцій здійснюється      за допомогою сховища.     Документування:       редагування текстів і графіки. Можливість вводити і редагувати дані в        текстовому і графічному форматі.    редагування за допомогою форм. Можливість підтримувати форми, певні        користувачами, вводити і редагувати дані у відповідності з формами.            можливості видавничих систем.    підтримка функцій і форматів гіпертексту.    відповідність стандартам документування.    автоматичний витяг даних з репозиторію        і генерація документації по специфікаціям користувача.      Управління конфігурацією:       контроль доступу і змін. Можливість контролю доступу на фізичному        рівні до елементів даних і контролю змін. Контроль доступу        включає можливості визначення прав доступу до компонентів, а також        вилучення елементів даних для модифікації, блокування доступу до них на        час модифікації і приміщення назад до головного сховища.    відстеження модифікацій. Фіксація і ведення журналу всіх модифікацій,        внесених в систему в процесі розробки або супроводу.    управління версіями. Ведення та контроль даних про версії системи і        всіх її колективно використовуваних компонентах.    облік стану об'єктів конфігураційного        управління. Можливість        одержання звітів про всіх послідовних версіях, вміст та стан        різних об'єктів конфігураційного управління.    генерація версій і модифікацій. Підтримка користувальницького опису        послідовності дій, необхідних для формування версій і        модифікацій, і автоматичне виконання цих дій.    архівування. Можливість автоматичного архівування елементів даних для        подальшого використання.      Управління проектом:       керування роботами і ресурсами. Контроль і управління процесом        проектування ІС в термінах структури завдань і призначення виконавців,        послідовності їх виконання, завершеності окремих етапів проекту        і проекту в цілому. Можливість підтримки планових даних, фактичних        даних та їх аналізу. Типові дані включають графіки (з урахуванням        календаря, робочих годин, вихідних та ін), комп'ютерні ресурси,        розподіл персоналу, бюджет та ін    оцінка.        Можливість оцінювати витрати, графік та інші проектні параметри,        вводяться користувачами.    управління процедурою тестування. Підтримка керування процедурами і програмою        тестування, наприклад, керування розкладом планованих процедур,        фіксація і запис результатів тестування, генерація звітів і т.д.    управління якістю. Введення відповідних даних, їх аналіз та        генерація звітів.    коригуючі дії. Підтримка керування коригуючими        діями, включаючи обробку повідомлень про проблемні ситуації.      Надійність  адміністрування сховища. Контроль та забезпечення цілісності      проектних даних.  автоматичне резервування (визначається постачальником або плановане      користувачем).  безпеку. Захист від несанкціонованого доступу.  обробка помилок. Виявлення помилок у роботі системи, повідомлення      користувача, коректне завершення роботи або збереження стану до      моменту переривання.  аналіз відмов у критичних додатках. 4.2.4.2. Простота використання  зручність для користувача інтерфейсу. Зручність розташування і      подання часто використовуваних елементів екрану, способів введення даних і      ін  локалізація (відповідно до вимог даної країни).  простота освоєння. Трудові і тимчасові витрати на освоєння      коштів.  адаптованість до конкретних потреб користувача.      Адаптованість до різних алфавіту, режимам текстового і графічного      представлення (зліва-направо, зверху-вниз), різних форматів дати,      способів введення/виводу (екранним форм і форматів), змін у      методології (змін графічних нотацій, правил, властивостей і складу      зумовлених об'єктів) та ін  якість документації (повнота, зрозумілість, легкість для читання,      корисність та ін.)  доступність і якість навчальних матеріалів. Вони можуть включати      комп'ютерні навчальні матеріали, навчальні посібники, курси.  вимоги до рівня знань. Кваліфікація і досвід, необхідні для      ефективного використання CASE-засобів.  простота роботи з CASE-засобом (як для початківців, так і для      досвідчених користувачів).  уніфікованість призначеного для користувача інтерфейсу (по відношенню до      інших засобів, що використовуються в даній організації).  онлайнові підказки (повнота і якість).  якість діагностики (зрозумілість і корисність діагностичних      повідомлень для користувача).  допустимий час реакції на дії користувача (в залежності      від середовища).  простота встановлення та оновлення версій. 4.2.4.3. Ефективність  вимоги до технічних засобів. Вимоги до оптимального      розміром зовнішньої та оперативної пам'яті, типу та продуктивності      процесора, що забезпечує прийнятний рівень продуктивності.  ефективність робочого навантаження. Ефективність виконання      CASE-засобом своїх функцій в залежності від інтенсивності роботи      користувача (наприклад, кількість натискань клавіш або кнопки миші,      потрібне для виконання певних функцій).  продуктивність. Час, що витрачається CASE-засобом для      виконання конкретних завдань (наприклад, час відповіді на запит, час      аналізу 100000 рядків коду). У деяких випадках дані оцінки      продуктивності можна отримати із зовнішніх джерел. 4.2.4.4. Сопровождаемость  рівень підтримки з боку постачальника (швидкість дозволу      проблем, поставки нових версій, забезпечення додаткових можливостей).  трасуванню оновлень (простота освоєння відмінностей нових версій      від існуючих).  сумісність оновлень (сумісність нових версій з      існуючими, включаючи, наприклад, сумісність з вхідним або вихідним      даними).  сопровождаемость кінцевого продукту (простота внесення змін до      ПЗ та документацію). 4.2.4.5. Переносимість  сумісність з версіями ОС (можливість роботи в середовищі різних      версій однієї і тієї ж ОС, простота модифікації CASE-засоби для роботи з      новими версіями ОС).  перенесення даних між різними версіями CASE-засоби.  відповідність стандартам переносимості. Такі стандарти включають      документацію, комунікації і призначений для користувача інтерфейс, віконний інтерфейс,      мови програмування, мови запитів і ін 4.2.4.6. Загальні критерії

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

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

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

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

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

Первісне використання нової CASE-технології в пілотному проекті має ретельно плануватися і контролюватися. Пілотний проект включає наступні кроки (малюнок 4.4).

Визначення характеристик пілотного проекту

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

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