Разработка информационной системы поддержки принятия решений оператором при управлении транспортировкой газа

Разработка информационной системы поддержки принятия решений оператором при управлении транспортировкой газа

Аннотация

Тема дипломной работы: «Разработка информационной системы поддержки принятия решений оператором при управлении транспортировкой газа»

Выполнил студент: Артюшин Дмитрий Юрьевич

Год защиты: 2015

Руководитель доцент: Стычук А.А 

В данной дипломной работе представлена реализация информационной системы поддержки принятия решения оператором при управлении транспортировкой газа предприятием ОАО «Газпромрегионгаз» Данная информационная система направлена на повышение эффективности и оперативности принимаемых решений в процессе управления.

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

Введение

транспортировка газопровод магистраль

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

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

Одной из тех сфер, предприятия которых особенно нуждаются в автоматизации процессов их работы, является промышленность. Это объясняется, во-первых, слабым уровнем развития промышленности в целом по России, и, во-вторых, высоким уровнем конкуренции со стороны западных производителей в этой сфере.

Одной из таких организаций является ОАО «Газпромрегионгаз», которая осуществляет транспортировку газа среднего давления по городу Орлу и Орловской области.

Целью данной дипломной работы является повышение эффективности и оперативности принимаемых решений оператором в процессе управления транспортировкой газового потока на предприятии ОАО «Газпромрегионгаз».

В ходе выполнения дипломной работы должны быть решены следующие задачи:

рассмотрены особенности функционирования предприятия по способу управления транспортировкой газа;

провести моделирование ППО;

разработана структура базы данных для хранения информации;

осуществлено проектирование приложения;

проведена оценка экономической эффективности информационной системы;

проведены мероприятия по обеспечению БЖД.

1. Анализ принципов функционирования предприятия ОАО «Газпромрегионгаз»

.1 Общая характеристика предприятия ОАО «Газпромрегионгаз»

Очередной филиал в городе ОРЛЕ был открыт компанией ОАО «Газпромрегионгаз» в сентябре 2005 года. Предприятие было создано для обслуживания газопроводов по Орлу и транспортировки газа через Орловскую область. Численность предприятия ОАО «Газпромрегионгаз» с филиалами районных служб Орловской области составляет 450 человек.

Предприятие расположено в г. Орел, ул. Монтажная, дом № 14 А.

Площадь предприятия составляет 500 м² на территории предприятия находится 3 здания, головное здание в два этажа площадью 150 м² .

Общая численность работников предприятия составляет 120 человек, в том числе:

-        ИТР и служащие - 90 чел;

         рабочие - 20 чел;

По специальностям:

         прочие специальности - 10 (электрики, грузчики, водители, охрана).

Сети филиалов объединяются с сетью офиса ОАО «Газпромрегионгаз» через VPN - туннели, таким образом, что ресурсы сетей филиалов доступны напрямую. VPN - туннели находятся между маршрутизаторами головного офиса, ОАО «Газпромрегионгаз» и филиалами.

Данное предприятие занимается обслуживанием газопровода по Орловской области. В ведомстве ОАО «Газпромрегионгаз» находятся 8 перекачивающих станций, десятки пропускных станций, сотни километров газопровода, за всем этим следят ЭВМ, которыми управляет персонал ОАО «Газпромрегионгаз». Одной из важнейшей задачи этого предприятия, является обеспечение безопасности транспортировки газа высокого и малого давления. На газовых магистралях находится большое число датчиков, которые собирают информацию и передают в диспетчерскую где они обрабатываются, анализируются и принимается решение, какое действие нужно предпринять, что бы избежать той или иной проблемной, конфликтной ситуации. За этой работой следит диспетчер, который занимается анализом поступающих сигналов, и от его умения, знания, опыта, зависит принятие правильного решения.

1.2 Описание организации деятельности ОАО «Газпромрегионгаз»

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

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

Главной статьей дохода ОАО «Газпромрегионгаз» является транспортировка газа внутри России, данное предприятие обслуживает город Орел и Орловскую область. Основная задача предприятия это:

-        эксплуатация газовых сетей;

-       оказание Информационно-консультативных услуг;

-       строительство объектов газоснабжения в населенных пунктах;

-       доставка газа конечному потребителю.

.3 Постановка задачи информационной системы поддержки принятия решения оператором

Процесс принятия решения на предприятии ОАО «Газпромрегионгаз» является довольно сложным. Поэтому очень важно быстро, а главное, правильно принимать различные управленческие решения. Разрабатываемая информационная система позволит значительно повысить эффективность и оперативность принятия решений в процессе управления транспортировки газа.

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

1.3.1 Функциональные требования к информационной системе

К основным функциональным требованиям можно отнести:

–    хранение и отображение всей необходимой информации о принятых решениях (полный список очередности операций, давление на входе в ГРП, температура, перепады на фильтрах, контроль выходного давления);

–       контроль за выполнением технологических операций;

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

–       формирование отчетов по процессу управления в виде графиков и диаграмм.

.3.2 Нефункциональные требования к информационной системе поддержки принятия решения

К нефункциональным требованиям можно отнести:

–      информационная система должна автоматически предусматривать блокировку некорректных действий пользователя;

–       информационная система должна обеспечивать приемлемое для нормального восприятия время отклика на запросы пользователя;

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

–       информационная система должна работать под управлением различных операционных систем как семейства Unix, так и Windows;

–      информационная система должна взаимодействовать с СУБД по протоколам, обеспечивающему интерфейс общения с сервером БД.

.4 Анализ существующих разработок поддержки принятия решения

Наиболее актуальным проблемам диспетчерской службы крупного газотранспортного или газодобывающего предприятия являются задачи обеспечения безопасности эксплуатации и улучшение управления процессами добычи и транспорта газаДля решения данных задач в дочерних Обществах ОАО «Газпромрегингаз» разрабатываются и внедряются системы телемеханики. Системы телемеханики обеспечивают удаленный контроль за территориально-распределенными объектами, информационную поддержку работы диспетчера, обеспечивают ретрансляцию на исполнительные устройства команд, поданных диспетчером телеуправления или телерегулирования. В штатном режиме работы объектов данные, полученные телемеханикой, являются основой для анализа режима работы технологических объектов и принятия решений по его оптимизации. В аварийных ситуациях данные, контролируемые телемеханикой, позволяют диагностировать разрывы трубопроводов и другие аварийные ситуации, определять место аварии осуществлять локализацию (отключение) аварийного участка.

Однако при использовании «традиционной» системы телемеханики и диспетчерского управления (SCADA-системы задачу анализа ситуации и принятия решений выполняет человек-диспетчер. В условиях необходимости принятия ответственных решений в ограниченные сроки (особенно при локализации аварий) и на основе анализа многокритериальных данных нагрузка на диспетчера существенно возрастает. Задача принятия решений усложняется при необходимости анализа технологического объекта сложной структур, например, закольцованной трубопроводной системы перемычками и различными вариантами потоков газа.

SCADA (аббр. от англ. Supervisory Control And Data Acquisition, Диспетчерское управление и сбор данных) - данное понятие обычно применяется к системе управления в промышленности: система контроля и управления процессом с применением ЭВМ. Процесс может быть технологическим, инфраструктурным или обслуживающим:

1)   Технологические процессы включают - производство, выработку энергии, конструирование, переработка. Может протекать в непрерывном, пакетном, периодическом или дискретном режимах.

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

)        Процессы в сфере обслуживания имеют как частную так и общественную стороны - здания, аэропорты, корабли и космические станции. Они контролируют и управляют HVAC, доступом и потреблением энергии.

Основными компонентами системы SCADA являются следующие подсистемы:

1)   Человеко-машинный интерфейс (HMI, англ. Human Machine Interface) - инструмент, который представляет данные о ходе процесса человеку оператору, что позволяет оператору контролировать процесс и управлять им.

2)      Диспетчерская система - собирает данные о процессе и отправляет команды процессу (управление).

)        Абонентский оконечный блок, либо УСО (RTU, англ. Remote Terminal Unit), подсоединяемый к датчикам процесса. Преобразует сигнал с датчика в цифровой код и отправляет данные в диспетчерскую систему.

)        Коммуникационная инфраструктура для реализации промышленной сети.системы решают ряд задач:

