Етапи типового проектування аїс. Проектування автоматизованої системи складського обліку з використанням CASE-засобу Rational Rose. Методи ведення проектувальних робіт
Етапи розвитку 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 входять такі компоненти.
Проектування АІС
Деталізована розробка проекту системи, що містить повний комплект її організаційної, конструкторської, технологічної та експлуатаційної документації Відповідно до ГОСТ 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 розробки робочої документації на систему та її частини у загальному випадку передбачає уточнення та деталізацію результатів попередніх етапів, створення та випробування дослідного та/або дослідно-промислового зразка об'єкта автоматизації, розробку та відпрацювання програмних продуктів, технологічної та експлуатаційної документації. Результати викладаються в робітникомабо техноробочому проекті. У сучасній практиці проектування автоматизованих інформаційних систем(наприклад, АБІС, АСНТІ, АСУта ін) він є початковим етапом їх впровадження в роботу фірми, організації або служби, що є замовником проекту, або головною у низці інших автоматизованих фірм, організацій, служб тощо.
Цикл розробки (проектування) програмного забезпечення -Сукупність стадій розробки програмного забезпеченняпочинаючи від системного аналізута розробки вихідних вимог до її впровадження.
Принципи проектування АІС- Набір закріплених багаторічним та різнобічним досвідом створення та експлуатації АІС правил чи вимог. Найбільш спільні з них:
· Ідентичність- розробка нової, вдосконалення вже існуючої або впровадження отриманої ззовні АІС є подібними за змістом науково-технічними проблемами, що відрізняються одна від одної лише змістом низки етапів і тимчасовими параметрами;
· Технологічність: автоматизована технологія означає розробку нової технології або модернізацію існуючої в умовах АІС та не допускає простого використання розробленого програмно-апаратного забезпечення в умовах старих традиційних технологій;
· Безперервність, поетапність та наступність розробки та розвитку: АІС - системи, що постійно розвиваються на своїй основі; кожне нововведення є розвитком основних системних принципів і вже досягнутої якості;
· Адаптивність: складові АІС повинні мати властивості, що забезпечують швидку адаптацію цих складових до змін зовнішнього середовища та нових засобів;
· Модульний принцип побудови програмних та технічних засобів: передбачає, що склад зазначених коштів складається з блоків (“модулів”), які забезпечують можливість їх заміни або зміни з метою вдосконалення функціонування АІС або її адаптації до нових умов;
· Технологічна (у т. ч. - мережева) інтеграція: передбачає єдність для всієї системи технології створення, оновлення, збереження та використання інформаційних ресурсів і, зокрема, - одноразову обробку документів та даних, а також їх багаторазове та багатоцільове використання;
· Повна нормалізація процесів та їх моніторинг: багатоцільове використання інформації АІС вимагає забезпечення високої достовірності даних у системі. Для цього на різних етапах обробки та введення інформаційних документів необхідно використовувати різні форми контролю інформації, вимоги до якого можуть бути сформовані зі складу розв'язуваних завдань та оброблюваних даних. постійний моніторинг необхідний також для отримання якісних і кількісних характеристик функціонування АІС на основі засобів інтелектуальної статистики, що вбудовуються і спеціально розробляються;
· Регламентація: АІС спрямовані на функціонування в промисловому режимі, що забезпечує масову потокову обробку інформаційних документів; ця обробка регламентується стандартами, маршрутними та поопераційними технологіями, нормативами на ресурсні та часові показники, розвиненою службою диспетчеризації.
· Економічна доцільність: створення АІС має передбачати вибір таких проектних рішень (у т. ч. програмних, технічних та організаційно-технологічних), які, за умови досягнення поставлених цілей та завдань, забезпечують мінімізацію витрат фінансових, матеріальних та трудових ресурсів.
· Типізація проектних рішень: розробка та розвиток АІС та їх мереж проводиться з орієнтацією на міжбібліотечне співробітництво, та кооперацію а також відповідно до правил та протоколів міжнародного інформаційного обміну;
· Максимальне використання готових рішень: для скорочення вартості та термінів розробки та впровадження АІС, а також зменшення помилок проектування як системи загалом, так і окремих її складових, рекомендується максимально можливо використовувати готові рішення та засоби. У зазначеному плані під час створення нової системи значний обсяг робіт пов'язані з аналізом альтернативних варіантів можливих рішень, вибором найбільш відповідного об'єкта автоматизації та її адаптацію новим умовам застосування;
· Корпоративність: при проектуванні автоматизованої системи, що входить до складу системи вищого рівня (міста, відомства, республіки тощо), має бути передбачена її апаратна, програмна, лінгвістична та інформаційна сумісність з іншими учасниками системи та/або мережі АІС. Вимоги корпоративності можуть суперечити вимогам чи рішенням, диктованими іншими принципами, наприклад - наступності проектних рішень;
· Орієнтація на перших осіб об'єкта автоматизації: успішне виконання робіт зі створення АІС, її розвитку та експлуатації можливе лише за умови їхньої безумовної підтримки першою особою об'єкта автоматизації (наприклад, директора бібліотеки або інформаційного органу) та закріплення безпосередньої відповідальності за їх виконання наказом щодо організації за керівником на рівні не менше заступника директора
НОРМАТИВНО-МЕТОДИЧНЕ ЗАБЕЗПЕЧЕННЯ СТВОРЕННЯ АІС.
Основні поняття проектування АІС
У загальному плані АІС включає: користувача (споживача), інформаційні ресурси, носії інформації, засоби збору, зберігання обробки інформації, засоби передачі інформації.
В основі проектування АІС лежать дві взаємопов'язані складові:
Стандарти проектування;
Методика проектування.
Основні поняття, підходи та визначення проектування АІС регламентуються трьома видами конструкторської та програмної документації:
- єдиною системою конструкторської документації (ЄСКД);
- єдиною системою програмної документації (ЄСПД);
- комплексом керівних документів на АІС.
Склад проектної документації – це комплекс стандартів та керівних документів на АІС ГОСТ 24.104-85, ГОСТ 34.003-90, ГОСТ 34.201-90 включає методичні вказівки на інформаційні технології та автоматизовані системи, а також вимоги до змісту документів.
Мета проектування-виявлення щодо простої внутрішньої структури, званої архітектурою системи.
АІС розробляється як певний проект. Багато особливостей управління проектами і фази розробки проекта (фази життєвого циклу) є загальними, не залежними як від предметної області, а й від характеру проекту. Поняття проект є складним поняттям і для нього важко підібрати однозначне формулювання.
Проект– це обмежена за часом цілеспрямована зміна окремої системи з спочатку чітко визначеними цілями, досягнення яких визначає завершення проекту, а також із встановленими вимогами до термінів, результатів, ризику, рамок витрачання коштів та ресурсів та до організаційної структури.
Для економічнихсистем під проектом ЕІС розумітимемо проектно-конструкторську та технологічну документацію, в якій представлено опис проектних рішень щодо створення та експлуатації ЕІС у конкретному програмно-технічному середовищі.
Під проектуванням ЕІСрозуміється процес перетворення вхідної інформації про об'єкт проектування, про методи проектування та досвід проектування об'єктів аналогічного призначення відповідно до ГОСТу в проект ЕІС. З цього погляду проектування ЕІС зводиться до послідовної формалізації проектних рішень на різних стадіях життєвого циклу ЕІС: планування та аналізу вимог, технічного та робочого проектування, впровадження та експлуатації ЕІС.
Об'єктами проектуванняЕІС є окремі елементи або їх комплекси функціональних та забезпечують частин. Так, функціональними елементами відповідно до традиційної декомпозиції виступають завдання, комплекси завдань та функції управління. У складі частини ЕІС, що забезпечує, об'єктами проектування служать елементи та їх комплекси інформаційного, програмного та технічного забезпечення системи.
Як суб'єктпроектування ЕІС виступають колективи фахівців, які здійснюють проектну діяльність, як правило, у складі спеціалізованої (проектної) організації, та організація-замовник, для якої необхідно розробити ЕІС. Масштаби систем, що розробляються визначають склад і кількість учасників процесу проектування. При великому обсязі та жорстких термінах виконання проектних робіт у розробці системи може брати участь декілька проектних колективів (організацій-розробників). І тут виділяється головна організація, яка координує діяльність всіх організацій-співвиконавців.
Форма участі співвиконавців у розробці проекту системи може бути різною. Найбільш поширеною є форма, при якій кожен співвиконавець виконує проектні роботи від початку до кінця для будь-якої частини системи, що розробляється. Зазвичай це буває функціональна підсистема чи взаємопов'язаний комплекс завдань управління. Рідше зустрічається форма участі співвиконавців, коли окремі співвиконавці виконують роботи на окремих етапах процесу проектування. Можливий варіант, при якому функції замовника та розробника поєднуються, тобто ЕІС проектується власними силами.
Здійснення проектування ЕІС передбачає використання проектувальниками певної технології проектування, що відповідає масштабу та особливостям проекту, що розробляється.
Технологія проектування ЕІС- це сукупність методології та засобів проектування ЕІС, а також методів та засобів організації проектування (управління процесом створення та модернізації проекту ЕІС)
Методологія (концепція + метод)
Інструментальні засоби Організація
проектування проектування
В основі технології проектування лежить технологічний процес, який визначає дії, їх послідовність, склад виконавців, засоби та ресурси, необхідні для виконання цих дій.
Так, технологічний процес проектування ЕІС загалом ділиться на сукупність послідовно-паралельних, пов'язаних і підпорядкованих ланцюжків дій, кожна з яких може мати свій предмет. Дії, що виконуються під час проектування ЕІС, можуть бути визначені як неподільні технологічні операції або підпроцеси технологічних операцій. Усі дії можуть бути власне проектуючими, які формують або модифікують результати проектування, та оціночними діями, які виробляють за встановленими критеріями оцінки результатів проектування.
Таким чином, технологія проектування задається регламентованою послідовністю технологічних операцій, що виконуються в процесі створення проекту на основі того чи іншого методу, в результаті чого стало б ясно, не тільки ЩО має бути зроблено для створення проекту, але і ЯК, КОМУ і в ЯКІЙ ПОСЛІДЖЕННОСТІ це повинно бути зроблено.
Предметом будь-якої технології проектування має бути відображення взаємопов'язаних процесів проектування на всіх стадіях життєвого циклу ЕІС.
До основних вимог, що пред'являються до обраної технології проектування, належать такі:
Створений за допомогою цієї технології проект має відповідати вимогам замовника;
Вибрана технологія має максимально відображати всі етапи життя проекту;
Технологія, що обирається, повинна забезпечувати мінімальні трудові та вартісні витрати на проектування та супровід проекту;
Технологія має бути основою зв'язку між проектуванням та супроводом проекту;
Технологія має сприяти зростанню продуктивності праці проектувальника;
Технологія повинна забезпечувати надійність процесу проектування та експлуатації проекту;
Технологія має сприяти простому веденню проектної документації.
Основу технології проектування ЕІС складає методологія, що визначає сутність, основні відмінні технологічні особливості.
Методологія проектуванняпередбачає наявність певної концепції, принципів проектування, реалізованих набором методів проектування, які, своєю чергою, мають підтримуватися деякими засобами проектування.
Організація проектування передбачає визначення методів взаємодії проектувальників між собою та із замовником у процесі створення проекту ЕІС, які можуть також підтримуватися набором специфічних засобів.
Методи проектування ЕІС можна класифікувати за рівнем використання засобів автоматизації, типових проектних рішень, адаптивності до передбачуваних змін.
Так, за ступенем автоматизаціїметоди проектування поділяються на методи:
ручного проектування, при якому проектування компонентів ЕІС здійснюється без використання спеціальних інструментальних програмних засобів, а програмування - алгоритмічними мовами;
комп'ютерного проектування, що здійснює генерацію або конфігурацію (налаштування) проектних рішень на основі використання спеціальних інструментальних програмних засобів.
За рівнем використання типових проектних рішень розрізняють такі методи проектування:
Оригінального (індивідуального) проектування, коли проектні рішення розробляються «з нуля» відповідно до вимог ЕІС;
Типового проектування, що передбачає конфігурацію ЕІС із готових типових проектних рішень (програмних модулів).
p align="justify"> Оригінальне (індивідуальне) проектування ЕІС характеризується тим, що всі види проектних робіт орієнтовані на створення індивідуальних для кожного об'єкта проектів, які в максимальній мірі відображають всі його особливості.
Типове проектування виконується з урахуванням досвіду, отриманого розробки індивідуальних проектів. Типові проекти як узагальнення досвіду для деяких груп організаційно-економічних систем або видів робіт у кожному конкретному випадку пов'язані з безліччю специфічних особливостей і розрізняються за ступенем охоплення функцій управління, виконуваних робіт і проектної документації.
За ступенем адаптивності проектних рішень методи проектування класифікуються на методи:
реконструкції, коли адаптація проектних рішень виконується шляхом переробки відповідних компонентів (перепрограмування програмних модулів);
Параметризації, коли проектні рішення налаштовуються (перегенеруються) відповідно до змінюваних параметрів;
Реструктуризація моделі, коли змінюється модель проблемної області, на основі якої автоматично перегенеруються проектні рішення.
Поєднання різних ознак класифікації методів проектування обумовлює характер використовуваної технології проектування ЕІС, серед яких виділяються два основні
класу: канонічна та індустріальна технології (табл. 2.1). Індустріальна технологія проектування, у свою чергу, розбивається на два підкласи: автоматизоване (використання CASE-технологій) та типове (параметрично-орієнтоване або модельно-орієнтоване) проектування. Використання індустріальних технологій проектування не виключає використання окремих випадках канонічної технології.
Таблиця 2.1 Характеристики класів технологій проектування
Для конкретних видів технологій проектування властиве застосування певних засобів розробки ЕІС, що підтримують виконання як окремих проектних робіт, етапів, так і їх сукупностей. Тому перед розробниками ЕІС, як правило, стоїть завдання вибору засобів проектування, які за своїми характеристиками найбільше відповідають вимогам конкретного підприємства.
Засоби проектування мають бути:
У своєму класі є інваріантними до об'єкта проектування;
Охоплювати разом всі етапи життєвого циклу ЕІС;
Технічно, програмно та інформаційно сумісними;
Простими в освоєнні та застосуванні;
Економічно доцільними.
Засоби проектування ЕІС можна розділити на два класи: без використання ЕОМ та з використанням ЕОМ.
Засоби проектування без використання ЕОМ застосовуються на всіх стадіях та етапах проектування ЕІС. Як правило, це засоби організаційно-методичного забезпечення операцій проектування та насамперед різні стандарти, що регламентують процес проектування систем. Сюди відносяться єдина система класифікації та кодування інформації, уніфікована система документації, моделі опису та аналізу потоків інформації тощо.
Засоби проектування з використанням ЕОМ можуть застосовуватися як на окремих, так і на всіх стадіях та етапах процесу проектування ЕІС та відповідно підтримують розробку елементів проекту системи, розділів проекту системи, проекту системи в цілому. Усі безліч засобів проектування з використанням ЕОМ ділять на чотири підкласи.
До першого підкласу відносяться операційні засоби, що підтримують проектування операцій обробки інформації. До цього підкласу коштів належать алгоритмічні мови, бібліотеки стандартних підпрограм та класів об'єктів, макрогенератори, генератори програм типових операцій обробки даних тощо, а також засоби розширення функцій операційних систем (утиліти). До цього класу також включаються такі найпростіші інструментальні засоби проектування, як засоби для тестування та налагодження програм, підтримки процесу документування проекту тощо. Особливість останніх програм у тому, що з допомогою підвищується продуктивність праці проектувальників, але з розробляється закінчене проектне рішення.
Таким чином, засоби даного підкласу підтримують окремі операції проектування ЕІС та можуть застосовуватись незалежно один від одного.
До другого підкласу зараховують кошти, що підтримують проектування окремих компонентів проекту ЕІС. До цього підкласу відносяться засоби загальносистемного призначення:
Системи управління базами даних (СУБД);
Методоорієнтовані пакети прикладних програм (вирішення задач дискретного програмування, математичної статистики тощо)
Табличні процесори;
Статистичні ППП;
Оболонки експертних систем;
Графічні редактори;
Текстові редактори;
Інтегровані ППП (інтерактивне середовище із вбудованими діалоговими можливостями, що дозволяє інтегрувати перераховані вище програмні засоби).
Для перерахованих засобів проектування характерно їх використання для розробки технологічних підсистем ЕІС: введення інформації, організації зберігання та доступу до даних, обчислень, аналізу та відображення даних, прийняття рішень.
До третього підкласу належать кошти, що підтримують проектування розділів проекту ЕІС. У цьому підкласі виділяють багатофункціональні засоби проектування.
Функціональні засоби спрямовані на розробку автоматизованих систем, що реалізують функції, комплекси завдань та завдання управління. Різноманітність предметних областей породжує різноманіття засобів даного підкласу, орієнтованих тип організаційної системи (промислова, непромислова сфери), рівень управління (наприклад, підприємство, цех, відділ, ділянку, робоче місце), функцію управління (планування, облік тощо.) .
До функціональних засобів проектування систем обробки інформації належать типові проектні рішення, функціональні пакети прикладних програм, типові проекти.
До четвертого підкласу засобів проектування ЕІС належать кошти, що підтримують розробку проекту на стадіях та етапах процесу проектування. До цього класу належить підклас засобів автоматизації проектування ЕІС (CASE-кошти).
Сучасні CASE-засоби, своєю чергою, класифікуються переважно за двома ознаками:
1) по етапах процесу розробки ЕІС;
2) за ступенем інтегрованості: окремі локальні засоби (tools), набір неінтегрованих засобів, що охоплюють більшість етапів розробки ЕІС (toolkit) та повністю інтегровані засоби, пов'язані загальною базою проектних даних – репозиторієм (workbench).
Проектування АІС є творчим процесом. Кожен проект проходить у своєму розвитку певні стани: від стану, коли проекту ще немає, до стану, коли проекту вже немає. Сукупність ступенів розвитку від виникнення ідеї до завершення проекту прийнято розділяти на стадії (фази, етапи). У визначенні кількості стадій (фаз) та їх змісту є деякі відмінності, проте суть змісту життєвого циклу розробки АІС у різних підходах однакова.
Під проектуваннямслід розуміти процес створення прообразу передбачуваного чи можливого об'єкта.
Сучасна технологія створення АІС є сукупністю ефективних засобів і методів проектування, що дозволяють спростити цей процес, зменшити вартісні витрати, скоротити календарні терміни проектування системи та підвищити якість розробки за рахунок широкого вибору перевірених передових проектних рішень.
До основних засобам проектуванняможна віднести:
Типові проектні рішення (ТПР) та пакети прикладних програм (ППП). ТПР - сукупність алгоритмічних та програмних елементів, що забезпечують реалізацію завдань на ЕОМ за допомогою відповідних технічних засобів;
Системи автоматизованого проектування (САПР), які передбачають використання ЕОМ всіх етапах створення АИС.
Загальні вимоги до засобів проектування:
Повне охоплення всього процесу створення АІС;
Сумісність, тобто. узгодженість як у процесі створення системи, так і у процесі її функціонування;
Універсальність, тобто. можливість застосування тих самих засобів для різних об'єктів;
Доступність в освоєнні та нескладність (простота) у реалізації;
Можливість організації процесу проектування в режимі інтерактивної взаємодії розробника системи, проектувальника та ЕОМ;
Адаптованість та економічна ефективність.
Серед методів проектуваннявиділяють:
Оригінальне проектування;
Типове проектування та його види: елементне, підсистемне, модульне, групове;
Автоматизоване проектування.
p align="justify"> Метод оригінального проектування є традиційним і орієнтований на одне конкретне підприємство. Характерною рисою даного методу є розробка оригінальних методик обстеження об'єкта та створення необхідної документації у вигляді індивідуального проекту. До гідності цього можна віднести відбиток специфічних особливостей об'єкта автоматизації у проекті АИС. До недоліків відносять порівняно високу трудомісткість і великі терміни розробки, низький показник функціональної надійності та адаптованості до умов, що змінюються. Проекти, створені оригінальним методом, піддаються модернізації, проте у чистому вигляді цей метод використовується рідко. Сьогодні за його реалізації використовуються різні засоби проектування і лише окремих частин проекту потрібні оригінальні проектні рішення. Це дещо згладжує його недоліки. Однак цей метод залишається актуальним під час автоматизації складних, неординарних об'єктів.
У сучасних умовах АІС, як правило, не створюються з нуля. Нині економіки практично всіх рівнях управління та всіх економічних об'єктах функціонують системи автоматизованої обробки інформації. Зростаюча потреба у своєчасній, якісній та оперативній інформації викликають необхідність створення АІС на новій технічній та технологічній базі.
Пошук раціональних шляхів проектування йде за такими напрямами:
1. розробка типових проектних рішень, реалізованих у пакетах прикладних програм (ППП) на вирішення економічних завдань із наступною прив'язкою ППП до конкретних умов застосування та функціонування;
2. розробка автоматизованих систем проектування.
Перший із шляхів - можливість використання типових проектних рішень, включених у пакети прикладних програм.
Типове проектування- індустріальний метод створення АІС, який використовує ТПР та ППП. Цей метод характеризується наявністю перевірених, типових організаційно-економічних, технічних, інформаційних, математичних та програмних засобів автоматизації управління. Застосування цього методу дозволяє знизити трудомісткість, знизити вартість і скоротити терміни проектування, підвищити якість проектування. Процес типового проектування полягає у виборі та прив'язці підсистем, що забезпечують, відповідно до вимог конкретної АІС. Типова частина АІС є комплексом інформаційного, програмного та технічного забезпечення. Типовий характер інформаційного забезпечення досягається шляхом суворого дотримання єдності структури інформаційної бази, складу масивів, форм вхідних та вихідних документів. Типовий характер програмного забезпечення досягається використанням ППП і типовий характер технічного забезпечення досягається застосуванням ЕОМ одного або спільних типів.
1. Різновидом методу типового проектування є метод елементного проектування, основу якого становлять ТПР. При розробці проекту використовується готове рішення з невеликими модифікаціями, а не розробляється нове.
2. При використанні модульного методуТПР створюються за модульним принципом, коли кожне проектне рішення розчленовується на окремі складові частини-модулі, які реалізують певну частину ТПР. Це дозволяє створити проект нової автоматизованої системи шляхом поєднання окремих типових модулів.
3. При використанні підсистемного методу проектуваннядля кожної підсистеми створюються проекти рішень та пакети прикладних програм – загальносистемні та функціональні. Виділення підсистем залежить від об'єкта господарсько-виробничого процесу. Для кожної з підсистем розробляється своє автоматизоване проектне рішення та ППП, які можуть бути загальносистемними чи функціональними. До загальносистемних відносяться ППП управління даними, ППП типових процедур обробки даних, методів математичної статистики та дискретного програмування та ін.
Важлива вимога до ППП, - сумісність, т.к. при проектуванні АІС доцільно використати відразу кілька пакетів. Проектування систем із застосуванням ППП фактично зводиться до прив'язки обраних за певними параметрами пакетів до конкретних умов об'єкта автоматизації. Позитивними якостями такого підходу до проектування можна назвати менш трудомісткий процес, скорочення часу проектування порівняно з оригінальним проектуванням, реалізація прогресивних методів обробки даних, спрощення документування проекту (т.к. використовується документація пакетів), підвищення надійності проектованих АІС.
4. Крім того, виділяють метод групового проектування. Його суть полягає у попередньому підборі групи об'єктів, однотипних за характеристиками. Серед них вибирається базовий об'єкт, для якого і розробляється проект, причому можуть використовуватись різні методи та способи проектування. Головним у своїй є забезпечення високої адаптивності проекту. Основна сфера застосування цього методу – непромислові об'єкти (наприклад, склади).
Найбільш ефективно автоматизації піддаються такі види діяльності:
1. бухгалтерський облік, включаючи управлінський та фінансовий. Найбільше ППП створено для бухгалтерського обліку. Серед них "1C: бухгалтерія", "Турбо-Бухгалтер", "Інфо-Бухгалтер", "Вітрило", "ABACUS", "Бембі+" та ін;
2. довідкове та інформаційне обслуговування економічної діяльності. Представлено такими ППП: "ГАРАНТ" (податки, бухоблік, аудит, підприємництво, банківська справа, валютне регулювання, митний контроль); "КОНСУЛБТАНТ+" (податки, бухоблік, аудит, підприємництво, банківська справа, валютне регулювання, митний контроль).
3. економічна та фінансова діяльність. Представлена такими ППП:
a) «Економічний аналіз та прогноз діяльності фірми, організації» (фірма «ІНЕК»), що реалізує функції: економічний аналіз діяльності фірми, підприємства; складання бізнес-планів; техніко-економічне обґрунтування повернення кредитів; аналіз та відбір варіантів діяльності; прогноз балансу, потоків коштів та готової продукції.
b) Розрахований на багато користувачів мережевий комплекс повної автоматизації корпорації «Галактика» (АТ «Новий атлант»), який включає планування, оперативне управління, облік і контроль, аналіз, крім того, дозволяє в рамках СППР забезпечувати вирішення завдань бізнес-планування з використанням ППП Project- Експерт.
4. організація праці керівника;
5. автоматизація документообігу;
6. навчання.
Останнім часом підприємства та фірми воліють купувати готові пакети та технології, а якщо необхідно, додавати до них своє програмне забезпечення, оскільки розробка власних АІС пов'язана з високими витратами та ризиком. Як правило, розробляється та пропонується базова система, яка адаптується відповідно до побажань індивідуальних клієнтів. При цьому користувачам надаються консультації, які допомагають мінімізувати терміни впровадження систем та технологій, афективніше їх використовувати, підвищити кваліфікацію персоналу.
Автоматизовані системи проектування -другий, що швидко розвивається шлях ведення проектувальних робіт.
Серед автоматизованих методів проектування особливу увагу займають методи модельного проектування. Створення та використання САПР забезпечує досить високий рівень функціональної надійності, комплексне охоплення всіх технологічних процесів, зниження трудомісткості проектних робіт із максимальним урахуванням інтересів об'єкта автоматизації. Однак цей метод досить дорогий і потребує висококваліфікованих розробників. Ключова вимога до САПР - можливість побудови та підтримки в системі проектування в адекватному стані деякої глобальної економічної інформаційної моделі об'єкта автоматизації. Модель – це відображення інформаційних компонентів об'єкта автоматизації та відносин між ними, задане у явному вигляді. Основна мета побудови моделі - створення відповідного цієї моделі проекту АІС, що враховує та активно використовує всі характеристики об'єкта. Така модель повинна містити у формалізованому вигляді опис сукупностей інформаційних компонентів та відносини між ними, включаючи інформаційні зв'язки та алгоритмічну взаємодію. За допомогою модельного методу проектування застосовується системний підхід, що обумовлює використання ЕОМ не тільки на всіх стадіях створення системи, а й у процесі аналізу результатів її промислової експлуатації. Розвиток та застосування САПР зумовило перехід до створення індивідуальних проектів, але на значно вищому рівні порівняно з оригінальним методом проектування.
В галузі автоматизації проектування ІС та ІТ за останнє десятиліття сформувався новий напрямок - CASE технологія автоматизованої розробки ПЗ(CASE - Computer-Aided Software/System Engineering). Зростаюча складність інформаційних систем, вимоги, що підвищуються до них, призвели до необхідності індустріалізації технологій їх створення.
CASE-технологіяє сукупність методів аналізу, проектування, розробки та супроводу ІВ, підтриману комплексом взаємозалежних засобів автоматизації. CASE - це інструментарій для системних аналітиків, розробників та програмістів, що дозволяє автоматизувати процес проектування та розробки ІВ. CASE-системи використовуються як потужний інструмент вирішення дослідницьких та проектних завдань, таких, як структурний аналіз предметної галузі, реалізація проектів засобами мов програмування останнього покоління, випуск проектної документації, тестування реалізації проектів, планування та контроль розробок, моделювання ділових додатків з метою вирішення задач оперативного та стратегічного планування та управління ресурсами тощо.
Основна мета CASE полягає у максимальній автоматизації процесів розробки та функціонування систем.
Під час використання CASE-технологій змінюється технологія ведення робіт всіх етапах життєвого циклу автоматизованих систем. У CASE-системах проектування, засноване на візуальних наочних методах розробки, при цьому для опису моделі проектованої ІС використовуються графи, діаграми, таблиці, схеми і текстові пояснення до них. Такі методології забезпечують строгий і наочний опис проектованої системи, який починається з її загального огляду і потім деталізується, набуваючи ієрархічної структури з дедалі більшим числом рівнів.
Автоматизація програмування заснована на автоматичній генерації програмних кодів, які містять описи даних, основну логіку їх обробки, схеми баз даних, файли опису інтерфейсів та ін. Крім того, CASE-технологія генерує необхідну документацію щодо проекту, готову до використання.
З використанням CASE-технології забезпечується підтримка єдиної бази проекту, тобто. вся інформація про розроблювану АІС автоматично поміщається в єдину базу даних проекту. Цим підтримується узгодженість, несуперечність, повнота та мінімальна надмірність проектних даних.
CASE-технологія забезпечує командну роботу груп розробників, т.к. Різним групам фахівців надається адекватний інструментарій, а також можливість узгодженого та коректного внесення змін до проекту різними фахівцями у реальному часі.
CASE-технології успішно використовуються для побудови практично всіх типів АІС. CASE також застосовується до створення моделей систем, які допомагають комерційним структурам вирішувати завдання стратегічного планування, управління фінансами, визначення політики фірм, навчання персоналу та інших.
CASE мають такі основні переваги:
Поліпшують якість створюваних ІВ (ІТ) за рахунок засобів автоматичного контролю (насамперед контролю проекту);
Дозволяють за короткий час створювати прототип майбутньої ІС (ІТ), що дозволяє швидко на ранніх етапах оцінити очікуваний результат;
Прискорюють процес проектування та розробки системи;
Звільняють розробника від рутинної роботи, дозволяючи йому цілком зосередитись на творчій частині проектування;
Підтримують розвиток та супровід вже функціонуючої ІВ.
На даний момент утворилася потужна CASE-індустрія, що об'єднала сотні фірм та компаній різної орієнтації. Серед них виділяються:
Компанії-розробники засобів аналізу та проектування ІС та ІТ
Фірми-розробники спеціальних засобів з орієнтацією на вузькі предметні області чи окремі етапи життєвого циклу ІВ;
Навчальні фірми, які організовують семінари та курси підготовки спеціалістів;
Консалтингові фірми, які надають практичну допомогу під час використання CASE-пакетів для розробки конкретних ІС;
Фірми, що спеціалізуються на випуску періодичних журналів та бюлетенів за CASE-технологіями.
Уряд Білгородської області Автоматизована інформаційна система «Проектне управління» АІС «Проектне управління» Нормативна база Рішення створено відповідно до встановлених у Російській Федерації стандартів, закріплених у: 1. ГОСТ Р 54869-2011 «Проектний менеджмент. Вимоги до управління проектом». 2. ГОСТ Р 54870-2011 «Проектний менеджмент. Вимоги до управління портфелем проектів». 3. ГОСТ Р 54871-2011 «Проектний менеджмент. Вимоги до управління програмою». Під час створення та налаштування системи враховано положення Постанови уряду Білгородської області від 31.05.2010 року N 202-пп "Про затвердження Положення про управління проектами в органах виконавчої влади та державних органах Білгородської області". 2 АІС «Проектне управління» Технологія розробки Мережа Інтернет Локальна мережа Рішення розроблено на базі платформи Motiware Melody One. Завдяки web-інтерфейсу системи всі учасники проектної діяльності отримують доступ до необхідних даних у будь-який час та з будь-якої точки земної кулі. Для доступу до системи достатньо підключення до Інтернету та встановленого браузера. Серверна частина 3 АІС «Проектне управління» Цілі Цілі створення та впровадження системи: . Підвищити ефективність реалізації проектів біля суб'єкта РФ з допомогою забезпечення команд проектів актуальною, повної і достовірної информацией. . Поліпшити взаємодію органів державної влади органів місцевого самоврядування з громадянами та бізнесом щодо ініціації та реалізації проектів. . Забезпечити всіх учасників проектної діяльності зручними засобами та інструментами управління проектом. . Спростити моніторинг реалізації проектів шляхом скорочення тимчасових витрат на підготовку та аналіз звітних даних. 4 АІС «Проектне управління» Функції системи Система дозволяє організувати повний цикл процесу управління проектом та/або портфелем проектів. Проект у системі послідовно проходить кілька стадій – від реєстрації ініціативної заявки до переміщення завершеного проекту до архіву. . Розгляд ініціативних заявок. Ініціація. Планування. Реалізація та Контроль. Завершення 5 АІС «Проектне управління» Робота з ініціативними заявками АІС «Проектне управління» Проекти Ініціативні заявки Портал взаємодії з громадянами та бізнесом Архів (відхилені заявки) 6 АІС «Проектне управління» Етап ініціації проекту 2. Ініціація проекту. Автоматичне надання проекту унікального реєстраційного номера. . Формування картки проекту на основі даних, зазначених у ініціативній заявці. 7 АІС "Проектне управління" Етап ініціації проекту 3. Формування паспорта проекту. Можливість поетапного редагування картки (полів) паспорту проекту. . Врахування бюджету проекту в розрізі джерел фінансування. . Формування команди проекту із зазначенням ролей учасників. . Введення та редагування характеристик проекту. . Генерація за встановленою формою та вивантаження із системи паспорта проекту у форматі *.docx. 8 АІС «Проектне управління» Етап планування проекту 4. Створення плану управління проектом. Подання плану управління проектів за допомогою діаграми Ганта. . Планування робіт за проектом із зазначенням дат початку та закінчення, відповідальних виконавців та вимог до результатів роботи. . Створення ієрархічного переліку робіт із проекту. . Генерація за встановленою формою та вивантаження із системи плану управління проектом у форматі *.docx. 9 АІС «Проектне управління» Етап реалізації та контролю 5. Організація процесу внесення змін до паспорту та плану управління проектом. Створення та редагування нових версій паспорта та/або плану управління проектом. . Формування за встановленим зразком та вивантаження із системи відомості змін у форматі *.docx. . Погодження відомості змін із групою моніторингу та контролю. 10 АІС «Проектне управління» Етап реалізації та контролю 6. Облік виконання робіт за проектом. Можливість прикріплення виконавцями файлів-звітів щодо виконання робіт. . Облік фактичних дат виконання робіт та відхилень від планових термінів. . Моніторинг наступних та прострочених контрольних подій. 11 АІС «Проектне управління» Етап завершення 7. Формування підсумкового звіту. Розрахунок оцінки успішності проекту. . Формування за встановленим зразком та вивантаження із системи підсумкового звіту у форматі *.docx. 12 АІС «Проектне управління» Архів проектів 8. Ведення архіву проектів. Створення єдиного сховища даних про всі проекти, будь-коли ініційованих біля суб'єкта РФ. . Доступ до повної інформації про завершені та переміщені в архів проекти. . Захист від внесення змін до завершених проектів. 13 АІС «Проектне управління» Звіти та аналітика Одним із завдань системи є забезпечення учасників проектної діяльності звітною інформацією про проекти у зручній та наочній формі. АІС дозволяє автоматично сформувати документацію проекту: . Паспорт проекту. . План керування проектом. . Підсумковий звіт. 14 АІС «Проектне управління» Відомості про впровадження Більше АІС «Проектне управління» успішно застосовується для здійснення проектної діяльності органами влади Білгородської області. 4200 проектів 5000 користувачів АІС «Проектне управління» 60000 робіт (контрольних подій) 19 муніципальних районів 3 міських округи 15 Уряд Білгородської області Дякую за увагу! 16