69174

Організаційно-методичні основи створення і функціонування інформаційних систем управління фінансами

Лекция

Информатика, кибернетика и программирование

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

Украинкский

2014-10-01

157.5 KB

3 чел.

Тема 5. Організаційно-методичні основи створення і функціонування інформаційних систем управління фінансами.

Методологічні оснобливості фінансової діяльності та їх вплив на організацію системи автоматизованого оброблення інформації.

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

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

На всіх рівнях фінансової діяльності можна виділити окремі особливості управління, а відповідно і особливості документообігу та методології.

Наприклад, в діяльності на фондовому ринку слід виділити державний сектор управління фондовим ринком та професійну діяльність на фондовому ринку.

До рівня державного управління слід віднести Державну коміссію з цінних паперів та фондового ринку та її теріторіальні відділення. Методологію роботи комісії визначають нормативні акти Верховної Ради України та КМУ. Державна комісія видає, в свою чергу нормативні акти, які є обов’язковими для всіх професійних суб’єктів фондового ринку.

Специфіка діяльності на фондовому ринку вимагає постійної корекції законодавства та методології роботи. Тому  вимоги до роботи повинні вчасно доводитись до всіх суб’єктів ринку. Це вимагає від комісії підтримування постійного зв’язку з суб’єктами ринку та зі своїми теріторіальними відділеннями.

Також необхідно підтримувати інформаційний сайт в інтернеті та видавати відповідні збірки нормативних актів в пресі.

В свою чергу суб’єкти ринку повинні постійно звітувати перед комісією по результатах своєї діяльності. Це вимагає створення уніфікованих форм звітності, яка для зручності надається в електронному та друкованому вигляді.

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

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

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

Організаційні та  функціональні  особливості  фінансових установ і їх вплив на структуру та  організацію  інформаційної бази.

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

В Україні функціонує дворівнева банківська система. На першому рівні перебуває Національний банк України (НБУ), а на другому — комерційні банки (КБ) різних форм власності, спеціалізації та сфери діяльності.

Організаційно НБУ не є унітарною установою, а також має ієрархічну структуру: на першому рівні — Центральне управління НБУ, а на другому — територіальні (здебільшого обласні) управління цього банку (ТУ НБУ).

Комерційні банки мають різну структуру, яка істотно впливає на структуру їх АІС і технологію обробки даних. Усі КБ за структурою можна поділити на такі типи.

Перший тип — так звані «унітарні» КБ, які не мають філій або відділень і територіально та організаційно розміщені в одному місці (в одному приміщенні). Усі КБ у момент свого відкриття є, як правило, «унітарними» і мають однорівневу структуру.

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

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

Задачі, проблеми управління, збору, передавання та зберігання даних, а отже, і структура банківської АІС для різних типів структур істотно різні.

У разі КБ зі структурою першого типу вся інформація про роботу самого банку та його клієнтів зосереджена практично в одному місці. Відповідна БАІС являє собою сукупність кількох інформаційно взаємозв’язаних функціональних і забезпечуючих АРМ, на яких базується автоматизація головних видів діяльності банку: внутрішньобанківських розрахункових, кредитних і депозитних операцій, бухгалтерської та оперативної звітності, операцій із міжбанківських розрахунків і т.ін.

До множини таких АРМ належать АРМ-3 (його називають ще АРМ НБУ) з виконання міжбанківських розрахунків зазначеного банку з використанням системи електронних платежів (СЕП) НБУ, а також комплекс програмних і технічних засобів (ПТК) із забезпечення роботи електронної пошти (ЕП) НБУ (обслуговуючий АРМ), на базі якої і працює СЕП.

Автоматизовані робочі місця можуть бути об’єднані в локальну обчислювальну мережу (ЛОМ) або працювати автономно, але неодмінно мають бути інформаційно узгоджені між собою. Отже, технічний комплекс (ТК) таких систем може являти собою або ПК, об’єднані в ЛОМ, або автономні персональні ЕОМ, інформаційний зв’язок між якими здійснюється з допомогою машинних носіїв.

У крайньому разі вся БАІС може складатися лише з одного ПК, де містяться АРМ-3 і ПТК ЕП НБУ. У першихї версіях АРМ-3 передбачалася можливість ручного вводу даних для міжбанківських розрахунків, тобто забезпечувалась можливість існування саме такої системи.