1)     Обмен данными с УСО (устройства связи с объектом, то есть с промышленными контроллерами и платами ввода/вывода) в реальном времени через драйверы.

2)      Обработка информации в реальном времени.

)        Отображение информации на экране монитора в удобной и понятной для человека форме.

)        Ведение базы данных реального времени с технологической информацией.

)        Аварийная сигнализация и управление тревожными сообщениями.

)        Подготовка и генерирование отчетов о ходе технологического процесса.

)        Осуществление сетевого взаимодействия между SCADA ПК.

)        Обеспечение связи с внешними приложениями (СУБД, электронные таблицы, текстовые процессоры и т. д.). системы позволяют разрабатывать АСУ ТП в клиент-серверной или в распределенной архитектуре.

Иногда SCADA-системы комплектуются дополнительным ПО для программирования промышленных контроллеров. Такие SCADA-системы называются интегрированными и к ним добавляют термин SoftLogіс.

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

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

Задачами СППР являются:

-    помощь диспетчеру в анализе текущего режима работы объекта;

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

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

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

-    давление на входе в ГРП;

-       контроль выходного давления;

-       перепад на фильтре;

-       t- газа на входе в ГПР;

-       давление в трубе;

-       температура в помещении;

-       датчик проникновения «Свой - Чужой»;

-       датчик утечки газа.

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

В составе СППР являются входит ряд модулей.

База данных Подсистемы глубокого архива (ПГА), реализованная средствами СУБД InterBase. Подсистема глубокого архива предназначена для обеспечения информационных обменов между разнородными источниками и потребителями информации СППР, и представления входных и выходных данных СППР в удобном для обработки и визуализации виде;

Рисунок 1 - Общая структура системы телеметрии.

База знаний СППР (СУБД InterBase). В базе знаний хранятся заранее разработанные рекомендации по действиям диспетчера в различных аварийных ситуациях;

Сигнальная подсистема СППР. Сигнальная подсистема постоянно проводит мониторинг данных, поступающих от системы телемеханики и хранящихся в БД ПГА. Если имеются данные, удовлетворяющие критериям возможного разрыва, сигнальная подсистема определяет участок разрыва и выводит на экран АРМ диспетчера рекомендации по ликвидации аварии для текущего режима работы коллектора.

Обобщенная структура Диспетчерского пункта с системой поддержки принятия решений показана на рисунке 7. Стрелками показаны информационные потоки, циркулирующие внутри и вне системы.

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

Входными данными для СППР являются:

-    данные реального времени от Системы телемеханики Межпромыслового коллектора: давления газа в точках замера, положение телемеханизированных кранов, информация о месте и времени обнаружения волн давления (13 контролируемых пунктов телемеханики);

-       данные ручного ввода от Диспетчерского пункта СТМ МПК - положение нетелемеханизированных кранов. Как отмечалось выше, в настоящий момент объем телемеханизации составляет около 30%. Однако в базе данных реального времени присутствуют все краны коллектора. Состояние нетелемеханизированных кранов вводится диспетчером ЛПУ вручную по результатам мониторинга коллектора службой ЛЭС;

-       данные реального времени от информационно-справочной системы диспетчерского управления (ИС ДУ) установками комплексной подготовки газа (УКПГ);

-       режим работы газоперекачивающих агрегатов (ГПА), положение запорной арматуры Узлов замера газа(УЗГ), давление, температура, расход газа, данные ручного ввода по сторонним поставщикам газа в коллектор. Данные вводятся диспетчером с 2-часовой или суточной периодичностью;

-       нормативно-справочная информация (НСИ) о топологии МПК, геометрии участков коллектора, типах и параметрах ГПА на УКПГ. НСИ используется для построения математической модели коллектора;

-       «база знаний» - заранее подготовленный набор инструкций по действиям диспетчера в различных нештатных ситуациях, в зависимости от текущего режима работы МПК. В инструкциях учитываются знания о всех возможных режимах работы МПК на данный момент, и предыдущий опыт действий персонала в аналогичных ситуациях.

Схема входных информационных потоков СППР приведена на Рисунке 2.

Рисунок 2 - Схема информационных потоков СППР

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

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

1.5 Организационная структура предприятия ОАО «Газпромрегионгаз»

Организационная структура предприятия ОАО «Газпромрегионгаз» является централизованной. Высшим органом управления на данном предприятии является директор, в его подчинении находится главный бухгалтер, заместитель и главный инженер (рисунок 3). К главному бухгалтеру относится отдел бухгалтерии. Первому заместителю подведомственны такие отделы, как: планово-экономический отдел, отдел информационных технологий и связи, отдел капитального строительства и т.д. В подчинении главного инженера: Центрально диспетчерская служба (ЦДС), Районо - Эксплуатационная служба, Производственно - Технический отдел и т.д., в ЦДС также есть свой начальник, в его ведении находятся: диспетчер, аварийные службы. По сменно целые сутки на данном предприятии работают: диспетчер (3 человека), аварийные бригады (их 4, по 5 человек), охрана предприятия.

1.6 Описание модели процессов предметной области

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

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

·   каковы основные функции, выполняемые ИТ-службой?

·   кто или что является объектом выполняемых работ?

Рисунок 3 - Организационная структура предприятия

·   откуда собираются данные о проделанной работе?

·   кто ответственный за сбор и предоставление отчетов?

·   каким образом производиться сбор данных для статистических отчетов по работе с базой данных?

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

На процессы, протекающие в ИТ-службе, выделим следующие точки зрения:

·   главный инженер;

·   диспетчер;

·   сотрудник ИТ - отдела.

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

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

Для рассматриваемой предметной области было принято решение построить модель - модель «to-be» («как будет»).

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

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

Определим границы модели. Обычно они подразделяются на границы в ширину и в глубину. Отражением границы модели в ширину является контекстная диаграмма, представляющая собой связь системы с внешним миром. Глубина модели - число уровней её детализации.

Построим контекстную диаграмму (рисунок 4).

Контекстная диаграмма представляет основную функцию ИТ-службы ОАО «Газпромрегионгаз» - организация проведения операций по поддержки принятия решений.

Информация о присутствующих на контекстной диаграмме стрелках сведена в таблицу 1.

Для более детального рассмотрения процессов предметной области необходимо провести декомпозицию контекстной диаграммы. Полученная таким образом диаграмма представлена на рисунке 5. В результате декомпозиции было выделено 2 активности:

·    «Этап настройки системы»;

·   «Этап выбора решений».

В первую очередь, на основании данных для настройки системы (активность «Этап настройки системы»). Именно на основе данных для настройки будут осуществляться все дальнейшие этапы процесса производства.

Таблица 1 - Описание стрелок контекстной диаграммы

Название	Описание	Тип
Информация о ситуации	Информация о ситуации в конкретный момент времени	Входная
Данные для настройки системы		Входная
Нормативы организации	Различные приказы, предписания, постановления	Управляющая
Методы теории систем	Различные приказы, распоряжения, постановления и правила, касающиеся деятельности подразделения	Управляющая
Набор предлагаемых решений	Сабор предлагемых решений для принятия правильного решения оператором	Выходная
Операторы	Сотрудники подразделения ОАО «Газпромрегионгаз»	Механизм
ЭВМ	Электронно-вычислительная машина	Механизм

Следующим этапом деятельности является этап выбора решений. Работы, проходящие на данном этапе, отражены активностью «Этапы выбора решений». Основанием для проведения выбора решения является настройка системы, сформированное на предыдущем этапе. Это является наиболее важным подготовительным этапом производственной деятельности, поэтому необходимо провести декомпозицию соответствующей активности.

Теперь перейдем к декомпозиции активности «Этап настройки системы» (рисунок 6), которая нас и будет интересовать для автоматизации. Так как данная активность разбивается на три активности:

·   «Анализ проблемы»;

·   «Формулирование целей и задач»;

·   «Определение критериев».

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

На последнем этапе осуществляется определение критериев. Это делается для получения фактов и правил для правильного принятия решения.

 Декомпозиция блока «Определение критериев» представлена на рисунке 7.

 На ней имеются следующие активности:

