Інформаційні системи в міжнародному бізнесі - Навчальний посібник (Гужва В. М., Постєвой А. Г.)

4.2. основні положення британської технології розробки автоматизованих систем ssadm

4.2.1. Загальна характеристика технології SSADM

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

Універсальність технології SSADM має і зворотний бік — вона не охоплює всього життєвого циклу автоматизованих систем (рис. 4.1). З рисунка видно, що технологія застосовується після того, як визначено стратегію автоматизації, що має бути відображена в тактико-технічному завданні. Технологічний процес SSADM підтримує аналіз реалізованості запропонованого завдання, визначені вимоги до нової АС, а також її проектування. У свою чергу проектування поділяється на дві стадії — логічне й фізичне. При цьому логічне проектування передбачає прийняття технічних рішень безвідносно до середовища реалізації, тобто до системи програмування, ОС, СУБД і апаратури. На стадії фізичного проектування відбувається прив’язка логічного проектування до такого середовища.

 

 

Рис. 4.1. Місце технології SSАDM у життєвому циклі

автоматизованої системи

Основні принципи технології SSADM

Розробники технології SSADM виходили з таких принципів:

1) постійного залучення представників майбутніх користувачів до процесу вироблення рішень протягом усього проектування АС;

2) чіткої структуризації технологічного процесу, взаємної ув’язки стадій, етапів і проектних процедур, явної регламентації ролей усіх учасників розробки;

3) ефективного контролю за ходом розробки з боку керів­ників проекту, вбудованого контролю якості проектування на базі формалізованих критеріїв, можливості використання існую­чих технологій автоматизованого управління розробкою;

4) ув’язування з технологіями, реалізованими в існуючих системах програмування та управління базами даних;

5) формалізації процесу розробки, яка забезпечує широке використання засобів автоматизації проектування.

Загалом у технології SSADM можна умовно виділити дві основні складові частини: типовий технологічний процес і методичне забезпечення.

4.2.2. Типовий технологічний процес SSADM

На рис. 4.1 показано типовий технологічних процес (ТПП), який складається з п’яти узагальнених стадій. У свою чергу ці стадії поділяються на сім дрібніших стадій, стадії — на етапи, а етапи — на операції. На рис. 4.2 зображено структурну схему ТПП. На ній, зокрема, наведено основні проектні документи, які розробляються на відповідних стадіях. Деякі документи, наприклад Каталог вимог і Логічна модель даних, є вихідними документами для деяких стадій. Це свідчить про ітераційний характер процесу вироблення проектних рішень у рамках техно­логії SSADM.

Далі наведемо короткий опис робіт, що виконуються на кож­ній стадії.

Стадія 0. Оцінювання реалізованості. Стадія необов’язкова, оскільки передбачені на ній роботи виконуються, як правило, при розробці стратегії автоматизації. Якщо проект досить складний, то на цій стадії розробляють загальний задум і оцінюють витрати і очікуваний ефект з урахуванням наявних ресурсів.

Стадія 1. Передпроектне обстеження. Мета стадії — побудувати формалізовану модель існуючої системи або організації, виявити її недоліки і сформулювати основні вимоги до нової системи, які поки що в неформалізованому вигляді відобража­ють у Каталозі вимог. Оцінюють важливість кожної виявленої вимоги (наприклад, за трибальною шкалою). Для моделювання використовують зображення існуючої системи у формі Схем інформаційних потоків (СІП). Дані, що обробляються, документують у вигляді логічної схеми даних (ЛСД).

 

Заявка (ТТЗ) на створення АС

 

Рис. 4.2. Узагальнена система типового технологічного процесу SSADM

