АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

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

Читайте также:
  1. Напрями розроблення «наукової філософії» в ХІХ ст.
  2. Наукові підходи до розроблення управлінських рішень.
  3. ПРОДОВЖЕННЯ ДОДАТКУ 2
  4. Продовження додатку Ж
  5. Розроблення остаточної редакції проекту та підготування справи НД
  6. Стаття 7. Розроблення, погодження та затвердження проекту
  7. Структура Додатку ЗВ до Декларації про прибуток підприємства
  8. Теорія розроблення СППР

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


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

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

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


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

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

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


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 |

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



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.004 сек.)