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

Приклад підходу до визначення критеріїв вибору 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-засобів аналізувати і перевіряти опису та документацію на повноту і несуперечність, а також на відповідність до прийнятих в даній методології стандартів та правил (включаючи ГОСТ, еурд). У результаті аналізу повинна формуватися інформація, що вказує на наявні суперечності або неповноту в проектній документації. Повинна бути також забезпечена можливість створювати нові форми документів, що визначаються користувачами.  Використання загальноприйнятих, стандартних нотацій і угод

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

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