Сукупність функціональних АРМ (ФАРМ) внутрішньобанківських розрахунків у БАІС об’єднують в єдину систему — програмно-технічний комплекс під назвою «Операційний день банку» (ОДБ), котрий забезпечує автоматизоване виконання внутрішньобанківських розрахункових і бухгалтерських операцій протягом одного операційного дня банку.

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

Загальну схему БАІС банківської автономної установи унаочнює рис. 2.2.

    Рис. 2.2. Загальна структура АІС комерційного банку:

ЕПД — електронні платіжні документи; ППД — платіжні документи на

паперових носіях

Згідно з чинним положенням платіжні документи в СЕП можуть надходити лише через АРМ-3. У нових версіях АРМ-3 вилучено функцію ручного вводу таких документів, тому останні можуть надходити до АРМ-3 лише з ОДБ БАІС. У складі ПТК ОДБ рекомендується виокремлювати спеціальне АРМ бухгалтера електронних платежів (АРМ БЕП), яке дає змогу відповідному працівникові банку протягом банківського дня проглядати й роздруковувати файли обміну між АРМ-3 і ОДБ та перевіряти електронні підписи на документах, які надходять із СЕП, або накладати електронний підпис на підготовлені до відправлення до СЕП документи, а також створювати файл, що являє собою квитанцію-підтвердження про отримання файлів від СЕП.

«Багатокористувацький» програмний комплекс «Клієнт-банк» автоматизує процеси формування, приймання, відправлення й передавання фінансових та інших повідомлень між клієнтами й банком. Зв’язок установлюється, як правило, по телефонних каналах через систему електронної пошти. Така система надає клієнтові низку переваг порівняно з традиційними методами передавання платіжних повідомлень (пошта, телеграф, телекс), оскільки під час роботи з цією системою всі операції з оплати виконуються в офісі клієнта.

Застосування банківських автоматів (банкоматів) передбачає використання магнітних пластикових карток (МПК), за допомогою яких через автомат можна виконувати деякі банківські операції, такі як видача готівки, одержання інформації про стан рахунку і т.ін.

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

У разі багаторівневої структури КБ зі створенням АІС виникають додаткові проблеми. Насамперед це проблема передавання даних на великі відстані й забезпечення при цьому їх безпеки, достовірності й конфіденційності; проблеми оцінювання фінансового стану банку як сукупності елементів; управління територіально-регіональним розподілом фінансів, формування статистичної та оперативної звітності по банку в цілому і т.ін.

Оскільки робота з клієнтами ведеться на всіх рівнях, то можливі різні системи її організації, а отже, і застосування різних моделей і методів розв’язування одних і тих самих задач у різних елементах. Наприклад, залежно від суми або терміну кредиту можливі різні способи організації кредитування клієнтів: через центральне чи регіональне управління КБ або через філії.

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

У разі складної структури КБ зв’язок між його елементами, а відповідно і їх АІС може реалізуватися або у процесі використання послуг ЕП НБУ та інших систем електронного передавання даних, або створенням власних систем передавання даних.

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

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

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

Водночас кожний КБ є ризиковим підприємством, котре має зводити цей ризик до мінімуму, дбаючи про те, щоб він не впливав на прибуток його клієнтів. Звідси випливають завдання оцінювання платоспроможності позичальників та розміру ризику; визначення сумарних обсягів повернення грошових коштів за виданими й узятими позиками, за депозитними вкладами, за вимогами клієнтів; оперативного обліку наявності грошових коштів та можливості їх використання протягом певного періоду і т.ін. Взагалі постають проблеми управління ресурсами банку в часі, оцінювання й аналізу ситуації типу: «що буде, коли?» та «що потрібно, аби?».

Управляти ресурсами банку не менш складно, ніж виробництвом на підприємстві. Адже існують численні джерела надходження й використання коштів, причому потужність цих джерел різна та змінювана в часі, здебільшого стохастично. Відповідна математична задача не має прямого аналітичного розв’язання, тому доводиться застосовувати методи імітаційного моделювання, експертні системи тощо.

Загалом БАIС (ЕБС) забезпечують:

