Поясніть зміст поняття „системне проектування. Наведіть приклади методів системного проектування

Вид материала

Документы

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

Подобный материал:

• Становлення науки про проектування. Огляд досліджень в області методології проектування, 147.21kb.
• Робоча навчальна програма дисципліни "автоматизоване проектування телекомунікаційних, 447.76kb.
• Програми дисциплін ● Адміністрування сапр сучасний погляд на процес І об’єкт проектування, 150.64kb.
• Пащенко Валерій Миколайович, к т. н., доц. Відповідальний за випуск Рецензенти: зміст, 513.21kb.
• Програма для профільного навчання учнів загальноосвітніх навчальних закладів, 897.92kb.
• Формат опису модуля, 47.98kb.
• Назва модуля: Архітектурне проектування за темою дипломного проекту Код модуля, 20.09kb.
• Удк 007. 62-50 підхід до проектування інформаційних систем документообігу в органах, 174.35kb.
• Рхітектур І багатоядерних процесорів, алгоритмів паралельної обробки інформації, інструментарію, 117.29kb.
• Виробнича стратегія та проектування структури змін, 95.62kb.

ПП.19.ПП.22

Поясніть зміст поняття „системне проектування”. Наведіть приклади методів системного проектування. Охарактеризуйте класичні моделі циклу життя інформаційної системи. Виконайте порівняльну характеристику водоспадної та спіральної моделі.


Системне проектування — це організаційна дисципліна, при­значена для проектування інформаційних систем (ІС), що вико­ристовує певний набір засобів проектування.

Системне проектування застосовується до найрізноманітніших класів систем, як загальноуправлінські ІС (MIS — management infor­mation system, EIS — executive information system, DSS — Decision Support System), спеціалізовані за галузями ІС (банківські, управлін­ня дискретним та неперервним виробництвом, системи управління готельним господарством та ін.), спеціалізовані за функціями ІС, (управління роботою складу, система маркетингових досліджень, аналітичні системи), універсальні ІС (електронний архів, корпора­тивна система управління процесом виконання офісних робіт, сис­тема статистичних розрахунків) та ін.

Для проектування спеціалізованої ІС або адаптації універсальної ІС до вимог і потреб конкретного замовника застосовується бага­то в чому спільний набір засобів і технологій. Цей набір разом з програмними засобами, що їх підтримують, називають «Майстернею Інформаційних Технологій» (IT Workshop).

Тенденції розвитку сучасних інформаційних технологій призво­дять до постійного зростання складності інформаційних систем (ІС), створюваних у різноманітних галузях економіки.

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

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

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


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

Ручне розроб­лення звичайно породжувало такі проблеми:

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

Перераховані чинники сприяли появі програмно-технологічних засобів спеціального класу — CASE-засобів, що реалізують CASE-технологію створення і супроводу ІС. Термін CASE (Computer Aided Software — пізніше System — Engineering) використовується у дуже широкому контексті. Початкове значення терміну CASE, обмежене питаннями автоматизації розроблення тільки лише програмного за­безпечення ІС, тепер набуло нового сенсу, що охоплює процес роз­роблення складних ІС загалом. Тепер під терміном CASE-засобу ро­зуміються програмні засоби, що підтримують процеси створення і супроводу ІС, включаючи аналіз і формулювання вимог, проекту­вання прикладного ІС (застосувань) і баз даних, генерацію коду, тес­тування, документування, забезпечення якості, конфігураційне ке­рування і керування проектом, а також інші процеси. CASE-засоби разом із системним ІС і технічними засобами утворюють повне се­редовище розроблення ІС.

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

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

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

CASE — це інструментарій системних аналітиків, розробників та програмістів, що дозволяє автоматизувати процес проектуван­ня та розроблення складних інформаційних систем (ІС). Інструмен­тарій CASE використовується як для аналізу існуючих систем, так і для проектування нових або перепроектування існуючих.

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

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

