НОРМАТИВНО-МЕТОДИЧНЕ ЗАБЕЗПЕЧЕННЯ СТВОРЕННЯ АІС.
Основні поняття проектування АІС
У загальному плані АІС включає: користувача (споживача), інформаційні ресурси, носії інформації, засоби збору, зберігання обробки інформації, засоби передачі інформації.
В основі проектування АІС лежать дві взаємопов'язані складові:
Стандарти проектування;
Методика проектування.
Основні поняття, підходи та визначення проектування АІС регламентуються трьома видами конструкторської та програмної документації:
- єдиною системою конструкторської документації (ЄСКД);
- єдиною системою програмної документації (ЄСПД);
- комплексом керівних документів на АІВ.
Склад проектної документації – це комплекс стандартів та керівних документів на АІС ГОСТ 24.104-85, ГОСТ 34.003-90, ГОСТ 34.201-90 включає методичні вказівки на інформаційні технології та автоматизовані системи, а також вимоги до змісту документів.
Мета проектування-виявлення щодо простої внутрішньої структури, званої архітектурою системи.
АІС розробляється як певний проект. Багато особливостей управління проектами і фази розробки проекта (фази життєвого циклу) є загальними, не залежними як від предметної області, а й від характеру проекту. Поняття проект є складним поняттям і для нього важко підібрати однозначне формулювання.
Проект– це обмежена за часом цілеспрямована зміна окремої системи з спочатку чітко визначеними цілями, досягнення яких визначає завершення проекту, а також із встановленими вимогами до термінів, результатів, ризику, рамок витрачання коштів та ресурсів та до організаційної структури.
Для економічнихсистем під проектом ЕІС розумітимемо проектно-конструкторську та технологічну документацію, в якій представлено опис проектних рішень щодо створення та експлуатації ЕІС у конкретному програмно-технічному середовищі.
Під проектуванням ЕІСрозуміється процес перетворення вхідної інформації про об'єкт проектування, про методи проектування та досвід проектування об'єктів аналогічного призначення відповідно до ГОСТу в проект ЕІС. З цього погляду проектування ЕІС зводиться до послідовної формалізації проектних рішень на різних стадіях життєвого циклу ЕІС: планування та аналізу вимог, технічного та робочого проектування, впровадження та експлуатації ЕІС.
Об'єктами проектуванняЕІС є окремі елементи або їх комплекси функціональних та забезпечують частин. Так, функціональними елементами відповідно до традиційної декомпозиції виступають завдання, комплекси завдань та функції управління. У складі частини ЕІС, що забезпечує, об'єктами проектування служать елементи та їх комплекси інформаційного, програмного та технічного забезпечення системи.
Як суб'єктпроектування ЕІС виступають колективи фахівців, які здійснюють проектну діяльність, як правило, у складі спеціалізованої (проектної) організації, та організація-замовник, для якої необхідно розробити ЕІС. Масштаби систем, що розробляються визначають склад і кількість учасників процесу проектування. При великому обсязі та жорстких термінах виконання проектних робіт у розробці системи може брати участь декілька проектних колективів (організацій-розробників). І тут виділяється головна організація, яка координує діяльність всіх організацій-співвиконавців.
Форма участі співвиконавців у розробці проекту системи може бути різною. Найбільш поширеною є форма, при якій кожен співвиконавець виконує проектні роботи від початку до кінця для будь-якої частини системи, що розробляється. Зазвичай це буває функціональна підсистема чи взаємопов'язаний комплекс завдань управління. Рідше зустрічається форма участі співвиконавців, коли окремі співвиконавці виконують роботи на окремих етапах процесу проектування. Можливий варіант, при якому функції замовника та розробника поєднуються, тобто ЕІС проектується власними силами.
Здійснення проектування ЕІС передбачає використання проектувальниками певної технології проектування, що відповідає масштабу та особливостям проекту, що розробляється.
Технологія проектування ЕІС- це сукупність методології та засобів проектування ЕІС, а також методів та засобів організації проектування (управління процесом створення та модернізації проекту ЕІС)
Методологія (концепція + метод)
Інструментальні засоби Організація
проектування проектування
В основі технології проектування лежить технологічний процес, який визначає дії, їх послідовність, склад виконавців, засоби та ресурси, необхідні для виконання цих дій.
Так, технологічний процес проектування ЕІС загалом ділиться на сукупність послідовно-паралельних, пов'язаних і підпорядкованих ланцюжків дій, кожна з яких може мати свій предмет. Дії, що виконуються під час проектування ЕІС, можуть бути визначені як неподільні технологічні операції або підпроцеси технологічних операцій. Усі дії можуть бути власне проектуючими, які формують або модифікують результати проектування, та оціночними діями, які виробляють за встановленими критеріями оцінки результатів проектування.
Таким чином, технологія проектування задається регламентованою послідовністю технологічних операцій, що виконуються в процесі створення проекту на основі того чи іншого методу, в результаті чого стало б ясно, не тільки ЩО має бути зроблено для створення проекту, але і ЯК, КОМУ і в ЯКІЙ ПОСЛІДЖЕННОСТІ це повинно бути зроблено.
Предметом будь-якої технології проектування має бути відображення взаємопов'язаних процесів проектування на всіх стадіях життєвого циклу ЕІС.
До основних вимог, що пред'являються до обраної технології проектування, належать такі:
Створений за допомогою цієї технології проект має відповідати вимогам замовника;
Вибрана технологія має максимально відображати всі етапи життя проекту;
Технологія, що обирається, повинна забезпечувати мінімальні трудові та вартісні витрати на проектування та супровід проекту;
Технологія має бути основою зв'язку між проектуванням та супроводом проекту;
Технологія має сприяти зростанню продуктивності праці проектувальника;
Технологія повинна забезпечувати надійність процесу проектування та експлуатації проекту;
Технологія має сприяти простому веденню проектної документації.
Основу технології проектування ЕІС складає методологія, що визначає сутність, основні відмінні технологічні особливості.
Методологія проектуванняпередбачає наявність певної концепції, принципів проектування, реалізованих набором методів проектування, які, своєю чергою, мають підтримуватися деякими засобами проектування.
Організація проектування передбачає визначення методів взаємодії проектувальників між собою та із замовником у процесі створення проекту ЕІС, які можуть також підтримуватися набором специфічних засобів.
Методи проектування ЕІС можна класифікувати за рівнем використання засобів автоматизації, типових проектних рішень, адаптивності до передбачуваних змін.
Так, за ступенем автоматизаціїметоди проектування поділяються на методи:
ручного проектування, при якому проектування компонентів ЕІС здійснюється без використання спеціальних інструментальних програмних засобів, а програмування - алгоритмічними мовами;
комп'ютерного проектування, що здійснює генерацію або конфігурацію (налаштування) проектних рішень на основі використання спеціальних інструментальних програмних засобів.
За рівнем використання типових проектних рішень розрізняють такі методи проектування:
Оригінального (індивідуального) проектування, коли проектні рішення розробляються «з нуля» відповідно до вимог ЕІС;
Типового проектування, що передбачає конфігурацію ЕІС із готових типових проектних рішень (програмних модулів).
p align="justify"> Оригінальне (індивідуальне) проектування ЕІС характеризується тим, що всі види проектних робіт орієнтовані на створення індивідуальних для кожного об'єкта проектів, які в максимальній мірі відображають всі його особливості.
Типове проектування виконується з урахуванням досвіду, отриманого розробки індивідуальних проектів. Типові проекти як узагальнення досвіду для деяких груп організаційно-економічних систем або видів робіт у кожному конкретному випадку пов'язані з безліччю специфічних особливостей і розрізняються за ступенем охоплення функцій управління, виконуваних робіт і проектної документації.
За ступенем адаптивності проектних рішень методи проектування класифікуються на методи:
реконструкції, коли адаптація проектних рішень виконується шляхом переробки відповідних компонентів (перепрограмування програмних модулів);
Параметризації, коли проектні рішення налаштовуються (перегенеруються) відповідно до змінюваних параметрів;
Реструктуризація моделі, коли змінюється модель проблемної області, на основі якої автоматично перегенеруються проектні рішення.
Поєднання різних ознак класифікації методів проектування обумовлює характер використовуваної технології проектування ЕІС, серед яких виділяються два основні
класу: канонічна та індустріальна технології (табл. 2.1). Індустріальна технологія проектування, у свою чергу, розбивається на два підкласи: автоматизоване (використання CASE-технологій) та типове (параметрично-орієнтоване або модельно-орієнтоване) проектування. Використання індустріальних технологій проектування не виключає використання окремих випадках канонічної технології.
Таблиця 2.1 Характеристики класів технологій проектування
Для конкретних видів технологій проектування властиве застосування певних засобів розробки ЕІС, що підтримують виконання як окремих проектних робіт, етапів, так і їх сукупностей. Тому перед розробниками ЕІС, як правило, стоїть завдання вибору засобів проектування, які за своїми характеристиками найбільше відповідають вимогам конкретного підприємства.
Засоби проектування мають бути:
У своєму класі є інваріантними до об'єкта проектування;
Охоплювати разом всі етапи життєвого циклу ЕІС;
Технічно, програмно та інформаційно сумісними;
Простими в освоєнні та застосуванні;
Економічно доцільними.
Засоби проектування ЕІС можна розділити на два класи: без використання ЕОМ та з використанням ЕОМ.
Засоби проектування без використання ЕОМ застосовуються на всіх стадіях та етапах проектування ЕІС. Як правило, це засоби організаційно-методичного забезпечення операцій проектування та насамперед різні стандарти, що регламентують процес проектування систем. Сюди відносяться єдина система класифікації та кодування інформації, уніфікована система документації, моделі опису та аналізу потоків інформації тощо.
Засоби проектування з використанням ЕОМ можуть застосовуватися як на окремих, так і на всіх стадіях та етапах процесу проектування ЕІС та відповідно підтримують розробку елементів проекту системи, розділів проекту системи, проекту системи в цілому. Усі безліч засобів проектування з використанням ЕОМ ділять на чотири підкласи.
До першого підкласу відносяться операційні засоби, що підтримують проектування операцій обробки інформації. До цього підкласу коштів належать алгоритмічні мови, бібліотеки стандартних підпрограм та класів об'єктів, макрогенератори, генератори програм типових операцій обробки даних тощо, а також засоби розширення функцій операційних систем (утиліти). До цього класу також включаються такі найпростіші інструментальні засоби проектування, як засоби для тестування та налагодження програм, підтримки процесу документування проекту тощо. Особливість останніх програм у тому, що з допомогою підвищується продуктивність праці проектувальників, але з розробляється закінчене проектне рішення.
Таким чином, засоби даного підкласу підтримують окремі операції проектування ЕІС та можуть застосовуватись незалежно один від одного.
До другого підкласу зараховують кошти, що підтримують проектування окремих компонентів проекту ЕІС. До цього підкласу відносяться засоби загальносистемного призначення:
Системи управління базами даних (СУБД);
Методоорієнтовані пакети прикладних програм (вирішення задач дискретного програмування, математичної статистики тощо)
Табличні процесори;
Статистичні ППП;
Оболонки експертних систем;
Графічні редактори;
Текстові редактори;
Інтегровані ППП (інтерактивне середовище із вбудованими діалоговими можливостями, що дозволяє інтегрувати перераховані вище програмні засоби).
Для перерахованих засобів проектування характерно їх використання для розробки технологічних підсистем ЕІС: введення інформації, організації зберігання та доступу до даних, обчислень, аналізу та відображення даних, прийняття рішень.
До третього підкласу відносяться кошти, що підтримують проектування розділів проекту ЕІС. У цьому підкласі виділяють багатофункціональні засоби проектування.
Функціональні засоби спрямовані на розробку автоматизованих систем, що реалізують функції, комплекси завдань та завдання управління. Різноманітність предметних областей породжує різноманіття засобів даного підкласу, орієнтованих тип організаційної системи (промислова, непромислова сфери), рівень управління (наприклад, підприємство, цех, відділ, ділянку, робоче місце), функцію управління (планування, облік тощо.) .
До функціональних засобів проектування систем обробки інформації належать типові проектні рішення, функціональні пакети прикладних програм, типові проекти.
До четвертого підкласу засобів проектування ЕІС належать кошти, що підтримують розробку проекту на стадіях та етапах процесу проектування. До цього класу належить підклас засобів автоматизації проектування ЕІС (CASE-кошти).
Сучасні CASE-засоби, своєю чергою, класифікуються переважно за двома ознаками:
1) по етапах процесу розробки ЕІС;
2) за ступенем інтегрованості: окремі локальні засоби (tools), набір неінтегрованих засобів, що охоплюють більшість етапів розробки ЕІС (toolkit) та повністю інтегровані засоби, пов'язані загальною базою проектних даних – репозиторієм (workbench).
Проектування АІС є творчим процесом. Кожен проект проходить у своєму розвитку певні стани: від стану, коли проекту ще немає, до стану, коли проекту вже немає. Сукупність ступенів розвитку від виникнення ідеї до завершення проекту прийнято розділяти на стадії (фази, етапи). У визначенні кількості стадій (фаз) та їх змісту є деякі відмінності, проте суть змісту життєвого циклу розробки АІС у різних підходах однакова.
Етапи розвитку CASE-систем
За останнє десятиліття сформувався новий напрямок у проектуванні інформаційних систем – автоматизоване проектування за допомогою CASE-засобів. Термін CASE (Computer Aided System/Software Engineering) спочатку стосувався лише автоматизації розробки програмного забезпечення; Тепер він охоплює процес розробки складних АІС загалом.
Спочатку CASE-технології розвивалися з метою подолання недоліків структурної методології проектування (складності розуміння, високої трудомісткості та вартості використання, труднощі внесення змін до проектних специфікацій тощо) за рахунок автоматизації та інтеграції підтримуючих засобів.
CASE-технології не існують власними силами, є самостійними. Вони автоматизують та оптимізують використання відповідної методології, дають можливість підвищити ефективність її застосування.
Іншими словами, CASE-технологіїявляють собою сукупність методологій аналізу, проектування, розробки та супроводу складних систем програмного забезпечення, підтриману комплексом взаємопов'язаних засобів автоматизації, які дозволяють у наочній формі моделювати предметну область, аналізувати цю модель на всіх стадіях розробки та супроводу АІС та розробляти програми відповідно до інформаційних потреб користувачів .
Сучасні CASE-засоби охоплюють широку сферу підтримки численних технологій проектування АІС - від простих засобів аналізу та документування до повномасштабних засобів автоматизації, що покривають весь життєвий цикл АІС. Найбільша потреба у використанні CASE-систем випробовується на початкових етапах розробки – на етапах аналізу та специфікації вимог до АІС. Допущені помилки практично фатальні, їх ціна значно перевищує ціну помилок пізніх етапів розробки.
Основні завдання CASE-засобів полягають у тому, щоб відокремити початкові етапи (аналіз та проектування) від наступних і не обтяжувати розробників деталями середовища розробки та функціонування системи.
У більшості сучасних CASE-систем застосовуються методології структурногота/або об'єктно-орієнтованого аналізуі проектування,засновані на використанні наочних діаграм, графів, таблиць та схем.
При грамотному застосуванні CASE-інструментарію досягається значне зростання продуктивності праці, що становить (за оцінками зарубіжних фірм користувачів CASE-технологій) від 100 до 600% залежно від обсягу, складності робіт та досвіду роботи з CASE. При цьому змінюються всі фази життєвого циклу АІС, але найбільші зміни стосуються фаз аналізу та проектування (табл. 2.5, 2.6).
Таблиця 2.5.Оцінки трудовитрат за фазами життєвого циклу АІС
Таблиця 2.6.Порівняння використання CASE та традиційної розробки
Застосування CASE-засобів не лише автоматизує структурну методологію та дає можливість використовувати сучасні методи системної та програмної інженерії, а й надає інші переваги (рис. 2.22), зокрема:
1. покращує якість програмного забезпечення, що розробляється за рахунок засобів автоматичної генерації та контролю;
2. дозволяє зменшити час створення прототипу АІС, що дає можливість на ранніх етапах оцінити якість та ефективність проекту;
3. прискорює процес проектування та розробки;
4. дозволяє багаторазово використовувати розроблені компоненти;
5. підтримує супровід АІС;
6. звільняє від рутинної роботи з документування проекту, оскільки використовує вбудований документатор;
7. полегшує колективну роботу над проектом.
Мал. 2.22.Переваги розробки АІС із використанням CASE-технологій: а- Коефіцієнт зменшення вартості проекту; б -коефіцієнт зменшення часових витрат на розробку
В основі більшості CASE-засобів лежать чотири основні поняття: методологія, метод, нотація, засіб [ 11,15, 16].
Методологіявизначає керівні вказівки для оцінки та вибору рішень при проектуванні та розробці АІС, етапи роботи, їх послідовність, правила розподілу та призначення методів.
Методи -процедури генерації компонентів та їх описів
Нотаціїпризначені для опису загальної структури системи, елементів даних, етапів обробки можуть включати графи, діаграми, таблиці, блок-схеми, формальні та природні мови.
Засоби- інструментарій для підтримки та посилення методів; підтримує роботу користувачів під час створення та редагування проекту в інтерактивному режимі, допомагає організувати проект у вигляді ієрархії рівнів абстракції, здійснює перевірки відповідності компонентів.
Класифікація CASE-засобів
Досі немає стійкої класифікації CASE-засобів, визначено лише підходи до класифікації залежно від різних класифікаційних ознак. Нижче наведено деякі з них.
Орієнтація на технологічні етапи та процеси життєвого циклу АІС:
1. засоби аналізу та проектування. Використовуються для створення специфікацій системи та її проектування. Вони підтримують широко відомі методології проектування;
2. засоби проектування баз даних. Забезпечують логічне моделювання даних, генерацію структур БД;
3. засоби управління вимогами;
4. засоби управління конфігурацією програмного обеспечения. Підтримують програмування, тестування, автоматичну генерацію з специфікацій;
5. засоби документування;
6. засоби тестування;
7. засоби управління проектом. Підтримують планування, контроль, взаємодію;
8. засоби реверсного інжинірингу, призначені для перенесення існуючої системи у нове середовище.
Підтримувані методології проектування[ 11, 12, 15, 16]:
1. функціонально-орієнтовані (структурно-орієнтовані);
2. об'єктно-орієнтовані;
3. комплексно-орієнтовані (набір методологій проектування).
Підтримувані графічні нотації побудови діаграм:
1. з фіксованою нотацією;
2. з окремими нотаціями;
3. з найпоширенішими нотаціями.
Ступінь інтегрованості:
1. допоміжні програми (Tools), які самостійно вирішують автономне завдання;
2. пакети розробки (Toolkit), які є сукупність коштів, які забезпечують допомогу однієї з класів програмних завдань;
3. набори інтегрованих засобів, пов'язаних загальною базою проектних даних - репозиторієм, що автоматизують усі або частину робіт різних етапів створення АІС (Workbench).
Колективна розробка проекту:
1. без підтримки колективної розробки;
2. зорієнтовані розробку проекту як реального времени;
3. орієнтовані режим об'єднання подпроектов.
Типи CASE-засобів:
1. засоби аналізу (Upper CASE); Серед спеціалістів називаються засобами комп'ютерного планування. За допомогою цих CASE-коштів будують модель, що відображає всю існуючу специфіку. Вона спрямована на розуміння загального та приватного механізмів функціонування, наявних можливостей, ресурсів, цілей проекту відповідно до призначення фірми. Ці засоби дозволяють проводити аналіз різних сценаріїв, накопичуючи інформацію для ухвалення оптимальних рішень;
2. засоби аналізу та проектування (Middle CASE); вважаються засобами підтримки етапів аналізу вимог та проектування специфікацій та структури АІС. Основний результат використання середнього CASE-засобу полягає і у значному спрощенні проектування системи, оскільки проектування перетворюється на ітеративний процес роботи з вимогами до АІС. Крім того, середні CASE-кошти забезпечують швидке документування вимог;
3. засоби розробки ПЗ (Lower); підтримують системи розроблення програмного забезпечення АІС. Містять системні словники та графічні засоби, що виключають необхідність розробки фізичних специфікацій - є системні специфікації, які безпосередньо переводяться в програмні коди системи, що розробляється (при цьому автоматично генерується до 80 % кодів). Головними перевагами нижніх CASE-коштів є значне зменшення часу на розробку, полегшення модифікацій, підтримка можливостей роботи з прототипами.
CASE-кошти, крім того, класифікують за типом та архітектурою обчислювальної техніки,а також за типом операційної системи.
В даний час ринок програмних продуктів представлений найрізноманітнішим програмним забезпеченням, у тому числі і CASE-засобами практично будь-якого з перерахованих класів.
Характеристики CASE-засобів
Silverrun. CASE-засіб Silverrun американської фірми Computer Systems Advisers, Inc. (CSA) використовується для аналізу та проектування АІС бізнес-класу та орієнтовано переважно на спіральну модель ЖЦ. Воно застосовується для підтримки будь-якої методології, заснованої на окремій побудові функціональної та інформаційної моделей (діаграм потоків даних та діаграм «сутність-зв'язок»).
Налаштування на конкретну методологію забезпечується вибором необхідної графічної нотації моделей та набору правил перевірки проектних специфікацій. У системі є готові налаштування для найбільш поширених методологій: DATARUN (основна методологія Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engineering. До кожного поняття, введеного у проекті, є можливість додавання своїх описателей. Архітектура Silverrun дозволяє нарощувати середовище розробки при необхідності.
Silverrun має модульну структуруі складається з чотирьох модулів, кожен з яких є самостійним продуктом і може купуватись та використовуватись окремо.
1. Модуль побудови моделей бізнес-процесіву формі діаграм потоків даних Business Process Modeler (BPM) дозволяє моделювати функціонування автоматизованої організації або створюваної АІС. Можливість роботи з моделями великої складності забезпечена функціями автоматичної перенумерації, роботи з деревом процесів (включаючи візуальне перетягування гілок), від'єднання та приєднання елементів моделі для колективної розробки. Діаграми можуть зображуватись у кількох зумовлених нотаціях, включаючи Yourdon/DeMarco та Gane/Sarson. Є також можливість створювати власні нотації, наприклад до числа дескрипторів, що зображуються на схемі, додавати певні користувачем поля.
2. Модуль концептуального моделювання даних Entity-Relationship eXpert (ERX) забезпечує побудову моделей даних «сутність-зв'язок», які не прив'язані до конкретної реалізації. Вбудована експертна система дозволяє створювати коректну нормалізовану модель даних у вигляді відповідей змістовні питання взаємозв'язку даних. Передбачено автоматичну побудову моделі даних із описів структур даних. Аналіз функціональних залежностей атрибутів дає можливість перевірити відповідність моделі вимогам третьої нормальної форми та забезпечити їх виконання. Перевірена модель передається модуль Relational Data Modeler.
3. Модуль реляційного моделювання Relational Data Modeler (RDM) дозволяє створювати деталізовані моделі "сутність-зв'язок", призначені для реалізації в реляційній БД. У цьому модулі документуються всі конструкції, пов'язані з побудовою бази даних: індекси, тригери, процедури, що зберігаються і т. д. Гнучка змінна нотація і розширюваність репозиторію дозволяють працювати за будь-якою методологією. Можливість створення підсхем відповідає підходу ANSI SPARC до представлення схеми БД. На мові підсхем моделюються як вузли розподіленої обробки, так і уявлення користувача. Цей модуль забезпечує проектування та повне документування реляційних БД.
4. Менеджер репозиторію робочої групи Workgroup Repository Manager (WRM) застосовується як словник даних для зберігання загальної всіх моделей інформації, а також забезпечує інтеграцію модулів Silverrun в єдине середовище проектування.
Достоїнством CASE-засобу Silverrun є висока гнучкість та різноманітність образотворчих засобів побудови моделей, а недоліком – відсутність жорсткого взаємного контролю між компонентами різних моделей (наприклад, можливості автоматичного розповсюдження змін між DFD різних рівнів декомпозиції). Слід, однак, відзначити, що цей недолік може мати важливе значення тільки у разі використання каскадної моделі життєвого циклу.
У Silverrun включені кошти:
1. автоматична генерація схем баз даних для найбільш поширених СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase;
2. передачі даних засобам розробки програм: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.
Таким чином, можна повністю визначити ядро БД з використанням усіх можливостей конкретної СУБД: тригерів, процедур, що зберігаються, обмежень посилальної цілісності. При створенні програми дані, перенесені з репозиторію Silverrun, використовуються або для автоматичного створення інтерфейсних об'єктів, або для швидкого їх створення вручну.
Для обміну даними з іншими засобами автоматизації проектування, створення спеціалізованих процедур аналізу та перевірки проектних специфікацій, складання спеціалізованих звітів відповідно до різних стандартів у системі Silverrun передбачено три способи видачі проектної інформації у зовнішні файли.
1. Система звітів. Звіти виводяться у текстові файли.
2. Система експорту/імпорту. Задається не лише вміст експортного файлу, а й роздільники записів, полів у записах, маркери початку та кінця текстових полів. Такі експортні файли можна формувати та завантажувати у репозиторій. Це дозволяє обмінюватися даними з різними системами: іншими CASE-засобами, СУБД, текстовими редакторами та електронними таблицями.
3. Зберігання репозиторію у зовнішніх файлах з доступом за допомогою ODBC-драйверів. Для доступу до даних репозиторію з найпоширеніших СУБД забезпечено можливість зберігати всю проектну інформацію у форматі цих СУБД.
Silverrun підтримує два способи групової роботи:
1) у стандартній однокористувацькій версії є механізм контрольованого поділу та злиття моделей. Модель може бути розділена на частини та розподілена між декількома розробниками. Після детального опрацювання частини знову збираються у єдину модель;
2) мережева версія Silverrun дозволяє вести паралельну групову роботу з моделями, що зберігаються в мережевому репозиторії на базі СУБД Oracle, Sybase або Informix. При цьому кілька розробників можуть працювати з однією моделлю, оскільки блокування об'єктів відбувається на рівні окремих елементів моделі.
JAM. Засіб розробки додатків JYACC"s Application Manager (JAM) - продукт фірми JYACC. Головною особливістю є відповідність методології RAD, так як JAM дозволяє досить швидко реалізувати цикл розробки програми, що полягає у формуванні чергової версії прототипу програми з урахуванням вимог, виявлених на попередньому кроці, і пред'явити його користувачеві.
JAM має модульну структуру та складається з наступних компонентів:
1. ядра системи;
2. JAM/DBi – спеціалізованих модулів інтерфейсу до СУБД (JAM/DBi-Oracle, JAM/DBi-Informix, JAM/DBi-ODBC тощо);
3. JAM/RW – модуля генератора звітів;
4. JAM/CASEi - спеціалізованих модулів інтерфейсу до CASE-засобів (JAM/CASE-TeamWork, JAM/CASE-Inno-vator тощо);
5. JAM/TPi - спеціалізованих модулів інтерфейсу до менеджерів транзакцій (наприклад, JAM/TPi-Server TUXEDO тощо);
6. Jterm – спеціалізованого емулятора Х-терміналу.
Ядро системи є закінченим продуктом і може використовуватися для розробки додатків. Всі інші модулі – додаткові та самостійно використовуватися не можуть.
Ядро системи включає такі основні компоненти:
1. редактор екранів. До складу редактора екранів входять середовище розробки екранів, візуальний репозиторій об'єктів, власна СУБД JAM – JDB, менеджер транзакцій, відладчик, редактор стилів;
2. редактор меню;
3. набір допоміжних утиліт;
4. засоби виготовлення промислової версії програми.
При використанні JAM розробка зовнішнього інтерфейсу програми є візуальним проектуванням і зводиться до створення екранних форм шляхом розміщення на них інтерфейсних конструкцій і визначення екранних полів введення/виведення інформації. Проектування інтерфейсу в JAM здійснюється за допомогою редактор екранів.Програми, розроблені в JAM, мають багатовіконний інтерфейс. Розробка екрану полягає у розміщенні на ньому інтерфейсних елементів, їх групуванні, завданні значень їх властивостей.
Редактор менюдозволяє розробляти та налагоджувати системи меню. Реалізовано можливість побудови піктографічних меню. Призначення пунктів меню до об'єктів програми здійснюється в редакторі екранів.
У ядро JAM вбудована однокористувальна реляційна СУБД JDB. Основним призначенням JDB є прототипування додатків у випадках, коли робота зі штатної СУБД неможлива чи недоцільна. У JDB реалізований необхідний мінімум можливостей реляційних СУБД, до якого не входять індекси, процедури, що зберігаються, тригери і уявлення. За допомогою JDB можна побудувати БД, ідентичну цільовій БД (з точністю до відсутніх JDB можливостей), і розробити значну частину програми.
Відладчик дозволяє проводити комплексне налагодження програми, що розробляється. Здійснюється трасування всіх подій, що виникають у процесі виконання програми.
Утиліти JAM включають три групи:
1) конвертори файлів екранів JAM у текстові. JAM зберігає екрани як двійкових файлів власного формату;
2) конфігурування пристроїв введення-виведення. JAM та програми, побудовані за його допомогою, не працюють безпосередньо з пристроями введення-виведення. Натомість JAM звертається до логічних пристроїв введення-виводу (клавіатура, термінал, звіт);
3) обслуговування бібліотек екранів.
Одним із додаткових модулів JAM є генератор звітів.Компонування звіту здійснюється у редакторі екранів JAM. Опис роботи звіту здійснюється за допомогою спеціальної мови. Генератор звітів дозволяє визначити дані, що виводяться у звіт, групування інформації, що виводиться, форматування виводу і т.д.
Програми, розроблені з використанням JAM, можуть бути виготовлені у вигляді модулів, що виконуються. Для цього розробники повинні мати компілятор С та редактор зв'язків.
JAM містить вбудована мова програмування JPL (JAM Procedural Language), за допомогою якого у разі потреби можуть бути написані модулі, що реалізують специфічні дії. Ця мова є інтерпретованою. Існує можливість обміну інформацією між середовищем візуально побудованого додатка та такими модулями. Крім того, в JAM реалізовано можливість підключення зовнішніх модулів, написаних мовами, сумісних за викликами функцій з мовою С.
JAM є подієво-орієнтованою системою,що складається з набору подій - відкриття та закриття вікон, натискання клавіші клавіатури, спрацювання системного таймера, отримання та передача керування кожним елементом екрану. Розробник реалізує логіку програми шляхом визначення оброблювача кожної події.
Оброблювачами подій JAM можуть бути як вбудовані функції JAM, так і функції, написані розробником на С або JPL. Набір вбудованих функцій містить понад 200 функцій різного призначення; вони доступні для дзвінків із функцій, написаних як на JPL, так і на С.
Промислова версія програми,розробленого за допомогою JAM, складається з наступних компонентів:
1. виконуваного модуля інтерпретатора програми;
2. екранів, що становлять додаток (поставляються у вигляді окремих файлів, у складі бібліотек екранів або вбудовуються в тіло інтерпретатора);
3. зовнішніх JPL-модулів (поставляються у вигляді текстових файлів або в прекомпілірованому вигляді; прекомпіліро-
4. ванні зовнішні JPL-модулі - у вигляді окремих файлів та у складі бібліотек екранів);
5. файлів конфігурації програми - файлів конфігурації клавіатури та терміналу, файлу системних повідомлень, файлу загальної конфігурації.
Безпосередня взаємодія із СУБД реалізують модулі JAM/DBi (Database interface). Способи реалізації взаємодії в JAM поділяються на два класи: ручні та автоматичні.
При ручний спосіброзробник самостійно пише запити на SQL, у яких джерелами і адресатами прийому результатів виконання запиту може бути як інтерфейсні елементи візуально спроектованого зовнішнього рівня, і внутрішні, невидимі кінцевого користувача змінні.
Автоматичний режимреалізується менеджером транзакцій JAM. Він здійснимо для типових поширених видів операцій з БД, так званих QBE (Query By Example - запити за зразком), з урахуванням досить складних взаємозв'язків між таблицями БД та автоматичним керуванням атрибутами екранних полів введення-виводу залежно від виду транзакції (читання, запис та т. д.), в якій бере участь згенерований запит.
JAM дозволяє будувати програми для більш ніж 20 СУБД: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-сумісні СУБД та ін.
Відмінною рисою JAM є високий рівень переносимості програм між різними платформами (MS DOS/MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS/Open VMS та ін.); можлива вимога "перемалювати" статичні текстові поля на екранах з російським текстом при переносі між середовищами DOS-Windows-UNIX. Крім того, переносимість полегшується тим, що в JAM програми розробляються для віртуальних пристроїв введення-виведення, а не для фізичних. Таким чином, при перенесенні програми з платформи на платформу, як правило, потрібно лише визначити відповідність між фізичними пристроями введення-виведення та їх логічними уявленнями для програми.
Використання SQL як засіб взаємодії з СУБД також допомагає забезпечувати переносимість між СУБД. У разі перенесення структури БД програми можуть вимагати ніякої модифікації, крім ініціалізації сеансу роботи. Це можливо, якщо програма не використовувала специфічні для СУБД розширення SQL.
При зростанні навантаження на систему та складності розв'язуваних завдань (розподіленість та гетерогенність використовуваних ресурсів, кількість одночасно підключених користувачів, складність логіки програми) застосовується триланкова модель архітектури"Клієнт - сервер" з використанням менеджерів транзакцій. Компоненти JAM/TPi-Client та JAM/TPi-Server дозволяють досить просто перейти на триланкову модель. У цьому ключову роль грає модуль JAM/TPi-Server, оскільки основна складність застосування триланкової моделі полягає у реалізації логіки докладання у сервісах менеджерів транзакцій.
Інтерфейс JAM/CASE дозволяє здійснювати обмін інформацією між репозиторієм об'єктів JAM та репозиторієм CASE-засобу. Обмін відбувається аналогічно до того, як структура БД імпортується в репозиторій JAM безпосередньо з БД. Відмінність полягає в тому, що обмін між репозиторіями є двонаправленим.
Крім модулів JAM/CASEi, існує також модуль JAM/CASEi Developer's Kit. За допомогою цього модуля можна самостійно розробити інтерфейс (тобто спеціалізований модуль JAM/CASEi) для конкретного CASE-засобу, якщо готового модуля JAM/CASEi для нього не існує.
Існує інтерфейс, що реалізує взаємодію між CASE-засобом Silverrun та JAM. Він робить перенесення схеми БД та екранних форм програми між CASE-засобом Silverrun-RDM та JAM версії 7.0; має два режими роботи:
1) прямий режим (Silverrun-RDM->JAM) призначений для створення об'єктів CASE-словника та елементів репозиторію JAM на основі представлення схем у Silverrun-RDM. З представлення моделей даних інтерфейсу Silverrun-RDM виробляється генерація екранів і елементів репозиторію JAM. Міст перетворює таблиці та відносини реляційних схем RDM на послідовність об'єктів JAM відповідних типів. Методика побудови моделей даних інтерфейсу Silverrun-RDM передбачає застосування механізму підсхем для прототипування екранів програми. За описом кожної із підсхем RDM міст генерує екранну форму JAM;
2) зворотний режим (JAM-> Silverrun-RDM) призначений для перенесення модифікацій об'єктів CASE-словника у реляційну модель Silverrun-RDM.
Режим реінжинірингу дозволяє переносити модифікації всіх властивостей екранів JAM, раніше імпортованих з RDM, в схему Silvcrrun. Для контролю цілісності БД не допускаються зміни схеми як додавання чи видалення таблиць і полів таблиць.
Ядро JAM має інтегрований до засобів конфігураційного управління (PVCS на платформі Windows і SCCS на платформі UNIX). Під керуванням цих систем передаються бібліотеки екранів та/або репозиторії. За відсутності таких систем, JAM самостійно реалізує частину функцій підтримки групової розробки.
На платформі MS-Windows JAM має вбудований інтерфейс до PVCS, і дії щодо вибірки/повернення виконуються безпосередньо з середовища JAM.
Vantage Team Builder (Westmount I-CASE). Vantage Team Builder є інтегрованим програмним продуктом, орієнтованим на реалізацію та повну підтримку каскадної моделі життєвого циклу.
Vantage Team Builder забезпечує виконання наступних функцій:
1. проектування діаграм потоків даних, діаграм «сутність-зв'язок», структур даних, структурних схем програм та послідовностей екранних форм;
2. проектування діаграм архітектури системи - SAD (проектування складу та зв'язку обчислювальних засобів, розподілу завдань системи між обчислювальними засобами, моделювання відносин типу «клієнт - сервер», аналіз використання менеджерів транзакцій та особливостей функціонування систем у реальному часі);
3. генерація коду програм мовою цільової СУБД із повним забезпеченням програмного середовища проживання і генерація SQL-коду до створення таблиць БД, індексів, обмежень цілісності і збережених процедур;
4. програмування мовою З вбудованим SQL;
5. управління версіями та конфігурацією проекту;
6. розрахований на багато користувачів доступ до репозиторію проекту;
7. генерація проектної документації за стандартними та індивідуальними шаблонами;
8. експорт та імпорт даних проекту у форматі CDIF (CASE Data Interchange Format).
Vantage Team Builder поставляється в різних конфігураціях залежно від СУБД (ORACLE, Informix, Sybase або Ingres) або засобів розробки додатків (Uniface). Конфігурація Vantage Team Builder for Uniface відрізняється від інших частковою орієнтацією на спіральну модель життєвого циклу з допомогою можливостей швидкого прототипування. Для опису проекту АІС використовується великий набір діаграм.
При побудові всіх типів діаграм забезпечується контроль відповідності моделей синтаксису використовуваних методів, а також контроль відповідності однойменних елементів та їх типів різних типів діаграм.
При побудові діаграм потоків даних DFD забезпечує контроль відповідності діаграм різних рівнів декомпозиції. Контроль за правильністю верхнього рівня DFD здійснюється за допомогою матриці списків подій ELM. Для контролю над декомпозицією складових потоків даних використовується кілька варіантів їх описи: як діаграм структур даних DSD або в нотаціїБНФ (форма Бекуса – Наура).
Для побудови SAD використовується розширена нотація DFD, що дозволяє вводити поняття процесорів, завдань та периферійних пристроїв, що забезпечує наочність проектних рішень.
При побудові моделі даних як ERD виконується її нормалізація і вводиться визначення фізичних імен елементів даних і таблиць, які використовуватимуться у процесі генерації фізичної схеми даних конкретної СУБД. Забезпечується можливість визначення альтернативних ключів сутностей та полів, що становлять додаткові точки входу до таблиці (поля індексів), та потужності відносин між сутностями.
Наявність універсальної системи генерації коду, що ґрунтується на специфікованих засобах доступу до репозиторію проекту, дозволяє підтримувати високий рівень виконання проектної дисципліни розробниками: жорсткий порядок формування моделей; жорстку структуру та вміст документації; автоматичну генерацію вихідних кодів програм тощо; все це забезпечує підвищення якості та надійності розроблюваних ІВ.
Для підготовки проектної документації можна використовувати видавничі системи FrameMaker, Interleaf або Word Perfect. Структура та склад проектної документації налаштовуються відповідно до заданих стандартів. Налаштування виконується без зміни проектних рішень.
Під час розробки великих АІС вся система загалом відповідає одному проекту як категорії Vantage Team Builder. Проект може бути декомпозований на низку систем, кожна з яких відповідає деякій відносно автономній підсистемі АІС та розробляється незалежно від інших. Надалі системи проекту можуть бути інтегровані.
Процес проектування АІС з використанням Vantage Team Builder реалізується у вигляді чотирьох послідовних фаз (стадій) аналізу, архітектури, проектуванняі реалізації,при цьому закінчені результати кожної стадії повністю або частково переносяться (імпортуються) у наступну фазу. Всі діаграми, крім ERD, перетворюються на інший тип або змінюють вигляд відповідно до особливостей поточної фази. Так, DFD перетворюються на фазі архітектури в SAD, DSD - в DTD. Після завершення імпорту логічний зв'язок із попередньою фазою розривається, тобто в діаграми можна вносити всі необхідні зміни.
Конфігурація Vantage Team Builder for Uniface забезпечує спільне використання двох систем у рамках єдиного технологічного середовища проектування, при цьому схеми БД (SQL-моделі) переносяться до репозиторію Uniface, і навпаки, прикладні моделі, сформовані засобами Uniface, можуть бути перенесені до репозиторію Vantage Team Builder . Можливі неузгодженості між репозиторіями двох систем усуваються за допомогою спеціальної утиліти. Розробка екранних форм серед Uniface виконується з урахуванням діаграм послідовностей форм FSD після імпорту SQL-модели. Технологія розробки АІС з урахуванням цієї зміни показано на рис. 2.23.
Структура репозиторію, що зберігається в цільовій СУБД, та інтерфейси Vantage Team Builder є відкритими, що в принципі забезпечує можливість інтеграції з будь-якими іншими засобами.
Uniface.Продукт фірми Compuware є середовищем розробки великомасштабних додатків в архітектурі «клієнт-сервер» і має наступну компонентну архітектуру:
1. Application Objects Repository (репозиторій об'єктів додатків) містить метадані, що автоматично використовуються всіма іншими компонентами протягом життєвого циклу АІС (прикладні моделі, описи даних, бізнес-правил, екранних форм, глобальних об'єктів і шаблонів). Репозиторій може зберігатися у будь-якій з БД, що підтримуються Uniface;
Мал. 2.23.Взаємодія Vantage Team Builder та Uniface
2. Application Model Manager підтримує прикладні моделі (E-R-моделі), кожна з яких є підмножиною загальної схеми БД з точки зору даної програми, і включає відповідний графічний редактор;
3. Rapid Application Builder – засіб швидкого створення екранних форм та звітів на базі об'єктів прикладної моделі. Включає графічний редактор форм, засоби прототипування, налагодження, тестування та документування. Реалізовано інтерфейс із різноманітними типами віконних елементів керування Open Widget Interface для існуючих графічних інтерфейсів – MS Windows (включаючи VBX), Motif, OS/2. Універсальний інтерфейс представлення Universal Presentation Interface дозволяє використовувати ту саму версію програми серед різних графічних інтерфейсів без зміни програмного коду;
4. Developer Services (служби розробника) використовуються для підтримки великих проектів та реалізують контроль версій (Uniface Version Control System), права доступу (розмежування повноважень), глобальні модифікації тощо. Це забезпечує розробників засобами паралельного проектування, вхідного та вихідного контролю, пошуку, перегляду, підтримки та видачі звітів за даними системи контролю версій;
5. Deployment Manager (управління розповсюдженням додатків) - засоби, що дозволяють готувати створений додаток для розповсюдження, встановлювати та супроводжувати його (при цьому платформа користувача може відрізнятись від платформи розробника). До їх складу входять мережеві драйвери та драйвери СУБД, сервер додатків (полісервер), засоби поширення додатків та управління БД. Uniface підтримує інтерфейс практично з усіма відомими програмно-апаратними платформами, СУБД, CASE-засобами, мережевими протоколами та менеджерами транзакцій;
6. Personal Series (персональні засоби) використовуються для створення складних запитів та звітів у графічній формі (Personal Query та Personal Access - PQ/PA), а також для перенесення даних у такі системи, як WinWord та Excel;
7. Distributed Computing Manager – засіб інтеграції з менеджерами транзакцій Tuxedo, Encina, CICS, OSF DCE.
Версія Uniface 7 повністю підтримує розподілену модель обчислень та триланкову архітектуру «клієнт-сервер» (з можливістю зміни схеми декомпозиції додатків на етапі виконання). Програми, що створюються за допомогою Uniface 7, можуть виконуватися в гетерогенних операційних середовищах, що використовують різні мережеві протоколи, одночасно на кількох різнорідних платформах (у тому числі й у Internet).
До складу компонентів Uniface 7 входять:
1. Uniface Application Server – сервер додатків для розподілених систем;
2. WebEnabler - серверне програмне забезпечення для експлуатації додатків в Internet і intranet;
3. Name Server - серверне програмне забезпечення, що забезпечує використання розподілених прикладних ресурсів;
4. PolyServer - засіб доступу до даних та інтеграції різних систем.
До списку підтримуваних СУБД входять DB2, VSAM та IMS; PolyServer також забезпечує взаємодію з ОС MVS.
Designer/2000+ Developer/2000. Designer/2000 2.0 фірми ORACLE є інтегрованим CASE-засобом, що забезпечує разом із засобами розробки додатків Developer/2000 підтримку повного ЖЦ ПЗ для систем, що ісользують СУБД ORACLE .
Designer/2000 є сімейством методологій і програмних продуктів, що підтримують їх. Базова методологія Designer/2000 (CASE*Method) – структурна методологія проектування систем, що повністю охоплює всі етапи життєвого циклу АІС. На етапі планування визначаються цілі створення системи, пріоритети та обмеження, розробляється системна архітектура та план розробки АІС. У процесі аналізу будуються: модель інформаційних потреб (діаграма «сутність-зв'язок»), діаграма функціональної ієрархії (на основі функціональної декомпозиції АІС), матриця перехресних посилань та діаграма потоків даних.
На етапі проектування розробляється докладна архітектура АІС, проектується схема реляційної БД та програмні модулі, встановлюються перехресні посилання між компонентами АІС для аналізу їхнього взаємного впливу та контролю за змінами.
На етапі реалізації створюється БД, будуються прикладні системи, провадиться їх тестування, перевірка якості та відповідності вимогам користувачів. Створюється системна документація, матеріали для навчання та керівництва користувачів. На етапах експлуатації та супроводу аналізуються продуктивність та цілісність системи, виконується підтримка та, за необхідності, модифікація АІС.
Designer/2000 забезпечує графічний інтерфейс розробки різних моделей (діаграм) предметної області. У процесі побудови моделей інформація про них заноситься до репозиторію. До складу Designer/2000 входять такі компоненти.
Дотримання наведених принципів необхідне під час виконання робіт усім стадіях створення та функціонування АИС і АИТ, тобто. протягом усього їхнього життєвого циклу.
Життєвий цикл(ЖЦ) - період створення та використання АІС (АІТ), починаючи з моменту виникнення необхідності в даній автоматизованій системі та закінчуючи моментом її виходу з вживання.
Життєвий цикл АІС та АІТ дозволяє виділити чотири основні стадії, кожна стадія проектування поділяється на ряд етапів та передбачає відповідні роботи:
I стадія - передпроектне обстеження:
1-й етап - формування вимог, вивчення об'єкта проектування, розробка та вибір варіанта концепції системи;
2-й етап - аналіз матеріалів та формування документації - створення та затвердження техніко-економічного обґрунтування та технічного завдання на проектування системи на основі аналізу матеріалів обстеження, зібраних на першому етапі.
ІІ стадія - проектування:
1-й етап - технічне проектування,де ведеться пошук найбільш раціональних проектних рішень з усіх аспектів розробки, створюються та описуються всі компоненти системи, а результати роботи відображаються у технічному проекті;
2-й етап - робоче проектування,у процесі якого здійснюється розробка та доведення програм, коригування структур баз даних, створення документації на постачання, встановлення технічних засобів та інструкцій з їх експлуатації, підготовка для кожного користувача посадових інструкцій. Технічний та робочий проекти можуть об'єднуватися в єдиний документ – техноробочий проект.
ІІІ стадія - введення системи у дію:
1-й етап - підготовка до впровадження- встановлення та введення в експлуатацію технічних засобів, завантаження баз даних та дослідна експлуатація програм, навчання персоналу;
2-й етап - проведення дослідних випробуваньвсіх компонентів системи перед передачею у промислову експлуатацію, навчання персоналу;
3-й етап (завершальна стадія створення АІС та АІТ) - здавання в промислову експлуатацію;оформляється актами приймання-здавання робіт.
IV стадія - промислова експлуатація - крім повсякденного функціонування включає супровід програмних засобів та всього проекту, оперативне обслуговування та адміністрування баз даних.
5. Методи ведення проектувальних робіт
Створення автоматизованих інформаційних систем та технологій може здійснюватися за двома варіантами. Перший варіант передбачає, що цією роботою займаються спеціалізовані фірми, які мають професійний досвід підготовки програмних продуктів конкретної орієнтації. За другим варіантом, проектуванням та створенням розробок займаються проектувальники-програмісти, які перебувають у штаті підприємств, де створюються нові інформаційні технології та системи.
У процесі розробки автоматизованих систем, робочих місць та технологій проектувальники стикаються з низкою взаємопов'язаних проблем:
Проектувальнику складно отримати вичерпну інформацію для оцінки формулюваних замовником (користувачем) вимог до нової системи чи технології.
Замовник нерідко не має достатніх знань щодо проблем автоматизації, щоб судити про можливість реалізації тих чи інших інновацій. У той же час проектувальник стикається з надмірною кількістю докладних відомостей про проблемну область, що викликає труднощі моделювання та формалізованого опису інформаційних процесів та вирішення функціональних завдань.
Специфікація проектованої системи через великий обсяг та технічні терміни часто незрозуміла замовнику, а надмірне її спрощення не може задовольнити фахівців, які створюють систему.
За допомогою відомих аналітичних методів можна вирішити деякі з перерахованих проблем, проте радикальне рішення дають лише сучасні структурні методи, серед яких центральне місце займає методологія структурного аналізу.
Структурним аналізом називається метод дослідження системи, який починається з її загального огляду і потім деталізується, набуваючи ієрархічної структури з дедалі більшим числом рівнів.
Структурний аналіз передбачає розбиття системи на рівні абстракції з обмеженою кількістю елементів кожному з рівнів (зазвичай від 3 до 6-7). На кожному рівні виділяються лише суттєві для системи деталі.
Методологія структурного аналізу базується на принципах декомпозиції та принцип ієрархічного впорядкування.
Принцип декомпозиціїпередбачає вирішення важких завдань шляхом розбиття їх на завдання легкі для розуміння та розв'язання.
Принцип ієрархічного впорядкуваннядекларує, що система може бути зрозуміла та побудована за рівнями, кожен із яких додає нові деталі.
на передпроектної стадіїпроводиться вивчення та аналіз усіх особливостей об'єкта проектування з метою уточнення вимог замовника. Зокрема, виявляється сукупність умов, за яких передбачається експлуатувати майбутню систему (апаратні та програмні ресурси; зовнішні умови її функціонування; склад людей та робіт, що мають до неї відношення та беруть участь в інформаційних та управлінських процесах), проводиться опис виконуваних системою функцій тощо. п.
На цьому етапі визначаються:
Архітектура системи, її функції, зовнішні умови, розподіл функцій між апаратними засобами та програмним забезпеченням;
Інтерфейси та розподіл функцій між людиною та системою;
Вимоги до програмних та інформаційних компонентів системи, необхідні апаратні ресурси, вимоги до бази даних, фізичні характеристики компонентів системи, їх інтерфейси.
Якість подальшого проектування вирішальним чином залежить від правильного вибору методів аналізу, сформульованих вимог до новоствореної технології.
Методи, що використовуються на стадії передпроектного обстеження, поділяються на:
- Методи вивчення та аналізу фактичного стану об'єкта або технології. Ці методи дозволяють виявити вузькі місця в досліджуваних процесах і включають: усне чи письмове опитування; письмове анкетування; спостереження, вимірювання та оцінку; групове обговорення; аналіз завдань; аналіз виробничих та управлінських процесів.
Загалом методи вивчення та аналізу фактичного стану управлінської діяльності та існуючої технології вирішення завдань призначені для збору необхідних матеріалів та формування основи для проектування АІС та АІТ.
- Методи формування заданого стану. Ґрунтуються на обґрунтуванні всіх складових частин АІС виходячи з цілей, вимог та умов замовника. До даних методів, що є робочими засобами проектувальників, відносяться методи: моделювання процесу управління; структурне проектування; декомпозиція; аналіз інформаційного процесу
- метод моделювання процесу управління.У процесі вивчення об'єкта проектування будуються економіко-організаційні та інформаційно-логічні моделі. Вони відображають господарські та управлінські відносини, а також пов'язані з ними інформаційні потоки.
- метод структурного проектуваннядозволяє розділити весь комплекс завдань на доступні для огляду підкомплекси (модулі).
- метод декомпозиціїмодулів передбачає подальше розбиття підкомплексів задач на окремі завдання, показники
- аналіз інформаційних процесівпризначений для виявлення та подання взаємозв'язку між результатом, процесом обробки та введенням даних. Він використовується також для аналізу та формування інформаційних зв'язків між робочими місцями працівників управління, спеціалістів, технічного персоналу та інформаційними технологіями. З цією метою описуються вхідна та вихідна інформація, а також алгоритм обробки інформації стосовно кожного робочого місця.
- Методи графічного представлення фактичного та заданого станівпередбачають використання наочного подання процесів обробки інформації. До найбільш відомих їх відносяться блок-схемний метод, методи стрілочних діаграм, мережевих графіків, таблиць послідовності операцій проходження процесів.
Якщо на передпроектній стадії мають бути сформульовані в технічному завданні вимоги до створення АІС та АІТ, то проектування має дати відповідь на запитання: «Як система задовольнятиме вимогам до неї?».
У результаті виконання етапів проектування має бути отримано проект системи у межах бюджету виділених ресурсів.
Етапи проектування включають такі основні роботи:
Розробку цілей та організаційних принципів АІС;
Формування варіанта АІС та АІТ;
Налагодження програм;
Дослідна експлуатація;
Здача проекту АІС та АІТ.
У процесі організації проектування приймаються різноманітні рішення, що впливають динаміку і якість виконання робіт. Тому для кожного етапу проектування визначаються: очікувані результати та документи; персональні функції керівника; рішення, що приймаються керівником; функції замовника та розробника АІС та АІТ.
До складу проектної та виконавчої документації входять: інструкції робочих процесів, програми для робочих місць, інструкції щодо оформлення документів, рекомендації щодо використання інформації, методів, таблиць рішень тощо.
У сучасних умовах АІС, АІТ та АРМ, як правило, не створюються на порожньому місці. Потреба своєчасної, якісної, оперативної інформації та оцінка її як найважливішого ресурсу в управлінських процесах, а також останні досягнення науково-технічного прогресу викликають необхідність перебудови функціонуючих АІС та створення АІС та АІТ на новій технічній та технологічній базах.
Проектування АІС
Деталізована розробка проекту системи, що містить повний комплект її організаційної, конструкторської, технологічної та експлуатаційної документації Відповідно до ГОСТ 34.601-90. проектування автоматизованих систем передбачає виконання низки стадій, зокрема: формування вимог до АС, розробку концепції АС, розробку технічного завдання, ескізне проектування, технічне проектування та розробку робочої документації. Стадії створення АС, крім проектування, включають також: введення в дію та супровід АС. Кожна стадія поділяється на етапи. У додатках до цього стандарту також визначено:
· Перелік видів організацій, що у роботах.
Залежно від характеру об'єкта проектування та конкретних умов ГОСТ 34.601-90 допускає вилучення окремих стадій, і навіть їх об'єднання. З урахуванням багаторічної практики, що склалася в Росії при створенні автоматизованих інформаційних систем (" АІС”) зазвичай виконуються такі стадії проектування: передпроектне обстеження, концептуальне проектування, ескізне проектування, технічне проектування та робоче проектування. Інші державні стандарти, що регламентують різні аспекти проектування АС:
· ГОСТ 34.602-89 Комплекс стандартів на автоматизовані системи. Технічне завдання створення автоматизованої системи. Введ.01.01.90.
· Стандарт 34.603-92 Інформаційна технологія. Види випробувань АС.
· Стандарти 34. (971, 972,973, 974, 981) – 91 Інформаційна технологія. Взаємозв'язок відкритих систем.
· Стандарт 34.91. Інформаційна технологія. Локальні обчислювальні мережі та ін.
Передпроектне обстеження- Збір та обробка відомостей про організацію та особливості функціонування об'єкта автоматизації, включаючи даних про його взаємодію із зовнішнім середовищем та іншими об'єктами, а також виконання системного аналізу, розробка техніко-економічного обґрунтування доцільності автоматизації та вироблення загальних вимог на розробку автоматизованої системи. Зміст робіт при передпроектному обстеженні об'єкта автоматизації відповідає стадії "Формування вимог до АС" ГОСТ 34.601-90, етапи: "Обстеження об'єкта та обґрунтування необхідності створення АС", "Формування вимог користувача до АС", "Оформлення звіту про виконану роботу та заявки на розробку АС – тактико-технічного завдання”.
Концептуальне проектування- Відповідає стадіям проектування за ГОСТ 34.601-90 - "Розробка концепції АС" (етапи: "Розробка варіантів концепції АС та вибір варіанта концепції АС, що задовольняє користувача", "Оформлення звіту про виконану роботу") та "Розробка технічного завдання". Видами підсумкових документів робіт на цій стадії є аванпроект(також використовуються найменування - “ Концептуальний проект ”, “Пілотний проект”) або Програмастворення системи, які включають:
· Коротку характеристику вихідного стану об'єкта автоматизації та середовища, в якому він функціонує;
· Вказівка основних цілей та перелік завдань автоматизації;
· Опис укрупненої організаційно-функціональної структури обраного варіанта (або варіантів) побудови створюваної системи;
· Техніко-економічне обґрунтування;
· Укрупнений опис та основні вимоги до засобів інформаційного та лінгвістичного забезпечення;
· Загальні вимоги до засобів програмно-апаратного забезпечення;
· Перелік та укрупнену характеристику етапів створення системи, терміни їх виконання, склад виконавців та очікувані результати їх виконання;
· Вихідну оцінку вартісних показників виконання робіт;
· Технічне завдання на систему в цілому та/або її основні складові частини (підсистеми, програмно-технічні комплекси та засоби, окремі завдання тощо), що затверджується Замовником робіт.
Ескізне проектування- Розробка попередніх проектних рішень за системою та її частинами. Підсумковим документом виконання робіт на даній стадії проектування є ескізний проект, який містить принципові конструкторські та схемні рішення об'єкта розробки, а також дані, що визначають його призначення та основні параметри (при проектуванні програмного забезпеченнясистеми ескізний проект повинен містити повну специфікаціюрозроблюваних програм).
Технічне проектування -Стадія робіт з проектування АС, яка включає:
· Розробку проектних рішень за системою та її частинами;
· Розробку документації на АС та її частини;
· Розробку та оформлення документації на поставку виробів для комплектування АС та/або технічних вимог (технічних завдань) на їх розробку;
· Розробка завдань на проектування у суміжних частинах проекту об'єкта автоматизації.
Підсумковим документом цієї стадії проектування є технічний проект, що містить крім перерахованих матеріалів важливі електричні схеми та конструкторську документацію об'єкта розробки та складових його частин, перелік обраних готових засобів програмного та технічного забезпечення(у тому числі - ЕОМ, операційної системи, прикладних програмі т.д.), а також алгоритмивирішення завдань для розробки нових засобів програмного забезпечення та ін.
Робоче проектування- Заключна стадія проектування, яка окрім необхідної ГОСТ 34.601-90 розробки робочої документації на систему та її частини у загальному випадку передбачає уточнення та деталізацію результатів попередніх етапів, створення та випробування дослідного та/або дослідно-промислового зразка об'єкта автоматизації, розробку та відпрацювання програмних продуктів, технологічної та експлуатаційної документації. Результати викладаються в робітникомабо техноробочому проекті. У сучасній практиці проектування автоматизованих інформаційних систем(наприклад, АБІС, АСНТІ, АСУта ін) він є початковим етапом їх впровадження в роботу фірми, організації або служби, що є замовником проекту, або головною в низці інших автоматизованих фірм, організацій, служб тощо.
Цикл розробки (проектування) програмного забезпечення -Сукупність стадій розробки програмного забезпеченняпочинаючи від системного аналізута розробки вихідних вимог до її впровадження.
Принципи проектування АІС- Набір закріплених багаторічним та різнобічним досвідом створення та експлуатації АІС правил чи вимог. Найбільш спільні з них:
· Ідентичність- розробка нової, вдосконалення вже існуючої або впровадження отриманої ззовні АІС є подібними за змістом науково-технічними проблемами, що відрізняються одна від одної лише змістом низки етапів і тимчасовими параметрами;
· Технологічність: автоматизована технологія означає розробку нової технології або модернізацію існуючої в умовах АІС та не допускає простого використання розробленого програмно-апаратного забезпечення в умовах старих традиційних технологій;
· Безперервність, поетапність та наступність розробки та розвитку: АІС - системи, що постійно розвиваються на своїй основі; кожне нововведення є розвитком основних системних принципів і вже досягнутої якості;
· Адаптивність: складові АІС повинні мати властивості, що забезпечують швидку адаптацію цих складових до змін зовнішнього середовища та нових засобів;
· Модульний принцип побудови програмних та технічних засобів: передбачає, що склад зазначених коштів складається з блоків (“модулів”), які забезпечують можливість їх заміни або зміни з метою вдосконалення функціонування АІС або її адаптації до нових умов;
· Технологічна (у т. ч. - мережева) інтеграція: передбачає єдність для всієї системи технології створення, оновлення, збереження та використання інформаційних ресурсів і, зокрема, - одноразову обробку документів та даних, а також їх багаторазове та багатоцільове використання;
· Повна нормалізація процесів та їх моніторинг: багатоцільове використання інформації АІС вимагає забезпечення високої достовірності даних у системі. Для цього на різних етапах обробки та введення інформаційних документів необхідно використовувати різні форми контролю інформації, вимоги до якого можуть бути сформовані зі складу розв'язуваних завдань та оброблюваних даних. постійний моніторинг необхідний також для отримання якісних і кількісних характеристик функціонування АІС на основі засобів інтелектуальної статистики, що вбудовуються і спеціально розробляються;
· Регламентація: АІС спрямовані на функціонування в промисловому режимі, що забезпечує масову потокову обробку інформаційних документів; ця обробка регламентується стандартами, маршрутними та поопераційними технологіями, нормативами на ресурсні та часові показники, розвиненою службою диспетчеризації.
· Економічна доцільність: створення АІС має передбачати вибір таких проектних рішень (у т. ч. програмних, технічних та організаційно-технологічних), які, за умови досягнення поставлених цілей та завдань, забезпечують мінімізацію витрат фінансових, матеріальних та трудових ресурсів.
· Типізація проектних рішень: розробка та розвиток АІС та їх мереж проводиться з орієнтацією на міжбібліотечне співробітництво, та кооперацію а також відповідно до правил та протоколів міжнародного інформаційного обміну;
· Максимальне використання готових рішень: для скорочення вартості та термінів розробки та впровадження АІС, а також зменшення помилок проектування як системи загалом, так і окремих її складових, рекомендується максимально можливо використовувати готові рішення та засоби. У зазначеному плані під час створення нової системи значний обсяг робіт пов'язані з аналізом альтернативних варіантів можливих рішень, вибором найбільш відповідного об'єкта автоматизації та її адаптацію новим умовам застосування;
· Корпоративність: при проектуванні автоматизованої системи, що входить до складу системи вищого рівня (міста, відомства, республіки тощо), має бути передбачена її апаратна, програмна, лінгвістична та інформаційна сумісність з іншими учасниками системи та/або мережі АІС. Вимоги корпоративності можуть суперечити вимогам чи рішенням, диктованими іншими принципами, наприклад - наступності проектних рішень;
· Орієнтація на перших осіб об'єкта автоматизації: успішне виконання робіт зі створення АІС, її розвитку та експлуатації можливе лише за умови їхньої безумовної підтримки першою особою об'єкта автоматизації (наприклад, директора бібліотеки або інформаційного органу) та закріплення безпосередньої відповідальності за їх виконання наказом щодо організації за керівником на рівні не менше заступника директора
