Главная База знаний "Allbest" Программирование, компьютеры и кибернетика Проектирование информационной системы с целью рационализации службы ремонта

Проектирование информационной системы с целью рационализации службы ремонта

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

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

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

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

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

Содержание

  • Введение
  • 1. Разработка и анализ технического задания
  • 1.1 Описание предметной области
  • 1.2 Анализ предметной области
  • 1.3 Разработка технического задания
  • 1.3.1 Наименование области применения
  • 1.3.2 Цель разработки системы и решения задачи
  • 1.3.3 Функциональные требования к системе
  • 1.3.4 Количественные требования к системе
  • 1.3.5 Требования по безопасности и целостности информации
  • 1.3.6 Требования по совместимости
  • 1.3.7 Требование к графическому интерфейсу
  • 1.3.8 Требования к программным и аппаратным средствам
  • 1.4 Анализ технического задания и выбор средств и решений выполнения технического задания
  • 2. Разработка системного проекта
  • 2.1 Архитектура и функции системы
  • 2.2 Построение модели прецедентов
  • 2.3 Описание прецедента
  • 2.4 Разработка модели потоков данных
  • 2.5 Концептуальная модель интегрированной базы данных
  • 3. Разработка моделей процессов
  • 4. Разработка модели данных
  • Заключение
  • Список литературы

Введение

Ремонт остаётся важным направлением воспроизводства основных фондов. Поисками рациональных форм и методов технического обслуживания оборудования заняты многие предприятия, так как система периодических ремонтов, нормативная часть которой основана на "Единой системе ППР и рациональной эксплуатации технологического оборудования машиностроительных предприятий”, разработанной ЭНИМСом, широко применяемая в машиностроении, становится малоприменима в современных условиях. Это обусловлено появлением сложного и материалоёмкого оборудования, для которого проведение ремонтов по заранее разработанным картам, замена определённых деталей и узлов не выработавших свой ресурс, предусмотренных системой ППР, становится нерациональным и экономически необоснованным.

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

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

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

1. Разработка и анализ технического задания

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

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

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

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

Решение задачи на данном предприятие начинается с оформления цехом заявки на проведение планово-предупредительного ремонта внутрицехового производственного оборудования (ППР ВЦПО) и заключения договора на оказание ремонтных работ. Цеху выдается смета на оплату за обслуживание производственного оборудования. Факт оплаты сметы регистрируется в журнале регистраций для учета цехов, которым необходимо выполнить ППР п/о. На основании собранной необходимой информации: количество объектов заключивших договор, количество объектов которые произвели оплату, объектов оставшихся не обслуженными с прошлого периода, количество производственного оборудования, составляется план-график. Каждый раз после выполнения ППР производственного оборудования, обслуживающий персонал ВЦПО оформляет, во первых, записи в цеховой книжке; во вторых, фиксирует данные о каждом обслуженном цехе в журнале регистрации, для учета количества обслуженных и количества оставшихся не обслуженными оборудования в цехах; в третьих, составляет ведомость учета обслуженных объектов. Для контроля за выполнением плана ремонта в конце месяца мастером ВЦПО сравниваются количество объектов по плану и количество объектов после выполнения ППР, но их разница нигде не фиксируется. Не обслуженные объекты переносятся на следующий месяц.

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

1.3 Разработка технического задания

1.3.1 Наименование области применения

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

модель ремонт служба интерфейс

1.3.2 Цель разработки системы и решения задачи

Данная система разработана для:

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

2. максимально эффективно распределить рабочее время.

3. повысить достоверность и оперативность выдаваемой информации.

4. уточнить необходимые контролируемые показатели.

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

Необходимо разработать систему для предприятия ОАО "САПТ". К проектируемой системе предъявляются следующие функциональные требования:

1 Система должна хранить информацию о цехах, производственном оборудовании и исполнителях ремонта.

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

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

4 Система должна формировать договор, смету, план-график ППР, акт-наряд, ведомость и отчет работ.

5 Система должна хранить информацию об цехах заключивших договор и о выполненных работах.

1.3.4 Количественные требования к системе

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

1.3.5 Требования по безопасности и целостности информации

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

создания резервных копий файлов,

периодического сжатия файлов,

защиты файлов средствами шифрования,

введения и изменения пароля для открытия файла,

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

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

1.3.6 Требования по совместимости

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

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

1.3.7 Требование к графическому интерфейсу

Обращение к системе пользователем происходит посредством пользовательского интерфейса (клиентской части), установленного на его рабочем месте.

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

1.3.8 Требования к программным и аппаратным средствам

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

Минимальные требования к техническому обеспечению:

Процессор Intel Pentium IV;

Оперативная память 512 Mb;

Жесткий диск 80 Gb;

Привод CD-RW;

Монитор.

Программное обеспечение.

Microsoft Windows XP;

Microsoft Office 2003;

Используемая операционная система: Windows XP, так как для данной системы не нужно использовать много рабочих мест. Используя технологию Клиент-Сервер большие требования к аппаратным средствам будут предъявляться к серверу, а не на клиентской части.