·   «Ввод пользователем данных для форматирования правила»;

·   «Проверка данных введенных пользователем»;

·   «Сохранение правил в базе знаний».

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

Декомпозиция блока «Этап выбора решений» представлена на рисунке 8.  Этап выбора решений включат в себя 3 наиболее важных стадии:

·   «Формирование множества альтернатив»;

·   «Анализ альтернатив»;

·   «Формирование управляющих воздействий».

·     На первом шаге происходит формирование множества вариантов решения данной проблемы, активность «Формирование множества альтернатив», на следующем этапе активности мы производим анализ сформированных альтернатив, выбираем наиболее подходящий вариант принятия решения, активность «Анализ альтернатив». Далее на основе выбранного варианта производим формирование управляющего воздействия оказываемого на систему, которое отражено активностью «Формирование управляющих воздействий».

Произведем, декомпозицию блока «Формулирование множества альтернатив» которая представлена на рисунке 9.

На ней имеются следующие активности:

- «Определить тип ситуации»;

«Определить возможные альтернативы».

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

Декомпозиция блока «Анализ альтернатив» представлена на рисунке 10

На ней имеются следующие активности:

«Определить критерии для данных параметров»;

«Извлечь из базы данных электронные значения параметров»;

     - «Сформировать список альтернатив удовлетворяющих критериям»

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

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

2. Разработка информационной системы поддержки принятия решений оператором при управлении транспортировкой газа

Выделив основные требования к разрабатываемой системе, перейдем к проектированию основных составляющих. Так как поставленные требования предусматривают создание довольно мощной информационной системы, в рамках данной дипломной работы будет заложена основа системы с реализацией большинства функций. Концептуализацию предметной области будем проводить средствами Erwin.

2.1 Концептуализация предметной области

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

-  «Пользователь» - информация о пользователе входящим в систему;

-       «Режим» - выбор режима, в котором пользователь входит в систему;

-       «История» - история произошедших событий в системе;

-       «Правило» - правило, используемое в системе;

-       «Мероприятие» - реакция на возникшую ситуацию;

-       «Условие» - часть правила входящее в условие;

-       «Параметр» - набор критериев используемых в системе;

-       «Знак»  - математическое значение (>,<,=>,<=,=).

Результаты анализа основных атрибутов, а также описание их взаимосвязи с моделью процессов предметной области (ППО) сведем в таблицу 2, приведенную ниже.

Таблица 2 - Атрибуты сущностей и их взаимосвязь с моделью ППО

Сущность		Атрибут		Описание		Тип
1		2		3		4
Пользователь		логин		вводимый логин		Текстовый
		пароль		вводимый пароль		Текстовый
		режим администратора		вход в систему в режие администратор		Целое
		режим аналитика		вход в систему в режима аналитик		Целое
		режим диспетчера		вход в систему в режиме диспетчер		Целое
Режим		номер режима		суррогатный ключ, задающий режим		Целое
		имя режима		название режима		Текстовый
История		дата и время		момент времени в который происходит событие		Дата и время
		номер правила		правило которое сработало		Целое
		номер меры		номер меры принятой в отвер на событие		Целое
		номер режима		в каком режиме находился пользователь в момент возникновения события		Целое
		логин		имя пользователя		Текстовый
		описание события		комментарий к событию		Текстовый
	Правило		номер правила		идентификационный номер правила		Целое
			имя правила		имя применяемого правила		Текстовый
	Мероприятие		номер меры		суррогатный ключ, задающий мероприятие		Целое
			описание меры		текстовое описание мероприятия		Текстовый
	Условие		номер условия		идентификационный номер условия		Целое
			номер порогового значения		суррогатный ключ, задающий номер порогового значения		Целое
			номер знака		идентификационный номер знака		Целое
			номер параметра		идентификацинный номер параметра		Целое
	Пороговое значение		номер порогового значения		суррогатный ключ, задающий номер порогового значения		Целое
			пороговое значение		максимально допустимое значение		Целое
	Знак		номер знака		идентификационный номер знака		Целое
			значение		имя значения		Текстовый
	Параметр		номер параметра		идентификациооный номер параметра		Целое
			название параметра		имя параметра		Текстовый

.2 Определение ограничений целостности

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

Архитектура приложения требует переноса максимального числа реализаций бизнес-правил на СУБД. Однако, поддержку некоторых ограничений на значения БД, продиктованных особенностями конкретной предметной области, реализовать в СУБД бывает затруднительно или невозможно. Поддержку таких ограничений целостности можно реализовать и на уровне клиентского приложения.

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

Таблица 3 - Ограничения на значения атрибутов

Сущность	Атрибут	Допустимые значения	Примечания
Знак	Номер знака	[0..4]	Всего может быть только пять состояний
Режим	Номер режима	[0..2]	Всего может быть только три режима

На атрибуты «Название параметра» и «Номер параметра» сущности «Параметр» также накладываются ограничения, но значения этого атрибута не заносятся пользователем, а присутствуют в БД с момента ее генерации.

Атрибут «Название параметра» может принимать следующие значения:

-        «Давление на входе»;

-       «Давление среднее»;

-       «Давление на фильтре 1»;

-       «Давление низкое»;

-       «Перепад на фильтре 2»;

-       «Газ, %».

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

Стратегии ограничения целостности приведем в таблице 4.

Таблица 4 - Основные стратегии ограничения целостности БД для связей и категорий

Действие	Идентифицирующая связь	Неидентифицирующая связь
Вставка родителя	---	---
Вставка потомка	Запрещающая	Запрещающая
Изменение родителя	Запрещающая	Каскадная
Изменение потомка	Запрещающая
Удаление родителя	Каскадная	Запрещающая
Удаление потомка	---	---

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

Так, например, для связей «Документ-Подразделение», «Документ-Компьютерная_техника» на изменение родителя установлена запрещающая стратегия.

Таблица 5 - Неосновные стратегии ограничения целостности БД для идентифицирующих и неидентифицирующих связей

Действие	Идентифицирующая связь	Неидентифицирующая связь
Изменение родителя	Каскадная	Запрещающая
Удаление родителя	Запрещающая	Каскадная

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

Для связей «Условие-Правило», «Правило-Мероприятие» установлена запрещающая стратегия на удаление. В первом случае такую стратегию можно объяснить следующим образом: невозможно удалить условие, если оно содержится в любом правиле, не удалив предварительно это правило. В другом случае - невозможно удалить мероприятие, не отменив его для соответствующего правила.

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

Часть проверок на корректность перенесена на уровень пользовательского приложения. При концептуальном проектировании схемы БД, на значения ряда атрибутов были наложены дополнительные ограничения целостности. Ограничения на значения других атрибутов реализуем при помощи предложения CHECK и включим в состав описания полей таблиц БД при проектировании ее структуры. Так в таблице «Условие» на поле «Номер параметра» наложено следующиее ограничение:

CHECK (Номер параметра >=0 AND Номер параметра <=6).

Стратегии ограничения целостности БД для идентифицирующих и неидентифицирующих связей реализованы при помощи триггеров. СУБД InterBase по умолчанию поддерживает запрещающую стратегию ограничения целостности на удаление и изменение родителя, а также вставку ребенка. Поэтому такие стратегии не нуждаются в построении дополнительных триггеров. Однако все остальные стратегии нуждаются в построении соответствующих триггеров. CASE-средство ERWin генерирует стандартные тексты триггеров для реализации каскадных изменений, которыми мы и воспользуемся. С помощью триггеров мы реализуем дополнительные ограничения на значения полей проектируемой БД. Это применимо в следующих случаях:

-    при генерации первичного ключа;

-       при вставке текущего пользователя системы в БД;

-       при добавлении текущей даты;

-       при каскадной вставке записей.

При добавлении записи в таблицу «Условие» генерируется первичный ключ, и в эту таблицу заносится информация о пороговом значении из таблицы «Пороговое значение».

Для сущностей «Правило», «Условие» и «Пороговое значение» были введены суррогатные ключи. Их значение определяется при помощи генератора в специальном триггере:

CREATE TRIGGER сур_ключ FOR таблицаINSERT

 New.идентификатор = gen_id(генератор, 1)

End

