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

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 26.05.2015
Размер файла 645,2 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

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

Содержание

Введение

1. Аналитическая часть

1.2 Анализ предметной области

1.3 Анализ существующих решений по автоматизации предметной области

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

1.5 Сбор требований

1.6 Спецификация требований

1.7 Анализ и моделирование требований

1.8 Аттестация требований

2. Эксплуатационная часть

2.1 Возможные неисправности

2.2 Сопровождения ИС

Заключение

Основная литература

автоматизация информационный система требование

Введение

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

Рассматриваемая курсовая работа написана на базе предприятия по установке газового оборудования Порошов А.В. "ООО Газ для вас" г. Моршанск.

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

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

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

?работу с входными данными;

?получение выходных документов;

?формирование отчетов.

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

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

?осуществить бизнес-моделирование процессов предприятия, для исследоваемой информационной системы;

?провести анализ требований к системе и ее проектирование;

?исследовать концептуальную и физическую модели данных;

?провести оценку эффективности технологии исследования.

1. Аналитическая часть

1.1 Анализ предметной области

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

Для того чтобы внести ясность в понятия газификации, воспользуемся определениями, данными в Федеральном законе от 31.03.1999 N69 ФЗ "О ГАЗОСНАБЖЕНИИ В РОССИЙСКОЙ ФЕДЕРАЦИИ" [45].

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

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

Основами создания и развития единого рынка газа на территории Российской Федерации являются:

?формирование круга потребителей газа на основе широкого внедрения газа как энергетического и топливного ресурса в производство и быт на территориях субъектов Российской Федерации - развитие газификации;

?создание экономически взаимовыгодных отношений потребителей и поставщиков газа;

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

?проведение государственной политики ценообразования, направленной на развитие единого рынка газа.

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

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

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

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

Сотрудник (business worker) - индивидуум, который действует внутри моделируемой бизнес системы, взаимодействует с другими сотрудниками и является участником бизнес - процесса моделируемой системы.

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

Бизнес ? вариант использования (business use case) - вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес - процесса.

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

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

На рисунке 1.1 представлена схема бизнес-процесса по формированию заказа клиента.

Рисунок 1.1 - Бизнес-процесс "Формирование заказа клиента"

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

На рисунке 1.2 представлена схема бизнес-процесса расчет с клиентом.

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

Рисунок 1.2 - Бизнес-процесс "Расчет с клиентом"

На рисунке 1.3 представлена схема бизнес-процесса контроль по срокам гарантии.

Рисунок 1.3 - Бизнес-процесс "Контроль по срокам гарантии"

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

На рисунке 1.4 представлена схема бизнес-процесса формирование заказа на оборудование.

Рисунок 1.4 - Бизнес-процесс "Формирование заказа на оборудование"

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

На рисунке 1.5 представлена схема бизнес-процесса формирование прайса оборудования.

Рисунок 1.5 - Бизнес-процесс "Формирование прайса оборудования"

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

Рисунок 1.6 - Бизнес-процесс "Составление плана работ"

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

На рисунке 1.7 представлена схема бизнес-процесса составление индивидуального плана работ для внештатных сотрудников.

Рисунок 1.7 - Бизнес-процесс "Составление индивидуального плана работ для внештатных сотрудников"

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

Рисунок 1.8 - Бизнес-процесс "Составление акта о выполненной работе"

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

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

На рисунке 1.9 представлены объекты, составляющие бюджетную классификацию Российской федерации. В таблице 1.1 представлена расшифровка объектов представленных на рисунке 1.9.

Рисунок 1.9 - Объекты и сущности предметной области

Таблица 1.1 - Объекты и сущности предметной области

Наименование

Описание

client

клиент

equipment

оборудование

nacenka

процентная наценка на оборудование

price

прайс

postavshik

поставщик

manwork

менеджер по работе с клиентами

order_client

заказ клиента

order_postavshik

заказ на оборудование

maininstal

начальник отдела по установке оборудования

count

счет

act

акт о выполненной работе

employeelist

список внештатных сотрудников

empinstal

сотрудник отдела по установке оборудования

1.3 Анализ существующих решений по автоматизации предметной области

Среди существующих программных решений по автоматизации следует отметить автоматизированную информационную систему "Информационная система предприятия" Конфигурация имеет сертификат "Совместимо! Система программ 1С:Предприятие" и позволяет эффективно организовать работу с документами в электронной форме.

Основные возможности программы:

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

