Реферат по компьютерным технологиям на тему:

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

Выполнил:

Проверил:

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-модели все основные компоненты размещаются на клиентской установке. При обращении к данным ядро СУБД, в свою очередь, обращается с запросами на ввод-вывод данных за сервисом к файловой системе. С помощью функций операционной системы в оперативную память клиентской установки полностью или частично на время сеанса работы копируется файл базы данных. Таким образом, сервер в данном случае выполняет чисто пассивную функцию.

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

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

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

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

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

Рис. Модель удаленного доступа к данным (RDA-модель)

В файле (файлах) базы данных, размещаемом на сервере системы, находится также и системный каталог базы данных, в который помещаются в том числе и сведения о зарегистрированных клиентах, их полномочиях и т.п.

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

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

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

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

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

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

К недостаткам RDA-модели можно отнести высокие требования к клиентским вычислительным установкам, так как прикладные программы обработки данных, определяемые спецификой предметной области информационной системы, выполняются на них.

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

Развитием PDA-модели стала модель сервера базы данных. Ее сердцевиной является механизм хранимых процедур. В отличие от PDA-модели, определенные для конкретной предметной области информационной системы события, правила и процедуры, описанные средствами языка SQL, хранятся вместе с данными на сервере системы и на нем же выполняются. Иначе говоря, прикладной компонент полностью размещается и выполняется на сервере системы. Схематично DBS-модель приведена на рис.

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

На клиентских установках в DBS-модели размещается только интерфейсный компонент (компонент представления), что существенно снижает требования к вычислительной установке клиента. Пользователь через интерфейс системы на клиентской установке направляет на сервер базы данных только лишь вызовы необходимых процедур, запросов и других функций по обработке данных. Все затратные операции по доступу и обработке данных выполняются на сервере и клиенту направляются лишь результаты обработки, а не наборы данных, как в RDA-модели. Этим обеспечивается существенное снижение трафика сети в DBS-модели по сравнению с RDA - моделью.

Следует заметить, что на сервере системы выполняются процедуры прикладных задач одновременно всех пользователей системы. В результате резко возрастают требования к вычислительной установке сервера, причем как к объему дискового пространства и оперативной памяти, так и к быстродействию. Это основной недостаток DBS-модели.

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

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

Чтобы разнести требования к вычислительным ресурсам сервера в отношении быстродействия и памяти по разным вычислительным установкам, используется модель сервера приложений.

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

Рис. Модель сервера приложений (AS-модель).

Как и в DBS-модели, на клиентских установках располагается только интерфейсная часть системы, т.е. компонент представления. Однако вызовы функций обработки данных направляются на сервер приложений, где эти функции совместно выполняются для всех пользователей системы. За выполнением низкоуровневых операций по доступу и изменению данных сервер приложений, как в RDA-модели, обращается к SQL-серверу, направляя ему вызовы SQL-процедур, и получая, соответственно, от него наборы данных.

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

В этом отношении сервер приложений управляет формированием транзакций, которые выполняет SQL-сервер. Поэтому программный компонент СУБД, инсталлируемый на сервере приложений, еще называют монитором обработки транзакций (Transaction Processing Monitors - TRM), или просто монитором транзакций.

AS-модель, сохраняя сильные стороны DBS-модели, позволяет оптимально построить вычислительную схему информационной системы, однако, как и в случае RDA-модели, повышает трафик сети.

В практических случаях используются смешанные модели, когда простейшие прикладные функции и обеспечение ограничений целостности данных поддерживаются хранимыми на сервере процедурами (DBS-модель), а более сложные функции предметной области (так называемые правила бизнеса) реализуются прикладными программами на клиентских установках (RDA-модель) или на сервере приложений (AS-модель).

2. Автоматизированные системы сбора, хранения и анализа информации

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

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

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

Информационная система есть распространенное обозначение человеческого коллектива и процедур, а также разработанного, построенного, используемого и обслуживаемого оборудования для сбора, обработки, сохранения, извлечения и отображения информации.

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

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

По типу хранимых данных ИС делятся на фактографические и документальные. Фактографические системы предназначены для хранения и обработки структурированных данных в виде чисел и текстов. Над такими данными можно выполнять различные операции.

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

Основываясь на степени автоматизации информационных процессов в системе управления фирмой (организацией), ИС делятся на ручные, автоматические и автоматизированные.

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

В автоматических ИС все операции по переработке информации выполняются без участия человека.

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

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

Комплекс средств автоматизации (КСА) - совокупность всех компонентов АС, за исключением персонала.

Пользователь АС - лицо, участвующее в функционировании АС или использующее результаты ее функционирования.

В зависимости от характера обработки данных АИС¹ делятся на информационно-поисковые и информационно-решающие.

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

Информационно-решающие системы осуществляют, кроме того, операции переработки информации по определенному алгоритму. По характеру использования выходной информации такие системы принято делить на управляющие и советующие. Результирующая информация управляющих АИС непосредственно трансформируется в принимаемые человеком решения. Для этих систем свойственны задачи расчетного характера и обработка больших объемов данных, например АИС планирования производства или заказов, бухгалтерского учета. Советующие АИС вырабатывают информацию, которая принимается человеком к сведению и учитывается при формировании управленческих решений, а не инициирует конкретные действия. Эти системы имитируют интеллектуальные процессы обработки знаний, а не данных (например, экспертные системы).

В зависимости от сферы применения различают следующие классы АИС.

Системы организационного управления предназначены для автоматизации функций управленческого персонала как промышленных предприятий, так и непромышленных объектов (гостиниц, банков, магазинов и пр). Основными функциями подобных систем являются: оперативный контроль и регулирование, оперативный учет и анализ, перспективное и оперативное планирование, бухгалтерский учет, управление сбытом, снабжением и другие экономические и организационные задачи.

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

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

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

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

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

Функциональная подсистема представляет собой комплекс задач с высокой степенью информационных обменов (связей) между задачами. При этом под задачей понимается некоторый процесс обработки информации с четко определенным множеством входной и выходной информации. Состав функциональных подсистем определяется характером и особенностями автоматизируемой деятельности, отраслевой принадлежностью, формой собственности, размером предприятия. Деление АИС на функциональные подсистемы может строиться по различным принципам:

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

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

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

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

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

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

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

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

В соответствии с названиями приведенных на рис.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.