автоматизацiю внутрiшньобанкiвської дiяльностi, i насамперед операцiй з обробки платiжних та iнших документiв у тих пiдроздiлах банкiвської установи, якi працюють безпосередньо з клiєнтами;

автоматизацiю виконання мiжбанкiвських розрахункiв та iнших зовнiшньобанкiвських операцiй;

автоматизацiю фiнансових операцiй у рамках мiжнародного банкiвського бiзнесу.

Зрозумiло, що автоматизувати зазначені процеси слід з огляду на їх взаємодоповняльність і взаємозв’язок, а також на те, що автоматизацiя кожного із цих процесів доволі специфiчна i становить складну проблему з високим рівнем автономності.

Принципи створення та функціонування інформаційних систем.  

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

Так, згідно з нормативними документами під час створення автоматизованих систем (АС) необхiдно керуватися принципами системностi, розвитку, сумiсностi, стандартизацiї та ефективностi.

1. Принцип системностi. Необхiдно встановлювати такі зв’язки мiж структурними елементами системи, якi забезпечують її сумiснiсть та взаємодiю з iншими системами. Отже, усi зв’язки, елементи, функцiї та проблеми управлiння й дiяльностi мають розглядатися як єдине цiле.

2. Принцип розвитку (вiдкритостi). Автоматизована система має створюватися з урахуванням можливостi поповнення й оновлення її функцiй та складу без порушення функцiонування АС.

3. Принцип сумiсностi. Під час створення системи мають бути реалiзованi iнформацiйнi iнтерфейси, завдяки яким ця система зможе взаємодiяти з iншими системами згідно зі встановленими правилами. Так, будь-яка АIС на рiвнi КБ має iнформацiйно взаємодiяти із системами установ НБУ, а АIС обласної податкової адмiнiстрацiї — з АIС Головної податкової адмiнiстрацiї України.

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

Зауважимо, що стандартизація віповідає і запитам користувача, «консерватизм» якого ураховують і вiдомі розробники програмного забезпечення. Наприклад, до пакета ЕХСЕL включенi й функцiї вiдомого пакета LOTUS-1-2-3.

5. Принцип ефективностi. Досягнення рацiонального спiввiдношення мiж витратами на створення АС i цiльовими ефектами, включаючи кiнцевi результати, отримані вiд автоматизацiї, які не завжди i не обов’язково мають набирати грошової форми, це може бути час (вiрнiше, його економiя), певні зручностi, новi функцiї, iмiдж i т.ін.

Окрiм розглядуваних основних можна додатково визначити ще деякі принципи створення й функцiонування АIС ФКУ.

1. Принцип нових задач. Визначаючи перелiк задач, які пiдлягають включенню в АIС, слід ураховувати основні технологічні операції обробки документів та завдання щодо забезпечення повноти, вчасності й оптимальності прийняття рiшень,  які ранiше не виконувались через обмежені можливості обробки iнформацiї.

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

3. Принцип єдиної iнформацiйної бази. Ідеться про застосування єдної системи класифiкацiї та єдиної системи кодування, одних і тих самих структурних одиниць економiчної iнформацiї.

При створеннi БАIС, крiм того, виникають додатковi вимоги, тобто доводиться спиратися на деякі додаткові принципи.

А. Принцип безпеки даних.

А.1. Iнформацiя має бути захищена як пiд час її безпосередньої обробки та зберiгання в системi, так i в моменти обмiну мiж комп’ютерами.

А.2. Має бути виключена можливiсть несанкцiонованого доступу до даних у системi.

А.3. Усi операцiї в системi мають реєструватися.

А.4. Будь-яке порушення системи безпеки має бути виявлене.

Б. Принцип надiйностi системи. У БАIС мають бути однаково високонадiйними як апаратне, так i програмне забезпечення. Iнформацiя для клiєнта має бути точною, доступною i надаватися йому без затримки. У разі виходу системи з ладу данi мають бути вiдновленi, а пошкодження усунене.

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

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

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

Д. Важливою є також i вимога щодо зручності, простоти та ефективностi експлуатацiї системи. Банки насамперед обирають системи, якi легко встановлювати, використовувати й обслуговувати.

Зауважимо, що розглянуті вимоги вельми загальні, а отже, кожний банк хоча й зацікавлений додержувати їх, проте ступінь їх зацікавленості різний, залежний від обставин. Завжди при створеннi системи iснують iндивiдуальнi вимоги до неї i кращою iз пропонованих АIС буде та, яка більще пiдходить до цих вимог.

