Главная
База знаний "Allbest"
Программирование, компьютеры и кибернетика
Геоинформационные технологии. Автоматизированные системы сбора и хранения и анализа информации. Основы автоматизированных систем проектно-изыскательских работ в природообустройстве
Геоинформационные технологии. Автоматизированные системы сбора и хранения и анализа информации. Основы автоматизированных систем проектно-изыскательских работ в природообустройстве
Геоинформационные технологии (ГИС) как совокупность программно-технологических средств получения новых видов информации об окружающем мире. Территориальные уровни использования ГИС в России. Назначение системы городского экомониторинга Москвы, ее уровни.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | реферат |
| Язык | русский |
| Дата добавления | 25.04.2010 |
| Размер файла | 253,7 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Из мировой практики известно, что затраты на сопровождение прикладного программного обеспечения АИС составляют не менее 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.
Подобные документы
Анализ видов обеспечения автоматизированных систем предприятия. Средства программирования распределенных систем обработки информации. Изучение особенностей использования технологии распределенных объектов. Эксплуатация программного обеспечения системы.
отчет по практике [486,0 K], добавлен 23.11.2014Классификация информации по разным признакам. Этапы развития информационных систем. Информационные технологии и системы управления. Уровни процесса управления. Методы структурного проектирования. Методология функционального моделирования IDEF0.
курсовая работа [5,2 M], добавлен 20.04.2011Информация как один из основных, решающих факторов, который определяет развитие технологии и ресурсов в целом, ее характерные черты и признаки. Методика создания автоматизированных систем, их технологическое обеспечение. Правила защиты информации.
курс лекций [664,4 K], добавлен 15.10.2009Основные составляющие современного персонального компьютера и их назначение. Геоинформационные системы и возможности их применения на автомобильном транспорте. Принципы построения навигационных систем. Сотовые системы связи. Локальные компьютерные сети.
контрольная работа [54,9 K], добавлен 21.02.2012Использование геоинформационных систем в здравоохранении. Создание ГИС-технологии изучения генетических процессов, происходящих в генофонде народов России. Характеристика и информационная безопасность мобильной геоинформационной системы "ArcPad".
курсовая работа [1,5 M], добавлен 04.03.2014Понятие экономической информации, ее классификаторы. Системы классификации и кодирования информации. Документация и технологии её формирования. Применение технологий Workflow, их функции. Виды носителей информации, современные технологии ее хранения.
курсовая работа [2,0 M], добавлен 27.09.2013Анализ автоматизированных информационных технологий, применяемых в экономике. Особенности экономической информационной системы, предназначенной для поиска, хранения и выдачи информации по запросам пользователей. Поиск информации с помощью баз данных.
курс лекций [1,4 M], добавлен 27.01.2010Эволюция технического обеспечения. Основные требования, применение и характеристики современных технических средств автоматизированных информационных систем. Комплексные технологии обработки и хранения информации. Создание базы данных учета и продажи.
курсовая работа [127,1 K], добавлен 01.12.2010Понятие и классификация информационных систем, их типы и функциональные особенности: связи, хранения и обработки информации, поисковые. Процесс устаревания данных систем, их значение и задачи в мире, сферы использования и возможности, управление.
презентация [555,0 K], добавлен 10.03.2015Роль информации о персонале для руководства предприятием. Анализ его материального оснащения, технических средств сбора, регистрации и передачи информации. Задачи автоматизированной системы управления персоналом. Программно–техническое обеспечение задачи.
дипломная работа [971,1 K], добавлен 28.11.2012
