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

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

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

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

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

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

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

• експортні обмеження.

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

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

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

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

4.2.5. Приклад підходу до визначення критеріїв вибору case-засобів

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

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

Традиційно при обговоренні проблеми вибору CASE-засобів велика увага приділялася особливостям реалізації тієї чи іншої методології аналізу наочної області (E-R, IDEF0, IDEF1Х, Gane/Sarson, Yourdon, Barker і ін.). Безумовно, багатство образотворчих і описових засобів дає можливість на етапах стратегічного планування і аналізу побудувати якнайповнішу і адекватну модель наочної області. З іншої сторони, якщо говорити про кінцеві результати у базах даних і додатках, то виявляється, що частина описів в них практично не відображається, залишаючись декларативною (на виході ми у будь-якому випадку отримаємо опис БД в табличному уявленні з мінімальним набором обмежень цілісності і певним кодом додатків, велику частину яких складають екранні форми, що не виводяться безпосередньо з моделей наочної області). Досвідчені аналітики і проектувальники завжди з більшими або меншими стараннями прийдуть до потрібного кінцевого результату незважаючи на те, яка конкретно методологія або її різновид реалізований в даному інструменті. Це, звичайно, не означає, що методологія не важлива, навпаки, відсутність або неповнота описових засобів можуть значно ускладнити роботу над проектом. Проте, часто на першому плані виявляються інші критерії, невиконання яких може породити набагато більші труднощі.

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

Виходячи з перерахованих вище міркувань, як основні критерії вибору CASE-засобів приймаються наступні критерії:

1. Підтримання повного життєвого циклу ІС із забезпеченням еволюції її розвитку

Повний життєвий цикл ІС повинен підтримуватися комплексом інструментальних засобів, перерахованих в розділі 3.2, з урахуванням наступних особливостей:

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

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

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

Забезпечення цілісності проекту і контролю за його станом

Дана вимога означає наявність єдиного технологічного середовища створення, супроводу і розвитку ІС. Єдине технологічне середовище повинне забезпечуватися за рахунок використовування єдиного CASE-засобу для підтримки моделей ІС, а також за рахунок наявності програмно-технологічних інтерфейсів між окремими інструментальними засобами, сертифікованих і підтримуваних фірмами-розробниками відповідних засобів. Зокрема, інтерфейс між CASE-засобами і засобами розробки додатків повинен виконувати дві основні функції: а) безпосередній перехід в рамках єдиного середовища від опису логіки додатку, реалізованого CASE-засобом, до розробки призначеного для користувача інтерфейсу (екранних форм); б) перенесення опису БД з репозиторія CASE-засобу в репозиторій засобу розробки додатків і назад. Вся інформація про проект повинна автоматично поміщатися в базу проектних даних, при цьому повинна підтримуватися узгодженість, несуперечність, повнота і мінімальна надмірність проекту, а також коректність операцій його редагування. Цього може бути досягнуто за умови виключення або істотного обмеження можливості актуалізації репозиторія різними засобами. В рамках CASE-засобу повинен забезпечуватися контроль відповідності декомпозицій діаграм, а також контроль відповідності діаграм різних типів (наприклад, діаграм потоків даних і ER-діаграм).

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

3. Незалежність від програмно-апаратної платформи і СУБД

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

4. Підтримання одночасної роботи груп розробників

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

5. Можливість розробки додатків "клієнт-сервер” необхідної конфігурації

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

6. Відкрита архітектура і можливості експорту/імпорту

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

7. Якість технічної підтримки в Росії, вартість придбання і підтримання, досвід успішного використання

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

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

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

8. Простота освоєння і використання

Враховуються наступні характеристики:

• відповідність інструменту особливостям і потенційним можливостям колективу розробників;

• доступність призначеного для користувача інтерфейсу;

• час, необхідний для навчання;

• простота установки;

• якість документації;

• об'єм ручної праці при супроводі ІС.