приховати рекламу

Геоінформаційні технології Автоматизовані системи збору та зберігання і аналізу інформації

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Реферат з комп'ютерних технологій на тему:

"Геоінформаційні технології. Автоматизовані системи збору та зберігання і аналізу інформації. Основи автоматизованих систем проектно-вишукувальних робіт у природооблаштування"

Виконав:

Перевірив:

2010

Зміст

Введення

1. Геоінформаційні технології

2. Автоматизовані системи збору, зберігання та аналізу інформації

3. Автоматизовані системи проектно-вишукувальних робіт у природооблаштування

Список літератури

Введення

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

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

1. Геоінформаційні технології

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

підвищення точності картографічної інформації;

скорочення трудовитрат на виготовлення продукції;

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

Методологічною основою процесів обробки інформації в ГІС є цифрове моделювання місцевості, що об'єднує процеси збору первинної інформації, її моделювання та безпека, обробки та формування документів.

За рахунок застосування сучасних технічних засобів здійснюється автоматизація польових і камеральних робіт.

Використання ГІС відбувається на різних рівнях. Це обумовлено різноманіттям геоінформаційних технологій.

Виділяють такі територіальні рівні використання ГІС у Росії:

глобальний рівень - Росія на глобальному та євразійському фоні, масштаб 1: 4 500 000 - 1: 100 000 000;

всеросійський рівень - вся територія країни, включаючи прибережні акваторії та прикордонні райони, масштаб 1: 2 500 000-1: 20 000 000;

регіональний рівень - великі природні та економічні регіони, суб'єкти Федерації, масштаб 1: 500 000 - 1: 4 000 000;

локальний рівень - області, райони, національні парки, ареал кризових ситуацій, масштаб 1: 50 000 - 1 000 000;

муніципальний рівень - міста, міські райони, приміські зони, масштаб 1: 50 000 і більше.

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

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

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

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

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

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

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

Структурно програмне забезпечення ГІС включає базові та прикладні програмні засоби.

Базові програмні засоби включають: операційні системи (ОС), програмні середовища, мережеве програмне забезпечення і системи управління базами даних. Операційні системи призначені для управління ресурсами ЕОМ і процесами, які використовують ці ресурси. На даний час основні ОС: Windows і Unix.

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

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

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

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

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

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

В основі будь-ГІС лежить інформація про який-небудь ділянці земної поверхні: континенті, країні, місті, вулиці.

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

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

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

Багато ГІС включають аналітичні функції, які дозволяють моделювати процеси, грунтуючись на картографічної інформації.

Програмне ядро ​​ГІС можна умовно розділити на дві підсистеми: СУБД і керування графічним виводом зображення. У Як СУБД використовують SQL-сервери.

Розглянемо типову схему організації ГІС-технології, в даний час склався основний набір компонентів, складових ГІС. До них відносяться:

придбання та попередня підготовка даних;

введення і розміщення даних;

управління даними;

маніпуляція даними та їх аналіз;

виробництво кінцевого продукту.

Функціональним призначенням даних компонентів є:

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

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

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

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

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

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

Переважна більшість ГІС-систем розрізняють геометричну та атрибутивну компоненти баз даних ГІС. Їх часто називають також просторовими (картографічними, геометричними) і непространственних (табличними, реляційними) даними.

Картографічна інформація може надаватися точками, кривими і майданними об'єктами.

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

Атрибутивна інформація зберігається у вигляді окремих табличних файлів, як правило, у форматах реляційних баз даних систем DBF, PARADOX, ORACLE, INGRESS. Такий спосіб характерний як для західних комерційних продуктів, так і сучасних вітчизняних розробок.

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

Модель файлового сервера

У FS-моделі всі основні компоненти розміщуються на клієнтській установці. При зверненні до даних ядро ​​СУБД, у свою чергу, звертається із запитами на введення-виведення даних за сервісом до файлової системи. За допомогою функцій операційної системи в оперативну пам'ять клієнтської установки повністю або частково на час сеансу роботи копіюється файл бази даних. Таким чином, сервер в даному випадку виконує суто пасивну функцію.

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

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

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

Модель віддаленого доступу до даних заснована на обліку специфіки розміщення та фізичного маніпулювання даних у зовнішній пам'яті для реляційних СУБД. У R DA-моделі компонент доступу до даних у СУБД повністю відділений від двох інших компонентів (компонента уявлення і прикладного компонента) і розміщується на сервері системи.

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