Організація робіт по  створенню АЕІС. Основні стадії і етапи створення інформаційних систем. Призначення, структура та зміст документів «Опис постановки задачі», «Алгоритм розв’язання задачі”. Форми представлення алгоритмів.

Стадiї та етапи розробки АIС

Процес створення АIС (рис. 2.5) являє собою сукупнiсть упорядкованих у часi, взаємозв’язаних i об’єднаних у стадiї та етапи робiт, виконання яких необхiдне i достатнє для створення системи, що вiдповiдає заданим вимогам.

Рис. 2.5. Послідовність побудови АІС

Розглянемо докладніше відповідні стадії та етапи.

1. Стадiя формування вимог до АIС.

Етапи: обстеження об’єкта i обгрунтування необхiдностi побудови системи; формування вимог користувача до неї; оформлення звiту i заявки на її розробку (тактико-технiчне завдання).

2. Стадiя розробки концепцiї АIС.

Етапи: вивчення об’єкта; виконання необхiдних науково-дослідних робіт (НДР); розробка варiантiв концепцiї АIС i вибiр того з них, який задовольняє вимоги користувача; оформлення звiту про виконану роботу.

3. Стадiя розробки технiчного завдання.

Етапи: розробка технiчного завдання та його затвердження.

4. Стадiя ескiзного проектування.

Етапи: розробка попереднiх проектних вирiшень стосовно системи та окремих її частин.

5. Стадiя технiчного проектування.

Етапи: розробка проектних вирiшень стосовно системи та її частин; розробка документацiї АIС та її частин; розробка й оформлення документацiї на поставляння або розробку виробiв для комплектування системи; розробка завдань на проектування в сумiжних частинах проекту автоматизацiї.

6. Стадiя робочого проектування.

Етапи: розробка робочої документацiї на систему та її частини; створення  або адаптацiя програм.

7. Стадiя впровадження системи в дiю.

Етапи: пiдготовка об’єкта автоматизацiї до впровадження АIС; пiдготовка персоналу; комплектування АIС (програмними i технiчними засобами, iнформацiйними виробами); будiвельно-монтажнi роботи; пусконалагоджувальнi роботи; попереднi випробування; дослiдна експлуатацiя; приймальні випробування.

8. Стадiя супроводження.

Етапи: виконання робiт згідно з гарантiйними зобов’язаннями та пiслягарантiйне обслуговування.

Залежно вiд складностi автоматизовуваних процесiв i завдань не всi стадiї є однаково обов’язковими. Iз перших трьох стадiй обов’язковою є третя, результатом виконання якої має бути затверджений документ «Технiчне завдання» (ТЗ). Розробляє його, як правило, замовник. ТЗ поділяється на 9 роздiлiв i визначає вимоги до автоматизованих функцiй i завдань та до видiв забезпечення; регламентує органiзацiю розробки, розміри витрат, термiни виконання стадiй i етапiв робiт тощо. ТЗ визначає також черговiсть розробки й упровадження системи (пусковi комплекси, черги i т.iн.).

Схарактеризуємо стисло головні розділи ТЗ.

Розділ 1. Загальнi вiдомостi. Подаються повна та умовна назви роботи, замовника й об’єкта.

Розділ 2. Призначення та мета роботи. З’ясовуються призначення та мета автоматизацiї, наприклад скорочення термiнiв обробки даних, мінімізації витрат.

Роздiл 3. Характеристика предметної областi. Наводяться вiдомостi про об’єкт управлiння та процеси, які потрiбно автоматизувати, про умови виконання завдань.

Розділ 4. Основні вимоги. Цей розділ найважливіший у ТЗ. Формулюються вимоги до шуканих вирішень і системи в цiлому, до взаємозв’язкiв i взаємодiї різних комплексiв завдань одного з одним та з іншими системами; до рiвня автоматизацiї, технiчного, програмного, iнформацiйного та iнших видiв забезпечення.

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

Зауважимо, що обсяг ТЗ може змінюватися в доволі широких межах. Наприклад, у однiєї i тiєї самої фiрми-розробника ТЗ на «Багатокористувацький програмний комплекс «Клієнт-банк» становить 5 сторiнок, а на систему ОДБ — понад 40.