Для работы такой конструкции сначала требуется создать генератор с именем «генератор»:GENERATOR генератор

Затем нужно присвоить ему первоначальное значение:

SET GENERATOR генератор TO 1.

Первоначальное значение генератора 1 мы сделали для удобства, чтобы все номера имели положительные значения.

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

2.3 Выбор целевой СУБД

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

поддержка реляционной модели баз данных;

- поддержка стандарта SQL (Structured Query Language);

- достаточное быстродействие;

достаточная надежность.

Вышеперечисленным требованиям в полной мере отвечает система InterBase 6.5: Client and Server. Кроме того, данная система обладает рядом других достоинств:

· поддержка архитектуры «Клиент/Сервер»;

· наличие средств оптимизации производительности сервера (настройки, статистика);

· автоматическая оптимизация запросов;

· возможность создания хранимых процедур и представлений;

· наличие драйвера ODBC, обеспечивающего связь баз данных с клиентскими приложениями.

Выбор СУБД InterBase 6.5: Client and Server в качестве средства реализации базы данных повлек за собой необходимость адаптации к ней концептуальной схемы. Кроме того, в соответствие с типами, определенными для атрибутов в процессе логического проектирования, из всех типов, поддерживаемых СУБД InterBase 6.5: Client and Server, для целочисленных атрибутов были выбраны типы «integer», а для атрибутов символьных типов - тип «varchar» с указанием максимального числа символов в строке.

В результате проведенных работ была построена физическая модель данных, ориентированная на работу под управлением СУБД Interbase 6.5 (приложение А).

.4 Алгоритмы работы системы

Опишем основные алгоритмы, реализованные в системе. На рисунке 12 изображена схема алгоритма действий диспетчера. В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос SELECT с определёнными условиями для сущностей «Условие-Правило», «Условие», «Правило», «Пороговое значение».

На рисунке 13 изображена схема алгоритма добавления нового пользователя. В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос UPDATE с определенными условиями для сущности «Пользователь».

Рисунок 13 - Схема алгоритма добавления нового пользователя

Рисунок 12 -Схема алгоритма действий диспетчера

На рисунке 14 изображена схема алгоритма изменения данных пользователя. В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос UPDATE с определенными условиями для сущности «Пользователь».

Рисунок 14 - Схема алгоритма изменения данных пользователя

На рисунке 15 изображена схема удаления существующего пользователя, В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос DELETE с определенными условиями для сущности «Пользователь».

Рисунок 15 - Схема удаления существующего пользователя

На рисунке 16 изображена схема работы алгоритма добавление нового условия. В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос INSER с определенными данными для сущности «Условие».

Рисунок 16 - Схема добавления нового условия

На рисунке 17 изображена схема удаления выбранного правила. В ходе выполнения осуществляется взаимодействие с базой данных. «Запрос 1» представляет собой SQL запрос DELETE с определенными данными для сущности «Правило».

Рисунок 17 - Схема удаления выбранного правила

2.5 Проектирование пользовательского интерфейса

В процессе разработки диалога с пользователем, как правило, выделяют ряд состояний системы, в которых она остается неизменной и пользователь может выполнять некоторые действия.

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

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

Рисунок 18 - Транзитивная сеть, описывающая логику диалога системы с пользователем

Если произошел ввод идентификатора диспетчер, то система переходит в режим подсети диспетчер, Логика диалога диспетчера с программой отражена на рисунке 19.

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

Рисунок 19 - Транзитивная сеть, описывающая логику диалога системы с диспетчером

Если был осуществлен вход под идентификатором администратор, то логика диалога будет следующая (рисунок 20)

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

Рисунок 20 - Транзитивная сеть, описывающая логику диалога системы с администратором

Если произошел вход в систему под идентификатором аналитик, то транзитивная сеть, описывающая логику диалога, будет представлена на следующем рисунке 21

Здесь описаны переходы на окно ввода имени нового правила, удаление существующего правила и на окно конструктора нового правила, выход из подсети и переход на форму регистрации.

Рисунок 21 - Транзитивная сеть, описывающая логику диалога системы с аналитиком.

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

Таблица 6 - Описание состояний транзитивной сети

	Состояние	Описание
	1	2
	S0	Стартовое состояние, пользователь вводит логин и пароль. Режим работы
	F0	Конец. Финальное состояние. Завершаем работу программы
	SD	Открыта основная форма - Диспетчер
	SD1	Отображена вкладка - История событий
SD2		Открыто окно Word, в котором отображена история событий
FD		Выход из системы, закрытие сеанса - Диспетчер
Sadm		Открыта основная форма - Администратор
Sadm1		Отображена форма редактирования учетных записей
Sadm2		Отображено модальное окно ввода нового пароля
Sadm3		Отображено модальное окно подтверждения удаления пользователя
Sadm4		Отображено модальное окно добавления нового пользователя
SA		Открыта основная форма - Аналитик
SA1		Окно ввода имени для объединенного правила
FA		Выход из системы, закрытие сеанса - Аналитик
Fadm		Выход из подсети - Администратор
SA2		Отображение окна подтверждения удаления правила
SA3		Окно - Конструктор нового правила

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

Таблица 7 - Описание переходов транзитивной сети

№ дуги	Входной сигнал				Реакция на входной сигнал
1	2				3
1	Нажата кнопка "Вход"				Отказ от входа в систему, предложение ввести логин и пароль и режим работы
2	Введены логин и пароль для режима "Диспетчер"				Переход системы в режим "Диспетчер", отображение главного окна диспетчера
3	Введены логин и пароль для режима "Администратор"				Переход системы в режим "Администратор", отображение главного окна администратора
4	Введены логин и пароль для режима ""Аналитик"				Переход системы в режим "Аналитик ", отображение главного окна аналитика
5,6,7,8	Нажата кнопка закрытие приложения				Выход из приложения
9	Нажата кнопка выбор из меню "Изменение частоты опроса"				В основной форме диспетчер изменяет частоту опроса
10	Нажата кнопка "Опросить сейчас"				В основной форме диспетчера обновляются параметры
11,12,13,14,15,16,17	Нажатие на элемент списка ГРП				Обновление таблиц в основном окне
18	Выбор вкладки история события				Отражена история события в виде таблицы
19,20,21,22,23,24,25	Установлена отметка на соответствующей ГРП				Отобразить события в таблице отмеченных ГРП
26,27,28,29,30,31,32	Снята отметка с определения ГРП			Скрыть не отмеченное событие связанное с ГРП
33	Выбор вкладки "Главная форма"			Переход на главную форму "Диспетчер"
34,35	Нажатие кнопки "Экспорт"			Открыт текстовый процесс Word
36,37,38	Нажатие кнопки "Сменить пользователя"			Возврат на форму выбора Логина и пароля и режим работы
39,4	Зактрытие текстового окна Word			Переход на ранее активную вкладку
41,42	Выход из подсети "Диспетчер"			Переход на форму выбора логина ,пароля и режима работы
43	Ввод данных о СУБД			Обновление данных на форме
44	Ввод имени БД			Обновление имени БД на форме
45	Ввод вида источника данных			Обновление вида источников на форме
46	Нажата кнопка "Работа с учетными записями"			Открытие формы "редактор учетных записей"
47	Нажата кнопка "Изменить пароль"			Откритие окна изменения пароля
48	Нажата кнопка "Удалить"			Открытие окна удаления пользователя
49	Нажатак кнопка "Добавить"			Открытие окна добавления нового пользователя
50	Выделение строки в таблице учетных записей			Подсвечивание выбранной учетной записи
51	Введен новый пароль в поле ввода			Отобразить спецсимволом символ пароля
52	Нажата кнопка "OK"			Пароль изменен
53	Нажата кнопка "Отмена"			Пароль остается без изменений
54	Нажата кнопка "ОК"			Учетная запись удалена
55	Нажата кнопка "Отмена"			Не удалена учетная запись
56	Установлена метка			Установлена метка администратор
57	Установлена метка			Установлена метка аналитик
58	Установлена метка			Установлена метка диспетчер
59	Сната метка			Снята метка администратор
60	Сната метка			Снята метка аналитик
61	Сната метка			Снята метка диспетчер
62	Введен логин			Отображен логин новой учетной записи
63	Нажата кнопка "ОК"			Пользователь добавлен
64	Нажата кнопка "Отмена"			Пользователь не добавлен
65	Выбрать первую строку из таблицы			Подсвечивание выделения в таблице
66	Снять выделение с строки таблицы			Снять выделение с таблицы
67		Нажата кнопка объединить в основной форме аналитика	Отображено окно ввода для добавления правила
68,73		Нажата кнопка "ОК"	Обновить список правил в таблице
69,74		Нажата кнопка "Отмена"	Отобразить таблицу правил без изменений
71, 70		Выход из подсети "Администратор"	Переход на ввод логина, пароля и режима входа
72		Нажата кнопка удалить	Отображение окна подтверждения
75		Выход из подсети "Аналитик"
76		Нажата кнопка ввести новое правило	Открыто окно конструктора нового правила
77		Нажата кнопка "Готово"	Добавлено новое правило
78		Нажата кнопка "Отмена"	Отображение прежнего списка правил
79		Отображено новое название	Отображение названия
80		Ввод нового названия	Введено новое название правила
81		Выделить строку в таблице	Подсветить выбранную строку
82		Выбрать параметр	Отобразить выбранный параметр
83		Выбрать значение	Отобразить выбранное значение
84		Выбрать знак	Отобразить выбранный знак
85		Добавить условие	Внесение нового условия в таблицу условий
86		Нажатие кнопки изменить	Отобразить данные в полях параметров ,знак, значение соответсвующее выделенному условию