?ведение справочников, хранящих контактную и другую информацию об организации, сотрудниках, контрагентах и физических лицах;

?предопределенный набор типовых видов документов, отражающих предметную область, возможность расширения состава документов;

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

?возможность работы с электронной почтой и хранение всей корреспонденцию.

Канцелярия:

?регистрация первичных документов и хранение их электронных копий;

?формирование реестров документов;

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

?учет важных документов по местам хранения;

?работа со списками документов - группировки документов в дела;

?автоматизация документооборота;

?все документы системы включены в систему документооборота;

?схемы исследования (маршруты движения) документов доступны для редактирования и настройки под особенности работы;

?организация очередей исследования документов.

Другие возможности:

?напоминания;

?оперативный журнал событий, заданий;

?пообъектный учет

?аудит действий пользователя в системе;

?средства совместной работы над документами - блокировки, удостоверение содержания;

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

Технические особенности реализации: Конфигурация для своей работы требует установленную программную оболочку "1С:Предприятие 8", не защищена аппаратным ключом и поставляется с исходными текстами модулей. Фрагменты конфигурации, отвечающие за использования внешних справочников через Интернет, обмен документами, поставляются без исходных текстов и не могут быть изменены. В конфигурации предусмотрена возможность локализации и работа пользователей на нескольких языках в рамках одной информационной базы. Особенности лицензирования: Основная поставка дает право на работу с одной информационной базой (информационная база может быть распределенной) и не ограничивает пользователя рамками локальной сети. Дополнительная лицензия позволяет работать одновременно с любым количеством поставок.

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

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

Существует две основных методологии проектирования:

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

??методология объектно-ориентированного проектирования.

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

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

Наиболее распространенные модели структурного подхода:

SADT - Structured Analysis and Design Techniques - описывает модели и функциональные диаграммы;

DFD - Data Flow Diagrams - диаграммы потоков данных;

ERD - Entity Relationship Diagrams - диаграммы "сущность - связь".

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

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

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

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

Для реализации проекта был выбран объектно-ориентированный подход в силу следующих факторов:

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

??повышение безопасности кода за счет инкапсуляции;

??гибкость при модификации и расширении системы;

??отсутствие необходимости исследования классов с нуля, за счет наследования;

?общая ориентированность объектно-ориентированной технологии на исследование информационных систем, как класса программного обеспечения и т.д.

1.5 Сбор требований

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

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

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

1.6 Спецификация требований

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

Спецификация требований - процесс документирования системы в структурированном, доступном всем и управляемом формате. Спецификация требований (Software Requirements Specification, SRS) используется для текущего сопровождения проекта и представления требований, сформулированных по отношению к проекту. SRS позволяет определить предметную область программного продукта, рассматриваемого относительно трех его основных составляющих: данных, процесса и поведения. Спецификация требований к ПО используется при исследовании, тестировании, гарантии качества продукта, управлении проектом, приемке проекта и связанных с проектом функциях. SRS имеет ключевое значение для всего жизненного цикла исследования программного продукта. Это не только производный документ, в котором определены спецификации программного проекта, но и основной документ, применяемый с целью проведения аттестационных и приемочных испытаний.

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

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

1.6 Анализ и моделирование требований

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

Рисунок 1.10 - Пользователи системы

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

Дадим краткую характеристику каждому классу пользователей системы.

Менеджер по работе с клиентами - сотрудник занимающийся приемом заказов и последующей работе с клиентами.

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

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

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

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

На рисунке 1.11 представлены варианты использования системы менеджером по работе с клиентами.

В процессе выполнения прецедента "Формирование заказа" пользователь выполняет поэтапное формирование заказа, последовательно вводя данные о клиенте.

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

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

Рисунок 1.11- Варианты использования системы менеджером по работе с клиентами

В процессе выполнения прецедента "Внесение изменений" пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т.е. если не выполнялся прецедент "Утверждение заказа". В процессе выполнения прецедента "Контроль по срокам гарантии" пользователь следит за сроками гарантии на оборудование. В процессе выполнения прецедента "Расчет с клиентом" пользователь формирует счет. На рисунке 1.12 представлены варианты использования системы начальником отдела по установки оборудования.

В процессе выполнения прецедента "Формирование заказа поставщикам" пользователь выполняет поэтапное формирование заказа поставщикам.

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

В процессе выполнения прецедента "Внесение изменений в заказ поставщикам" пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т.е. если не выполнялся прецедент "Утверждение заказа поставщикам".