Стадія 2. Вибір варіанта автоматизації. Мета — розробити кілька можливих варіантів побудови нової системи і вибрати з них найкращий. Вимоги, зафіксовані на попередній стадії, проектувальники розбивають на кілька перехресних множин залежно від їх важливості і з урахуванням їх змісту. Для кожної також групи складають короткий опис варіанта побудови нової системи і дають якісну, а якщо можливо, і кількісну оцінку його вартості та ефективності. Наприклад, в одну групу можуть бути включені лише вимоги з найвищим пріоритетом, а в іншу — всі виявлені вимоги. Першій з них відповідає найдешевший варіант системи, що забезпечує реалізацію мінімального набору функ­цій, а другій — найдорожчий варіант з найбільш повними функ­ціональними можливостями. Ці два варіанти утворюють кордони, в межах яких слід з урахуванням обмежень на виділені ресурси шукати компромісне рішення. Для цього складають і оці­нюють ще кілька проміжних варіантів, а для остаточного розгляду відбирають два-три найбільш прийнятних, для яких складають більш детальний опис і оцінки. Ці варіанти пред’являють замовникові і представникам майбутніх користувачів, які серед найкращих вибирають кінцевий варіант.

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

Стадія 4. Вибір варіанта технічної реалізації. Мета — визначення найбільш прийнятного варіанта середовища програмної реалізації, а також складу і конфігурації технічних засобів. На основі відомостей, що містяться в технічному завданні, оціню­ють потрібні продуктивність обчислювального пристрою і обсяг пам’яті, які необхідні для зберігання і обробки даних. Це дає змогу також конкретизувати вимоги до програмного середовища реалізації, звузити коло пошуку відповідних програмних засобів і систем. При цьому розробляють кілька можливих ва­ріантів і кожний з них оцінюють виходячи з критерію вар­тість/ефективність. З урахуванням усіх істотних чинників, що впливають на якість майбутньої системи, остаточно зупиняються на найбільш прийнятному варіанті.

Стадія 5. Розробка логічного проекту. Мета — спроектувати комплекс програмних засобів на логічному рівні, тобто на незалежному від середовища реалізації. Ці проектні роботи виконуються одночасно зі стадією 4. На основі технічного завдання спочатку розробляють логіку діалогової взаємодії. Потім проектують алгоритми задач обробки даних, а також інформаційних задач. При цьому, якщо необхідно, уточнюють каталог вимог і логічну модель даних. Розроблені проектні документи погоджують між собою і об’єднують разом з ЛМД у логічний проект.

Стадія 6. Фізичне проектування. Мета — згенерувати роботоздатний фізичний опис даних у вибраному середовищі реалізації і розробити завдання на створення програмних компонентів майбутньої АС. На базі існуючої логічної моделі даних розробляють первісний варіант її фізичного зображення і оцінюють його роботоздатність. У разі потреби, з метою прискорення доступу до деяких груп даних, доопрацьовують ЛМД, зокрема, добавивши класи індексних інформаційних об’єктів. У логічні постановки задач вносять елементи, які залежать від специфіки середовища реалізації, наприклад опису даних на вибраній мові програмування. При цьому уточнюють раніше отримані оцінки потрібної пам’яті та швидкодії обчислювальних засобів, і в разі потреби вносять корективи в проект. На закінчення уточнюють деталі реалізації інтерфейсу користувача і відображають їх у завданнях на програмування. Розроблені постановки задач збирають у єдиний пакет — фізичний проект.

Отже, основним продуктом, створеним з використанням технології SSADM, є комплект документів, на основі яких розроблювана АС може бути реалізована на обчислювальному пристрої з використанням системи програмування і СУБД, вибра­них на стадії 4.

4.2.3. Основні проектні методики

Методичне забезпечення технології SSADM утворене 13 методиками проектування АС, що тісно пов’язані між собою і з елементами ТПП. Їх коротку характеристику наведено в табл. 4.1.

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

 

Таблиця 4.1

Коротка характеристика методик

№ п/п

Назва методики

Характер основних проектних документів

Номери стадій, на яких використовуються

1

Визначення вимог до АС

Каталог форм

0, 1, 2, 3, 4, 5, 6

2

Моделювання інформаційних потоків

Схема, таблична форма

0, 1, 2, 3,

