Приклад підходу до визначення критеріїв вибору CASE-засобів наведено в [1]. Передбачається, що CASE-засоби будуть використані в крупному типовому проекті ІС, що володіє характеристиками, перерахованими у вступі. У загальному випадку стратегія вибору CASE-засобів для конкретного застосування залежить від цілей, потреб і обмежень майбутнього проекту ІС (включаючи кваліфікацію беруть участь у процесі проектування фахівців), які, у свою чергу, визначають використовувану методологію проектування.
Слід підкреслити, що визначальним фактором при виборі тих чи інших інструментальних засобів є використовувана методологія і технологія проектування, а не навпаки. З цієї точки зору безглуздо порівнювати CASE-засоби самі по собі у відриві від методології, оскільки ІС можна в принципі розробити будь-якими засобами.
Традиційно під час обговорення проблеми вибору CASE-засобів велика увага приділялася особливостям реалізації тієї чи іншої методології аналізу предметної області (ER, IDEF0, IDEF1Х, Gane / Sarson, Yourdon, Barker та ін.) Безумовно, багатство образотворчих і описових засобів дає можливість на етапах стратегічного планування та аналізу побудувати найбільш повну та адекватну модель предметної області. З іншого боку, якщо говорити про кінцеві результати - базах даних і додатках, то виявляється, що частина описів у них практично не відбивається, залишаючись суто декларативною (на виході ми в будь-якому випадку отримаємо опис БД в табличному представленні з мінімальним набором обмежень цілісності і здійснимих код додатків, більшу частину яких складають екранні форми, не виведені безпосередньо з моделей предметної області). Досвідчені аналітики і проектувальники завжди з більшими чи меншими трудовитратами прийдуть до потрібного кінцевого результату незалежно від того, яка конкретно методологія чи її різновид реалізована в даному інструменті. Це, звичайно, не означає, що методологія не важлива, навпаки, відсутність або неповнота описових засобів можуть з самого початку значно ускладнити роботу над проектом. Однак, часто на першому плані виявляються інші критерії, невиконання яких може породити набагато більші труднощі.
Як було зазначено в підрозділі 1.3, технологія проектування повинна бути підтримана комплексом узгоджених CASE-засобів, що забезпечують автоматизацію процесів, які виконуються на всіх стадіях ЖЦ. Може скластися враження, що якщо можна сформувати необхідну апаратну платформу з компонентів різних фірм-виробників, то так само просто можна вибрати і скомплексіровать різні інструментальні засоби, кожне з яких є одним зі світових лідерів у своєму класі. Однак для інструментальних засобів в даний час, на відміну від обладнання, відсутні міжнародні стандарти на основні властивості кінцевих продуктів (програм, баз даних і їхнє сполучення). Оскільки складові частини проекту повинні бути інтегровані в єдиний продукт, отже, має сенс розглядати не будь-які, а тільки пов'язані інструментальні засоби, які в принципі можуть бути орієнтовані - навіть всередині одного класу - на різні методології; при цьому необхідно відбирати до складу комплексу CASE- коштів засоби, що підтримують принаймні близькі методології, якщо не одну й ту ж.
Виходячи з перерахованих вище міркувань, в якості основних критеріїв вибору CASE-засобів приймаються такі критерії:
Підтримка повного життєвого циклу ІС з забезпеченням еволюційності її розвиткуПовний життєвий цикл ІС повинен підтримуватися комплексом інструментальних засобів, перерахованих в розділі 3.2, з урахуванням таких особливостей:
колективного характеру розробки моделей, проектних специфікацій та програм територіально розподіленими групами фахівців з використанням різних інструментальних засобів (включаючи їх інтеграцію, тестування і налагодження); необхідності адаптації типового проекту до різних системно-технічним платформ (технічним засобам, операційним системам і СУБД) та організаційно- економічним особливостям об'єктів впровадження; необхідності інтеграції з існуючими розробками (включаючи реінжиніринг додатків і конвертація БД). Для існуючих ІС повинен забезпечуватись плавний перехід зі старої середовища експлуатації в нову з мінімальними переробками і підтримкою експлуатованих баз даних і додатків, впроваджених до початку робіт по створенню нової системи. Забезпечення цілісності проекту і контролю за його станомДана вимога означає наявність єдиної технологічної середовища створення, супроводу і розвитку ІВ, а також цілісність сховища. Єдина технологічна середовище має забезпечуватися за рахунок використання єдиного CASE-засоби для підтримки моделей ІС, а також за рахунок наявності програмно-технологічних інтерфейсів між окремими інструментальними засобами, сертифікованих і підтримуваних фірмами-розробниками відповідних коштів. Зокрема, інтерфейс між CASE-засобами і засобами розробки додатків повинен виконувати дві основні функції: а) безпосередній перехід у рамках єдиного середовища від опису логіки додатка, реалізованого CASE-засобом, до розробки користувальницького інтерфейсу (екранних форм), б) перенесення опису БД з репозиторію CASE-засоби в репозиторій засоби розробки додатків і назад. Вся інформація про проект повинна автоматично поміщатися в базу проектних даних, при цьому повинні підтримуватися узгодженість, несуперечність, повнота і мінімальна надмірність проекту, а також коректність операцій його редагування. Це може бути досягнуто за умови виключення або суттєвого обмеження можливості актуалізації репозиторія різними засобами. У рамках CASE-засобу повинен забезпечуватися контроль відповідності декомпозицій діаграм, а також контроль відповідності діаграм різних типів (наприклад, діаграм потоків даних і ER-діаграм).
Невиконання вимоги цілісності в умовах роз'єднаності розробників і тимчасової протяжності великого проекту може означати втрату контролю за його станом.
Незалежність від програмно-апаратної платформи і СУБДВимога визначається неоднорідністю середовища функціонування ІС. Така незалежність може мати дві складові: незалежність середовища розробки і незалежність середовища експлуатації додатків. Вона забезпечується за рахунок наявності сумісних версій CASE-засобів для різних платформ і драйверів відповідних мережевих протоколів, менеджерів транзакцій і СУБД.
Підтримка одночасної роботи груп розробниківРозвинені CASE-засоби повинні мати можливості поділу повноважень персоналу розробників та об'єднання окремих робіт у загальний проект. Повинна забезпечуватися одночасна (в заданій мережевої конфігурації) робота проектувальників БД та розробників додатків (розробники додатків в такій ситуації можуть починати роботу з базою даних, не чекаючи повного завершення її проектування CASE-засобами). При цьому всі групи фахівців повинні бути забезпечені адекватним інструментарієм, а внесення змін до проекту різними розробниками повинно бути узгодженим і коректним. Кожен розробник повинен мати можливість роботи зі своїм особистим репозиторієм, що є фрагментом або копією загального сховища. Повинні забезпечуватися змістовна інтеграція всіх змін, що вносяться розробниками, загалом репозиторії, одночасна доступність для розробника загального та особистого репозиторіїв і простота перенесення об'єктів між ними.
Можливість розробки додатків "клієнт-сервер" необхідної конфігураціїМається на увазі поєднання наявності розвиненої графічної середовища розробки додатків (многооконность, різноманітність стандартних графічних об'єктів, різноманітність використовуваних шрифтів і т.д.) з можливістю декомпозиції (partitioning) додатки на "клієнтську" частина, що реалізує користувальницький екранний інтерфейс і "серверну" частина. При цьому повинна забезпечуватися можливість переміщення окремих компонентів додатка між "клієнтом" і "сервером" на найбільш підходящу платформу, що забезпечує максимальну ефективність функціонування програми в цілому, а також можливість використання сервера додатків (менеджера транзакцій).
Відкрита архітектура і можливості експорту / імпортуВідкрита і загальнодоступна інформація про використовувані форматах даних і прикладних програмних інтерфейсах повинна дозволяти інтегрувати інструментальні засоби третіх фірм і відносно безболісно переходити від однієї системи до іншої. Можливості експорту / імпорту означають, що специфікації, отримані на етапах аналізу, проектування і реалізації для однієї ІС, можуть бути використані для проектування іншої ІС. Повторне проектування і реалізація можуть бути забезпечені за допомогою засобів експорту / імпорту специфікацій у різні CASE-засоби.
Якість технічної підтримки в Росії, вартість придбання та підтримки, досвід успішного використанняМається на увазі наявність кваліфікованих дистриб'юторів і консультантів, швидкість обслуговування користувачів, високу якість технічної підтримки і навчання продукту і методології його застосування для великих колективів розробників (наявність відомостей про практику використання системи, якість документації, укомплектованість прикладами та навчальними курсами, наявність пілотних проектів). Витрати на навчання новим технологіям значні, проте втрати від використання сучасних складних технологій ненавченими фахівцями можуть виявитися значно вище.
Крім того, фірми-постачальники інструментальних засобів повинні бути стійкими, оскільки технологія вибирається не на один рік, а також повинні забезпечувати хорошу підтримку на території Росії (гаряча лінія, консультації, навчання, консалтинг), можливо, через дистриб'юторів.
Що стосується вартості, слід враховувати можливість отримання безкоштовної тимчасової ліцензії, вартість ліцензії на одне робоче місце CASE-засобів, знижки, надані фірмою у разі придбання великої кількості ліцензій, необхідність придбання run-time версій для експлуатації додатків і т.д. У той же час вартість продукту повинна розглядатися не сама по собі, а з урахуванням її відповідності можливостям продукту.
Простота освоєння і використанняВраховуються такі характеристики:
відповідність інструмента особливостям і потенційним можливостям колективу розробників; доступність для користувача інтерфейсу; час, необхідний для навчання; простота установки; якість документації; обсяг ручної праці при супроводі ІС. Забезпечення якості проектної документаціїЦя вимога ставиться до можливостей CASE-засобів аналізувати і перевіряти опису та документацію на повноту і несуперечність, а також на відповідність прийнятим у даній методології стандартам і правилам (включаючи ГОСТ, ЕСПД). У результаті аналізу повинна формуватися інформація, яка вказує на наявні протиріччя або неповноту у проектній документації. Повинна бути також забезпечена можливість створювати нові форми документів, що визначаються користувачами.
Використання загальноприйнятих, стандартних нотацій та угодДля того, щоб проект міг виконуватися різними колективами розробників, необхідно використання стандартних методів моделювання і стандартних нотацій, які повинні бути оформлені у вигляді нормативів до початку процесу проектування. Недотримання проектних стандартів ставить розробників в залежність від фірми-виробника цього засобу, робить скрутним формальний контроль коректності проектних рішень і знижує можливості залучення додаткових колективів розробників, зміни виконавців і відчуження проекту, оскільки число фахівців, знайомих з даним методом (нотацією) може бути обмеженим.
У результаті виконаного аналізу може виявитися, що жодне доступний засіб не задовольняє в потрібній мірі всім основним критеріям і не покриває всі потреби проекту. У цьому випадку може застосовуватися набір засобів, що дозволяє побудувати на їх базі єдину технологічну середу.