Рис. Модель віддаленого доступу до даних (R DA-модель)

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

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

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

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

Іншим, може бути неявним, гідністю RDA-моделі є уніфікація інтерфейсу взаємодії прикладних компонентів інформаційних систем з загальними даними. Така взаємодія стандартизовано в рамках мови SQL спеціальним протоколом ODBC (Open Database Connectivity - відкритий доступ до баз даних), що грає важливу роль у забезпеченні інтероперабельності (багатопротокольної), тобто незалежності від типу СУБД на клієнтських установках в розподілених системах.

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

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

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

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

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

Рис. Модель сервера бази даних (DBS-модель)

На клієнтських установках в DBS-моделі розміщується тільки інтерфейсний компонент (компонент подання), що істотно знижує вимоги до обчислювальної установці клієнта. Користувач через інтерфейс системи на клієнтській установці направляє на сервер бази даних тільки лише виклики необхідних процедур, запитів та інших функцій по обробці даних. Всі витратні операції по доступу та обробці даних виконуються на сервері і клієнтові прямують лише результати обробки, а не набори даних, як у R DA-моделі. Цим забезпечується суттєве зниження трафіку мережі в DBS-моделі в порівнянні з R DA - моделлю.

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

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

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

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

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

Рис. Модель сервера додатків (AS-модель).

Як і в DBS-моделі, на клієнтських установках розташовується тільки інтерфейсна частина системи, тобто компонент подання. Однак виклики функцій обробки даних спрямовуються на сервер додатків, де ці функції спільно виконуються для всіх користувачів системи. За виконанням низькорівневих операцій по доступу та зміни даних сервер додатків, як в R DA-моделі, звертається до SQL-сервера, направляючи йому виклики SQL-процедур, і отримуючи, відповідно, від нього набори даних.

Як відомо, послідовна сукупність операцій над даними (SQL-інструкцій), що має окреме смислове значення, називається трансакцією.

У цьому відношенні сервер додатків управляє формуванням транзакцій, які виконує SQL-сервер. Тому програмний компонент СУБД, яке інсталюється на сервері додатків, ще називають монітором обробки транзакцій (Transaction Processing Monitors - TRM), або просто монітором транзакцій.

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

У практичних випадках використовуються змішані моделі, коли найпростіші прикладні функції та забезпечення обмежень цілісності даних підтримуються збереженими на сервері процедурами (DBS-модель), а більш складні функції предметної області (так звані правила бізнесу) реалізуються прикладними програмами на клієнтських установках (R DA-модель ) або на сервері додатків (AS-модель).

2. Автоматизовані системи збору, зберігання та аналізу інформації

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

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

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

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

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

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

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

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

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

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

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

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

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

Комплекс засобів автоматизації (КСА) - сукупність всіх компонентів АС, за винятком персоналу.

Користувач АС - особа, яка бере участь у функціонуванні АС чи використовує результати її функціонування.

Залежно від характеру обробки даних АІС 1 діляться на інформаційно-пошукові та інформаційно-вирішальні.

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

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

У залежності від сфери застосування розрізняють такі класи АІС.

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

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

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

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

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

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

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

• предметного;

• функціональному;

• проблемному;

• змішаному (предметно-функціональному).

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

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

Склад забезпечують підсистем не залежить від конкретних функціональних підсистем і предметної області.

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

Відповідно до назвами наведених на рис.1 систем (абревіатури загальноприйняті серед фахівців з інформаційних технологій та систем) неважко визначити призначення і особливості кожної з них.

Рис.1. Класифікація АІС з урахуванням особливостей автоматизируемой професійної діяльності:

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

Розрізняють дев'ять забезпечують підсистем або так зване забезпечення АІС, зокрема:

інформаційне;

лінгвістичне;

математичне;

• методичне;

організаційне;

• правове;

• програмне;

• технічне;

ергономічне.

Нижче наведені тестовані визначення кожного виду забезпечення, його компоненти та особливості.

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

Інформаційне забезпечення включає:

опис технологічних процесів;

• опис організації інформаційної бази;

• опис вхідних потоків;

• опис вихідних повідомлень;

• опис систем класифікації та кодування;

• форми документів;

• опис структури масивів.

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

Призначення класифікаторів:

• систематизація найменувань кодованих об'єктів;