3

Логічне моделювання даних

Схема, таблична форма

0, 1, 2, 3, 4, 5

4

Визначення функціональних задач

Схема, таблична форма

1, 2, 3

5

Динамічне моделювання даних

Схема, таблична форма

3, 5

6

Реляційний аналіз даних

Таблична форма

1, 3, 5

7

Вибір варіантів автоматизації

Пояснювальна записка, таблична форма, схема

2

8

Розробка демонстраційного прототипу

Відеограма, схема

3

9

Вибір варіанта технічної реалізації

Пояснювальна записка, таблична форма, схема

4

10

Проектування діалогової взаємодії

Таблична форма, схема

3, 5

11

Логічне проектування процедур обробки даних

Таблична форма, схема

5

12

Фізичне проектування баз даних

Таблична форма, схема

6

13

Фізичне проектування процедур обробки даних

Таблична форма, схема

6

 

З метою залучення користувачів до процесу розробки цілий ряд методик базується на інтенсивному використанні зображень проектних рішень у графічній формі, що забезпечує достатню наочність і не потребує для розуміння їх суті спеціальної підго­товки в галузі інформаційних технологій. Така форма, наприклад, лежить в основі методик «Моделювання інформаційних потоків», «Логічне моделювання даних», «Динамічне моделювання даних» та ін.

У межах ТПП використання окремих методик, наприклад «Вибір варіантів», обмежено однією технологічною стадією або навіть етапом. Однак через ітераційний характер розробки основних проектних документів більшість методик використовуються протягом кількох стадій. Методичне забезпечення тех­нології SSADM відрізняється від відомих аналогів тим, що значно підвищує якість проектування. Ідеться про поняття «подія», яке, поряд з поняттями «дані» і «задача», займає в SSADM центральне місце. Введення до розгляду поняття «подія» дозволяє перенести прийняття проектних рішень з цих питань на стадію 3 і зафіксувати їх у проектних документах у досить загальному вигляді й у формі, зрозумілій користувачам, які таким чином можуть контролювати правильність рішень на змістовому рівні.

Крім того, якщо традиційні методи проектування зорієнто­вані на зображення проекту майбутньої системи лише в просторі «дані» — «задачі», то технологія SSADM дає змогу розглядати проект ще в двох інших проекціях: «дані» — «події» і «події» — «задачі». Наявність цих двох допоміжних аспектів дозволяє розробникам вже на ранніх стадіях виявити приховані суперечності в проекті та усунути помилки ще до того, як їх могли б знайти за традиційного підходу.

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

4.2.4. Перспективи розвитку технології SSADM

За час, що минув з 1990 р., коли було введено в дію четверту версію технології SSADM, у галузі програмної інженерії відбу­лися деякі зміни:

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

— були створені й стали широко використовуватись інстру­ментальні програмні засоби для розробки графічного інтер­фейсу користувача, а також засоби для швидкого прототипування додатків;

— більш високого ступеня зрілості досягли об’єктно-орієнто­вані методи розробки автоматизованих систем.

Усі ці нововведення, що потенційно дають змогу значно підвищити якість і продуктивність праці розробників АС, не знайшли свого відображення в четвертій версії SSADM; саме тому в середині 1995 р. було запроваджено вдосконалену версію 4.2. Ця версія була доповнена методикою, яка підтримує оціню­вання реалізованості та передпроектне обстеження, а також вмі­щує конкретні рекомендації розробникам щодо виявлення вузьких місць в існуючій системі та складання каталогу вимог. Окрім того, дещо змінився ТПП. Зокрема, розробка форм вхідних і ви­хідних документів і процедур діалогу була повністю винесена на стадію 3 (у версії 4 логіку діалогів проектують на стадії 5, а деталі їх реалізації — на стадії 6). Це нововведення дало змогу ширше використовувати засоби проектування графічного інтер­фейсу, а також зменшити кількість розроблюваних документів, прискоривши при цьому розробку АС.