5.2. цикл розробки арм
Управління є безперервним процесом, будучи функцією систе- ми. Для вдосконалення управління за рахунок радикального поліп- шення інформаційної системи використовують системний підхід. Отже, і розробка додатків пов’язана з необхідністю їх систематично- го поліпшення. При огляді і плануванні розробки додатків можуть використовуватися різні схеми стадій і етапів створення додатків. Наприклад, традиційна системотехнічна розробка завдань і компле- ксів автоматизованих систем управління (АСУ) і окремих автомати- зованих робочих місць зазвичай розглядається за трьохстадійною схемою: 1) передпроектна стадія; 2) проектна; 3) введення в експлуатацію. Через деякий час після закінчення упровадження виконується ще етап аналізу ефективності. При цьому кожен етап розробки за- безпечується певними методиками. Логіка ж послідовності робіт ви- значається єдиною методологією системних досліджень. На рис. 5.12. наведена схема типового циклу, логічно обумовленого цією методологією. Автоматизоване робоче місце є підсистемою інформаційної си- стеми (ІС). Тому всі принципи розробки окремого АРМа відповіда- ють принципам розробки будь-якої ІС. Цикл розвитку системи охоплює етапи дослідження, аналізу, проектування, введення в експлуатацію, супроводу (підтримки).
Деякі етапи іноді можуть виконуватися одночасно, паралельно. Ко- жен етап розробки додатку завершується створенням цільової про- дукції етапу. Рис.5.13. зосереджує увагу на продукції всіх етапів ци- клу розвитку системи.
Поліпшена система Дослідження Аналіз
Супроводження Цикл розвитку інформаційних систем
Проектування
тестування Впровадження
Рис.5.12. Цикл розвитку інформаційних систем
На етапі системних досліджень повинен бути сформульований висновок про можливість реалізації (здійсненності) системи. Для цього необхідно розглянути такі головні питання: • чи дійсно є проблема або є альтернативи, які не мають проблем; • чи доцільне створення нової інформаційної системи; • чи дійсно її можна буде реалізувати (створити). При підтримці керівництва повинен бути створений план про- ведення робіт.
1. Системні дослідження Висновок про можливість здійсненності системи
Вимоги до системи
Специфікація до системи
Працездатна система
Поліпшена система
Етапи циклу розробки системи та їх цільова продукція
Етап системного аналізу ставить мету сформулювати функ- ціональні вимоги до майбутньої системи. Продуктом етапу є до- кумент «Вимоги до системи». Тут вивчаються інформаційні по- треби кінцевих користувачів, вплив навколишнього середовища, роль існуючої інформаційної системи. Вимоги повинні бути ви- значені і документовані не тільки з системи в цілому, але і з окремих її ресурсів (устаткування, телекомунікації, програмне забезпечення, бази даних), а також з окремих інформаційних процесів (введення даних, зберігання, обробка, виведення, управління даними). Етап системного проектування завершується створенням дета- льних специфікацій щодо кожного елементу інформаційної системи. Створюються специфікації устаткування (основного і додаткового), програмного забезпечення, специфікації персоналу (всіх категорій користувачів, які працюватимуть з новою системою), специфікації
ресурсів даних (документів і баз даних), специфікації інформацій- них продуктів (форм екранів, форм документів). Етап упровадження (введення в експлуатацію) завершується створенням працездатної системи. На цьому етапі виконуються такі заходи: • отримується (або розробляється) і встановлюється устаткуван- ня та програмне забезпечення; • проводиться тестування системи та її документування; • проводиться навчання персоналу; • здійснюється перехід на нову систему. Залежно від того, чи зберігається стара технологія обробки да- них на період упровадження нової системи, розрізняють варіанти упровадження: (1) з дублюванням робіт старим способом, (2) без дублювання. Упровадження з дублюванням робіт більш надійне у випад- ках відмови нової системи або будь-яких її порушень. Проте цей варіант вимагає додаткових витрат на подвійну технологію обро- бки даних. Якщо в процесі упровадження системи пріоритетним є зберегти і не погіршити якість обслуговування клієнтів, то слід вибрати метод упровадження з дублюванням, не зважаючи на витрати. Якщо ж на першому місці є зниження витрат, то краще вибрати метод упровадження без дублювання. В останньому випадку слід завчасно провести тестування устаткування і про- грамного забезпечення, а також попереднє навчання персоналу з контролем навчання. За наявності декількох структурних підрозділів, в яких слід упроваджувати проект системи, перехід на нову систему може здійс- нюватися послідовним, паралельним або комбінованим методом. При послідовному методі проект упроваджується по черзі в кож- ному підрозділі. Сумарний час упровадження проекту при цьому ма- ксимальний, проте, для не першочергових підрозділів є можливість вносити корективи, необхідність яких виявляється при упроваджен- ні в першочергових підрозділах.
При паралельному методі проект упроваджується одночасно у всіх підрозділах, тому час введення тут мінімальний, а вне- сення корективів ускладнюється і збільшується з числом під- розділів. Компромісним і оптимальним є комбінований метод, коли спо- чатку проект упроваджується послідовно в одному-двох підрозді- лах, потім за наслідками упровадження в проект вносять необхідні корективи, і, нарешті, відкоректований проект одночасно (паралель- но) упроваджується у решті підрозділів організації.
5.2.1. Системні дослідження
Етап системних досліджень є надзвичайно важливим для пода- льшої обробки, хоча це і попереднє дослідження, оскільки він вико- нує роль стратегічної розвідки для подальшого фронту робіт. Тут дослідники з’ясовують стан справ і відповідають на питання: чи дій- сно існує проблема, що є її істинною причиною, і чи вирішить цю проблему нова інформаційна система? Якою повинна бути нова сис- тема, щоб усунути проблему? Робота дослідників ІС для будь-яких систем має три складових: • вибір стратегії для планування системи; • вивчення здійсненності; • створення звіту про здійсненність. Оскільки ресурси персоналу і фінансові ресурси майже завжди обмежені, то розробка стратегічного курсу підтримки інтересів фір- ми з боку інформаційної системи у деяких далекоглядних фірмах на- буває характеру регулярного планування, в процесі якого відпрацьо- вуються нові схеми інформаційної системи. Якщо такі можливості у фірми є, то це полегшує етап досліджень і формування нової ІС. Вивчення здійснення необхідне у зв’язку з тим, що процеси створення ІС зазвичай вимагають великих витрат часу і засобів, то- му небажано починати велику розробку, якщо немає упевненості в її
здійсненні, тобто в реальній можливості її завершення і позитивного впливу на вирішення проблем. У процесі системного дослідження здійснення головна увага приділяється вивченню інформаційних потреб кінцевих користува- чів, необхідних початкових ресурсів, можливих поточних витрат, можливого прибутку за рахунок нової ІС. Збір даних про інформаційні потреби користувачів проводиться різними методами. Популярні маркетингові методи (інтерв’ю, спо- стереження, анкетні опитування). У процесі «польових» спостере- жень та інтерв’ю важливо враховувати психологічний чинник. Підсумкові результати обробки дослідницьких даних подають- ся в числовому і графічному вигляді, а також відображаються в кінцевому звіті про підсумки попереднього дослідження здійснення нової ІС. Звіт за наслідками дослідження здійснення звичайно містить попередню специфікацію витрат і конструктивний план розробки за- пропонованої інформаційної системи. Звіт передається керівництву організації для розгляду і затвердження до початку робіт. У звіті ар- гументуються: • організаційне здійснення, • економічне здійснення, • технічне здійснення, • операційне здійснення. Йдеться про комплексний огляд чинників, які впливають на здійснення розробки нової ІС. Організаційне здійснення — це визначення збігу можливостей запропонованої ІС із стратегічними планами організації. Економічне здійснення — це визначення можливого зменшення витрат, підвищення доходів, зменшення інвестицій. Технічне здійснення аргументується можливостями устаткування і програмного забезпечення: надійністю, перспективністю, доступністю. Операційне здійснення має сенс визначити відношення до ІС з боку людини, яка потрапляє в сферу безпосереднього спілкування з
ІС або може відчувати вплив результатів її упровадження. У звіті наголошують на сприйнятті кінцевих користувачів, клієнтів, поста- чальників, відповідності адміністративним і державним нормам, правам людини, наявність підтримки керівництва. Операційне здійс- нення вважають якісним, якщо люди висловили готовність експлуа- тувати і підтримувати майбутню інформаційну систему, а також якщо повністю враховані всі правові чинники.
5.2.2. Системний аналіз
Кінцевий продукт цього етапу — функціональні вимоги, тобто документована постановка системних вимог до нової ІС. Коли йдеться про створення великої системи, цей документ є формою зві- ту про системні вимоги. Системний аналіз охоплює такі головні види робіт, як дета- льне вивчення інформаційних потреб кінцевих користувачів організації, її підсистем і її оточення, вивчення будь-яких існу- ючих форм активності й існуючих ресурсів ІС, логічну взаємо- пов’язаність і документування вимог кінцевих користувачів до нової ІС. Перший етап системного аналізу (аналіз організаційного ото- чення) викликаний тим, що неможливо створити працездатну інфор- маційну систему, якщо дослідники нічого не знають про особливос- ті функціонування організації, функції якої повинна обслуговувати ІС і елементом якої вона є. Слід розуміти особливості і тип діяльнос- ті, управлінську структуру, методи управління, зв’язки підрозділів, пер- сонал, динаміку інформаційного обміну між окремими працівниками і
робочими групами (форми документів і звітів, терміни, кількість зразків і т. ін.). Другий етап системного аналізу (аналіз існуючих систем) обумовлений тим, що в організаціях вже можуть існувати якісь ІС з певними ресурсами (інформаційними, програмними, технічними, а також персоналом). Навіть тоді, коли проводиться повне оновлення технічної і програмної бази, існуюче інформаційне забезпечення відображає ядро головних потреб, які не тільки не можна ігнорувати в новій системі, а навпаки, стартуючи від нього, необхідно розвину- ти і розширити. Отже, слід ретельно вивчати, які завдання вирішують «старі» системи, яке устаткування і програмне забезпечення вони мають, який персонал працює в інформаційному відділі; чи існують бази даних, яка їх структура і якими методами формуються звіти про ре- зультати — все це найважливіші питання. Важливо з’ясувати, чи застосовується кодування інформації і які рівні кодів при цьому використовуються (місцеві, державні, між- народні); з’ясувати існуючий регламент обробки даних, кого і чому він не влаштовує, чи бувають практичні затримки даних і звітів, причини затримки; з’ясувати, чи є документація на стару систему. Все це має бути як пам’ятка в особистому щоденнику дослідника системи. Другий етап системного аналізу — це складний і відповідаль- ний крок до оброблення метаінформації, тобто «даних про дані». Головними орієнтирами в організації метаінформації є об’єкти (до- кументи, діаграми, аналітичні тексти і записки, економічні показни- ки, сукупності), а також процеси створення об’єктів, процеси їх пе- редачі, обробки, зберігання. Для виконання третього етапу системного аналізу (аналіз вимог системи) дослідник повинен мати певні знання типових методів ви- рішення основних управлінських завдань (облікових, аналітичних, планових, оперативних). Все це є складовою частиною спеціальних знань системоаналітика. Наприклад, якщо системний аналітик взагалі
не має уявлення про схему інформаційного комплексу обліку това- рів на складі або обліку продажу в торговій залі, то навряд чи він зможе охопити всі вимоги комплексно, якщо окремі співробітники складу і торгового відділу знають лише свої обмежені обов’язки і функції. Тому системоаналітик повинен простежити всі гілки ком- плексу вимог в бесідах з кінцевими користувачами, а потім зробити аналітичні системні висновки: ці вимоги існують і підтримуються існуючою інформаційною системою, а це повинно стати функціона- льною вимогою до нової, поліпшеної системи. Величезні труднощі якісного проведення системного аналізу викликали у системоаналітиків прагнення розробити альтернативні інженерні методи для його полегшення, технологізувати системний аналіз існуючої системи і з’єднати його з синтезом нової системи. Такі методи нині створені (наприклад, CASE-технології). Вони з’єд- нали системний аналіз із системним проектуванням, забезпечивши автоматизовану генерацію детальних структур і специфікацій нової інформаційної системи. Третій етап системного аналізу — визначення того, що повинно бути в новій ІС. Це методологічний етап синтезу вимог до нової сис- теми, які випливають з перших двох етапів аналізу, а також із спеці- альних знань і засобів системоаналітиків. Фахівці з системного ана- лізу знають, що однією з підступних пасток в їх роботі є можливість сплутати аналіз існуючої системи з тим, що повинно бути. Тому другий і третій етапи системного аналізу чітко розділені. Про це важливо пам’ятати для того, щоб не помилитися в оцінках основи, на якій будується нова система. У системотехнічній методології ана- ліз існуючого відділяється від аналізу майбутнього, щоб не сприйня- ти бажане за дійсне. Четвертий, підсумковий етап системного аналізу (документу- вання вимог до нової системи) повинен узагальнити наявні аналі- тичні матеріали і створити документоване відображення функціо- нальних вимог до нової ІС. Документ «Вимоги до системи» або «Функціональні вимоги» є основою подальшої роботи фахівців
інформаційного відділу для створення детального проекту нової си- стеми, тобто для створення специфікацій всіх її елементів, програм, інструкцій Таким чином, етап системного аналізу відповідає на питання, що повинна мати інформаційна система для задоволення вимог ко- ристувачів, а етап системного проектування відповідає на питання як конкретно здійснити таку ІС.
5.2.3. Зміст етапу «Системне проектування»
Системне проектування великих корпоративних ІС досить скла- дне за змістом і вимоги до персоналу розробників. Воно є окремою науковою дисципліною. Тут ми даємо стислу характеристику робіт і уявлення про головні чинники підвищення ефективності системного проектування, тобто про використання стандартів, автоматизації розробки. Головний документ, який повинні мати фахівці з обробки даних перед початком проектування — це «Функціональні вимоги» або «Вимоги до системи». Розробка системних специфікацій є метою етапу системного проектування, а самі специфікації — його продук- том, який є основним документом для четвертого етапу — упрова- дження нової ІС. Етап системного проектування завершується формуванням детального (робочого) проекту інформаційної системи. Проект є серіями специфікацій і інструкцій користувачам. У процесі проектування розрізняють етапи: (1) логічне проекту- вання, (2) фізичне проектування, (3) системні специфікації. Логічні і фізичні аспекти більш належать до проектування бази даних. Структура бази даних знаходиться в центрі уваги всього про- ектування прикладних ІС. Головне тут — виявити і створити описи інформаційних об’єктів, їх структури, а також зв’язків між об’єкта- ми та їх елементами.
Практичне проектування прикладної інформаційної системи (додатки) може бути подане як розробка трьох головних видів її еле- ментів: • інформаційного забезпечення (концептуальних і зовнішніх моделей бази даних, словника елементів бази даних); • призначеного для користувача інтерфейсу (командних лінійок, панелей меню, діалогових вікон, повідомлень, екранів вхідних і вихідних форм); • програмного забезпечення (програм і процедур). Розробка інформаційного забезпечення. До початку розробки діалогів і прикладних програм повинні бути визначені, специфікова- ні і документовані логічні структури всіх об’єктів бази даних та її словник, а також логічні структури всіх інших файлів — це головна вимога системного проектування. Проектування інформаційного за- безпечення виявляє і документує три його головні стадії: (1) суть, тобто об’єкти; (2) зв’язки об’єктів; (3) правила інтеграції суті та опису їх ролей. Суть (об’єкти) — реально існують в системі. Це працівники, ро- бочі місця (підрозділи або їх адреси), предмети (товари, матеріали, споруди і т. д.). Опис суті за спеціальними правилами є найважливі- шою початковою умовою використання CASE-технологій. Зв’язки об’єктів описують наявність певних відношень між різ- ними елементами одного об’єкту або між об’єктами, а також кількісні особливості відносин. Виявлення зв’язків — надзвичайно складна процедура аналізу і проектування, вона вимагає чималих зусиль. Цю метаінформацію про відношення елементів в інформаційній системі називають «суть-зв’язок» або ER-модель (скорочення від англійського Entity-Relationship model). Правила інтеграції логічних елементів в окремі записи фіксу- ються в спеціальній таблиці відповідності записів та їх елементів. У першому стовпчику таблиці одноразово фіксується ім’я кожного унікального типу запису (наприклад, ПРИБУТТЯ-НА-СКЛАД), а в першому рядку заголовка цієї таблиці також один раз перелічені
унікальні імена елементів всіх записів (НОМЕР-ДОКУМЕНТА, ДА- ТА-ОТРИМАННЯ, СУМА-НАРАХОВАНО і т. ін.). На перетині ряд- ків і стовпчиків таблиці ставляться символи занесення елементів у записи. Для того, щоб уникнути неоднозначного використання еле- ментів, в спеціальному словнику фіксується точне значення і роль кожного елементу бази даних. Словник містить текстові характерис- тики (тлумачення) всіх елементів з метою забезпечення однознач- ного розуміння їх значення (перш за все проектувальниками і корис- тувачами, що беруть участь у проектуванні). (2) Розробка призначеного для користувача інтерфейсу фактично реалізує організаційну модель додатку, пов’язуючи її з інформацій- ним забезпеченням (базою даних) і програмним забезпеченням (про- грамними модулями). Призначений для користувача інтерфейс моделює також відно- сини між користувачем і комп’ютерною системою через готові екранні форми введення даних і виведення звітів. При проектуванні інтерфейсу розробляється ієрархічна структура (дерево) діалогів, створюються перелічення діалогів, етапів, використаних об’єктів, фізичний вид кожного етапу діалогу. (3) Розробка прикладного програмного забезпечення в даний час здійснюється в основному на логічному рівні, з використанням можливостей об’єктно-орієнтованих програмних мов четвертого по- коління. Проектування структури бази даних і спілкування з сучас- ними системами управління базами даних також здійснюється на логічному рівні, тобто з використанням легких для розуміння їх зна- чення ідентифікаторів, імен даних. Фізичне розміщення бази даних на пристроях пам’яті відбувається автоматично за допомогою СУБД. Окрім програм розробляються також і процедури, наприклад, процедура архівації денного файлу операцій, процедура відкриття нового операційного дня і ін. Розробка програм і процедур взаємопов’язує призначений для користувача інтерфейс, інформаційне забезпечення, характеристики
устаткування. У цьому значенні розробку програм можна порівняти з роботою архітектора, який формує загальний естетичний вигляд і забезпечує зручності для людини, орієнтуючись на властивості на- явних будівельних матеріалів.
5.2.4. Роль інструментів і стандартів у проектуванні
Неможливо створити стійку, динамічну і ефективну ІС, не використовуючи стандартів відображення структури системи, тех- нологій, алгоритмів і т. ін. Багаторічний досвід проектування систем створив досить зручні і, головним чином, графічні засоби (інструме- нти) для наочного зображення цих елементів проекту. Звичайно, проект системи можна описати у вигляді звичного тексту, але його буде важко зрозуміти, якщо в ньому не буде блок-схем. Використання спеціальних засобів проектування дозволяє одержати концептуаль- ну ясність, документально відображаючи ресурси, процеси і комуні- кації ІС. При цьому широко використовуються табличні форми, діа- грами, блок-схеми з додаванням позначок, та інші графічні способи подання ресурсів і процесів. Є засоби машинні та такі, які заносять- ся вручну. Існують пластикові лінійки з набором стандартних графічних символів для креслення алгоритмів від руки. Проте це не єдиний спосіб стандартизації. Стандартизується також термінологія, прин- ципи проектування та ін. В інженерному значенні графічні символи відіграють вирішальну роль, і добре виконані блок-схеми проясню- ють весь проект. Маючи комп’ютер, сьогодні можна «накреслити» блок-схему за допомогою набору графічних символів, що є у наявності в різних програмах. Мінімум є, наприклад, в Word, де на панелі «Малюван- ня» через кнопку «автофігури» можна вибрати опцію «Блок-схеми» і побудувати блок-схему за допомогою набору з 28 символів, з’єдну- ючи їх лініями.
У процесі системного проектування деякі фірми встановлюють і застосовують свої стандарти. Окремі країни встановлюють націо- нальні стандарти. Існують стандартні засоби, альтернативні ручному проекту- ванню, і орієнтовані на комп’ютери (стандарти окремих CASE-тех- нологій). Світова тенденція в цьому напрямі полягає в переході на вико- ристання комп’ютерів для створення повноцінних проектів ІС. У США, наприклад, використовуються стандарти «Архітектура інтегрованих додатків» від Digital Equipment Corporation, Systems Application Architecture (SAA) архітектура прикладних систем (від IBM), стандарти Application Integration Architecture (AIA) — New Wave (від Hewlett-Packard) та ін. Стандарт Systems Application Architecture містить три частини: (1) загальний доступ, що призначений для користувача; (2) загаль- ний програмний інтерфейс; (3) загальна телекомунікаційна база.
5.2.5. Суть CASE·технологій
Ефективне документування інформаційної системи забезпечу- ється тоді, коли її проектування ведеться з використанням комп’юте- рів і спеціального програмного забезпечення, створеного для підтрим- ки роботи проектувальників інформаційної системи. Документацію етапу проектування досить часто коректують на етапі упровадження системи, після тестування всіх її елементів (технічних, програмних, організаційних). Йдеться фактично про повторне документування. У концепції безперервного планового розвитку інформаційної системи з метою підтримки стратегічних інтересів фірми оновлення доку- ментації стає нормальним явищем і не створює проблем, якщо проек- тування ведеться з використанням ефективної інженерної системи конструювання програмного забезпечення — Computer Aided Software Engeniering (CASE).
CASE-технологія забезпечує комп’ютеризовану розробку інфор- маційного і програмного забезпечення, а також комп’ютеризоване документування розробки. Відомо, що спочатку повинна бути роз- роблена модель бази даних. Проте і вона будується поступово, крок за кроком, за певною технологією. Витоки цього процесу слід шукати в консультаціях інженера — системоаналітика з кінцевим користувачем. Користувач розповідає, з якими даними він працює як з вхідними (первинними), які дані запозичує з інших (чужих) паперів або файлів, які звіти формує. Головна мета такої бесіди для системоаналітика — створити адеква- тну модель предметної галузі. Бесіда відбувається «при наявності» комп’ютера, в якому вста- новлений програмний CASE-генератор. Те, що користувач розпові- дає про свої інформаційні потоки, системоаналітик зразу ж моделює на екрані дисплея у вигляді графічних символів, з’єднуючи їх лінія- ми відповідно до інформації про зв’язки інформаційних елементів. Давайте трохи підслухаємо таку бесіду... — Як називається ваша робота (ваша ділова функція)? — запи- тує аналітик. — Аналіз продажу, — відповідає користувач. Аналітик кликнув мишею і на екрані з’явився блок з підказкою «Введіть назву функці- ї». Аналітик ввів у цей блок назву «Аналіз продажу. Далі йдуть пи- тання щодо початкових документів, про їх елементи, зв’язки, назви звітів, елементи звітів і обчислювань. Все, що стосується цієї ділової функції, в пам’яті комп’ютера пов’язується з нею автоматично. Комп’ютер відкриває таблицю для опису нового об’єкта і робить запит щодо його елементів. Найважливішими поняттями тут є — суть і зв’язок. У бесідах поступово з’ясовуються зв’язки між елементами. Наприклад, елементи «НОМЕР-БАНКІВСЬКОГО-РАХУНКУ-ЗАМОВНИКА» і «ПРІЗВИ- ЩЕ-ЗАМОВНИКА» мають зв’язок типу «один до одного». На екрані дисплея поступово будується графічна модель (діаг- рама) функції, моделі використаних нею об’єктів і зв’язків з іншими
функціями. Після закінчення бесіди і завершення введення відповідей, CASE-генератор автоматично створює словники ділових функцій, документів, звітів, елементів (атрибутів, реквізитів). Екранні CASE-моделі дуже наочні. Вони не лякають кінцевого користувача, що бере участь у бесіді, високою математичною абст- ракцією. З використанням стандартних малюнків-шаблонів (графічних символів блок-схем) крок за кроком на екрані складається і розши- рюється модель предметної галузі (конкретної ділової функції) з її елементами-образами. Тут є назва функції, символи користувача, документів, звітів, комп’ютера, бази даних, ліній зв’язку і т. ін. Про- те по суті CASE-моделі глибоко абстрактні. Саме завдяки цьому стає можливою високошвидкісна автоматична генерація похідної метаінформації у вигляді комплексу проектної документації (специ- фікацій і програмних модулів). Коли закінчаться бесіди системних аналітиків з усіма користу- вачами, які самі побачили і підтвердили правильність сприйняття комп’ютером їх ділових вимог, стає можливим генерувати високо- якісну документацію системи за всіма її ресурсами: інформаційних, програмних, технічних, ресурсах персоналу — для кожного автоматизованого робочого місця. Свої CASE-пакети мають різні фірми, наприклад, МОНОЛОГ, ORACLE, Digital, IBM. Найбільш відома в наших умовах CASE-сис- тема ORACLE, що складається з трьох інструментальних засобів: • CASE*Dictionary для ведення словника бази даних; • CASE*Designer для графічного подання моделей предметних галузей; • CASE*Generator для автоматичної генерації програмних модулів. Будь-який CASE-пакет сприяє загальному впорядкуванню ін- формаційної системи, поєднанню всієї сукупності її процесів, що особливо важливо в умовах інформаційної мережі, в якій працюють і робочі групи, і окремі користувачі. CASE-пакети, перш за все, є інструментами системоаналітиків, проте, біля них в процесі розробки і супроводу ІС зосереджуються зусилля і користувачів, і програмістів.
CASE-пакети розрізняються за кількістю підтримуваних ними етапів розробки. Частина пакетів забезпечує лише графічне подання функцій і потоків даних, інша частина — додатково охоплює опис баз даних і побудову фрагментів програм. CASE-технології опису- ють функції, виконувані в певній предметній галузі, а також інфор- маційні потоки в системі в цілому. Після закінчення проектування і введення системи в експлуатацію, CASE-пакет використовується як інструмент супроводу інформаційної системи та її удосконалення впродовж всього існування циклу ІС. CASE-технології органічно реалізують принцип системного під- ходу до розробки інформаційної системи в концепції мережі автома- тизованих робочих місць (АРМ) кінцевих користувачів. Таким чином,
Традиційні засоби проектування інформаційних систем, що ви- користовуються інженерами проектувальниками
Таблиця 5.4.
Проектуючи форми екранів, часто використовують наперед від- друковані формуляри з розміткою можливих позицій рядків, стовп- ців, символів, наприклад, схема екрану на 20 рядків, по 78 символів в рядку. Важливу роль у проектуванні відіграє матриця системних ком- понентів, яка без застосування умовної символіки зручно і комплексно відображає в табличній формі три головних складових інформацій- ної системи: процеси, ресурси, продукти.
5.2.6. Зміст етапів «Упровадження» і «Супровід»
Розроблений проект упроваджується в реальне середовище під- приємства або організації, тобто пристосовується до поточної робо- ти користувачів. Етап упровадження проекту інформаційної системи (додатки) охоплює: • придбання комп’ютерів і програмного забезпечення; • розробку додаткових програм, які не вдалося придбати; • розробку (коректування) документації проекту; • тестування устаткування і програмного забезпечення; • навчання користувачів і персоналу, який повинен працювати з системою; • безпосередній перехід до використання нової системи. Упровадження може бути досить важким робочим процесом. Слід розуміти, що відмінно запроектована система може провалити- ся, якщо вона не буде ретельно і надійно пристосована до реальних процесів управління. Етап супроводу (обслуговування) інформаційної системи на- ступний за упровадженням проекту. Поточний супровід охоплює моніторинг (стеження) системи та її модифікацію для проведення необхідних удосконалень. Частиною цього процесу є огляд після встановлення для визначення того, наскільки система відповідає цілям її створення. Помилки в новій інформаційній системі виправляються
шляхом відповідного системного обслуговування. Крім того, супро- від охоплює такий вид післяустановчих робіт, як модифікація систе- ми у зв’язку із змінами у сфері діяльності організації або у зв’язку із змінами законодавства (наприклад, зміна податкової ставки викликає зміни в системі бухгалтерського і фінансового обліку організації).
Запитання і завдання для обговорення
1. Які ключові поняття БД і СУБД ви можете назвати? 2. Що таке трирівнева архітектура БД? 3. Які види зв’язків можливі між двома сутностями? 4. З яких стадій складається розробка АРМів? 5. Що включає етап системних досліджень? 6. Які заходи виконуються на етапі упровадження? 7. Чим завершується етап системного проектування? 8. Опишіть суть CASE-технологій? 9. Що охоплює етап упровадження проекту АРМ?
|
Експлуатаційний
цикл
2.
Системний аналіз
3.
Системне проектування
4.
Системне впровадження
5.
Системна експлуатація
Рис.
5.13.
Системний
аналіз, на відміну від попереднього системного дослідження, — поглиблене
вивчення інформаційних потреб користувачів, яке буде покладене в основу
детального проекту- вання нової ІС.
CASE-технологія
— головний практичний інструмент і хоро- ший підсумок довгого наукового пошуку
вдалих кібернетичних рішень в галузі розробки інформаційних систем.
Читать: 1.1. зміст управлінської праці та психології управління |