На сьогоднішній день CASE-технологія є основною технологією проектування та реінженерії ІС, а широке її запровадження почалося значно раніше. Відповідно до огляду передових технологій (Survey of Advanced Technology), складеному фірмою Systems Development Inc. у 1996 p. за результатами анкетування більш ніж 1000 американсь­ких фірм, CASE-технологія вже тоді потрапила в розряд найстабіль-ніших інформаційних технологій (її використовувала половина всіх опитаних користувачів більш ніж у третині своїх проектів, із них 85% завершилися успішно).

Проте, незважаючи на наведені дані, слід враховувати наступне:

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

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

Успішне впровадження CASE-засобів забезпечує:

високий рівень технологічної підтримки процесів розроблення і супро­воду ІС;

позитивний вплив на деякі або усі з перерахованих чинників: продуктив­ність, якість продукції, дотримання стандартів, документування;

прийнятний рівень віддачі від інвестицій у CASE-засоби.

КЛАСИЧНІ СХЕМИ ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

Проектування ІС для достатньо стабільних умов (що припускалося в 70-і і в першій половині 80-х років) вважається класичним. Представницькість відповідних технологій, орієнтація на наймасовішу частину ІС, наявність не лише теоретичних підстав, але і промисло­вих методик та стандартів, використання цих методик протягом де­сятиріч — саме це дозволяє називати ці засоби класичними. Засоби проектування таких ІС в 80-х роках були добре описані в літературі різних напрямків: методичних монографіях, стандартах (ANSI, ISO, ГОСТ-и), підручниках. Відповідна організація робіт рекомендувала­ся офіційно і широко застосовувалася в багатьох галузях.

Головна різниця між класичними технологіями стосується орга­нізації циклу життя ІС.

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

Найбільше поширення одержали такі дві основні моделі ЦЖ:

водоспадна модель та її модифікації (70-85 pp.); спіральна модель (86-90 pp.).

1. Водоспадна модель організації робіт, її переваги та недоліки

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

Крім того, найрозумніше організовані методики та стандарти уни­кали жорстко однозначного «прив'язування» робіт до конкретних ста­дій. Разом з тим, при можливості неодноразового включення деякої роботи в загальну схему постійно виділялися наступні проектні стадії:

Ч «запуск» (proposal for the development, agreement, mobilization): органі­зація підстави для діяльності і запуск робіт: наказ та (або) договір на розробку інформаційної системи, завдання на виконання робіт;

Ч «обстеження» (feasibility stady, scope analysis, strategy stady and plan­ning, requirement definition) : передпроектне обстеження, загальний аналіз ситуації на підприємстві (фірмі), Розроблення загального об­ґрунтування доцільності створення ІС;

Ч «концепція, ТЗ» (strategy planning, analysis, requirement specification, function description): дослідження вимог підприємства і користува­чів, формування рекомендацій з розроблення ІС, Розроблення техніч­ного завдання (ТЗ) на проектування ІС загалом та часткових ТЗ (ЧТЗ) для підсистем;

Ч «ескізний проект» (detailed analysis, high level design): Розроблення архітектури майбутньої ІС в межах ескізного проекту ;

Ч дослідний варіант ІС (pilot-project, test development): Розроблення спрощеного варіанта, пілотного проекту майбутньої ІС;

Ч дослідне використання пілот-проекту ІС, Розроблення виправлень та доповнень до ТЗ (test, corrected requirement specification);

Ч «777» (detailed analysis and design, test development): Розроблення тех­нічного проекту ІС;

Ч «РП» (development, test, system implementation): Розроблення робочої документації проекту;

Ч «введення в дію» (deployment, put into operation): іншими словами — «впровадження» ІС .

* Одна з назв, що використовується для такої послідовної схе­ми організації робіт, це «водоспадна модель» (waterfall model). Основними укрупненими етапами послідовної (водоспадної, кас­кадної) схеми є: формулювання та аналіз вимог, проекту­вання, реалізація, впровадження, супровід.



Рис. 15.1. Ідеальна послідовність виконання етапів водоспадної моделі