На рисунке 22 изображена экранная форма программного приложения с помощью, которого происходит вход в систему, требуется ввести логин, пароль, режим входа.

Рисунок 22 - Экранная форма входа в систему

На рисунке 23 изображена экранная форма подсети диспетчер. На форме отображена главная страница приложения, справа присутствует список ГРП, при выделении конкретной ГРП появляется список, в котором отображено время опроса и данные.

Рисунок 23 - Экранная форма подсети диспетчер

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

На рисунке 24 изображена экранная форма программного приложения диспетчер, вкладка история событий, которая отражает запрошенные данные в соседнем поле на конкретной выбранной ГРП.

Рисунок 24 - Экранная форма вкладки история событий

Рисунок 25 -Экранная форма вкладки тревожного сообщения

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

На рисунке 26 отображена главное окно вкладки администратор, на нем администратору предлагается ввести имя сервера БД, имя БД и вид источника данных, также есть кнопка работа с учетными записями рисунок 27, при нажатии которой администратор может производить ряд действий:

добавление новой учетной записи;

удаление существующей учетной записи;

изменение пароля у существующей учетной записи;

При добавлении учетной записи администратору предлагается ввести логин нового работника и отметить галочкой его права (рисунок 28).

Рисунок 26 - Главная экранная форма вкладки администратор

Рисунок 27 - Главная экранная форма вкладки администратор

Рисунок 28 -Экранная форма вкладки добавления нового пользователя

Для того, что бы изменить пароль необходимо выбрать из списка работника и нажать на кнопку сменить пароль, откроется экранная форма, на которой необходимо ввести новый пароль и подтвердить, нажав на кнопку ОК (рисунок 29).

Рисунок 29 - Экранная форма изменения пароля

На экранной форме 30 отражено окно, с помощью которого аналитик добавляет, удаляет, изменяет, правила. На форме отображен список правил и критерии.

Рисунок 30 - Экранная форма вкладки аналитик

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

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

Рисунок 31 - Экранная форма объединения правила

Рисунок 32 - Экранная форма редактирования правил

3. Обоснование экономической эффективности разработки информационной системы для ОАО «Газпромрегионгаз»

.1 Необходимость оценки экономической эффективности проекта

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

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

Основным эффектом от внедрения разрабатываемой информационной системы будет экономический. Он вызван:

-      повышением качества принимаемых решений вследствие внедрения ИС;

-       экономей затрат труда диспетчера;

-      уменьшением количества ошибок вследствие уменьшения человеческого фактора.

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

3.2 Оценка затрат на разработку и внедрение собственной информационной системы

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

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

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

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

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

,                                        (4.1)

где  - общая трудоемкость в часах;

 - трудоемкость i-го этапа проектных работ.

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

Сумма затрат на оплату труда определяется по формуле:

                                          (4.2)

где  - затраты на оплату труда исполнителей, руб.;

 - трудоемкость i-го этапа проектных работ;

- часовая тарифная ставка  исполнителя  j-ой    категории,

выполняющего i-ый этап работ, руб.;

Учитывая, что по данным бухгалтерии часовая тарифная ставка начальника производства составляет 130 рублей, а инженера-программиста -

рублей, получим сумму затрат на оплату труда по формуле (8):

 = 81736 (руб).

Таблица 8 - Распределение трудовых затрат при разработке АС

Этап проектирования		Количество н-часов		Исполнитель	Часовая тарифная ставка, руб.			З/п, руб.
1		2		3	4			5
Сбор, формулирование и анализ требований к ИС		24		нач. производства	130			6240
		24		инженер-программист	45			2160
Концептуальное и логическое проектирование		24		инженер-программист	45			1080
Физическое проектирование и реализация:		212		инженер-программист	45			9540
- проектирование БД		80		инженер-программист	45			3600
	- проектирование приложения		40	инженер-программист		45	1800
	- проектирование программного интерфейса		92	инженер-программист		45	4140
	тестирование, настройка		40	нач. производства		130	10400
			40	инженер-программист		45	3600
	Технико-экономическое обоснование эффективности ИС		24	инженер-программист		45	1080
			4	консультант по экономической части		188	440
	Анализ соблюдения норм безопасности труда		16	инженер-программист		45	720
			4	консультант по БЖД		96	640
	Руководство этапами дипломного проектирования		23	руководитель дипломной работы		188	2640
	ИТОГО		435				48080

В результате расчетов общая трудоемкость равна:  = 435 н-часов.

Далее выполним оценку затрат, связанных с эксплуатацией ЭВМ в процессе проведения проектных работ. При этом немаловажным фактором является то, что выполнение работ на этапах машинного проектирования производилось с использованием 1 компьютера.

Затраты на эксплуатацию ЭВМ вычисляются по формуле:

,   (4.3)

где - затраты на эксплуатацию ЭВМ, руб.;

 - общие стоимостные затраты, руб.;

 - стоимость амортизации машин, руб.

Общие стоимостные затраты определяются согласно формуле:

,      (4.4)

где  - стоимость машинного часа ЭВМ, руб.;

- время эксплуатации ПЭВМ, н/часов.

Стоимость машинного часа ЭВМ вычислим, исходя из следующих данных: мощность используемой ЭВМ - 0,5 кВт, стоимость электроэнергии - 2,28 руб/кВт.

 (руб).

Также произведем анализ затрат машинного времени по этапам проектирования. Результаты представлены в таблице 9.

Таблица 9 - Расчет времени эксплуатации ЭВМ при проектировании  автоматизированной системы

Этап проектирования	Количество н- часов
Сбор, формулирование и анализ требований к ИС	48
Концептуальное и логическое проектирование	24
Проектирование базы данных	80
Взаимодействие с базой данных	40
Разработка компонентов информационной системы	92
Тестирование, настройка	80
Технико-экономическое обоснование эффективности ИС	28
Руководство этапами дипломного проектирования	24
Итого	416

Таким образом,  н - часов. Подставив полученные данные в формулу (4.4), получим:

 (руб).

Стоимость амортизации машины определяется по формуле:

,         (4.5)

где  - часовая сумма амортизации машин, руб.

Расчет часовой суммы амортизации ЭВМ произведем, исходя из следующих данных: стоимость компьютера - 20000,00 руб., количество рабочих дней в году - 313 дней, количество рабочих часов в дне - 8 часов, срок эксплуатации ЭВМ - 5 лет.

 (руб).

В связи с этим стоимость амортизации ЭВМ будет равна:

 (руб).

Подставив рассчитанные значения  и  в формулу (4.3), определим величину затрат на эксплуатацию ЭВМ в процессе проведения проектных работ:

 (руб).