• однозначна інтерпретація одних і тих же об'єктів у різних завданнях;

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

• можливість зіставлення одних і тих же показників, що містяться у формах статистичної звітності;

• можливість пошуку та обміну інформацією між підсистемами та зовнішніми АІС;

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

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

• ієрархічний;

• Фасетноє;

• дескрипторних.

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

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

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

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

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

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

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

Системи класифікації принципово відрізняються від систем кодування відповідно до визначення.

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

Кодування застосовується для заміни назви об'єкта на умовне позначення (код) з метою забезпечення зручної і більш ефективної обробки інформації.

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

• уніфікованим систем документації;

• уніфікованим формам документів різних рівнів управління;

• складом і структурою реквізитів і показників;

• порядку впровадження, ведення та реєстрації уніфікованих форм документів.

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

• надзвичайно великий обсяг документів для ручної обробки;

• одні й ті ж показники часто дублюються в різних документах;

• робота з великою кількістю документів відволікає фахівців від рішення безпосередніх завдань;

• наявність показників, які створюються, але не використовуються, та ін

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

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

Для створення інформаційного забезпечення необхідно:

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

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

• вдосконалення системи документообігу;

• наявність і використання системи класифікації і кодування;

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

• створення масивів інформації на машинних носіях, що вимагає наявності сучасного технічного забезпечення.

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

Мовні засоби лінгвістичного забезпечення діляться на дві групи: традиційні мови (природничі, математичні, алгоритмічні, моделювання) і мови, призначені для діалогу з ЕОМ.

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

До складу математичного забезпечення входять:

• засоби математичного забезпечення (засоби моделювання типових задач управління, методи багатокритеріальної оптимізації, математичної статистики, теорії масового обслуговування та ін);

• технічна документація (опис завдань, алгоритми рішення задач, економіко-математичні моделі);

• методи вибору математичного забезпечення (методи визначення типів задач, методи оцінки обчислювальної складності алгоритмів, методи оцінки достовірності результатів).

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

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

Організаційне забезпечення реалізує наступні функції:

• аналіз існуючої системи управління підприємством (організацією), де використовується АІС, виявлення завдань, що підлягають автоматизації;

• підготовку завдань до автоматизації, включаючи розробку технічних завдань і техніко-економічних обгрунтувань ефективності;

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

Організаційне забезпечення включає:

• методичні матеріали, що регламентують процес створення і функціонування АІС;

• сукупність засобів для ефективного проектування і функціонування АІС;

• технічну документацію, що отримується в процесі обстеження підприємства, проектування, впровадження та супроводу системи;

• персонал (організаційно-штатні структури підприємства), який проектує, впроваджує, супроводжуючий і використовує ІС.

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

До складу правового забезпечення входять закони, укази, постанови державних органів влади; накази, інструкції та інші нормативні документи міністерств, відомств, організацій, місцевих органів влади. У правовому забезпеченні можна виділити загальну частину, регулюючу функціонування будь-якої ІВ, і локальну частину, регулюючу функціонування конкретної системи.

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

Правове забезпечення функціонування АІС включає:

• статус АІС;

• права, обов'язки і відповідальність персоналу;

• правові положення окремих видів процесу управління;

• порядок створення і використання інформації.

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

До програмного забезпечення АІС відносять:

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

• програмне забезпечення загального призначення, призначене для вирішення типових задач обробки інформації.

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

Технічне забезпечення - сукупність усіх технічних засобів, використовуваних при функціонуванні АІС.

До технічних засобів відносять:

• використовувану обчислювальну техніку різного призначення (сервери, робочі станції);

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

• пристрої передачі даних і лінії зв'язку;

• пристрої автоматичного знімання інформації;

• оргтехніку, експлуатаційні матеріали і т.д.

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

Документацію технічного забезпечення можна умовно розділити на групи:

• загальносистемна документація, що включає державні та галузеві стандарти з технічного обслуговування;

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

• нормативно-довідкова документація, використовувана при розрахунках по технічному забезпеченню.

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

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

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

Згідно архітектура - це організаційна структура автоматизованої системи. Відомо й інше визначення: архітектура - це концептуальний опис структури системи, що включає опис елементів системи, їх взаємодії і зовнішніх властивостей. Виділяють два рівні архітектури АІС:

• бізнес-архітектуру (бізнес-рівень);

• рівень інформаційних технологій (технічний рівень).

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

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

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