Ідеальна послідовність виконання етапів наведена вище (рис. 15.1), а фактичний перебіг робіт — на рис. 15.2. Отже, в дійсності виника­ла необхідність в ітераційних процедурах уточнення вимог до систе­ми навіть під час робіт з комплексного тестування ІС.




Рис. 15.2. Фактичні пов'язання між елементами водоспадної моделі





Рис. 15.3. Розподіл ресурсів за водоспадною моделлю

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

Особливості водоспадної моделі проектування ІС

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

Позитивні чинники застосування водоспадної схеми є наступними:

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

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

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

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

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

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

ВДОСКОНАЛЕННЯ КЛАСИЧНИХ СХЕМ ПРОЕКТУВАННЯ

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

Схема неперервного розроблення

Прикладом вдосконалення класичного проектування може слу­жити підхід, який керівники великих проектів фірми IBM в 70-х — 80-х роках називали «Розробкою, що триває (продовжується)». Ха­рактерною особливістю такого підходу став неперервний процес розроблення і розвитку великої ІС з визначеними плановими мо­ментами передачі до експлуатації нових версій та нових функціо­нальних блоків (підсистем, задач) та вбудованими у процес проек­тування постійно здійснюваними процедурами експертизи якості, дієздатності та ін.

Велика увага приділялася організації процесу проектування. Вбу­довані у процес експертизи служили тим засобом зворотного зв'яз­ку, ґрунтуючись на якому можна було одержувати підтвердження користувача, і удосконалювати процес розроблення.



Рис. 15.4. Вдосконалення класичної схеми проектування

Змістовно цей підхід описаний Дж. Фоксом. Схема проектного циклу при проектуванні, що триває, співпадає з циклом життя сис­теми (рис.15.4).

Спіральні схеми проектування

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

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

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

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



В середині 80-х років використання принципу продовженого роз­роблення для прискореного почергового впровадження окремих програмних комплексів — прикладних або загальносистемних — стало розвиватися в різних напрямках і отримало декілька ходових жаргонних назв, наприклад — «швидке прототипування», (rapid pro-toyping approach або fast-track).

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

У проектний цикл для цього додатково включалися такі стадії: О розроблення макета-прототипу фрагмента майбутньої ІС (rapid prototyping) спільно з майбутнім користувачем; випробування макета-прототипу фрагмента майбутньої ІС, доопра­цювання прототипу до працюючого фрагмента ІС (feedback, improved prototype design and development).

Перевагами спіральної моделі є:

* накопичення та повторне використання програмних засобів, моде­лей та прототипів;

** орієнтація на розвиток та модифікацію ІС у процесі його проекту­вання;

** аналіз ризику та витрат у процесі проектування.

Однак застосування швидкого прототипування поряд з швидким

ефектом приводило до зниження керованості проектом загалом та

узгодженості різноманітних фрагментів ІС.

Недоліки класичних схем проектування

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

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

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

Не лише жорсткість моделей, але і використання фірмових (па-тентованних) архітектур комп'ютерів, операційних систем (ОС) та систем управління базами даних (СУБД) призводила до негативних результатів при виникненні неминучої необхідності розвитку ІС. Ці недоліки отримали оцінку як недоліки закритих систем: закриті ІС було складно або дуже дорого розвивати, дуже дорого або практич­но неможливо пов'язувати з іншими системами.



Рис. 15.6. Модель-«цибулина» закритої ІС

Одне з популярних представлень архітектури такої закритої ІС (модель у формі цибулини) наведене на рис. 15.6. На цьому малюнку:

І комп'ютер — комп 'ютер конкретного типу (конкретної фірми-виробника); І операційна система — конкретна операційна система для даного типу

комп 'ютера, І СУБД — конкретна система управління базами даних для І та 2; І прикладні програми — прикладні програми для 2 та 3; І користувач-оператор — користувач-оператор, навчений саме для 2, З і 4; І остаточний користувач: навчений та має інструкції для роботи власне

з 4 та 5.

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