Розділ «17. Проектування інформаційних систем. CASE - технології»

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

o відсутність прямих аналогів, що обмежує можливість використання типових проектних рішень і прикладних систем;

o необхідність узгодження існуючих додатків з новими розробками;

o функціонування в неоднорідному середовищі на декількох апаратних платформах;

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

o істотна тривалість проекту - обумовлена, з одного боку, обмеженими можливостями колективу розробників; з іншого боку, масштабами організації-замовника і різним ступенем готовності окремих її підрозділів до впровадження ІС.

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

У 70-х і 80-х роках при розробці ІС досить широко застосовувалася структурна методологія, що надає в розпорядження розробників чіткі формалізовані методи опису ІС і прийнятих технічних рішень. Вона заснована на наочній графічній техніці: для опису різного роду моделей ІС використовуються схеми і діаграми. Наочність і чіткість засобів структурного аналізу дозволяла розробникам і майбутнім користувачам системи із самого початку неформально брати участь у її створенні, обговорювати і закріплювати розуміння основних технічних рішень. Однак, широке застосування цієї методології і дотримання її рекомендацій при розробці ІС зустрічалося досить рідко, оскільки при неавтоматизованій (ручній) розробці це було практично неможливо. Вручну вкрай важко розробити і графічно представити строгі формальні специфікації системи, перевірити їх на повноту і несуперечливість, і тим більше змінити. Якщо все-таки вдається створити строгу систему проектних документів, то її переробка з появою суттєвих змін є практично нездійсненною задачею. Ручна розробка, як правило, породжувала наступні проблеми:

o неадекватна специфікація вимог;

o нездатність виявляти помилки в проектних рішеннях;

o низька якість документації, що знижує експлуатаційні якості;

o тривалий цикл і незадовільні результати тестування.

Підходи до створення інформаційних систем. Традиційні підходи до побудови інформаційних систем базуються на ідеї того, що на початку проекту складно визначити весь обсяг даних і які аналітичні задачі будуть розв'язуватись кінцевими користувачами. Наприклад, методологія Oracle DWM FT (Datawarehouse Method Fast Track - метод створення сховищ даних "високошвидкісна траса") виходить з припущення, що розробники впродовж цілого життєвого циклу інформаційної системи будуть визначати і аналізувати вимоги до сховища даних. Заснована на DSDM (Dynamic System Development Method - метод розробки динамічних систем) ця методологія реалізує підхід RAD (Rapid Application Development - швидка розробка аплікацій).

Згідно DSDM і Oracle DWM FT, цикл проектування проходить через створення ряду прототипів до тих пір, поки не будуть задоволені вимоги кінцевих користувачів. Для того, щоби цей цикл не став нескінченним, розробка поділяється на 120-денні часові відрізки (timebox), за які можливо виконати чітко визначений сталий набір вимог (за аналогією із ящиком для іграшок toybox, в який неможливо помістити додаткові іграшки, якщо не витягнути деякі з тих, що там вже є). Розробники стверджують, що завдяки гнучкості і простоті використання інструментів Business Intelligence, створення прототипів не представляє труднощів. Проте, застосування такого підходу є виправданим IT-фахівцями, які не прагнуть розширювати свої знання в даній області.

Методологія RAD отримала в наш час широке застосування у сфері створення автоматизованих інформаційних систем. Вона охоплює всі етапи життєвого циклу інформаційних систем.

Основні принципи RAD полягають в наступному:

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

o повне завершення робіт на кожному етапі життєвого циклу не є обов'язковим;

o застосування CASE-засобів і засобів швидкої розробки додатків;

o тестування і розвиток проекту здійснюється одночасно з розробкою.