Автор работы: Пользователь скрыл имя, 24 Октября 2013 в 05:34, дипломная работа
Необходимо, чтобы информация поступала сотрудникам вовремя, а круг лиц, имеющих доступ к конкретному документу, должен быть четко определен.
Целью данной дипломной работы является создание автоматизированной подсистемы единой дежурно-диспетчерской службы Главного управления МЧС РФ по Амурской области, с помощью которой будут решаться основные задачи и функции диспетчеров и оперативных дежурных по регистрации и обработке сведений о пожарах и других чрезвычайных ситуаций.
Введение 8
1 Анализ и характеристика предметной области 10
1.1 Общая характеристика Главного управления МЧС РФ по Амурской области 10
1.2 Организационная структура Главного управления МЧС РФ по Амурской области 11
1.3 Анализ внешнего документооборота 16
1.4 Анализ внутреннего документооборота 19
1.5 Анализ объекта автоматизации 21
1.6 Анализ бухгалтерской отчётности 28
1.7 Анализ финансовой деятельности 30
1.8 Обоснование необходимости создания системы 42
2 Техническое задание 44
2.1 Общие сведения 44
2.2 Назначение и цели создания системы 44
2.2.1 Функциональное и эксплуатационное назначение изделия 46
2.2.1.1 Требования к системе 46
2.2.1.2 Рассмотренные альтернативы 47
2.2.2 Экономическая и социальная целесообразность разработки 48
2.3 Характеристика объекта автоматизации 48
2.3.1 Входные данные 49
2.3.2 Процесс обработки 49
2.3.3 Выходные данные 49
2.4 Требования к системе 50
2.4.1 Функции системы 50
2.4.2 Стандарты 51
2.4.3 Информационная совместимость 51
2.4.4 Программные ограничения, совместимость 52
2.4.5 Требования к составу и параметрам технических средств (аппаратные ограничения) 52
2.4.6 Результирующие компоненты автоматизированной системы 53
2.4.7 Носители информации 53
2.4.8 Эргономические характеристики 53
2.4.9 Безопасность и секретность 54
2.4.10 Требования надежности 54
2.4.11 Перезапуск системы 54
2.4.12 Удобство эксплуатации 55
2.4.13 Требования к безопасности жизнедеятельности и
охране окружающей среды 55
2.5 Стадии и этапы разработки 55
2.6 Порядок контроля и приемки 56
2.7 Требования к составу и содержанию работ по подготовке
объекта автоматизации к вводу в действие 56
2.8. Требования к документированию 57
3 Проектирование автоматизированной подсистемы единой дежурно- диспетчерской службы ГУ МЧС по Амурской области 58
3.1 Выбор программного обеспечения для реализации системы 58
3.2 Характеристика функциональных подсистем 61
3.3 Характеристика обеспечивающих подсистем 63
3.3.1 Организационное обеспечение 63
3.3.2 Правовое обеспечение 64
3.3.3 Лингвистическое обеспечение 64
3.3.4 Математическое обеспечение 64
3.3.5 Техническое обеспечение 65
3.3.6 Программное обеспечение 65
3.4 Информационное обеспечение 66
3.4.1 Проектирование базы данных 66
3.4.1.1 Инфологическое проектирование 66
3.4.1.2 Логическое проектирование 85
3.4.1.3 Физическое проектирование 88
3.4.2 Классификация информации 96
3.4.3 Классификация пользователей 97
3.5 Анализ существующего программного и аппаратно-технического сетевого обеспечения предприятия 98
3.6 Модернизация существующего программного и аппаратно-технического сетевого обеспечения предприятия 99
3.7 Программная реализация информационной системы 100
3.7.1 Разработка программного продукта 100
3.7.2 Проектирование интерфейса пользователя 102
3.7.2.1 Требования к интерфейсу пользователя 102
3.7.2.2 Руководство пользователя 103
3.8 Защита информации в системе 108
Заключение 111
Библиографический список 112
Приложение А. Документооборот и процессы обработки информации 114
Приложение Б. Проектирование модели данных 117
Приложение В. Схемы ЛВС
На сервере должен быть установлен и запущен сервер InterBase.
Для работы с отчетами, сформированными системой, на клиентских компьютерах необходимо установить Microsoft Office (Word, Excel).
2.4.5 Требования к составу и параметрам технических средств (аппаратные ограничения)
Для функционирования системы необходим выделенный сервер с надежной файловой системой (NTFS) и операционной системой (Microsoft Windows 2000 Server или Microsoft Windows 2003 Server). Кроме того, сервер должен быть подключен источнику бесперебойного питания (при перебоях электропитания сервер должен корректно завершить свою работу, иначе это может привести к возникновению ошибок в базе). Минимальная конфигурация сервера:
Минимальные системные требования к персональным компьютерам рабочих станций сети:
1) процессор: Intel Pentium II 400;
2) оперативная память: 128 - 256 Мб;
3) устройства ввода информации: клавиатура, мышь;
4) монитор: поддерживающий разрешение 1024´768 при частоте обновления не менее 75 Гц;
5) принтер;
6) сетевой
адаптер: поддержка сети Ethern
Кроме того, на рабочие станции должны поддерживать протокол передачи данных TCP/IP.
2.4.6 Результирующие компоненты автоматизированной системы
Разрабатываемый программный продукт должен иметь следующую комплектацию:
2.4.7 Носители информации
Программное изделие поставляются на CD диске, так же на этом диске должен содержаться текстовый документ, в котором описан процесс установки всех необходимых компонент. Их установка производится на жесткие магнитные диски (НЖМД).
2.4.8 Эргонометрические
Создаваемое программное изделие ориентированно на пользователя, владеющего навыками работы в операционной системе Windows. Интерфейс программы должен быть интуитивно понятен и требовать от пользователя минимум действий, а вся входная информация должна контролироваться во избежание ввода ошибочных и некорректных данных.
Расположение компьютеров и периферийных устройств должно быть установлено в соответствии со всеми принятыми нормами. Соблюдение этих требований позволит минимизировать вредное воздействие на организм пользователя со стороны системы.
2.4.9 Безопасность и секретность
В разрабатываемой системе должно быть реализовано строгое разграничение доступа зарегистрированных пользователей к информационным ресурсам (возможность доступа только к тем ресурсам и выполнения только тех операций с ними, которые необходимы конкретным пользователям для исполнения своих служебных обязанностей), то есть защиту от несанкционированного доступа. Для обеспечения защиты хранимых данных будут использованы следующие методы и способы:
2.4.10 Требования надежности
Система должна отвечать
следующим требованиям надежнос
2.4.11 Перезапуск системы
В случае появления ошибок в информационной базе после аварийного сбоя система должна успешно запуститься с последней рабочей резервной копии и нормально функционировать.
2.4.12 Удобство эксплуатации
Все элементы интерфейса должны содержать всплывающие подсказки, в которых кратко формулируется назначение этого объекта. Справка должна содержать основы работы с программным продуктом, то есть последовательности действия пользователя для получения желаемого результата.
2.4.13 Требования к безопасности
жизнедеятельности и охране окр
Разрабатываемая система должна отвечать всем требованиям, предъявляемым инструкциями по технике безопасности на предприятии. То есть для всего компьютерного оборудования должен быть предусмотрен заземляющий контур, все провода должны быть с неповрежденной изоляцией, рабочие станции и другое сетевое оборудование должно превышать допустимый уровень шума (75 дБ), все мониторы должны удовлетворять нормам по электромагнитному излечению.
2.5 Стадии и этапы разработки
Выделяются следующие стадии и этапы разработки:
2.6 Порядок контроля и приемки
Порядок контроля и приемки:
В случае если разработанный продукт соответствует всем выдвигаемым к нему требованиям, то выносится решение о его дальнейшем использовании.
2.7. Требования к составу и
содержанию работ по
Перед тем как ввести в эксплуатацию готовую информационную систему разработчик обязан договорится с руководством организации о времени в течении которого он обязан внедрить разработанную систему. Под внедрением системы понимается совокупность мероприятий включающих в себя обучение персонала, настройку системы для дальнейшего использования, информирование специалистов отдела АСУ о порядке проведения работ по сопровождению системы и предоставление им необходимой документацией на систему, ознакомление администратора с его обязанностями. Также разработчик обязан предоставить демонстрационную версию программы.
2.8. Требования к документированию
Документация на разрабатываемую систему должна включать:
– документацию на программные средства вычислительной техники по ГОСТ 19.101;
– эскизный проект;
– технический проект.
Состав и содержание документации должны соответствовать требованиям ГОСТ 34.201-89 и нормативно-технических документов (комплекса стандартов и руководящих документов на автоматизированные системы и единой системы программной документации).
Перечень документов подлежащих разработке на систему:
– Схема функциональной структуры;
– Описание организации информационной базы;
– Руководство по организации сопровождения;
– Программа и методика испытаний;
– Описание применения;
– Технологическая инструкция.
Перечень документов подлежащих разработке по каждому комплексу задач, входящих в разрабатываемую систему:
– Описание постановки комплекса задач c перечнем выходных данных (документов);
– Описание технологического процесса обработки данных;
– Руководство пользователя.
3 ПРОЕКТИРОВАНИЕ АВТОМАТИЗИРОВАННОЙ ПОДСИСТЕМЫ ЕДИНОЙ ДЕЖУРНО-ДИСПЕТЧЕРСКОЙ СЛУЖБЫ ГУ МЧС ПО АМУРСКОЙ ОБЛАСТИ
3.1 Выбор программного
обеспечения для реализации
Для клиентских мест необходимо использовать приложение, позволяющее вносить информацию в базу данных, заполнять формы отчетов. Такой подход облегчает и упрощает выполнение процесса документооборота, а также исключает возможные ошибки оформления.
Диспетчеры и оперативные
Формы приложения должны иметь простой, интуитивно понятный даже неопытному пользователю интерфейс. Главное требование к приложению – понятная формулировка вопроса, предполагающее однозначный ответ.
Решение указанной проблемы в дальнейшем предполагается осуществить посредством использования следующих программных продуктов:
Построение модели информационных потоков учреждения и его отделов производим в пакете BPWin.
BPWin – мощный инструмент моделирования с возможностью анализа, документирования и корректирования бизнес процессов. Он поможет устранить лишние или неэффективные операции, уменьшить издержки, повысить гибкость и улучшить уровень обслуживания заказчика.
В модели BPWin, существует возможность четко задокументировать важные позиции, такие как необходимые операции, проследить, как они выполняются и какие необходимы для этого ресурсы. Модель BPwin обеспечивает интегрированное изображение того, как работает организация. Это изображение, в свою очередь, состоит из подмоделей отделов.
BPWin включает несколько расширений, поддерживающих методологии моделирования IDEF0, DFD и IDEF3. BPWin поддерживает двунаправленные линии связи с программой ERWin.
ERWin – средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, InterBase, Informix, Sybase, DB/2, Microsoft SQL Server, Progress) и реинжинеринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Для ряда средств разработки приложений (SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.
Существует возможность совместно использовать BPWin и ERWin как для моделирования процесса, так и для моделирования данных и можно обмениваться объектами и названиями атрибута между двумя программами. Эта возможность особенно полезна для пользователей, кто разрабатывает модель бизнес процесса и модель базы данных одновременно. Любые изменения, которые проводятся в объекте и названии атрибута в любой модели, могут быть внесены в другую модель. Также возможно создать двухсторонние линии связи между моделью BPWin и связанной с ней моделью ERWin, что выполняется, автоматически каждый раз, когда открывается одна из связанных диаграмм. Это проводится для синхронизации моделей.
Наиболее целесообразно