Результат виконання стадiї технiчного проектування являє собою документ «Технiчний проект» (ТП), який складається iз загально-системної документацiї та документiв щодо функціональної та забезпечувальної частин.

Документацiя стосовно ФЧ мiстить проектнi вирiшення з автоматизацiї функцiй та постановки завдань чи їх комплексiв, а документацiя стосовно ЗЧ — проектнi вирiшення з iнформацiйного, програмного, технiчного та iнших видів забезпечення.

На стадiї робочого проектування (РП) до найбiльш трудомiстких операцій належать розробка та відлагодження робочих програм.

Зауважимо, що в разі об’єднання стадiй технiчного та робочого проектування обсяг документацiї зменшується (приблизно на 20%).

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

Розробка автоматизованого розв’язування задач за умов функцiонування АIС

Органiзацiя розробки автоматизованого розв’язування окремих задач або їх комплексiв в тому разі, коли на об’єктi функціонує АIС, має свою специфiку, оскільки тоді, як правило, технiчний комплекс i базове програмне забезпечення (ПЗ) уже заданi. За таких умов розглядуваний процес розробки автоматизованого розв’язування задач поділяють на вісім етапів.

1. Формулювання вимог — аналог ТЗ.

2. Постановка задачi — елемент ТП.

3. Побудова алгоритму розв’язування задачi — елемент ТП.

4. Розробка контрольного прикладу (КП) — елемент ТП.

5. Розробка машинної блок-схеми та програм — елемент РП.

6. Вiдлагодження розроблених програм на контрольному прикладi — елемент РП.

7. Вiдлагодження розроблених програм на реальних даних (пробна експлуатація) — стадія 7-ма.

8. Прийняття в промислову експлуатацiю — стадiя 8-ма.

Зауважимо, що етапи 6-й і 7-й можна об’єднати, якщо для контрольного прикладу взяти реальнi данi і не розробляти машинну блок-схему (її розробляють, як правило, лише для складних алгоритмiв).

Етапи є елементами вiдповiдних стадiй розробки, i їх сутнiсть та змiст залежать вiд використовуваних технiчних i програмних засобiв. Цю залежнiсть у якiсному планi ілюструє табл. 2.1.

                                                                                             Таблиця 2.1

Номер i назва етапу

Вiдповiдна стадiя

Ступiнь залежностi етапу

ПЗ

ТЗ

1. Формулюваня вимог

ТЗ

2. Постановка задачi

ТП

Слабка

Слабка

3. Побудова алгоритму

ТП

Середня

Те саме

4. Розробка КП

ТП

Сильна

»

5. Розробка машинної блок-схеми та програм

РП

Те саме

»

6. Вiдлагодження

РП

»

Сильна

7. Пробна експлуатацiя

7-ма

»

Те саме

8. Прийняття в експлуатацiю

8-ма

»

»

Примітка: 1. У ТЗ висуваються вимоги до ТК та ПЗ, тому воно практично не задежить вiд них.

2. Вважаємо, що «сильний» ступiнь залежностi означає: роботу на відповідному етапі не можна виконати без урахування специфiки конкретного ТК чи ПЗ; «середній» — роботу виконати можна, урахувавши істотні властивостi даного типу ТК або ПЗ; «слабкий» — роботу можна виконати без урахування особливостей ТК чи ПЗ.

Оскільки технiко-економiчний зміст задачi не залежить від форми подання вхiдної та вихiдної iнформацiї, то постановка задачi значною мiрою iнварiантна щодо ТК та ПЗ.

Розглянемо далi змiст i вимоги до документа «Опис постановки задачi (комплексу задач)» як важливого i визначального елемента ТП.

Опис постановки задачi та її розробка

Опис постановки задачi (ПОЗ) (комплексу задач) є елементом технiчного проекту.

У разі машинної та автоматизованої обробки даних обсяг поняття «задача» охоплює:

1) процес машинної обробки даних, тобто безпосереднє розв’язування задачi машинними засобами;

2) метод розв’язування;

3) процедури пiдготовки даних до обробки;

4) використання даних, зокрема й для прийняття управлiнських рiшень.

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