архітектура програмних систем;

інформаційна архітектура;

• технологічна (інфраструктурна) архітектура.

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

Під архітектурою програмних систем розуміють сукупність таких технічних рішень:

• загальний архітектурний стиль і загальну організацію програмної частини АІС;

• розподіл програмного комплексу на функціональні підсистеми та модулі;

• властивості модулів, методи їх взаємодії і об'єднання, використовувані інтерфейси.

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

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

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

Життєвий цикл АІС. Одним з базових понять методології проектування АІС є поняття життєвого циклу її програмного забезпечення (ЖЦ ПЗ). ЖЦ ПЗ - це безперервний процес, який починається з моменту прийняття рішення про необхідність його створення і закінчується в момент його повного вилучення з експлуатації.

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

Домогтися цього протягом всього ЖЦ АІС - досить складна по ряду об'єктивних і суб'єктивних причин завдання, в результаті переважна більшість проектів АІС впроваджується з порушеннями якості, термінів або кошторису; майже третина проектів припиняють своє існування незавершеними.

З світової практики відомо, що витрати на супровід прикладного програмного забезпечення АІС складають не менше 70% його сукупної вартості протягом ЖЦ, тому вкрай важливо ще на проектній стадії передбачити необхідні методи і засоби супроводу, включаючи методи конфігураційного управління.

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

Розробка АІС охоплює всі роботи зі створення програмного забезпечення та його компонентів відповідно до заданих вимог. Цей процес також передбачає:

• оформлення проектної та експлуатаційної документації;

• підготовку матеріалів, необхідних для тестування розроблених програмних продуктів;

• розробку матеріалів, необхідних для навчання персоналу.

Як правило, складовими процесу розробки є стратегічне планування, аналіз, проектування і реалізація (програмування).

До процесу експлуатації відносяться:

• конфігурування бази даних і робочих місць користувачів;

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

• навчання персоналу.

Основні експлуатаційні роботи включають:

• безпосередньо експлуатацію;

• локалізацію проблем і усунення причин їх виникнення;

• модифікацію програмного забезпечення;

• підготовку пропозицій щодо вдосконалення системи;

• розвиток і модернізацію системи.

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

До попередніми діям при організації технічного обслуговування АІС відносяться:

• виділення найбільш відповідальних вузлів системи та визначення для них критичності простою (це дозволить виділити найбільш критичні складові АІС і оптимізувати розподіл ресурсів для технічного обслуговування);

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

• проведення аналізу наявних внутрішніх і зовнішніх ресурсів, необхідних для організації технічного обслуговування в рамках описаних завдань і поділу компетенції (основні критерії для аналізу: наявність гарантії на обладнання, стан ремонтного фонду, кваліфікація персоналу);

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

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

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

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

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

Управління проектом пов'язано з питаннями планування та організації робіт, створення колективів розробників, контролю термінів та якості виконання робіт. Технічне і організаційне забезпечення проекту включає:

вибір методів та інструментальних засобів реалізації проекту;

• визначення методів опису стану процесу розробки;

• розробку методів і засобів випробувань створеного програмного забезпечення;

• навчання персоналу.

Забезпечення якості проекту пов'язане з проблемами верифікації, перевірки та тестування компонентів АІС.

Верифікація - процес визначення відповідності поточного стану розробки, досягнутого на даному етапі, вимогам цього етапу.

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

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

За аналогією з відомим визначенням моделі ЖЦ ПЗ і відповідно до усталеної серед фахівців термінологією, наведемо визначення моделі ЖЦ АІС.

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

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

• стадії;

• результати виконання робіт на кожній стадії;

• ключові події або точки завершення робіт і прийняття рішень.

У відповідності з відомими моделями ЖЦ ПЗ визначають моделі ЖЦ АІС - каскадну, итерационную, спіральну. Нижче детально розглянута кожна з них.

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

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

Періодично назви стадій розробки в каскадної моделі змінювалися; крім того, в кожний період часу регламент приписування певних робіт до конкретних етапів ніколи не був жорстким і однозначним. Тим не менше виділяють п'ять стійких етапів розробки, практично не залежать від предметної області.

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

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

Третій етап - реалізація проекту; по суті, розробка програмного забезпечення (кодування) відповідно до проектних рішень попереднього етапу. Методи реалізації при цьому принципового значення не мають. Результатом виконання етапу є готовий програмний продукт.