Сервер: процессор core2 duo 3 GHz

ОЗУ 2Gb

Клиент: процессор Pentium IV 3 GHz

ОЗУ 1Gb

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

1.4 Анализ технического задания и выбор средств и решений выполнения технического задания

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

Для реализации проектируемой системы используем BPwin v.7 (для построения структуры процессов) и ERwin v.7 (для создания базы данных).

2. Разработка системного проекта

2.1 Архитектура и функции системы

Будущая система представляет из себя базу данных, которая хранит данные о цехах, имеющемся у них производственном оборудовании, сотрудниках выполняющих работу по ремонту ВЦПО. Так же база формирует документы, которые необходимы для решения поставленной задачи и рассчитывает стоимость ППР. Разрабатываемый проект строится по технологии "клиент-сервер": Важнейшим параметром крупной информационной системы является быстродействие при значительном количестве пользователей, а также надежность, масштабируемость и безопасность. Всё это обеспечивает архитектура "клиент-сервер". Такая архитектура позволяет оптимально распределить работу между клиентскими и серверной частями системы. Хранение информации должно быть организованно централизовано на отдельном сервере. Обращение к хранимой информации происходит с рабочих (клиентских) мест. Обращение происходит по сетевому протоколу ТСР/IР.

2.2 Построение модели прецедентов

Данная система имеет следующие виды процессов:

формирование договора

формирование сметы

регистрация факта-оплаты

формирование плана ППР

формирование акт-наряда

формирование ведомости

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

Виды процессов представлена в виде диаграммы прецедентов на рис.1

Рис.1 - Диаграмма прецедентов

2.3 Описание прецедента

Подробная форма прецедента "формирование договора".

1 основное действующее лицо: сотрудник договорного отдела.

2 заинтересованные лица и их интересы:

Сотрудник договорного отдела заинтересован в том, чтобы быстро и точно занести данные об абоненте и оборудовании.

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

Мастер ремонта ВЦПО заинтересован в своевременном получении информации, о количестве цехов и производственном оборудовании, которые заключили договор.

3 предусловия: заявление, перечень производственного оборудования, регистрация мастера и сотрудника договорного отдела в системе.

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

2.4 Разработка модели потоков данных

Для разработки модели потоков данных используем методологию DFD.

Информационная система представлена на рисунках 2,3,4,5.

Рис.2 - Контекстная система

Контекстная система разделяется на две подсистемы: "договорной отдел" и "ОГМ (Отдел главного механика)".

Рисунок 3 - Подсистемы

Каждая подсистема делится на процессы. Подсистема "договорной отдел" делится на процессы: формирование договора, формирование сметы, регистрация акта-оплаты.

Рис.4 - Процессы договорного отдела

Подсистема "ОГМ" делится на следующие процессы: формирование плана ППР, формирование акт-наряда, формирование ведомости, формирование отчета.

Рис.5 - Процессы ОГМ

2.5 Концептуальная модель интегрированной базы данных

Рис.6 - ЕR-диаграмма проектируемой системы

На ЕR-диаграмме, показанной на рисунке 6, представлена концептуальная инфологическая модель данных.

3. Разработка моделей процессов

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

Модель процессов представлена на рисунках 7,8,9,10.

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

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

Рисунок 7 - Контекстная система

Рис.8 - Подсистемы

Рис.9 - Процессы "Работы с договорами"

Рис.10 - Процессы "Работы ОГМ"

Процессы делятся на шаги сценариев. Например процесс "формирование сметы" делится на следующие шаги сценария.

1. "Сотрудник договорного отдела" входит в систему, система открывает новую форму.

2. "мастер произв. участка" заполняет заявление.

3. "Сотрудник договорного отдела" заносит данные о цехе в систему и система сохраняет их.

4. Система подсчитывает общую стоимость ППР.

5. Система формирует и печатает смету. Сотрудник договорного отдела выдает ее мастеру.

Существуют альтернативные сценарии.

1 пароль не верен - система предлагает повторить попытку ввода или войти как "гость".

2 абонент приносит неверную смету, сотрудник договорного отдела, просит исправить смету.

4. Разработка модели данных

Модель данных будем представлять в стандарте IDEF1X. Физико-логическую модель БД (ее примерную структуру) представлена следующим образом (рисунок 11): выделены основные сущности, соответствующие предметной области (для их связывания выбрана связь типа "один-ко-многим" и "один-к-одному".

Рис.11 - модель данных на логическом уровне

Заключение

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

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

Список литературы

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

2. Ларман Крэг. Применение ПМI и шаблонов проектирования. 2-издание. Пер. с англ. - М.: "Издательский дом Вильяме", 2004. - 624

3. Г.А. Титоренко. Автоматизированные информационные технологии в экономике. - М.: "ЮНИТИ", 2002

4. Хотяшов Э.Н. Проектирование машинной обработки экономической информации /Учебник - М.: Финансы и статистика, 1987.

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


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

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

© 2000 — 2023, ООО «Олбест» Все права защищены