Автоматизированная система учёта и ремонта электрохозяйства предприятия. (Взять для примера любое предприятие).

Автоматизация системы учета заявок и ремонта энергохозяйства предприятия
Содержание
Введение
1Исследовательский раздел
1.1Анализ исходных данных
1.1.1Характеристика объекта автоматизации
1.1.2Процесс учета заявок и ремонта электрохозяйства
1.2Анализ существующих аналогов. Обоснование выбора программных и аппаратных средств
1.2.1Автоматизированные системы технического обслуживания и ремонта оборудования
1.2.2Выбор стратегии автоматизации
1.3Постановка задачи
1.3.1Характеристика комплекса задач
1.3.2Выходная информация
1.3.3Входная информация
1.3.4Условно-постоянная информация
1.3.5Описание алгоритма решения задачи
1.4Развернутое ТЗ на проектирование
2Специальный раздел
2.1Разработка структурной схемы АС
2.2Разработка структуры базы данных
2.3Разработка основных форм документов
2.4Разработка алгоритмического и программного обеспечения
2.5Разработка пользовательского интерфейса
3Технологический раздел
3.1Технология разработки баз данных
3.2Технология отладки АС
Заключение
Список сокращений слов
Список использованной литературы
Приложение АФормы входных документов
Приложение БФормы выходных документов
Приложение ВСтруктурная схема АС учета заявок и ремонта энергохозяйства МГУПИ
Приложение ГСхема функций управления и обработки данных АС учета заявок и ремонта энергохозяйства МГУПИ
Приложение ДЭкранные формы
Приложение ЕОтчеты