Для расчета общей стоимости затрат на разработку информационной системы воспользуемся формулой:

,      (4.6)

где     - общие затраты на разработку, руб.

 (руб).

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

Затраты можно рассчитать по формуле:

 

С_В = С_У + С_ОБ,                        (4.7)

где С_В - стоимостные затраты на внедрение ИС, руб.;

С_У - величина затрат на установку ИС, руб.;

С_ОБ - стоимость обучения персонала эксплуатации ИС, руб.

Величина затрат на установку АС на предприятие определяется согласно формуле:

 

С_У = k · Т_У · p_А · (1 + K),                  (4.8)

где k - количество ПЭВМ, на которых планируется установка АС;

Т_У - трудоемкость установки АС, ч;

p_А - часовая тарифная ставка администратора ОИТ, руб.;

К - коэффициент заработной платы из формулы (4.2).

Трудоемкость установки проектируемого программного средства на одном компьютере составляет в среднем 0,15 ч., а один час работы администратора стоит 50 рублей. Программный продукт будет установлен на 1 ПЭВМ. Рассчитаем величину С_У:

C_У = 1 · 0,15 · 50,00 · (1,0 + 0,7) = 12,75 (руб).

Стоимость обучения работников предприятия и эксплуатации ИС С_ОБ, руб., определяется, как:

 

С_ОБ = gr ·Т_ОБ · p_ОБ · (1 + K)+ p · Т_ОБ · (1 + K),      (4.9)

где gr - количество обучающихся групп;

Т_ОБ - трудоемкость обучения персонала АС, ч;

p_ОБ - тарифная ставка работника, проводящего обучение, руб.;

К - коэффициент заработной платы из формулы (4.2);

р - тарифная ставка работника, проходящего обучение.

Учитывая, что один час работы диспетчера оплачивается в размере 130 рублей, а системного администратора - в размере 50 рублей, основе формулы (4.9), получим значение величины C_ОБ:

C_ОБ = 1 · 10 · 50 · (1,0 + 0,7) + 130 × 10 · (1,0 + 0,7) = 3910 (руб).

Таким образом, величина затрат на установку ИС и обучение сотрудника составляет 3910 руб.

Сложив все полученные значения получим, что общая сумма по разработке и внедрению программного продукта будет равна 168981,25

.3 Оценка трудовых затрат при базовом и проектируемом варианте слежения за параметрами

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

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

Трудовые затраты при ручном слежении, , н-часов, определяются следующим образом:

                         (3.8)

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

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

Стоимостные затраты на оплату труда исполнителей и на отчисления с заработной платы по базовому варианту определяются следующим образом:

   (3.9)

где     -  затраты на оплату труда исполнителей, руб.;

 - средняя часовая тарифная ставка исполнителя, руб. (в расчетах );

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

Стоимость амортизации ЭВМ определяется по формуле:

                                                                                          (3.10)

где - часовая сумма амортизации, вычисляемая по формуле (3.6) (в расчетах руб.).

Стоимость обработки данных с помощью ЭВМ определяется по формуле:

                                                                                      (3.11)

где - стоимость машинного часа ЭВМ (в расчетах  = 1,14 руб/ч, так как используемая ЭВМ имеет мощность 0,5 кВт, а стоимость электроэнергии принимается равной 2,28 руб/кВт).

Общие стоимостные затраты при ручном варианте рассчитывается по следующей формуле:

                                                                              (3.12)

Проведем анализ работ, подлежащих автоматизации, и рассчитаем их трудоемкость с использованием формулы (3.8).

Результаты оценки трудовых затрат при базовой поддержке принятия решения приведены в таблице 10.

Таблица 10 - Оценка трудовых затрат при полуавтоматизированной обработке информации

Наименование операции	Трудоемкость на на одну операцию (н-час)	Количество операций в год (шт.)	Трудоемкость на все операции (н-час)
Ведение истории сбоев	2	12	24
Ведение журнала отправки аварийных бригад	2	33	66
Проверка состояния параметров газоснабжения	0,2	4380	876
Итого:	-	-	966

Из таблицы 10 получаем, что общая трудоемкость ручного варианта составляет  = 966 н-часа. Подставив это значение в формулы (3.9), (3.10) и (3.11), получим следующие значения:

С помощью формулы (3.12) рассчитываем общие стоимостные затраты при полуавтоматизированном слежении за параметрами:

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

Для того чтобы оценить трудоемкость операции при автоматизированной поддержке принятия решения, воспользуемся приближенной оценкой. Будем исходить из возможностей разрабатываемой системы. Результаты анализа сведем в таблицу 11.

Таблица 11 - Объем работ при машинной обработке информации

Наименование операции	Трудоемкость на на одну операцию (н-час)	Количество операций в год (шт.)	Трудоемкость на все операции (н-час)
Ведение истории сбоев	1	12	12
Ведение журнала отправки аварийных бригад	0.30	33	9
Проверка состояния параметров газоснабжения	0.1	4380	438
Итого:	-	-	459

Итак, трудоемкость автоматизированного варианта обработки информации:

 459 н-часов

Заработная плата исполнителей при автоматизированной поддержке принятия решения и расходы на отчисления по заработной плате определяются по формуле (3.11):

Стоимость амортизации одной ЭВМ определяется по формуле (3.12):

Стоимость обработки данных с помощью ЭВМ определяется по формуле (3.13):

Общие стоимостные затраты, связанные с применением разрабатываемой подсистемы рассчитываются по формуле (3.14):

.4 Оценка экономической эффективности внедрения автоматизированной информационной системы поддержки принятия решений

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

-               показатель абсолютного снижения трудовых затрат;

-       коэффициент относительного снижения трудовых затрат;

-       индекс снижения трудовых затрат.

Абсолютное снижение трудовых затрат DТ, час., вычисляется по формуле:

DТ = Т₀ - Т₁,                                              (3.9)

где    Т₀ - трудовые затраты при ручной обработке информации;

Т₁ - трудовые затраты при автоматизированной обработке данных.

DТ = 966 - 459 = 507 ч.

Коэффициент относительного снижения трудовых затрат К_т определяется с помощью формулы:

К_т = DТ / Т₀ × 100%;                                   (3.10)

Подставив значения в формулу, получим: К_т =507/966×100%»52,3%.

Индекс снижения трудовых затрат У_т найдем по формуле:

У_т = Т₀ / Т₁;                                        (3.11)

Получим, У_т = 966 / 507 = 1,9.

К стоимостным показателям эффективности внедрения проекта относятся:

-     показатель абсолютного снижения стоимостных затрат;

-       коэффициент относительного снижения стоимостных затрат;

-       индекс снижения стоимостных затрат.

Абсолютное снижение стоимостных затрат DС, руб., определяется по формуле (3.18):

,                                                                                   (3.18)

где С₀ - стоимостные затраты при базовой технологии обработки информации, руб.;

С₁ - стоимостные затраты при автоматизированной технологии.

Таким образом, руб.

Коэффициент относительного снижения стоимостных затрат К_С вычисляется с помощью формулы (3.19):

,                                                                                (3.19)

Индекс снижения стоимостных затрат У_С определяется по формуле (3.20):

,                                                                                          (3.20)

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

Таблица 12 - Показатели эффективности внедрения подсистемы информационного обеспечения процесса обслуживания читателей

	Затраты		Абсолютное изменение затрат	Коэффициент изменения затрат	Индекс изменения затрат
	При базовой обработке	При планируемой обработке
Трудоемкость	966 н-часа	459 н-часа	507 н-часа	52,3	2,09
Стоимость	49159,74 руб.	23443,77 руб.	25715,97 руб.	52,3	2,09

Диаграммы на рисунках 33 и 34 отражает величину трудовых затрат, при полуавтоматизированном и автоматизированном способе выполнения операций, а также экономию трудовых затрат при внедрении ИС и экономию средств от внедрения разрабатываемой подсистемы поддержки принятия решений оператором.

Рисунок 33 - Диаграмма изменения трудовых затрат

Рисунок 34 - Диаграмма динамики стоимостных затрат

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

Для расчета срока окупаемости воспользуемся формулой (3.21):

,

(3.21)

где  - затраты на создание информационной системы,