На четвертому етапі проводиться перевірка отриманого програмного забезпечення на предмет відповідності вимогам, заявленим у технічному завданні. Дослідна експлуатація дозволяє виявити різного роду приховані недоліки, які проявляються в реальних умовах роботи АІС.

Останній етап - здача готового проекту, і головне тут - переконати замовника в тому, що всі його вимоги виконані повною мірою.

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

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

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

2) послідовне виконання етапів робіт дозволяє планувати терміни завершення і відповідні витрати.

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

Тим не менш модель має ряд недоліків, що обмежують її застосування:

• суттєва затримка в отриманні результатів;

• помилки і недопрацювання на будь-якому з етапів виявляються, як правило, на наступних етапах робіт, що призводить до необхідності повернення;

• складність паралельного ведення робіт за проектом;

• надмірна інформаційна перенасиченість кожного з етапів;

• складність управління проектом;

• високий рівень ризику і ненадійність інвестицій.

Затримка в отриманні результатів виявляється в тому, що при послідовному підході до розробки узгодження результатів з зацікавленими сторонами провадиться тільки після завершення чергового етапу робіт. У результаті може виявитися, що розробляється АІС не відповідає вимогам, і такі невідповідності можуть виникати на будь-якому етапі розробки, крім того, помилки можуть ненавмисно вноситися і проектувальниками-аналітиками, і програмістами, так як вони не зобов'язані добре розбиратися в тих предметних областях, для яких розробляється АІС.

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

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

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

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

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

відсутність паралелізму негативно позначається і на організації роботи всього колективу.

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

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

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

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

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

У разі ж виявлення помилок в роботі необхідне повернення до попередніх етапів; поточна робота тих, хто помилився, переривається. Наслідком цього звичайно є зрив термінів виконання як виправляється, так і нового проектів.

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

Високий рівень ризику. Чим складніше проект, тим довше триває кожен етап розробки і тим складніше взаємозв'язку між окремими частинами проекту, кількість яких також збільшується. Причому результати розробки можна реально побачити і оцінити лише на етапі тестування, тобто після завершення аналізу, проектування і розробки - етапів, виконання яких вимагає значного часу та коштів.

Запізніла оцінка породжує серйозні проблеми при виявленні помилок аналізу і проектування - потрібно повернення на попередні стадії і повторення процесу розробки. Проте повернення на попередні стадії може бути пов'язаний не тільки з помилками, але і з змінами, що відбулися в предметній області або у вимогах замовника за час розробки. При цьому ніхто не гарантує, що предметна область знову не зміниться до того моменту, коли буде готова наступна версія проекту. Фактично це означає, що існує ймовірність "зациклення" процесу розробки: витрати на проект будуть постійно зростати, а терміни здачі готового продукту постійно відкладатися.

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

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

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

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

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

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

Недоліки ітераційної моделі:

• час життя кожного етапу розтягується на весь період розробки;

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

• заплутаність архітектури;

• труднощі використання проектної документації на стадіях впровадження і експлуатації викликають необхідність перепроектування всієї системи.

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

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

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

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

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

Переваги ітераційного підходу:

• итерационная розробка істотно спрощує внесення змін до проекту при зміні вимог замовника;

• при використанні спіральної моделі окремі елементи АІС інтегруються в єдине ціле поступово. Оскільки інтеграція починається з меншої кількості елементів, то виникає набагато менше проблем при її проведенні (при використанні каскадної моделі інтеграція займає до 40% всіх витрат у кінці проекту);

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

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

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

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

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

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

При ітераційному підході корисно слідувати принципу "краще - ворог хорошого". Тому завершення ітерації повинно проводитися строго відповідно до плану, навіть якщо не вся запланована робота закінчена. Планування робіт зазвичай проводиться на основі статистичних даних, отриманих у попередніх проектах, та особистого досвіду розробників.

3. Автоматизовані системи проектно-вишукувальних робіт у природооблаштування

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

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

З цього випливає, що в екологічних ГІС застосовуються в першу чергу динамічні моделі. У силу цього велику роль в них відіграють технології створення електронних карт.

Сукупність усіх перерахованих трьох типів даних складає основу екологічного моніторингу.

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

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

На рівні збору поряд з топографічними характеристиками додатково визначаються параметри, що характеризують екологічну обстановку. Це збільшує обсяг атрибутивних даних в екологічних ГІС в порівнянні з типовими ГІС. Відповідно зростає роль семантичного моделювання.

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

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

