Материал: Порівняння Silverrun та CA ERwin Data Modeler на прикладі роботи інтернет-магазину

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

Спадний підхід рекомендується для відносно зрілих організацій з усталеним процесом створення і супроводу ПЗ, які прагнуть вкласти всі необхідні ресурси в повністю закінчену роботу. Щоб підвищити ймовірність успіху, потрібно прийняття серйозних зобов'язань з боку як керівництва, так і потенційних користувачів.

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

Переваги даного підходу полягають в наступному:

·        невелика автоматизація може бути виконана при мінімальних витратах;

·        автоматизація може бути виконана за короткий проміжок часу, дозволяючи швидко усунути відомі недоліки в існуючих процесах;

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

Недоліки даного підходу полягають в наступному:

·        кошти, придбані як результат окремих взятих застосувань даного підходу, можуть погано інтегруватися між собою. Це може призвести до необхідності виконання великого обсягу ручної роботи;

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

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

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

.6 Оцінка і вибір CASE-засобів

.6.1 Загальні відомості

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

Процес оцінки і вибору може переслідувати кілька цілей, включаючи одну або більше з наступних:

·        оцінка декількох CASE-засобів і вибір одного або більше з них;

·        оцінка одного або більше CASE-засобів і збереження результатів для подальшого використання;

·        вибір одного або більше CASE-засобів з використанням результатів попередніх оцінок.

Рис.1.2 - Модель процесу оцінки і вибору

Як видно з рисунка, вхідною інформацією для процесу оцінки є:

·        визначення користувальницьких потреб;

·        цілі та обмеження проекту;

·        дані про доступні CASE-засобах;

·        список критеріїв, які використовуються в процесі оцінки.

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

Елементи процесу включають:

·        цілі, припущення та обмеження, які можуть уточнюватися в ході процесу;

·        потреби користувачів, що відображають кількісні та якісні вимоги користувачів до CASE-засобів;

·        критерії, що визначають набір параметрів, відповідно до яких проводиться оцінка і прийняття рішення про вибір;

·        формалізовані результати оцінок одного або більше засобів;

·        рекомендований рішення (зазвичай або рішення про вибір, або подальша оцінка).

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

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

Визначення переліку критеріїв засноване на користувацьких вимогах і включає:

·        вибір критеріїв для використання з наведеного далі переліку;

·        визначення додаткових критеріїв;

·        визначення області використання кожного критерію (оцінка, вибір або обидва процесу);

·        визначення однієї або більше метрик для кожного критерію оцінки;

·        призначення ваги кожним критерієм при виборі.

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

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

·        підтвердити достовірність результатів оцінки та вибору;

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

·        зібрати інформацію, необхідну для розробки плану практичного впровадження;

·        придбати власний досвід використання CASE-засоби.

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

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

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

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

Пілотний проект повинен володіти наступними характеристиками:

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

·        Масштабованість. Результати, отримані в пілотному проекті, повинні показати масштабованість кошти. Мета - отримати чітке уявлення про масштаби проектів, для яких даний засіб застосовно.

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

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

·        Авторитетність. Група фахівців, що беруть участь в проекті, повинна володіти високим авторитетом, при цьому результати проекту будуть всерйоз сприйняті іншими співробітниками організації.

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

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

Крім того, організація повинна враховувати тривалість пілотного проекту (і в цілому процесу впровадження). Занадто тривалий проект пов'язаний з ризиком втрати інтересу до нього з боку керівництва.

2. Розгляд CASE-засобу Silverrun

.1 Silverrun

CASE-средство Silverrun американської фірми Сomputer Systems Advisers, Inc. (CSA) використовується для аналізу і проектування ІС бізнес-класу і орієнтоване більшою мірою на спіральну модель ЖЦ. Воно застосовується для підтримки будь-якої методології, заснованої на роздільному побудові функціональної та інформаційної моделей (діаграм потоків даних і діаграм "сутність-зв'язок").

Налаштування на конкретну методологію забезпечується вибором необхідної графічної нотації моделей і набору правил перевірки проектних специфікацій. У системі є готові налаштування для найбільш поширених методологій: DATARUN (основна методологія, підтримувана Silverrun), Gane / Sarson, Yourdon / DeMarco, Merise, Ward / Mellor, Information Engineering. Для кожного поняття, введеного в проекті є можливість додавання власних описувачів. Архітектура Silverrun дозволяє нарощувати середовище розробки в міру необхідності.

.2 Структура і функції

має модульну структуру і складається з чотирьох модулів, кожен з яких є самостійним продуктом і може набуватися і використовуватися без зв'язку з іншими модулями.