В процессе выполнения прецедента "Составление акта о выполненной работе" пользователь составляет акт о проделанной работе.

В процессе выполнения прецедента "Составление плана работ" пользователь составляет план работ в соответствии с принятым заказом.

В процессе выполнения прецедента "Формирование прайса" пользователь формирует прайс, следит за ценами, обновляет их.

Рисунок 1.12 - Варианты использования системы менеджером по персоналу

На рисунке 1.13 представлены варианты использования системы сотрудником отдела по установки оборудования.

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

В процессе выполнения прецедента "Формирование заказа поставщикам" пользователь выполняет поэтапное формирование заказа поставщикам.

В процессе выполнения прецедента "Внесение изменений в заказ поставщикам" пользователь проводит корректировку заказа. Выполнение этого прецедента возможно, только если заказ еще не утвержден, т.е. если не выполнялся прецедент "Утверждение заказа поставщикам".

В процессе выполнения прецедента "Составление плана для сотрудников" пользователь составляет план работ в соответствии с принятым заказом для каждого внештатного сотрудника в отдельности.

В процессе выполнения прецедента "Определение коэффициента участия сотрудников" пользователь определяет степень участия сотрудника.

В процессе выполнения прецедента "Формирование списка внештатных сотрудников" пользователь формирует список сотрудников для выполнения работ.

На рисунке 1.14 представлены варианты использования системы администратора автоматизированной системы.

В процессе выполнения прецедента "Регистрация пользователя" администратор регистрирует в системе новую учетную запись.

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

Рисунок 1.13- Варианты использования системы сотрудником отдела по установки оборудования

Рисунок 1.14 - Варианты использования системы специалистом администратором

В процессе выполнения прецедента "Удаление пользователя" администратор удаляет учетную запись пользователя и списка зарегистрированных в системе.

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

1.7 Аттестация требований

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

Существует набор методов аттестации, которые можно использовать как вместе, так и по отдельности:

??обзор требований - процесс просмотра системной спецификации на предмет неточных описаний и ошибок;

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

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

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

Выводы к разделу

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

В качестве методологии проектирования обосновано применение объектно-ориентированного подхода.

2. Эксплутационная часть

2.1 Возможные неисправности

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

Неисправность. Нет искры

Причина: Неисправна кнопка пьезорозжига

Признаки.

Устранение: Заменить кнопку

Причина: Отсутствует контакт

Признаки.

Устранение: Восстановить контакт.

Неисправность. Искра есть, но проходит в неправильном месте

Причина: Поврежден кабель

Признаки.

Устранение: Заменить кабель.

Причина: Поврежден электрод розжига

Признаки.

Устранение: Заменить электрод.

Неисправность. Не загорается пламя запальной горелки

Причина: Закрыт газовый кран на входе в котел

Признаки: Давление газа на входе в котел =0

Устранение: Открыть газовый кран.

Причина: Воздух в газовой арматуре и газопроводе

Признаки: При нажатии кнопки розжига раздается свист из форсунки запальной горелки

Устранение: Открутить гайку крепления трубки запального газа к газовой арматуре, ослабить трубку и,

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

Причина: Отрыв пламени

Признаки: При нажатии кнопки розжига раздается свист из форсунки запальной горелки

Устранение: Отрегулировать давление газа запальной горелки регулировочным винтом.

Установлена неправильная форсунка. Заменить.

Причина: Посторонний предмет или грязь в тракте подачи газа от газовой арматуры до запальной горелки

Признаки: При нажатии кнопки розжига не раздается свист из форсунки запальной горелки

Устранение: Прочистить трубку запального газа или форсунку

Причина. Неисправна газовая арматура

Признаки: При нажатии кнопки розжига не раздается свист из форсунки запальной горелки

Устранение: Заменить газовую арматуру

Неисправность: Пламя запальной горелки гаснет после отпускания кнопки розжига

Причина: Недостаточно долго удерживалась кнопка розжига

Признаки:

Устранение: Удерживать кнопку не менее 20 сек.

Причина: Вышел из строя датчик уходящих газов

Признаки: Отсоединить провода датчика уходящих газов от втулки 18 пп.6.1. и прозвонить датчик уходящих газов. R=?.

Устранение: Заменить датчик уходящих газов.

Причина: Вышла из строя термопара

Признаки: Отсоединить провода датчика уходящих газов от втулки 18 пп.6.1 и замерить напряжение на контактах втулки при горящем пламени запальника. При этом необходимо удерживать кнопку