В якості прикладу розглянемо систему екологічного моніторингу, створювану для Москви. Об'єктами моніторингу Москви є: атмосферне повітря, поверхневі і підземні води, грунт, зелені насадження, радіаційна обстановка, оточення і стан здоров'я населення.

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

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

Структура системи екомоніторингу Москви включає два рівні.

Нижній рівень системи включає:

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

територіальні центри збору і обробки даних, створені на базі територіальних відділень Москомпріроди.

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

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

Верхній рівень системи екомоніторингу складає інформаційно-аналітичний центр. У завдання верхнього рівня системи входять:

оперативна оцінка екологічної ситуації в місті;

розрахунок інтегральних оцінок екологічної ситуації;

прогноз розвитку, екологічної обстановки;

підготовка проектів керуючих впливів і оцінка наслідків прийнятих рішень.

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

Для ефективного використання накопичуваних даних необхідні комплексна обробка і досконалі методи моделювання та представлення даних.

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

Підсистема спеціалізованих моніторингів охоплює ряд організацій (Москомзем, НВО "Радон", Ниипи Генплану), що мають інструментальні пакети ГІС. Інші організації (Мослесопарк, МГЦСЕН) подібного програмного забезпечення не мають. Інтеграція даних в єдину систему відбувається двома шляхами:

на основі конвертації форматів даних в єдиний для всієї системи формат;

на основі вибору єдиного програмного забезпечення ГІС.

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

формування і ведення баз екологічної інформації по територіях, підприємствам, середах (повітря, вода, грунт);

ведення бази даних нормативно-законодавчих документів у галузі екології;

ведення бази даних нормативів вмісту забруднюючих речовин у повітрі, воді, грунті та продуктах харчування;

ведення бази даних приладів екологічного контролю.

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

Система екологічного моніторингу передбачає обмін даними між його учасниками. Тому одним з головних вимог, що пред'являються до програмного забезпечення всіх підсистем, є можливість конвертування файлів даних в стандартні формати (dbf для файлів баз даних і DXF для графічних файлів).

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

Масштаби карт, на яких працюють різні підсистеми екомоніторингу, можуть бути різними: від 1: 2 000 для територіальних відділень Москомпріроди до 1: 38 000 для верхнього рівня системи.

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

Сформована близько двадцяти років тому система нормування викидів забруднюючих речовин в атмосферу сьогодні визначає основні принципи управління якістю атмосферного повітря. У 1980-і роки разом з бурхливим розвитком обчислювальних засобів значно зросли обсяги робіт по встановленню нормативів ПДВ, і з'явилася необхідність у використанні спеціалізованих програмних засобів.

Найбільш трудомісткою частиною роботи з випуску проекту нормативів ПДВ є проведення розрахунків величин приземних концентрацій шкідливих речовин згідно з "Методикою розрахунку концентрацій в атмосферному повітрі шкідливих речовин, що містяться у викидах підприємств" (ОНД-86). Тому в першу чергу з'явився попит на програми, що реалізують алгоритм названої методики - уніфіковані програми розрахунку забруднення атмосфери (УПРЗА). Розробка перших таких програм велася централізовано і не мала комерційного характеру. Найбільш відомою УПРЗА того часу була програма "Ефір" для машин класу ЄС.

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

Деякі розробники пішли далі й автоматизували процес випуску таблиць проекту нормативів ГДВ та деяких інших документів. З'явилися програмні комплекси для великих машин, в яких головна програма (УПРЗА) доповнювалася декількома допоміжними.

Такий спосіб роботи позбавляв розробників томів ПДВ певної оперативності. При необхідності багаторазового зміни вихідних даних з метою отримання прийнятних величин приземних концентрацій були потрібні чималі витрати часу.

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

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

Однак ідеологія самих програмних засобів змінилася. Виробники програм могли використовувати недоступні раніше можливості персональних комп'ютерів. Програми випускалися з "користувальницьким" інтерфейсом, інтуїтивно зрозумілим навіть не фахівцям по роботі з ЕОМ. Установка програм на комп'ютер та їх налаштування теж були доступні не тільки фахівцям. Обробка помилок проводилася на зрозумілій користувачеві мові, захист від некоректних дій користувача стала досить досконалою. І все ж бар'єр, в основному психологічний, боязнь самостійної роботи на новій техніці були подолані не відразу.

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

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