Модуль побудови моделей бізнес-процесів у формі діаграм потоків даних (BPM - Business Process Modeler) дозволяє моделювати функціонування обстежуваної організації або створюваної ІВ. У модулі BPM забезпечена можливість роботи з моделями великої складності: автоматична перенумерація, робота з деревом процесів (включаючи візуальне перетягування гілок), від'єднання і приєднання частин моделі для колективної розробки. Діаграми можуть зображуватися в декількох наперед нотациях, включаючи Yourdon / DeMarco і Gane / Sarson. Є також можливість створювати власні нотації, у тому числі додавати в число зображуваних на схемою дескрипторів певні користувачем поля.

Модуль концептуального моделювання даних (ERX - Entity-Relationship eXpert) забезпечує побудову моделей даних "сутність-зв'язок", не прив'язаних до конкретної реалізації. Цей модуль має вбудовану експертну систему, що дозволяє створити коректну нормалізовану модель даних за допомогою відповідей на змістовні питання про взаємозв'язок даних. Можливе автоматичне побудова моделі даних з описів структур даних. Аналіз функціональних залежностей атрибутів дає можливість перевірити відповідність моделі вимогам третього нормальної форми і забезпечити їх виконання. Перевірена модель передається в модуль RDM.

Модуль реляційного моделювання (RDM - Relational Data Modeler) дозволяє створювати деталізовані моделі "сутність-зв'язок", призначені для реалізації в реляційної базі даних. У цьому модулі документуються всі конструкції, пов'язані з побудовою бази даних: індекси, тригери, збережені процедури і т.д. Гнучка змінна нотація і розширюваність репозиторію дозволяють працювати по будь-якої методології. Можливість створювати подсхеми відповідає підходу ANSI SPARC до подання схеми бази даних. Мовою подсхем моделюються як вузли розподіленої обробки, так і для користувача вистави. Цей модуль забезпечує проектування і повне документування реляційних баз даних.

Менеджер репозиторію робочої групи (WRM - Workgroup Repository Manager) застосовується як словник даних для зберігання спільної всіх моделей інформації, а також забезпечує інтеграцію модулів Silverrun в єдине середовище проектування.

Платою за високу гнучкість і різноманітність образотворчих засобів побудови моделей є такий недолік Silverrun, як відсутність жорсткого взаємного контролю між компонентами різних моделей (наприклад, можливості автоматичного розповсюдження змін між DFD різних рівнів декомпозиції). Слід, однак, відзначити, що цей недолік може мати суттєве значення тільки у випадку використання каскадної моделі ЖЦ ПЗ.

.3 Взаємодія з іншими засобами

Для автоматичної генерації схем баз даних у Silverrun існують мости до найбільш поширених СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачі даних в засоби розробки додатків є мости до мов 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Всі мости дозволяють завантажити в Silverrun RDM інформацію з каталогів відповідних СУБД або мов 4GL. Це дозволяє документувати, перепроектувати або переносити на нові платформи вже перебувають в експлуатації бази даних і прикладні системи. При використанні моста Silverrun розширює свій внутрішній репозиторій специфічними для цільової системи атрибутами. Після визначення значень цих атрибутів генератор додатків переносить їх у внутрішній каталог середовища розробки або використовує при генерації коду на мові SQL. Таким чином можна повністю визначити ядро ​​бази даних з використанням всіх можливостей конкретної СУБД: тригерів, збережених процедур, обмежень посилальної цілісності. При створенні програми на мові 4GL дані, перенесені з репозиторію Silverrun, використовуються або для автоматичної генерації інтерфейсних об'єктів, або для швидкого їх створення вручну.

Для обміну даними з іншими засобами автоматизації проектування, створення спеціалізованих процедур аналізу та перевірки проектних специфікацій, складання спеціалізованих звітів у відповідності з різними стандартами в системі Silverrun є три способи видачі проектної інформації в зовнішні файли:

·        Система звітів. Можна, визначивши вміст звіту по репозиторію, видати звіт в текстовий файл. Цей файл можна потім завантажити в текстовий редактор або включити в інший звіт;

·        Система експорту / імпорту. Для більш повного контролю над структурою файлів в системі експорту / імпорту є можливість визначати не тільки вміст експортного файлу, але і роздільники записів, полів в записах, маркери початку і кінця текстових полів. Файли з вказаною структурою можна не тільки формувати, але й завантажувати в репозиторій. Це дає можливість обмінюватися даними з різними системами: іншими CASE-засобами, СУБД, текстовими редакторами і електронними таблицями;

·        Зберігання репозиторію в зовнішніх файлах через ODBC-драйвери. Для доступу до даних сховища з найбільш поширених систем управління базами даних забезпечена можливість зберігати всю проектну інформацію безпосередньо у форматі цих СУБД.