Склад i змiст постановки задачi (комплексу задач) залежить вiд специфiки останньої та умов розв’язування. Загалом ПОЗ складається з таких основних роздiлів: 1) характеристика задачi; 2) вихiдна iнформацiя; 3) вхiдна iнформацiя.

Окрiм того, виконується опис алгоритму автоматизованого розв’язування задачі, який може бути включений до ПОЗ як роздiл 4-й або викладений окремо.

Іноді ПОЗ містить i роздiл «Розрахунок економiчної ефективностi», де обгрунтовується ефективність розв’язування задачi за допомогою ЕОМ.

Схарактеризуємо стисло кожний розділ ПОЗ.

Роздiл 1-й мiстить інформацію про призначення задачі (комплексу задач); перелiк об’єктiв, у процесі управлiння якими розв’язується задача; перiодичнiсть i тривалiсть розв’язування; умови, за яких припиняється розв’язування автоматизованим способом; iнформацiйнi та технологiчнi зв’язки з iншими задачами (комплексами) АIС; посади осiб і (або) назви пiдроздiлiв, якi визначають умови та часовi характеристики конкретного розв’язання (рішення) та подiл обов’язкiв мiж персоналом i технiчними засобами в рiзних ситуацiях розв’язування задачі (комплексу задач).

Роздiл 2-й (вихiдна iнформацiя) складається з перелiку та опису вихiдних повiдомлень (тобто форм вiдомостей, вiдеограм, вiдеокадрiв тощо) та перелiку й опису структурних одиниць iнформацiї вихiдних повiдомлень.

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

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

Роздiл 3-й (вхiдна iнформацiя) мiстить перелiк i опис вхiдних повiдомлень та перелiк i опис структурних одиниць iнформацiї вхiдних повiдомлень, якi мають самостiйне змiстове навантаження.

Пiд вхiдною iнформацiєю розумiють данi, якi є необхiдними для розв’язування задачi й надходять у виглядi документiв i повiдомлень рiзної форми. Опис вхiдних повiдомлень також задається у виглядi таблицi i мiстить найменування повiдомлення, його iдентифiкатор, форму подання, строки й частоту надходження.

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

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

Пiсля встановлення вихiдних даних визначають необхiднi вхiднi дані та розпочинають розробку алгоритму розв’язування задачi — послідовності правил отримання вихiдних даних на підставі вхiдних. Iз розробленого алгоритму визначається також iнформацiя для зберiгання та нагромадження. На закiнчення відпрацьовується система внесення змiн до iнформацiї задачi.

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

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

ПОЗ істотно спрощується, коли для її розв’язання використовуються типовi проектнi рiшення (ТПР) та пакети прикладних програм (ППП). Тодi фактично розробляється лише роздiл 1-й, а в 2-му та 3-му роздiлах ПОЗ відбувається просте «прив’язування» (добiр) потрiбних повiдомлень ППП (ТПР) або зазначені роздiли не розробляються зовсім.

Зауважимо, що специфiчні особливостi ПОЗ виявляються під час розв’язування задач у дiалоговому режимi. Адже потрiбно розробляти сценарiй дiалогу, враховуючи зручнiсть роботи, типи дiалогу, форми їх реалiзацiї на ЕОМ i навiть притаманні користувачеві прийоми та привички.

Опис алгоритму розв’язування задачi

    Алгоритм являє собою правило розв’язування задачi, сформульоване як послiдовнiсть обчислювальних, логiчних та iнших дій (кроків), виконуваних з метою отримання потрiбного результату. Алгоритм може бути заданий словесно (засобами природної мови), математичним або графiчним описом. Крiм того, алгоритм може задаватися алгоритмiчною мовою.

В АIС ФКУ алгоритми описуються здебільшого математичним або графiчним способом, а також алгоритмiчною мовою. Графiчному опису передує, як правило, побудова математичної моделi — математичного опису алгоритму. Такий опис полягає у формалiзованому (із застосуванням математичних символів) поданні всіх розглядуваних залежностей і методiв відшукання значень вихiдних даних на підставі вхiдних.