DС - абсолютное снижение стоимостных затрат, руб.

Подставив данные в формулу (3.21), получим:

Итак, срок окупаемости разрабатываемой подсистемы составит приблизительно 8 месяца. В результате анализа полученных показателей, можно сделать следующие выводы относительно эффективности внедрения проектируемой информационной системы: эксплуатация системы позволит снизить трудовые затраты более чем на 50 процентов, а также повысить производительность труда в 2 раза. В связи с этим, применение разрабатываемой информационной системы поддержки принятия решения оператором следует признать целесообразным.

4. Безопасность жизнедеятельности

.1 Анализ условий труда оператора ЭВМ

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

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

ГОСТ 12.0.003-74 «Система стандартов безопасности труда. Опасные и вредные производственные факторы. Классификация» и СанПиН 2.2.2.542-96 «Гигиенические требования к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работы» применяются для определения санитарно-гигиенических требований к обеспечению безопасных условий труда пользователей видеодисплейными терминалами (ВДТ) и персональными компьютерами (ПК).

На основе СанПиН 2.2.2.542-96 были проанализированы требования к ВДТ и ПЭВМ, требования к помещениям, организация рабочих мест, а именно помещение, в котором находится рабочее место программиста.

На рисунке 35 представлен план помещения, которое располагается на 3-м этаже трехэтажного административного здания. Площадь помещения составляет 12 м² (длина - 4 м, ширина - 3 м). Высота потолка - 3,1 м. В данном помещении оборудовано 1 рабочее место, оснащенное ПК. Соответственно, площадь, приходящаяся на 1 рабочее место, составляет 12 м² (при нормативе 6 м²). Объем на 1 человека составляет 30 м³ (при нормативе 20 м³). Помещение удовлетворяет требования СанПиН.

Рисунок 35 - Схема помещения

Помещение не граничит с шумными помещениями, уровень шума не превышает 20 дБА.

Средняя температура воздуха в помещении составляет около 23˚С, относительная влажность воздуха - 40 %, скорость движения воздуха - 0 м/с. Помещение оборудовано системой отопления. Устройство кондиционирования воздуха не присутствует. Пол ровный и антистатический. Помещение имеет естественное и искусственное освещение. Естественное освещение осуществляется с помощью одного оконного проема. Имеется один источник искусственного освещения - светильник на потолке помещения. Естественный свет падает сбоку, слева.

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

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

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

Приэкранные фильтры и специальные экраны отсутствуют. На расстоянии 5 см от экрана и корпуса монитора при любом положении регулировочных устройств доза рентгеновского излучения - 57 мкр/час.

Напряженность электромагнитного поля на расстоянии 50 см от видеодисплейного терминала имеет значения:

-        электрическая составляющая - 5,4 в/м;

-       магнитная составляющая - 0,127 а/м;

-       напряженность электростатического поля - 12 кв/м.

ЭВМ оснащены жидко-кристаллическими дисплеями ViewSonic VA703b с диагональю экрана 17 дюймов. Конструкция дисплея ЭВМ обеспечивает поворот корпуса в горизонтальной плоскости на 30, а также на 180 градусов в вертикальной плоскости с возможностью фиксации в заданном положении. Органы управления на лицевой панели утоплены в корпус. Дисплей имеет сертификат соответствия гигиеническому стандарту ТСО’99.

Основной работой считается работа с ПЭВМ. Она занимает 85 % времени рабочего дня. Регламентируемые перерывы равны 60 минутам при восьмичасовом рабочем дне в зависимости от интенсивности нагрузок. Время работы без перерыва - 3,5 часов. Работы в ночное время не производятся.

Сведем данные анализа труда в таблицу 13.

Таблица 13 - Результаты анализа условий труда в помещении

Фактор условий труда	единицы измерения	Нормативное значение	Измеренное значение		Заключение соответствий
1	2	3	4		5
Коэффициент естественной освещенности		1,2	2,0		соответствует
Ориентация светопроемов		север, северо- восток	запад		не соответствует
Площадь на одно рабочее место	6	12		соответствует
Объем на одно рабочее место	куб.м.	20	33,6		соответствует
Высота помещения	М	4	2,8		не соответствует
Отопление		должно быть	имеется		соответствует
Кондиционирование воздуха		должно быть	не имеется		не соответствует
Температура воздуха	°С	18-23	23		соответствует
Относительная влажность воздуха	%	31-62	40		соответствует
Подвижность воздуха	м/с	не более 0,1	0		соответствует
Покрытие пола		антистати-ческое	антистати-ческое		соответствует
Уровень шума	дБА	65	20		соответствует
Наличие принтеров		не должно быть	имеются		не соответствует
Освещенность поверхности стола	лк	300-500	400	соответствует
Чистка оконных стекол и светильников	раз/год	2	3	соответствует
Падение естественного света		слева	слева	соответствует
Расстояние между боковыми поверхностями мониторов	м	не менее 1,2	1,2	соответствует
Наличие регулирующих устройств на оконных проемах		должны быть	имеются	соответствует
Расстояние от глаз до экрана ВДТ	мм	500-700	550	соответствует
Проведение влажной уборки	раз/неделя	7	2	не соответствует
Наличие углекислотного огнетушителя		должен быть	имеется	соответствует
Наличие аптечки		должна быть	имеется	соответствует
Высота рабочего стола	мм	725	700	соответствует
Пространство для ног:
Высота	мм	600	70	соответствует
Ширина	мм	500	750	соответствует
Глубина	мм	450	600	соответствует
Наличие подставок для ног		имеются	не имеются	не соответствует
Наличие пюпитров		должны быть	не имеются	не соответствует
Длительность работы за ЭВМ без перерывов	час	не более 2	8	не соответствует
Регламентированные перерывы	мин	30-70	60	соответствует

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

1.    Высота помещения не соответствует указанным нормативным значениям (3 м, при нормативе 4 м)

.      В помещении есть принтеры.

3.      В помещении отсутствует кондиционер.

.        Рабочее кресло не удовлетворяет нормам.

.        Высота рабочего стола не соответствует нормам.

.        Процентное соотношение работы на ПЭВМ ко всему рабочему дню не соответствует нормативам (85%, при нормативе 50%)

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

-      эффективная организация рабочего места программиста;

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

-       расчет пожарной безопасности.

4.2 Мероприятия по обеспечению БЖД

.2.1 Расчет кондиционера по избытку тепла

Проведенные исследования показали, что микроклиматические условия в помещении программиста в некоторые времена года не соответствуют нормам.

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

Объем помещения, V _помещ, м³, рассчитывается по формуле:

_помещ = А × В × H,                                        (5.1)

где А - длина помещения, м;

В - ширина, м;

С - высота, м.

Рассчитанный по формуле (5.1) объем помещения отдела бухгалтерии составил:

V _помещ = 4 × 3 × 2,8 = 33,6 м³.

Необходимый для обмена объем воздуха, V_вент, м³, определяется исходя из уравнения теплового баланса:

_вент × С( t_уход - t_приход ) × Y = 3600 × Q_избыт,,                   (5.2)

где    Q_избыт - избыточная теплота, Вт;

С - удельная теплопроводность воздуха, Дж/кг×К (1000 Дж/кг×К);

Y - плотность воздуха, мг/см (1,2 мг/см).

Температура уходящего воздуха, t_уход, ⁰С, определяется по формуле:

_уход = t_р.м. + ( Н - 2 ) × t,                                       (5.3)

где    t - превышение t на 1м высоты помещения, ⁰С (3 ⁰С);

t_р.м. - температура на рабочем месте, ⁰С (23⁰С);

Н - высота помещения.

t_приход = 16 ⁰С.

t_уход = 23 + ( 2,8 - 2 ) × 3 = 25,4 ⁰С.

Рассчитаем количество избыточного тепла, Q_избыт, Вт, по формуле:

_избыт = Q₁ + Q₂ + Q_.3 ,                                         (5.4)

где  Q₁ - избыток тепла от электрооборудования и освещения, Вт;

Q₂ - теплопоступление от солнечной радиации, Вт;

Q_.3 - тепловыделения людей, ВТ.

₁ = Е × р ,                                                            (5.5)