Если документ не размещается на одном стандартном листе, то происходит выполнение разрыва строк и переноса оставшихся строк документа второй зоны вместе с реквизитами третьей зоны на другой лист.
Разработка алгоритмического и программного обеспечения
Алгоритм представляет собой систему точно сформулированных правил, определяющую процесс преобразования входной информации в желаемый результат (выходную информацию) за конечное число шагов.
Алгоритм решения поставленных задач был рассмотрен в разделе 1.3.5 в словесном виде. Для примера на рисунке 2.3 представлен алгоритм решения задачи «Подбор материалов».
Рисунок 2.3 – Алгоритм решения задачи «Подбор материалов»
Алгоритм решения комплекса задач и его программная реализация тесно взаимосвязаны. Разработка АС учета и ремонта электрохозяйства университета производилась средствами Microsoft Access 2003. Технологии СУБД позволяют производить планирование, проектирование и администрирование системы.
Кнопочное пользовательское меню, формы для ввода и обработки данных, запросы для выбора информации из БД и отчетные документы реализовывалось стандартными средствами Microsoft Access 2003.
Схема функций управления и обработки данных АС учета заявок и ремонта энергохозяйства МГУПИ приведена в Приложение Г. Здесь предусмотрены основные функции учета и обработки информации, а также системные функции по поддержке работы БД.
Описание форм для ввода и обработки информации представлено в таблице 2.1.
Таблица 2.1 - Описание форм для ввода и обработки информации
№ п/п Имя формы Идентификатор формы Краткое описание АС в отделе главного энергетика 1 Главное меню Главное меню Форма главного меню 2 Справочник «Энергохозяйство» ВводЭХ Форма для просмотра справочника «Сборочные единицы» 3 Заявка на ремонт Заявка Форма для регистрации заявки на ремонт 4 Работа с заявками на ремонт Работа с заявками Форма для просмотра и анализа информации по заявкам на ремонт 5 Отчет по остаткам Остатки Форма для просмотра отчета об остатках материалов и 6 Заявка на материалы СЗ склад Форма для создания заявки на склад 7 Акт списания из ОГЭ Списание ОГЭ Форма для списания материалов из ОГЭ 8 Отчет о проделанной работе Отчет Форма для регистрации отчета о проделанной работе АС на складе 9 Отчет по остаткам Остатки Форма для просмотра отчета об остатках материалов и 10 Акт списания со склада Акт склад Форма для списания материалов со склада
Для выборки информации из БД используются запросы. Они служат источником для формирования сложных форм и отчетов. Их описание представлено в таблице 2.2.
Таблица 2.2 - Описание запросов на выборку
№ п/п Имя запроса Связь с формой или отчетом Краткое описание АС в отделе главного энергетика 1 ОтборЗаявок Отбор Запрос для поиска заявок 3 Акт_ОГЭ Списание ОГЭ Запрос для формирования отчета «Акт о списании материалов» 4 Мат_ОГЭ Списание ОГЭ Запрос для выбора из отчета по остаткам материалов, имеющихся в наличие в ОГЭ АС на складе 5 Акт_склад Акт склад Запрос для поиска не списанных заявок на материалы 6 Акт_мат Акт склад Запрос для выбора из отчета по остаткам материалов, имеющихся в наличие на складе 9 Акт_отчет Акт склад Запрос для формирования отчета «Акт о списании материалов»
Запросы создавались при помощи Конструктора запросов. На рисунке 2.4 показан пример построения запроса Мат_ОГЭ, отвечающего за выборку информации по материалам, имеющимся в отделе главного энергетика по данным отчета о списании материалов.
Рисунок 2.4 – Конструктор запроса Мат_ОГЭ
SQL код запроса Мат_ОГЭ представлен ниже:
SELECT Остатки.Материал, Остатки.Подразделение, Материалы.Матер, Остатки.Количество, Подразделение.Подразд
FROM Материалы INNER JOIN (Подразделение INNER JOIN Остатки ON Подразделение.Код_подразд = Остатки.Подразделение) ON Материалы.Код_матер = Остатки.Материал
WHERE (((Подразделение.Подразд)="Отдел главного энергетика"));
На рисунке 2.5 показан пример построения запроса Акт_склад, отвечающего за выборку информации по заявкам на материалы, созданным в ОГЭ. Здесь проверяется условие отсутствия в записи информации о дате акта. Это означает, что была создана заявка на материалы, но их списание не было произведено.
Рисунок 2.5 - Конструктор запроса Акт_склад
SQL код запроса Акт_склад представлен ниже:
SELECT [Акт списания].Ном_акта, [Акт списания].Дата_СЗ, [Акт списания].Дата_акта, [Акт списания].Номер_заявки, [Акт списания].МОЛ, [Акт списания].Место, [Заявка на ремонт].Направл_ремонта
FROM [Заявка на ремонт] INNER JOIN [Акт списания] ON [Заявка на ремонт].Ном_заявки = [Акт списания].Номер_заявки
WHERE ((([Акт списания].Дата_акта) Is Null));
При разработки программы использовались макросы. Макрос — это объект Access, который представляет собой набор из нескольких макрокоманд (или включает одну макрокоманду). Это средства автоматизации, предусмотренные для выполнения одних и тех же задач. При запуске макрос автоматически выполняет последовательность определенных элементарных действий. В процессе разработки приложения использовались макросы для организации ввода информации при открытии экранной формы документа.
Для автоматизации действий системы в ответ на некоторые события использовался язык программирования Visual Basic For Application. Например, для формирования акта списания материалов на основании заявки на материалы (экранная форма ввода представлена в разделе 3.2, рисунок 3.7). При списании материала необходимо предусмотреть, чтобы поле «Дата акта» было заполнено. Для обработки события нажатия кнопки «Списать материал» выполняется следующая подпрограмма:
Private Sub Кнопка25_Click()
Me!Дата.SetFocus
If Me!Дата.Text = "" Then
MsgBox "Для списания материалов необходимо указать дату акта", vbOKOnly
Exit Sub
Else
Печать.Enabled = True
End If
End Sub
Если поле «Дата акта» не содержит значения, на экране пользователь получит сообщение о необходимости ввести дату (раздел 2.5, рисунок 2.14). Если дата акта введена, становится доступной кнопка «Печать», которая инициирует создание отчета «Акт списания материалов со склада» (форма отчета представлена в разделе 3.2, рисунок 3.8).
Разработка пользовательского интерфейса
Создание эффективного пользовательского интерфейса позволит пользователю свободно ориентироваться в приложении и делать свою работу быстро и качественно. Эффективность будет достигнута благодаря созданию наглядного меню и понятных для пользователя экранных форм с использованием понятий рассматриваемой предметной области.
Содержание экранных форм соответствует принципу "дружественности": обозначения реквизитов представлены на русском языке в соответствии с привычной для пользователя терминологией, процесс ввода информации сопровождается подсказками и контролем.
Администратором БД предоставляются права доступа для каждого пользователя. Для идентификации пользователя используются пароли.
Работа программы начинается с выполнения служебной функции проверки пароля для входа в систему (рисунок 2.6).
Рисунок 2.6 – Окно для ввода пароля
После корректного ввода пароля для сотрудника ОГЭ на экране появится главное меню АС учета заявок и ремонта энергохозяйства МГУПИ (рисунок 2.7).
Рисунок 2.7 – Главное меню АС для отдела главного энергетика
Главное меню для работы сотрудника склада представлено на рисунке 2.8
Рисунок 2.8 – Главное меню АС для склада
На рисунке 2.9 представлен пример экранной формы для ввода информации по объектам энергохозяйства университета.
Рисунок 2.9 – Форма для ввода справочной информации по объектам энергохозяйства
Перемещение по записям формы осуществляется при помощи кнопок: - предыдущая запись, - последующая запись. Для добавление нового объекта энергохозяйства используется кнопка , для удаления информации об объекте энергохозяйства используется кнопка . Выход из формы осуществляется при помощи кнопки .
Основная доля ошибок происходит по вине пользователя, а не компьютера, поэтому для контроля правильности вводимой информации используется визуальный и логический контроль. Вся информация, которая содержится в справочниках (название подразделений, имена сотрудников, номенклатура материалов) выбираются из выпадающих списков (рисунке 2.10), а не вводятся пользователем с клавиатуры.
Рисунок 2.10 – Пример поля со списком
В соответствующие поля пользователь может ввести только ту информацию, которая предусмотрена определенным типом данных для хранения этих атрибутов. Т.е. в числовые поля невозможно будет ввести текстовые значения. Также при вводе информации учитывается размерность поля.
Для ввода даты предусмотрена маска ввода в формате дд.мм.гггг (рисунок 2.11)
Рисунок 2.11 – Поле для ввода даты
В случае попытки ввести значение, не подходящее под маску ввода даты, на экране появиться сообщение об ошибке (рисунок 2.12)
Рисунок 2.12 – Сообщение об ошибке
В случае попытки перейти к несуществующей записи на экране появится следующее сообщение (рисунок 2.13):
Рисунок 2.13 – Сообщение на попытку перейти к несуществующей записи
Для формирования акта списания материалов на основании заявки на материалы (экранная форма ввода представлена в разделе 3.2, рисунок 3.7) необходимо предусмотреть, чтобы поле «Дата акта» было заполнено. Если поле не содержит значение даты в заданном формате на экране появится предупреждающее сообщение (рисунок 2.14):
Рисунок 2.14 – Сообщение о необходимости ввести дату акта о списании материалов со склада
Данные сообщения позволяют предубедить ошибки пользователя при работе с информацией базы данных.
Технологический раздел
Технология разработки баз данных
База данных является фундаментальным компонентом информационной системы, а ее разработку и использование следует рассматривать с точки зрения самых широких требований организации. Жизненный цикл информационной системы организации неотъемлемым образом связан с жизненным циклом системы базы данных, поддерживающей ее функционирование.
Жизненный цикл информационных систем в стандартах представляет собой набор этапов и операций в последовательности их выполнения и взаимосвязи, регламентирующие ведение работ от подготовки технического задания до окончания эксплуатации ИС.
Этапы жизненного цикла приложения базы данных показаны на рисунке 3.1. [13, с. 334].
Эти этапы не являются строго последовательными, а предусматривают в некоторых случаях возврат к предыдущим этапам с помощью обратных связей. Рассмотрим основные действия, выполняемые на каждом этапе жизненного цикла при разработке приложения базы данных.
Планирование разработки БД – это подготовительные действия, позволяющие с максимально возможной эффективностью реализовать этапы жизненного цикла приложения базы данных. Важным шагом на этом этапе является четкое определение технического задания для проекта базы данных. Техническое задание разработано в разделе 1.4 дипломного проекта.
Определение требований к системе - это описание области применения приложения базы данных и основных пользовательских представлений, которые поддерживаются базой данных. Под сбором и анализом требований к системе понимается процесс сбора и анализа информации о той части организации, работа которой будет поддерживаться с помощью создаваемого приложения базы данных. Данные действия производились при разработке раздела 1.3 Постановка задачи.
Рисунок 3.1 - Этапы жизненного цикла создания приложения БД базы данных
Проектирование базы данных - это процесс создания проекта базы данных, предназначенной для поддержки функционирования объекта автоматизации и способствующей достижению его целей. Процесс проектирования базы данных состоит из трех основных этапов: концептуальное, логическое и физическое проектирование. Проектирование базы данных — это итерационный процесс, который имеет свое начало, но не имеет конца и состоит из бесконечного ряда уточнений.
Проектирование базы данных может также предусматривать выбор наиболее подходящих инструментов автоматизированного проектирования и создания программ, которые принято называть CASE-инструментами. CASE-инструменты могут включать следующие компоненты:
словарь данных, предназначенный для хранения информации о данных, используемых в создаваемом приложении;
инструменты проектирования, обеспечивающие проведение анализа данных;
инструменты разработки корпоративной модели данных, а также концептуальных и логических моделей данных;
инструменты, позволяющие создавать прототипы приложений.
САSЕ-инструменты предназначены для упрощения и автоматизации решения отдельных задач в ходе разработки системы, поэтому позволяют существенно повысить продуктивность труда разработчиков. Эффективность характеризует общий уровень соответствия созданной системы имеющимся информационным потребностям ее пользователей. [17].
В процессе разработки логической и физической модели БД использовалось Case-средства Erwin Data Modeler.
Концептуальная модель данных создается на основе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование базы данных не зависит от выбранной СУБД, создаваемых прикладных программ, используемых языков программирования, типа выбранной вычислительной платформы, а также от любых других особенностей физической реализации. На данном этапе для описания структур данных предметной области строятся информационно-логические модели.
Логическая модель данных уточняет концептуальную модель и учитывает особенности выбранной модели организации данных в целевой СУБД. В процессе разработки логическая модель данных постоянно тестируется и проверяется на соответствие требованиям пользователей. Для проверки правильности логической модели данных используется метод нормализации. Нормализация гарантирует, что отношения, выведенные из существующей модели данных, не будут обладать избыточностью данных, способной вызвать нарушения в процессе обновления данных после их физической реализации. Логическая модель базы данных, построенная средствами Case-средства Erwin Data Modeler, представлена на рисунке 3.2.
Рисунок 3.2 - Логическая модель базы данных
На этапе физического проектирования рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных. Физическая модель разрабатываемой БД представлена на рисунке 3.3.
Рисунок 3.3 – Физическая модель базы данных
Выбор целевой СУБД должен производиться с учетом информации о таких общих требованиях к системе, как производительность, простота реорганизации, уровень защищенности и ограничения целостности данных. Цель данного этапа заключается в выборе системы, удовлетворяющей как текущим, так и будущим требованиям организации, при оптимальном уровне затрат, включающих расходы на приобретение СУБД, дополнительного аппаратного и программного обеспечения, а также расходы, связанные с переходом к новой системе и необходимостью переобучения персонала. В рамках дипломного проекта в качестве СУБД была выбрана Microsoft Access 2003. Схема данных, полученная в результате генерации БД в Microsoft Access, представлена в разделе 2.2 (рисунок 2.1).
Разработка приложения заключается в проектирование пользовательского интерфейса и прикладных программ, предназначенных для работы с базой данных. Данный этап выполняется параллельно с проектированием БД.
На этапе реализации производится физическая реализация базы данных на языке определения данных СУБД и разработанных приложений на языке программирования высокого уровня. На этом этапе реализуются также используемые приложением средства защиты базы данных и поддержки ее целостности. Описанию этапов разработки и описания приложения БД посвящена вторая глава дипломного проекта.
На этапе преобразования и загрузки данных происходит перенос в БД любых существующих данных и модификация всех существующих приложений с целью организации совместной работы с новой БД. На этом этапе необходимо осуществить загрузку информации из справочников бухгалтерской АС.
Этап тестирования заключается в обнаружении имеющихся ошибок в прикладных программах и в структурах базы данных. Технология отладки АС будет рассмотрена в разделе 3.2.
Заключительный этап эксплуатация и сопровождение БД связан с наблюдением за системой и поддержкой ее нормального функционирования. В случае необходимости возможна модернизация приложений БД. [13].
Технология отладки АС
Отладка АС связана с процессом выполнения прикладных программ с целью поиска ошибок. Прежде чем использовать новую систему на практике, ее следует тщательно протестировать. Этого можно добиться путем разработки продуманной стратегии тестирования с использованием реальных данных, которая должна быть построена таким образом, чтобы весь процесс тестирования выполнялся строго последовательно и методически правильно.
Тестирование вряд ли сможет продемонстрировать отсутствие ошибок в программном обеспечении — скорее, наоборот, оно способно лишь показать их наличие. Если тестирование проведено успешно, оно обязательно вскроет имеющиеся ошибки в прикладных программах и, возможно, в структурах базы данных. В качестве побочного результата тестирование может лишь продемонстрировать, что база данных и прикладные программы, по-видимому, работают в соответствии с их спецификациями и при этом удовлетворяют существующим требованиям, предъявляемым к производительности.
Как и при проектировании баз данных, пользователи новой системы должны быть вовлечены в процесс ее тестирования. По завершении тестирования процесс создания прикладной системы считается законченным, и она может быть передана в промышленную эксплуатацию. [14].
Для отладки АС используем метод детерминированного тестирования. При этом в качестве эталонов (тестов) используем конкретные исходные данные, состоящие из взаимосвязанных входных и результативных величин и правильных последовательностей их обработки. В процессе тестирования при заданных исходных величинах необходимо установить соответствие результатов их обработки эталонным величинам.
При установлении наличия ошибок на этапе тестирования возникает необходимость в следующем этапе – отладке. Отладка представляет собой процесс устранения ошибок: она начинается с обнаружения симптомов ошибки и заканчивается определением ее месторасположения и последующим исправлением. [17].
В разрабатываемой АС нет сложной обработки информации и вычислительных расчетов. Следовательно, этап отладки системы воспользуемся демонстрацией контрольного примера работы системы учета заявок и ремонта энергохозяйства МГУПИ. Для этого:
Введем исходные данные для реализации контрольного примера.
Определим узкие места при работе АС.
Проверим правильность обработки информации в обозначенных точках.
Для демонстрации работоспособности системы введена информация в справочники БД. Кроме этого, необходимо заполнить несколько первичных документов: заявку на ремонт и заявку на материалы.
Для анализа работоспособности АС необходимо проверить правильность организации ввода, обработки и вывода информации в следующих контрольных точках:
При вводе заявки на ремонт – возможность выбора справочной информации из раскрывающихся списков и корректность сохранения данных.
При работе с заявками на ремонт – возможность использования фильтра (Все заявки, Выполненные заявки или Заявки в работе).
При подборе материалов – корректность отображения информации из отчета об остатках материалов.
При подготовке акта о списании материалов в ОГЭ – возможность выбора из списка только тех материалов, которые имеются в наличие в данный момент времени.
При создании заявки на материалы – возможность выбора материалов, которые имеются на складе в данный момент времени.
При подготовке акта о списании материалов со склада на основании заявки на материал, поступившей из ОГЭ – корректность создания акта и возможность создания отчета.
При создании отчета о проделанной работе – корректность отображения информации.
Учитывая представленные требования к тестированию АС, проведена отладка всех модулей БД. Объем дипломного проектирования не позволяет полностью представить результаты отладки работы системы. Рассмотрим лишь наиболее интересные моменты.
Работа с заявками. Все заявки на ремонт объектов энергохозяйства университета можно посмотреть и проанализировав, нажав на кнопку «Работа с заявкам» в главном меню программы для ОГЭ. На экране появиться форма, в которой имеется возможность отобрать нужные записи (рисунок 3.4). Заявки отсортированы по приоритету. В поле со списком можно выбрать условие отбора заявок: «Все записи», «Завершено» и «В работе». Изменять информацию по заявкам в форме «Работа с заявками» не предусмотрено.
Рисунок 3.4 - Форма для просмотра заявок на ремонт
Подбор материалов. Этап подбора материалов для ремонта начинается с выбора кнопки главного меню программы для ОГЭ «Подбор материалов». На экране появляется форма, в которой содержится информация из отчета об остатках материалов (). Этот отчет можно распечатать нажав на кнопку «Печать» (форма отчета представлена в Приложение Е, рис. Е.1). На основании анализа информации пользователь принимает решение о возможности использовать материалы, имеющиеся в ОГЭ (нажать кнопку «Акт списания») или создавать заявку на материалы на склад (нажать кнопку «Заявка на склад»).
Рисунок 3.5 – Форма для подбора материалов
Создание заявки на списание материалов. Форма для создания заявки на материалы представлена на рисунке 3.6. В процессе создания заявки на склад указывается дата и основание заявки. Заявка на материалы может быть составлена на выполнение конкретных ремонтных работ (в этом случае указывается номер заявки на ремонт) или на текущие нужды (в этом случае поле со списком «Заявка на ремонт становится недоступным»). В табличной части формы указываются необходимые для ремонта материалы: из раскрывающегося списка можно выбрать код материала, в соответствии с которым автоматически заполняться поля «Название материала» и «Ед.изм.» Необходимо только указать норму расхода и количество материала. Сформированную заявку можно распечатать (форма отчета «Заявка на материалы» представлена в Приложение Е, рисунок Е.2). Созданная заявка должна быть одобрена на складе, где произойдет на ее основе формирование акта о списании материалов со склада. Для этого необходимо воспользоваться интерфейсом программы для работы сотрудника склада.
Рисунок 3.6 – Форма для создания заявки на материалы
Акт о списании материала со склада. Выбрав в главном меню программы для работы сотрудника склада пункт «Рассмотрение заявок на материалы» на экране появится форма для просмотра заявок на материалы от ОГЭ. Для подсказки имеется информация об основании заявки, ее дате и направлении (эти данные не доступны для изменения). Пользователь может изменить информацию о материалах (изменить количество, добавить другие материалы). Для списания материалов необходимо нажать на кнопку «Списать материал», что повлечет за собой формирование акта о списании материалов со склада.
Рисунок 3.7 – Форма для списания материалов со склада
При нажатии на кнопку «Печать» на экране появится отчет «Акт о списании материалов» (рисунок 3.8). Его можно распечатать на принтере, заверить и передать в бухгалтерию для учета.
Рисунок 3.8 - Форма отчета «Акт списания материалов со склада»
Отладка работы системы показала работоспособность АС на рабочем месте пользователя ОГЭ и склада.
Заключение
В результате дипломного проектирования была разработана автоматизированная система учета заявок и ремонта энергохозяйства Московского государственного университета приборостроения и информатики. Она предназначена для организации эффективной работы с системой документации отдела главного энергетика и склада университета, которая регламентирует ход ремонтных работ энергохозяйства. В дипломном проекте автоматизированы задачи регистрации заявок на ремонт, работы с очередью заявок, подготовки необходимых для ремонта материалов и учета завершения ремонтных работ. Пользователями системы являются сотрудники отдела главного энергетика и сотрудники склада, для которых разработаны отдельные пользовательские интерфейсы на базе СУБД Microsoft Access 3003.
В первой главе был произведен анализ предметной области, выбран комплекс задач для автоматизации, построен процесс учета заявок и ремонта энергохозяйства. Здесь выявилась необходимость производить определение приоритетов заявок с целью организации их очереди (последовательности выполнения). Это упрощает процесс работы с поступившими заявками и позволяет снизить потери от несвоевременного осуществления ремонтных работ на важных объектах энергохозяйства. К функциям отдела главного энергетика добавилось ведение автоматизированного справочника объектов энергохозяйства. Хорошо описанный регистр электрического оборудования и систем, ведение истории всех неисправностей и ремонтных работ в единой системе улучшает качество работ, связанных с планированием и осуществлением ремонта и технического обслуживания.
В первой главе была выбрана стратегия автоматизации. Был произведен обзор и анализ возможностей современных систем, предназначенных для реализации задач дипломного проектирования. Cистемы CMMS и EAM обеспечивают автоматизацию управления ремонтами и техническим обслуживанием оборудования и основных фондов предприятия. Однако стоимость данных систем и избыточность функций для поставленных задач позволила сделать вывод о целесообразности осуществления собственной разработки АС учета заявок и ремонта энергохозяйства. В постановке задачи на автоматизацию была определена характеристика комплекса задач, реквизиты справочной, входной и выходной информации, а также словесно описан алгоритм решения задачи.
Специальный раздел дипломного проектирования посвящен процессу разработки АС. Представленная структурная схема АС подразумевает использование информации, создаваемой и обрабатываемой в системе бухгалтерского учета. Это относится к общей справочной информации и информации об остатках материалов в ОГЭ и на складе. Передача данных от системы бухгалтерского учета будет производиться через табличный процессор Microsoft Excel. Передача информации о списании материалов для учета в системе БУ будет производиться путем передачи бумажной копии документа подготовленного акта о списании материалов. С учетом требований к АС была разработана схема базы данных, основные формы документов, пользовательский интерфейс для удобства работы пользователя с системой. Также представлена схема алгоритма решения задачи подбора материала для ремонта, в процессе которого возможна связь между приложениями, работающими в ОГЭ и на складе. В рамках освещения вопроса программного обеспечения была разработана схема функций управления и обработки данных АС учета заявок и ремонта энергохозяйства, описаны программные модули, запросы и отчетные формы.
В технологическом разделе представлена технология разработки БД в виде последовательности этапов. Более подробно рассмотрены вопросы концептуального, логического и физического проектирования, приведены соответствующие схемы данных. Процесс отладки АС рассмотрен в виде демонстрации контрольного примера работы системы.
Список сокращений слов
АС – автоматизированная система
АХУ – административно-хозяйственное управление
БД – база данных
БУ – бухгалтерский учет
ИС – информационная система
МГУПИ - Московский государственный университет приборостроения и информатики
ОГЭ – отдел главного энергетика
СУБД – система управления базой данных
ТЗ – техническое задание
ТОиР – техническое обслуживание и ремонт
CMMS (Сomputerized maintenance management systems) - компьютерные системы управления техническим обслуживанием и ремонтом
EAM (Enterprise asset management) – управление основными фондами предприятияСписок использованной литературы
ГОСТ 7.1–84 Система стандартов по информации, библиотечному и издательскому делу. Библиографическое описание документа. Общие требования и правила составления.
ГОСТ 18322-78 «Системы технического обслуживания и ремонта техники. Термины и определения».
ГОСТ 24.204-80. Требования к содержанию документа «описание постановки задачи».
Дипломное проектирование: Учебно-методическое пособие. Изд. 2-е, переработанное./Брейман А.Д., Зеленко Г.В., Степанова И.В. – М.: МГУПИ, 2006. – 43 с.
«Правила технической эксплуатации электроустановок потребителей», утверждены Приказом Министерства энергетики Российской Федерации от 13.01.2003 N6.
Конюхова Е. А. Электроснабжение объектов. - М.: Издательство «Мастерство», 2002. - 320 с.
Е. Руцков, Е. Данилова. ПО для автоматизации процессов управления ТОиР. Статья журнала «Корпоративные системы» №9 от 04.06.2004 г.
Чернобровцев А. Что могут EAM. Статья журнала Computerworld, №27, 2006 г.
Шехватов Д. Управление основными фондами: как автоматизировать ремонты и техническое обслуживание // Статья журнала CIO, № 2, 2003 г.
Мери Уидл. Союз ERP и EAM/CMMS улучшает бизнес-решения // Статья журнала «Директор ИС» №10, 2006 г.
Информатика: Учебник. - 3-е перераб. изд. /Под ред. проф. Н.В. Макаровой. - М.: Финансы и статистика, 2000. - 768 с.
Маклаков С.В. «Создание информационных систем с AllFunction Modeling Suite». – М.: ДИАЛОГ-МИФИ, 2003 – 432 с.
Коннолли Томас, Бегг Каролин. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : Пер. с англ. — М. : Издательский дом "Вильяме", 2003. — 1440 с.
Благодатских В.А. Стандартизация разработки программных средств: Учеб. пособие/ Под ред. Разумова О.С. – М.: Финансы и статистика, 2005. – 288 с.
Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем (I часть) / Московский государственный университет экономики, статистики и информатики. М., 2001г. – 232 с.
Харитонова И. А. Самоучитель: Office Access 2003. — СПб.: Питер, 2004. — 464 с.
Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. — М.: Финансы и статистика, 2002. - 352 с.
Данные сайта Московского государственного университета приборостроения и информатики http://www.mgapi.ru/
Данные сайта компании ЭнТехЭко http://www.rto.entecheco.com/
Данные сайта компании СпецТек http://www.trim.ru/
Формы входных документов
Рисунок А.1. Форма служебной записки с заявкой на проведение ремонтных работ
Рисунок А.2. Форма служебной записки на выдачу материалов со склада

Рисунок А.3. Форма оборотной ведомости по материальным запасам (страница 1)
Рисунок А.4. Форма оборотной ведомости по материальным запасам (страница 2)

Рисунок А.5 Форма отчета об остатках материалов, передаваемая в АС учета заявок и ремонта электрохозяйства МГУПИФормы выходных документов
Рисунок Б.1 Форма акта о списании материальных запасов (страница 1)
Рисунок Б.2 Форма акта о списании материальных запасов (страница 2)
Рисунок Б.3 Форма отчета о проделанной работеСтруктурная схема АС учета заявок и ремонта энергохозяйства МГУПИ
Схема функций управления и обработки данных АС учета заявок и ремонта энергохозяйства МГУПИ
Экранные формы
Рисунок Д.1 – Форма для регистрации заявок на ремонт
Рисунок Д.2 - Форма регистрации отчета о проделанной работеОтчеты
Рисунок Е.1 – Форма отчета по остаткам материалов
Рисунок Е.3 – Форма отчета о проделанной работе
75