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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Забезпечення якості проектної документації

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

1. Використання загальноприйнятих, стандартних нотацій і угод

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

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

Виконання пілотного проекту

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

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

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

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

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

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