где    Е - коэффициент потерь электроэнергии на теплоотвод (Е=0,55);

 р - мощность, Вт.

Q₁ = 0,55 × 320=176 Вт.

Рассчитаем теплопоступление от солнечной радиации по формуле:

 

Q₂ =m × S × k × Q_c,                                                (5.6)

где    m - число окон;

S - площадь окна, м²;

k  - коэффициент, учитывающий остекление (k=0,6);

Q_c - теплопоступление от окон, Вт/м².

Q₂ =1 × 4 × 0,6 × 120 = 288 Вт.

Рассчитаем теплопоступление от людей по формуле:

 

Q₃ = n × q,                                                           (2.7)

где    q - теплопоступление от человека, Вт/чел.(100 Вт/чел);

n - число людей, чел.

Q₃ = 1 × 100 = 100 Вт.

После того, как мы рассчитали все необходимые параметры, можно рассчитать количество избыточного тепла:

Q_избыт = 176 + 288 + 100 = 564 Вт.

Из уравнения теплового баланса следует:

 м³/ч

Оптимальным вариантом является кондиционирование воздуха, то есть автоматическое поддержание его состояния в помещении в соответствии с определенным уровнем температуры независимо от изменения состояния наружного воздуха и условий в самом помещении.

С учетом рассчитанных значений и стоимостного фактора из всего многообразия предлагаемых в настоящее время систем кондиционирования воздуха можно порекомендовать кондиционер Daewoo серии OWB-054D. Мощность охлаждения кондиционера составляет 2 кВт.

Кондиционер рассчитан на комнату площадью около 20 м², а площадь помещения рассматриваемого отдела = 12 м². Стоимость данного кондиционера в среднем составляет 10000 рублей.

.2.2 Эргономический анализ рабочего места оператора ПЭВМ

Для примера проведем эргономический анализ рабочего места, с единственным принтером в аудитории. Чертеж рабочего места оператора ПЭВМ (вид спереди) представлен на рисунке 36.

Антропометрический анализ зоны обслуживания рабочего места производился с использованием ЭВМ.

Входными данными являются: рост оператора (175 см), основная рабочая поза (сидя).

На выходе программы получаем следующие данные:

-        размах рук D 156 см;

-        длина руки F 60 см;

         расстояние от сиденья до плеч B 51 см;

         высота сиденья 51 см;

         высота пространства для ног оператора 71 см;

         ширина пространства для ног оператора 52 см;

         глубина пространства для ног оператора 35 см;

         высота рабочей поверхности от сиденья 20 см.

Анализ существующих и предполагаемых габаритов рабочего места оператора представлен в таблице 14.

Рисунок 36 - Чертеж рабочего места, вид спереди

Обозначения:

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

- органы управления монитором;

- входной лоток принтера для бумаги;

- выходной лоток;

- органы управления принтером;

- клавиатура;

- манипулятор типа «мышь»;

, 9, 10 - ручки ящиков стола.

Рисунок 37 - Чертеж рабочего места, вид сверху

Таблица 14 - Анализ габаритов рабочего места оператора ПЭВМ

Показатели	Существующие, см	Рекомендуемые, см
Высота сиденья Е	44	51
Высота пространства для ног оператора N	74	71
Ширина пространства для ног оператора M	63	52
Глубина пространства для ног оператора	60	35
Высота рабочей поверхности от сиденья P2	31	20

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

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

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

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

На выходе получаем рекомендательные размеры, позволяющие на виде спереди вычертить зоны зрения (радиус, см):

-        зона мгновенного зрения R1 7,24;

-        зона эффективной видимости R2 14,74;

         зона удобного обзора R3 95,26.

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

Зона же удобного обзора покрывает всю рабочую область. В связи с эти рекомендуется поднять монитор на 17 см и сместить влево на 5 см.

4.3 Обеспечение устойчивости работы отдела в случае  возникновения чрезвычайных ситуаций

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

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

При эксплуатации ЭВМ возможны возникновения следующих аварийных ситуаций:

короткие замыкания;

повышение переходных сопротивлений в электроконтактах;

перенапряжение;

При возникновении аварийных ситуаций происходит резкое выделение тепловой энергии, которая может явиться причиной возникновения пожара. На долю пожаров, возникающих в эл. установках приходится 20%. Поэтому обязательно должны соблюдаться требования пожарной безопасности.

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

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

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

включение системы оповещения о пожаре;

включение системы пожаротушения;

отключение вентиляции;

включение систем дымоудаления.

Заключение

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

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

выбрана модель хранения данных всей необходимой информации по процессу управления, в качестве которой использовалась СУБД InterBase;

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

Список использованной литературы

1. Бурлак Г.Н. Экономические аспекты разработки и использования программного обеспечения [Текст] / Г.Н. Бурлак, В.А. Благодатских. - М.:МЭСИ, 2014. - 164 с.

. Марка Д. Методология структурного анализа и проектирования SADT [Текст]: Пер. с англ. / Д. Марка, К. МакГоуэн М.: 2013, - 240 с.

. Никитин С.А. Технико-экономическое обоснование дипломных проектов по разработке автоматизированных систем [Текст]: Учебно-методическое пособие / С.А. Никитин, О.И. Осипова, А.А. Федотов  - Орел:Академия ФАПСИ, 2013. - 80 с.

. Олькина, Е.В. Методические указания по оформлению пояснительных записок к дипломным, курсовым проектам (работам) и отчетов по практикам в соответствии с требованиями государственных стандартов [Текст] / Елена Викторовна Олькина. - Орел: ОрелГТУ, 2007. - 54с. - (Для спец. 080801, 230105, 230201).

. Олькина, Е.В. Методические указания по оформлению электронных материалов к дипломным, курсовым проектам (работам) и отчетам по практикам в соответствии с требованиями государственных стандартов [Текст] / Елена Викторовна Олькина, Вадим Николаевич Волков. - Орел: ОрелГТУ, 2012. - 21с. - (Для спец. 080801, 230105, 230201).

6.       Соммервилл И. Инженерия программного обеспечения, 6-е издание [Текст]: Пер. с англ. / И. Соммервилл. - М.: Издательский дом «Вильямс», 2011. - 624 с.

7.       Еремин В.Г. Методы компьютерного эргономического анализа (расчета) рабочего места оператора. Методические указания. [Текст] / В.Г.Еремин , Е.В. Аксенова. - Орел: ОрелГПИ, 1999.

8.      Еремин В.Г. Обеспечение безопасности жизнедеятельности в машиностроении. [Текст] / В.Г. Еремин, В.В. Сафронов Учеб. пособие для ВУЗов. 2-ое изд., перераб. и доп. - М.: Машиностроение, 2002.

9.            Жидков С.А. Требования к программным системам [Текст] / С.А. Жидков ТРПС1.2.1. - 2002. -3с.

.              Информ-система Научно-производственное объединение [Электронный ресурс] . - Электронные, текстовые и граф. дан. (165 Кб). - Режим доступа http://www.informsystema.ru/russian/software/default.html - Систем. требования: ПК 386 или выше; 8 Мб ОЗУ; ОС с графической оболочкой; SVGA 32768 или более цв.; 640480; клавиатура.

11.    Мишенин А.И. Теория экономических информационных систем [Текст] / А.И. Мишенин. - М.: Финансы и статистика, 1993. - 240 с. - ISBN 5-9451-038-0.

12.    Олькина, Е.В. Методические указания по оформлению пояснительных записок к дипломным, курсовым проектам (работам) и отчетов по практикам в соответствии с требованиями государственных стандартов [Текст] / Е.В. Олькина. - Орел: ОрелГТУ, 2007.

13.    СанПиН 2.2.2/2.4.1340-03 Гигиенические требования к персональным электронно-вычислительным машинам и организации работы [Текст]. - М.: Изд-во стандартов, 2003. - 85 с. - ISBN 5-457612-748-7.

14.          Технико-экономическое обоснование дипломных проектов по разработке автоматизированных систем [Текст]: Учебно-методическое пособие. / С.А. Никитин, О.И. Осипова, А.А. Федотов. - Орел: Академия ФАПСИ, 2003. - 80 с.

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

Рисунок А.1 - Физический уровень базы данных