Графiчний опис алгоритму виконується здебільшого у виглядi структурної схеми. Кожний її елемент являє собою фрагмент алгоритму, який описує певнi (повнiстю визначенi) дiї з даними. Послiдовнiсть дiй зображується за допомогою ЛIНIЙ ПОТОКУ IНФОРМАЦIЇ. Напрям потоку iнформацiї «згори — униз» i «злiва — направо» вважається основним i стрiлками не позначається.

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

Iснують певнi графічні позначення i для типiв носiїв та форм передавання даних, тому за допомогою таких позначень можна подати не лише машинний алгоритм, а й усю технологiю розв’язування задачi та обробки iнформацiї. Це важливо, коли йдеться про складні iнформацiйні зв’язки мiж задачами або складні процеси обробки даних.

До ПОЗ включають здебільшого як математичний, так i графiчний опис алгоритму. У разі, коли готують окремий документ «Опис алгоритму», поділяють його на роздiли: призначення та характеристика комплексу задач, використовувана iнформацiя, результати розв’язування задач комплексу, математичний опис алгоритму, графiчний його опис.

Алгоритмiчна мова — це спецiальна мова зі своїм алфавiтом, словником, правилами побудови слів, словосполучень, речень, в якiй кожне слово має одне і цілком певне значення. Коли таку мову створено на основi якої-небуть природної мови, то відповідні алгоритми досить просто описуються й читаються.

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

Розрізняють кiлька рiвнiв деталiзацiї (задання) алгоритму автоматизованого розв’язування задач АІС ФКУ.

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

Наступний (перший) рiвень — це рiвень, коли алгоритм задається з точнiстю до робiт з iнформацiйними масивами й загальних операцiй із ними (сортування масиву, вибiр, злиття тощо) та з точнiстю до блокiв розрахункiв показникiв за заданими формулами. Багато з таких блокiв алгоритму (сортування, добiр, обчислення середнього і т.iн.) уже можуть бути реалiзованi вiдповiдними командами (операторами) мов високого рiвня. У разі одного масиву досить просто за допомогою вiдповiдних команд типу REPORT реалiзується блок видавання на друк повiдомлення в табличній формі.

Коли у процесі видавання вихiдних повiдомлень беруть участь два масиви (найчастіше — масив числових значень i кодiв реквiзитiв та масив довiдкових даних, який мiстить розшифрування кодiв), доводиться органiзовувати пошук даних за кодом. Тобто необхiдна подальша деталiзацiя алгоритму (хоча в сучасних мовах високого рiвня iснують вiдповiднi типовi засоби видавання повiдомлень).

Ще вищим є другий рiвень деталiзацiї алгоритму, що означає його задання з точнiстю до робiт з окремими записами iнформацiйних масивiв, до манiпулювання з полями записiв (вибiр записiв за умовою, пошук за ключем, перехiд за номером запису, добiр полiв, аналiз значень окремих полiв i т.iн.).

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


 

А также другие работы, которые могут Вас заинтересовать

77471. Понятие, способы, формы и особенности защиты прав предпринимателей 30.46 KB
  Под защитой прав предпринимателей понимается совокупность нормативно установленных мер механизмов по восстановлению или признанию нарушенных или оспариваемых прав и интересов их обладателей которые осуществляются в определенных формах определенными способами в законодательно определенных границах с применением к нарушителям мер юридической ответственности а также механизма по практической реализации исполнимости этих мер. Понятие защита права следует отличать от понятия охрана права которое обычно трактуется более широко так как...
77472. Правовое регулирование рекламной деятельности 36.5 KB
  Участниками рекламной деятельности являются рекламодатели рекламо-производители распространители рекламы. Ситуация когда отсутствие правового регулирования рекламы имеет неблагоприятные последствия наблюдалась в период становления рыночных отношений. Основные направления государственного регулирования рекламы...
77473. Субъекты рекламной деятельности 43.5 KB
  У частникам так же относят потребителей рекламы и государственные органы которые осуществляют контроль в этой сфере. Саморегулируемые организации в сфере рекламы Саморегулируемой организацией в сфере рекламы признается объединение рекламодателей...
77477. Правовой статус предпринимателя 19.88 KB
  Правовой статус. Малько – понятие правовой статус и правовое положение понимается данными авторами как равнозначные. Правовой статус это – сложная собирательная категория которая отражает весь комплекс связей субъекта с обществом государством и иными субъектами. Термины правовой статус и правовое положение являются разными по содержанию т.