Надалі завдяки контакту розробників і користувачів почали з'являтися нові класи задач, що реалізуються програмними засобами. Це в першу чергу відноситься до програм, які реалізують галузеві методики з розрахунку величин викидів шкідливих речовин для різних виробництв. Створення таких програмних засобів уже не диктувалося практичною неможливістю проведення розрахунків без використання комп'ютера (як це було при створенні УПРЗА), а було обумовлено необхідністю більш повно автоматизувати всі стадії процесу роботи фахівця природоохоронної служби підприємства. Таким чином стали формуватися системи, звані "робоче місце еколога", центральне місце в яких займає УПРЗА.

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

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

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

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

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

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

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

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

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

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

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

До складу системи входять:

Програма автоматичного прийому інформації про параметри джерел викиду підприємств по підготовлених в єдиному форматі даними інвентаризації, томи ПДВ, розділу проекту охорони навколишнього середовища

Програма ведення узагальненого міського банку даних джерел викиду

Програма підготовки статистичних оглядів

Програма розрахунку розсіювання шкідливих речовин в атмосфері по ОНД-86 (розрахунковий блок системи, узгоджений ГГО ім. А. І. Воєйкова)

Програма візуалізації екологічної інформації на електронній карті міста (регіону)

Програма "Магістраль", що дозволяє проводити розрахунок викидів забруднюючих речовин автотранспортними потоками при русі автомобілів по міських магістралях

Програма визначення допустимих вкладів у забруднення атмосфери викидів забруднюючих речовин підприємствами

Система в стандартному варіанті поставки забезпечує:

введення даних в єдиному форматі з дискет або по інших каналах (модем, мережа)

безпосередній ("ручний") введення інформації

автоматизовану обробку інформації, що надійшла і поповнення банку даних

доступ до інформації на будь-якому рівні (підприємства, району, міста) на існуючий стан і будь-яку дату перспективи

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

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

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

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

Для наочного представлення результатів зведених розрахунків забруднення атмосфери в місті фірма "Інтеграл" розробила програму "Екологічна карта забруднення повітря". Програма працює у взаємодії з системою "Еколог-місто" і дозволяє проводити аналіз проведених розрахунків приземних концентрацій з прив'язкою до топооснови місцевості. Таким чином зроблено крок в область стикування екологічних програмних засобів з ГІС-технологіями.

Система "Еколог-місто" успішно експлуатується в ряді регіонів країни, зокрема, Кондопозі, Воронежі, Пскові, Пермі. Впровадження системи якісно змінило весь підхід до воздухоохранной діяльності. Пішовши від рутинної роботи, територіальні органи охорони природи отримали реальну можливість управляти якістю охорони атмосферного повітря.

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

Ще одним перспективним напрямом є розробка програми з розрахунку середньорічних концентрацій забруднюючих речовин в атмосфері. Відповідне програмне забезпечення з'явиться одночасно з виходом у світ методики - наступника ОНД-86. Значення середньорічних концентрацій забруднюючих речовин можуть бути використані, зокрема, для оцінки ризику здоров'ю населення.

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

Список літератури

  1. Бугаєвський Л.М., Цвєтков В.Я. "Геоінформаційні системи: Навчальний посібник для вузів". М.: 2000.

  2. Ізбачков Ю.С., Петров В.М. "Інформаційні системи: Підручник для вузів". СПб.: 2006.

  3. Гагаріна Л.Г. "Розробка та експлуатація автоматизованих інформаційних систем: навч. Посібник". М.: 2007.

  4. Гобарева Я.Л. "Автоматизовані системи обробки економічної інформації" М.: 2005.

  5. Цвєтков В.Я. "Геоінформаційні системи і технології" М.: 1997.

Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Реферат
211.8кб. | скачати


Схожі роботи:
Геоінформаційні технології Автоматизовані системи збору та зберігання і аналізу інформації Основи
Розробка системи зі збору інформації
Технології обробки і зберігання інформації
Автоматизовані системи обробки інформації
Автоматизовані системи захисту інформації
Автоматизовані системи обробки інформації та управління
Автоматизовані системи обробки економічної інформації
Автоматизовані системи управління обробки інформації в торгівлі
Інтерв`ю як метод збору інформації
© Усі права захищені
написати до нас
Рейтинг@Mail.ru