Стрімке розроблення додатку RAD

Методологією розроблення додатків інформаційних систем, яка має на меті забезпечити швидку відповідь на потреби користувача, є стрімке розроблення додатка (rapid application

development (RAD). Цей термін, який запропонований комп'ютер­ним консультантом Мартіном Ямесом (Martin James), стосується швидкого створення життєвого циклу системи без погіршення її якості. Для цього підходу застосовуються й інші назви: швидке прототипування (Rapid Prototyping) або метод швидкого успіху (Quick-Hit Method, дослівно — метод натискування клавіш). Під­хід передбачає широке застосування різних технологічних засо­бів, зокрема, СППР-генераторів. Проте загальноприйнятих стан­дартів RAD щодо окреслення етапів і фаз розроблення інформа­ційних систем та діапазону застосовуваних технологічних засобів поки що не розроблено. Різні автори по-своєму трактують цю ме­тодологію.

Стрімке розроблення додатка (RAD) — це інтегрований ряд підходів, методологій та інструментальних засобів, що в сукуп­ності утворюють загальну стратегію розроблення СППР, яка на­зивається інформаційним інжинірингом. Термін «інформаційний інжиніринг» (Information engineering — IE) — запропонував М. Ямес для означення загального підходу до розроблення системи, що трактується як дії в межах фірми (підприємства).

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

Стосовно робочої сили, то скоріше, ніж використовувати одну команду, яка виконує всі дії з проектування життєвого циклу си­стеми, RAD передбачає можливість використовувати кілька спе­ціалізованих команд, що ефективніше. Члени цих команд мають бути фахівцями з методологій і інструментальних засобів розроб­лення систем, щоб виконати спеціалізовані завдання для швидко­го створення системи. М. Ямес використовує термін «SWAT team» — команда SWAT, де SWAT — абревіатура від «skilled with advanced tools».

Основна методологія RAD — це швидке розроблення життє­вого циклу, що складається з чотирьох фаз: планування вимог, проектування для користувача (user design), конструювання і пе­ремикання на нову систему (cutover). До методологічних засобів RAD належить і макетування.

Інструментальні засоби RAD складаються переважно з мов четвертого покоління (fourth-generation languages) і CASE—ін­струментальних засобів, які полегшують макетування і генеру­вання кодів (програм). Мови четвертого покоління надали мож-

ливість інформаційним спеціалістам або користувачам генеру­вати комп'ютерні коди без використання загальноприйнятих мов програмування. Прикладами мов четвертого покоління є Natural, FOCUS і SQL. Як уже зазначалося, за побудови СППР методом RAD застосовуються СППР-генератори.

Розглянемо особливості застосування швидкого макетування в методології RAD. Загальне описання макетування СППР для ме­тодології SDLC буде зроблено далі окремо.

Існують різні версії швидкого макетування. Типова методоло­гія макетування, зазвичай, включає п'ять кроків:

1. Ідентифікація вимог користувача.

2. Розроблення першого ітераційного прототипу СППР.

3. Дальший розвиток і модифікація ітераційного прототипу СППР.

4. Тестування СППР і повернення за необхідності до третього кроку.

5. Повномасштабне впровадження.

Макетування розвинулось як реакція на недоліки і обмеження SDLC-підходу. До розроблення СППР за цим методом аналітики разом з потенційними користувачами формулюють вимоги. Ці вимоги конкретизуються в загальних термінах орієнтованої на рішення діагностики і проектування. Аналітик потім розробляє прототип діючої системи.

Аналітики СППР використовують інструментальні засоби як, наприклад, системи керування базами даних і генератори задач додатків СППР, які сприяють прискоренню розроблення. Прото­тип не може дати відповіді на те, яким має бути доступ до реаль­ної бази даних, або яка екранна «допомога» потрібна. Ці та інші можливості потребують тривалого часу для розроблення. Влас­тивості, яких бракує, додаються пізніше, якщо тільки користувачі загалом задоволені тим, як функціонує прототип.

Швидке розроблення додатка RAD забезпечує послідовне нарощуване розроблення з постійним зворотним зв'язком із по­тенційними користувачами. Одного разу схвалений прототип може бути розширений у середовищі його розроблення або цей прототип може застосовуватися як специфікація для СППР, яка розробляється з використанням мови Java, С або C++. Коли прототип повторно програмується (репрограмується), то він стає деталізованою специфікацією і перетворюється в діючу си­стему. Найкращий підхід до розроблення на основі макетування — це коли фактично прототип розвивається безпосередньо в гото­вий виріб.

8.1.2. Фактори, які визначають інжиніринг СППР

Як і будь-яка інформаційна система, яка призначається для розв'язання певного кола завдань, система підтримки прийняття рішень створюється в результаті інжинірингу систем. Інжиніринг систем — це виконання систематизованого процесу — сукупно­сті дискретних і взаємопов'язаних кроків (фаз), з допомогою яких розв'язують певне завдання. Ці фази трансформують опера­ційні потреби (тобто потреби ОПР у підтримці і в системах для вдосконалення, розширення і посилення власних міркувань) у конкретну конфігурацію системи (апаратні засоби, програмне за­безпечення і необхідні периферійні пристрої, які можна за необ­хідності використовувати).

Процес інжинірингу (тобто процес проектування та розроб­лення) СППР значною мірою залежить від впливу таких факто­рів, які підлягають одночасному розгляду: середовища СППР; мети СППР; елементів СППР; способів об'єднання компонентів СППР; потрібних ресурсів.

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

Елементами, які зумовлюють дію середовища СППР, є: про­філь задачі; правила і процедури, які заздалегідь визначені в да­ній предметній галузі; рівень використання СППР (операційний, керівництво, стратегічне планування); фаза прийняття рішень, яка потребує підтримки; функціональна галузь; спосіб доступу (чи буде система дійсно інтерактивною).

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

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

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

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

Керування моделями і операціями моделювання сприяє логіч­ному вибиранню даних (за допомогою процесу, який керує мо­деллю). Сюди належить СКБМ, яка використовується для гене­рування, вибирання і поновлення відповідних параметрів, пере-структурування моделей і створення «довідника» моделей; засто­сування моделей; процесор команд моделювання та необхідний інтерфейс бази даних.

Важлива роль в інженерії СППР відводиться зв'язкам інтер­фейсу користувача, бази моделей і СКБМ, бази даних і СКБД із переліченими вище елементами середовища СППР.

Аналізуючи ресурси, які потрібно використовувати в процесі інжинірингу СППР, необхідно звернути увагу на наявність апа­ратних засобів оброблення інформації і на розроблення або при­дбання засобів програмного забезпечення, на забезпечення тру­довими ресурсами і необхідними даними.

Розглядом цих факторів, упорядкованих у заданій послідовно­сті, реалізується ідея системного підходу до створення складного проекту: аналіз факторів дає змогу відтворити етапи, починаючи з побудови загальної схеми ситуації в контексті прийняття рі­шень і закінчуючи абстрактним проектом системи, який потім розглядається з урахуванням наявних ресурсів. Такий ідеалізова­ний проект СППР у довгостроковому плані має потенційну цін­ність, оскільки розроблення комп'ютерних систем часто являє

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

8.1.3. Рекомендації щодо проектування СППР на основі підходу з урахуванням життєвого циклу системи

Перехід від абстрактного системного підходу стосовно створення СППР до фаз реалізації процесу проектування стиму­лює необхідність створення гнучкої методології проектування, яка б враховувала всі аспекти життєвого циклу системи. Життєвим циклом СППР називається сукупність взаємопов'язаних процесів створення і послідовних змін стану СППР від формулювання вихід­них вимог до закінчення експлуатації системи. Хоча важко запро­понувати універсальну методологію проектування СППР, але на­явний досвід створення і впровадження цих інтерактивних систем уможливлює формулювання загальних рекомендацій, які може використовувати проектувальник з метою створення влас­ної концепції розроблення СППР стосовно своїх потреб. Доціль­но розглянути такі найважливіші властивості прцесу проектуван-ня СППР:

1) «мігруюча» система і проблема — проектування системи, а також ступінь розуміння проблеми змінюються з часом. Ці змі­ни викликані динамічними аспектами впровадження СППР. Од­ночасний вплив двох процесів — навчання ОПР і побудови СППР — суттєво ускладнюють окреслення точних меж системи;