розжига в нажатом положении. Напряжение менее 10 мВ

Устранение: Заменить термопару

Причина: Вышел из строя электромагнитный клапан

Признаки: Все узлы контура согласно приведенным выше тестам в норме.

Устранение: Заменить электромагнитный клапан

Неисправность. Основная и запальная горелки гаснут спустя несколько минут после

включения основной горелки

Причина: Сработал датчик уходящих газов

Признаки.

Устранение: Прочистить дымоход

Неисправность: Не удается отрегулировать максимальное давление газа

Причина Давление газа на входе при работающей горелке меньше номинального

Признаки.

Устранение: Увеличить диаметр подводки и/или заявить в газовый трест

Причина: Проток через колонку меньше номинального

Признаки.

Устранение: Увеличить проток

Неисправность: Не разжигается основная горелка

Причина: Неправильная подводка воды

Признаки.

Устранение: Изменить подводку

Причина: Порвалась мембрана

Признаки.

Устранение: Заменить мембрану

Причина: Засорился фильтр в водной арматуре или сеточки на кранах

Признаки.

Устранение: Прочистить

Причина: Недостаточное давление воды на входе

Признаки.

Устранение: Увеличить давление

Причина: Проток воды через колонку меньше минимального

Признаки.

Устранение: Увеличить проток

Причина: Давление газа на входе меньше минимального

Признаки.

Устранение: Увеличить диаметр подводки и/или заявить в газовый трест

Неисправность. Температура горячей воды меньше заданного значения

Причина: Не отрегулировано давление газа

Признаки: Проверить манометром

Устранение: Отрегулировать давление газа

Причина: Отложение накипи в теплообменнике

Признаки: Снизился проток через колонку ниже паспортных данных

Устранение: Промыть теплообменник

Причина: Температура холодной воды на входе очень низкая

Неисправность: Горелка не выключается после закрытия крана горячей воды

Причина: Заедает шток или тарелка главного клапана не садится на место

Признаки:

Устранение: Заменить вышедшие из строя детали; смазать шток; очистить клапан от мешающих механических частиц

Неисправность. Горелка горит желтым пламенем

Причина: Загрязнилась горелка

Признаки.

Устранение: Почистить горелку

2.2 Сопровождения ИС

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

Консультации пользователей/технических специалистов Заказчика по эксплуатации системы Заказчика.

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

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

Отслеживание изменений и обновлений версий программ и конфигураций.

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

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

2.3 Резервное копирование базы данных

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

Причины могут следующими: в базе данных есть ограничения, такие как NOT NULL поля, внешние ключи, уникальность, а существующие данные в базе данных этим ограничениям не соответствуют по каким-либо причинам. Такие данные могут мирно существовать до тех пор, пока они не будут задействованы в операциях редактирования или удаления. В процессе восстановления "прощупываются" все данные - в первую очередь создаются ограничения и затем заливаются данные, в этот момент и происходит ошибка. Для профилактики следует восстанавливать базу данных в тестовую, и лишь при успешном завершении процесса восстановления, делать Restore в текущую базу. В случае возникновения ситуации с поврежденным файлом backup'а следует найти в базе данных несоответствия и исправить их.

Заключение

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

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

Основная литература

1. Баронов В.В. Информационные технологии и управление предприятием. - М: Компания АйТи, 2006. - 328с.

2. Благовещенская М.М., Злобин Л.А. Информационные технологии систем управления технологическими процессами: Учебник для вузов. - М.: Высшая школа, 2005. - 768с.

3. Землянский А.А. Информационные технологии в экономике: Учебник для вузов - 2004. - 336с.

4. Ивасенко А.Г. Информационные технологии в экономике и управлении. - М.: КноРус, 2005. - 160с.

5. Саак А.Э., Пахомов Е.В., Тюшняков В.Н. Информационные технологии управления. Учебник для ВУЗов. - СПб.: Питер, 2005. - 320с.

6. Титоренко Г.А. Автоматизированные информационные технологии в экономике: учебник - М.: ЮНИТИ, 2004. - 399с.

7. Уткин В.Б., Балдин К.В. Информационные системы в экономике. Учебное пособие. - М.: Академия, 2004.- 288с.

8. Уткин В.Б. Балдин К.В. Информационные системы и технологии в экономике. Учебник - М.: ЮНИТИ ДАНА, 2005. - 355с.

Размещено на Allbest.ru


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.