2) еволюція системи — в процесі проектування передбача­ється розширення можливостей СППР;

3) «м'які» і «тверді» можливості СППР — узагальнені та іс­нуючі «м'які» можливості пізніше перетворюються у «тверді» і здійснюються. Це пояснюється тільки тією обставиною, що на початку користувач у змозі вкласти більше зусиль у науку і ви­тратити більше засобів на побудову систем, ніж у наступних фазах;

4) «слабке» і «сильне» проектування — необхідно визначи­ти ознаки відмінності в процесі проектування між «слабким» і «сильним» підходами: у разі «слабкого» підходу враховуються тільки пріоритети ОПР за існуючих можливостей комп'ютера. Замовник не чинить тиску на користувача (тобто на особу, яка приймає рішення). «Сильний» підхід проявляється як результат

тиску з боку замовника з метою підвищення результативності прийняття рішень ОПР, у той час як ця особа поводиться пасив­но, боячись змін. У такому разі бракує внутрішньої мотивації у користувача щодо змін у процесі прийняття рішень.

Основним аспектом процесу проектування, який визначає стратегію створення системи, є «навчання»: СППР не розв'язує проблему до кінця, а лише посилює використання власного умін­ня ОПР у розв'язанні проблеми. Отже, метою побудови СППР спочатку є підтримка, а потім — розвиток підтримки стосовно прийняття рішень. Ініціююча система має бути настільки близь­кою до процесу прийняття рішень (тобто до процедур, викону­ваних ОПР у вигляді діалогу наказів), щоб стати легкою і при­вабливою для користувача.

Проектувальники

Поиск по сайту: