Разработка АРМ мастера строительно-монтажных работ структурного подразделения ОАО "Сургутнефтегаз"
Технико-экономическая характеристика предметной области. Организационная и функциональная структура объекта автоматизации. Анализ существующих программных продуктов для автоматизации предметной области. Проект информационной модели цеха вентзаготовок.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 24.10.2010 |
Размер файла | 129,9 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
НОУ ВПО МОСКОВСКАЯ АКАДЕМИЯ ПРЕДПРИНИМАТЕЛЬСТВА при Правительстве Москвы
ДИПЛОМНЫЙ ПРОЕКТ
Тема: Разработка АРМ мастера строительно-монтажных работ структурного подразделения ОАО «Сургутнефтегаз»
Реферат
Данная работа содержит: листов - 114, рисунков - 27, таблиц - 23 , приложений - 7, источников использованной литературы - 28.
Ключевые слова: автоматизация, автоматизированное рабочее место (АРМ), анализ, планирование, учет, отчетная документация. Системы вентиляции и кондиционирования воздуха (СВ и КВ).
Назначение системы: автоматизации функций управления мастера СВ и КВ: учет затрат материальных ценностей, учет выполнения объема работ, контроль качества работ, распределение работ, вычисление площади заготовок.
Цель создания системы:
· сокращение времени на обработку информации;
· сокращение времени на поиск необходимой информации;
· улучшение качества контроля и учета обрабатываемой информации;
· сокращение затрат на обработку информации;
· принятие правильных оперативных решений;
· вычисление площади заготовок.
Объект автоматизации: Рабочее место мастера строительно-монтажных работ специализация - вентиляция.
Результатом выполнения дипломного проекта является создание автоматизированного рабочего места мастера СВ и КВ, разработанного с помощью стандартного приложения пакета MS Office - MS Access, позволяющего реализовать поставленные цели.
Степень внедрения: программа успешно прошла тестирование.
Дипломный проект выполнен в текстовом редакторе MS Word 2003 c применением приложений MS Access 2003, функциональное моделирование проведено с помощью IDEEF0 - методологии с использованием CASE - средства Computer Associates BPWin 4.0. В качестве графического материала представлена презентация, выполненная в MS Power Point 2003.
Обозначения и сокращения
АРМ - Автоматизированное рабочее место
СМР - Строительно-монтажных работ
ИС - Информационная система
СВ и КВ - Системы вентиляции и кондиционирования воздуха
СНиПы - Строительный нормативы и правила
СНГ - Сургутнефтегаз
СРС - Сургутремстрой
СУ - Специализированное управление
ТМЦ - Товарно-материальные ценности
ПК - Персональный компьютер
Д - Переход с трубы большей развертки на трубу меньшей развертки
ДО - Переход односторонний
О - Отвод
П - Труба прямая, стандарт согласно СНиПам 2000 мм
ПП - Подмер - труба прямая, стандарт согласно СНиП менее 2000 мм
ПН - Тройник (труба прямая разной длины с врезкой в нее другой трубы любого диаметра).
ЭВМ - Электронно-вычислительная машина
ЛВС - Локально-вычислительная сеть
ОГЛАВЛЕНИЕ
Введение
1. Аналитическая часть
1.1. Технико-экономическая характеристика предметной области
1.2 Организационная структура объекта автоматизации
1.3 Функциональная структура объекта автоматизации
1.4 Информационная модель объекта автоматизации
1.5 Постановка задачи
1.5.1 Цель и назначение автоматизированного варианта решения задачи
1.5.2 Общая характеристика организации решения задачи на ЭВМ
1.5.3 Формализация расчетов
1. 6 Анализ существующих программных продуктов для автоматизации предметной области
1. 7 Обоснование проектных решений по видам обеспечения
1.7.1 Обоснование проектных решений по информационному обеспечению (ИО)
1.7.2 Обоснование проектных решений по технологическому обеспечению
1.7.3 Обоснование проектных решений по программному обеспечению (ПО)
1.7.4 Выбор технического обеспечения (ТО)
2. Проектная часть
2.1. Техническое задание
2.1.1 Полное наименование системы и ее условное обозначение
21.2 Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты
2.1.3 Плановые сроки начала и окончания работы по созданию системы
2.1.4 Порядок оформления и предъявления заказчику результатов работ по созданию системы
2.15 Назначение системы
2.1.6 Цель создания
2.1.7 Характеристика объекта автоматизации
2.2 Требования к Информационной системе
2.2.1 Требования к системе в целом
2.2.2 Требования к численности и квалификации персонала
2.2.3 Показатели назначения
2.2.4 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
2.2.5 Требования к защите информации
2.2.6 Требования к сохранности информации при аварийных ситуациях
2.2.7 Требования по сохранности информации при авариях
2.2.8 Требования к функциям (задачам), выполняемым системой
2.3 Требования к видам обеспечения
2.3.1 Математическое обеспечение
2.3.2 Лингвистическое обеспечение
2.3.3 Информационное обеспечение
2.3.4 Программное обеспечение
2.3.5 Требования к техническому обеспечению системы
2.3.6 Требования к организационному обеспечению
2.4 Состав и содержание работ по созданию системы
2.5 Информационная модель
2.6 Выявление проблем и недостатков в ИС цеха вентзаготовок
2.7 Определение области ориентирования
2.8 Создание Базы данных
2.8.1 Структура таблиц созданной базы данных
2.8.2 Описание запросов к базе данных
2.8.3 Порядок контроля и приемки системы
2.8.4 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
2.8.5 Требования к документированию
2.8.6 Источники разработки
2.8.7 Используемые классификаторы и системы кодирования
2.8.8 Характеристика входной оперативной информации
2.8.9 Характеристика результатной информации
2.8.10 Определение потоков информации «откуда» - «куда»
2.9 Информационная модель цеха вентзаготовок «TO - BE»
3. Обоснование экономической эффективности проекта
3.1 Выбор метода оценки обоснования экономической эффективности
3.2 Расчёт показателей экономической эффективности проекта методом приведённых затрат
ЗАКЛЮЧЕНИЕ
Список использованной литературы
Введение
Проблема автоматизации производственных процессов и процессов управления как средства повышения труда всегда являлась и остается актуальной в народном хозяйстве. В современном этапе автоматизации управления производством наиболее перспективным является автоматизация планово-управленческих функций на базе персональных ЭВМ, установленных непосредственно на рабочих местах специалистов. Эти системы получили широкое распространение в организационном управлении под названием автоматизированных рабочих мест (АРМ).
Автоматизированное рабочее место мастера строительно-монтажных работ - это рабочее место, которое оснащено вычислительной техникой. Оно состоит из ПК, принтера, средств связи - факс/телефон. ПК связан с другими ПК с помощью ЛВС смешанной топологии, которая в свою очередь контролируется системным администратором. С помощью вычислительной техники и установленного необходимого ПО могут решаться ряд проблем, таких как, автоматизация операций учетного процесса и др.
В частности это: операции ряда вычислений, таких как, площадь заготовок, количество нормо-часов, количество забракованных деталей (контроль качества), количество отработанного металла (учет ТМЦ), составление и отправка отчетов. Оперативное принятие управленческих решений.
Большая часть работы мастера связана с накоплением большого количества информации связанным с производством, таким как ведение документации по каждому строящемуся или ремонтируемому объекту. Это ежедневный огромный труд. Более того, мастера сами в некотором роде являются носителями оперативной информации. Получая её, в виде инструкций от вышестоящего начальства, они должны своевременно и правильно принять то или иное управленческое решение. Однако, при выполнении своих функциональных обязанностей часто встречаются наиболее повторяющиеся ошибки, приводящие в некотором роде к искажению информации. Либо несвоевременной её подачи до нужного адресата, что в свою очередь приводит определенного рода к негативным последствиям в производственном процессе.
Одна из основных проблем на сегодняшний день такова, что мастера, ежедневно получающие большой объём информации, часто не успевают своевременно её обработать. Вследствие чего вытекают следующие проблемы: искаженная и не вовремя данная информация приводит к нарушению производственного процесса. Помимо этого очень часто мастера СМР дают около 70% ненужной информации (личная, либо посторонняя), что явно мешает запоминать ту, которая необходима.
Пример: Бригада слесарей по изготовлению деталей и узлов систем вентиляции получила три заказа на изготовление партий деталей на определенные объекты. Но из-за искажения информации теряется приоритетность изготовления. Т. е. бригада срочно изготавливает детали на один (несколько) объектов, но приходит указание приостановить изготовление. Т. к. нужно срочно выполнить работу для другого или других объектов.
Проблема состоит в том, что партия может состоять из большого количества разных деталей. Изготовление её нужно отставить на определенное место, запомнить (отметить) число сделанных деталей и составить их в определённое место. А это временные затраты. Потом приступить к выполнению другой партии.
Бывают случаи, когда в заказе все детали помечены галочкой, т. е. это означает то, что детали сделаются. Но другой мастер, который отмечает и забирает документы, т.е. «изготовленные заказы» увидев такой заказ, думает, что его уже сделали и забирает документ в архив. Хотя заказ еще недоделан, т.е. временно отстранен и потом будет доделываться. Отсюда возникают проблемы - сколько осталось сделать из недоделанной партии. Начинается поиск этой партии в архиве, который является бумажным, т.е. документы сложены в папки. В ПК его нет. Но так как, бригаде нельзя простаивать, то все приступают к изготовлению следующего заказа, который лежит на столе заказов. И это далеко не все. Каждая деталь в зависимости от параметров (развертки) изготавливается из металла определенной толщины (чем больше развертка, тем толще метал), который тоже в свою очередь связан с технологией его обработки. Большую толщину, к примеру, 1мм или 1,2 мм простыми ножницами по металлу очень трудно резать (замедляется процесс изготовления). Приходиться перестраиваться одни инструменты убирать другие доставать, что тоже затрачивает временные ресурсы.
Как излагалось выше, вся основная информация необходимая для функционирования производства, хранится на бумажных носителях, со временем накапливается, представляя собой большие кипы бумаг сшитых в папки. При этом трудно осуществить быстрый отбор нужных данных по объекту монтажа, либо по партии отправляемой на объект, так как выбор (поиск) необходимого бумажного документа представляет собой определенную временную затрату. Помимо этого каждое утро поступает новая информация как по новому, так и по предыдущему объекту монтажа. Плюс к этому бывают изменения и в предыдущих заказах. Некоторые детали привозят обратно, их временно убирают, пока они не понадобятся. Затем изготавливаются другие детали и отвозятся на монтаж вместо привезённых деталей.
Актуальность темы дипломного проекта обусловлена тем, что в условиях повсеместного внедрения компьютерной обработки информации объективную необходимость приобретает внедрение специальных программ для повышения эффективности работы мастеров строительно-монтажных работ.
Основная цель дипломной работы состоит в создании АРМ мастера СМР, выработке предложений и рекомендаций по применению информационных технологий в процессе автоматизации функций управления: анализ, учёт, выработка плановых заданий, составление отчётной документации.
Для достижения поставленной цели определены следующие задачи:
1. Проанализировать информационную систему цеха.
· Поступление информации: от кого, кому, для чего
· Объем полученной информации
· Сроки обработки информации
· Бумажная документация и её объем
2. Установить основные проблемы в процессе обработки информации:
· значительные затраты времени на поиск нужного документа;
· устаревшая структура некоторых нужных для работы документов;
· неточности заполнения этих документов;
· создается несколько бумажных копий одного и того же документа, излишняя трата ресурсов;
· Документы (комплектовочные ведомости) накапливаются, на некоторых нет даты заказа и объема работы в м2.
3. Разработать АРМ мастера строительно-монтажных работ специализация - вентиляция.
· учет рабочего времени;
· выдача заявок на изготовление деталей и узлов систем вентиляции;
· контроль над изготовлением продукции;
· ведение установленной документации по ТМЦ;
· подготовка отчетной документации;
4. Модернизировать существующую ИС цеха вентзаготовок, путём построения модели TO - BE;
5. Автоматизировать процесс вычисления объема сделанной продукции в м2.
Практическая значимость заключается в том, что именно внедрение системы автоматизации учёта материальных ценностей и составления отчётности производственной информации позволит получать в любой момент необходимые данные о выполненной либо предстоящей работе, тем самым, повысив эффективность работы мастера строительно-монтажных работ.
Разработка АРМ мастера строительно-монтажных работ специализация - вентиляция позволит:
обеспечит правильное и своевременное получение инструкций работниками цеха по изготовлению систем вентиляции;
· повысит качество изготовляемой продукции;
· уменьшит количество бракованных деталей;
· упростит работу с документами, повысит ее эффективность;
· повысит производительность труда мастера и бригадира за счет сокращения времени создания, обработки и поиска документов, вследствие чего повышается производительность всей бригады ;
· повысит оперативность доступа к информации;
· сократит численность бумажной документации;
· увеличит пропускную способность обработки документации;
· сэкономит время и денежные средства на обработку информации.
Таким образом, автоматизация процесса работы мастера строительно-монтажных работ является нужным и перспективным процессом, который по мнению автора данной работы, должен быстро и эффективно внедряться в каждой организации строительной отрасли.
1. Аналитическая часть
1.1 Технико-экономическая характеристика предметной области
Строительный трест «Сургутремстрой» был основан в 1979 году как одно из структурных подразделений всего открытого акционерного общества «Сургутнефтегаз». В состав строительного треста “Сургутремстрой” ОАО “Сургутнефтегаз” входят: Ремонтно - строительное управление, Строительно - монтажное управление, Специализированное управление, Цех подготовки производства, Механоэнергетическая служба, Управление механизации и транспорта. В данной работе рассмотрена технико-экономическая характеристика специализированного управления в котором работает автор данной работы.
Работа специализированного управления в основном основана на ремонте структурных подразделений всего акционерного общества «Сургутнефтегаз». Основной профиль работ Специализированного управления - это сантехника, электромонтажные работы, термоизоляция, вентиляция. Структура выполняемых работ специализированного управления показана в таблице 1.1.
Таблица 1.1 - Профиль работ
№ п/п |
Наименование работ |
Сущность производимых Работ |
Итог |
|
1 |
Сантехнические |
Установка тепловодных радиаторов (батареи), сантехники. Монтаж труб отопления. |
Обеспечение производственных объектов теплом и сантехникой, согласно СНиП. |
|
2 |
Термоизоляция |
Изоляция трубопроводов минеральной ватой. Изготовление деталей и их монтаж на трубопроводы. |
Термическая изоляция трубопроводов от внешней среды (низких и высоких температур) |
|
3 |
Вентиляция |
Изготовление деталей и узлов СВ и КВ, их монтаж. Установка вентиляционного оборудования (вентиляторы, калориферы, клапана, воздушные фильтры) |
Обеспечение необходимой вентиляцией согласно СНиП. |
|
4 |
Электромонтажные |
Установка электрооборудования, монтаж электрических кабелей разного сечения. |
Подведение электричества к источникам потребления. |
Специализированное управление имеет свою собственную базу подготовки производства, в состав которой входит:
Административно-бытовой корпус;
Склад закрытого типа хранения “арочник”, где ТМЦ имеют большой временной интервал завоза и вывоза;
Склад открытого типа хранения “стеллажи”, с быстрым интервалом завоза-вывоза ТМЦ;
Цех по изготовлению санитарно-технических изделий;
Цех по изготовлению узлов и деталей СВ и КВ.
Цех по изготовлению узлов и систем вентиляции представляет собой производственный корпус: длина 80 м, ширина 40м, высота 8 метров. Большая часть цеха отведена под изготовление деталей и узлов систем вентиляции. Другая часть цеха отведена для изготовления заготовок термоизоляции. Цех оснащен двумя большими кран-балками грузоподъемностью до 3,5 тонн (включительно) для перемещения тяжеловесных грузов. Для изготовления заготовок систем вентиляции в цехе находятся следующие станки (механические устройства):
· Ножницы гильотинные - 2 единицы;
· Столы для раскройки металла - 7 ед;
· Станок листогиб (для загиба металла) 1ед;
· Сверлильный станок - 1 ед;
· Станок нарубной (нарубает металлический уголок размером от 20 до 80 мм);
· Станок точильный - 1 ед;
· Станок обрезной - 1ед;
· Станок Зиговочный (для изготовления швов на заготовках) - 1 ед;
· Машина зиговочная (для изготовления швов отводов)1 - ед.
Автоматизированное рабочее место мастера систем вентиляции и кондиционирования воздуха (СВ и КВ) находится в кабинете АБК и представляет собой парк вычислительной техники из двух единиц: персональный компьютер класса Pentium 4, копировальный центр. Из средств коммуникации: тел/факс, радиотелефон, коммутатор 3com, локальная вычислительная сеть тип Ethernet со смешанной топологией “кольцо-звезда” представляет собой кабель, витая пара. На персональном компьютере установлены сетевые карты, работающие, со скоростью 100 М/бит в секунду. Сетевым протоколом для передачи данных является TCP/IP (Nransmission Protocol/Internet Protocol). Для управления локальной сетью используется сервер, который находится в отдельной комнате - серверной головного офиса треста “Сургутремстрой”. Данный сервер служит контролером домена и используется в качестве файл-сервера, сервера баз данных, сервера приложений. ЛВС находится под контролем сисадмина треста «Сургутремстрой» и входит в состав ЛВС всего открытого акционерного общества «Сургутнефтегаз».
1.2 Организационная структура объекта автоматизации
Организационная структура Специализированного управления и базы подготовки производства, где находится объект автоматизации, показана в приложениях А.1, А.2.
Руководство специализированным управлением треста «Сургутремстрой» осуществляет начальник управления.
В специализированном управлении имеются следующие производственные участки и отделы:
Производственные участки с 1-го по 8-й;
Отдел кадров;
Бухгалтерия;
ОТиЗ;
ПЭО;
ПТО.
Начиная с Отдела кадров и заканчивая ПТО, эти отделы, осуществляют свои функции для всего строительного треста “СРС”, т. е. для Ремонтно-строительного управления, Специализированного управления, Строительно-монтажного управления, Управления механизации и транспорта.
Организационная структура объекта автоматизации (цех вент заготовок) показана на рис.1.1 и представляет собой линейную структуру. Руководство цехом осуществляет Начальник базы подготовки производства, он же производитель работ. К нему в подчинение входят четыре мастера строительно монтажных работ каждый по своей специализации - это мастер по термоизолировочным работам, мастер по сантехническим работам, мастер по вентиляционным работам и один кладовщик. Два бригадира, одним из которых является разработчик данного проекта. Две бригады, одна работает в цехе сантехнических заготовок, другая в цехе вентзаготовок.
Рисунок 1.1 - Организационная структура цеха вентзаготовок
1.3 Функциональная структура объекта автоматизации
Функции выполняемые бригадой по изготовлению деталей и узлов СВ и КВ производственного участка №8 включают в себя процедуры исполнения заказа, т.е. каждый рабочий бригады:
Подходит к комплектовочной ведомости и отмечает ту деталь, которую он будет изготавливать. Если есть, сомнения в изготовлении детали он смотрит чертеж - подмерку, в которой в аксонометрии указаны подробно все детали изготовляемого заказа. Отмечать следует строго по порядку сверху вниз. Это делается для того, чтобы нагрузка на изготовление деталей распределялась равномерно. Так как, одни детали изготавливаются быстро и легко, другие наоборот дольше и труднее. Все зависит от параметров и сложности изготовления детали;
Выбирает лист металла с толщиной нужной для изготовления той или иной детали, которая зависит согласно СНиПам по изготовлению от сечения детали. Если от 400X400 и выше то толщина металла не должна быть менее 0,7 мм. Иначе толщина металла - 0,5мм;
Берет лист металла и начинает его раскраивать согласно СНиПам по изготовлению деталей СВ и КВ;
После раскройки деталь вырезают по намеченному контуру;
Проделывают с ней специфическую обработку: технологическое отверстие, либо прокатывание швов для соединения сторон детали и т.д.;
Каждую готовую деталь подписывают (строго обязательно): номер детали, наименование объекта (сокращенно) и номер партии;
Каждую подписанную деталь составляет в партии.
Когда приходит автотранспорт за продукцией, изготовленные партии загружают в него и отправляют на объект монтажа.
Все процедуры обработки показаны с помощью контекстной и декомпозиционной диаграмм пакета AllFusionModeller на рисунке 1.2 и 1.3.
1.4 Информационная модель объекта автоматизации
Информационная модель, показанная на рис 1.4, изображена с помощью программы Bpwin, пакета AllFusionProcessModeller и отражает собой информационную модель цеха вентзаготовок, которая непосредственно связана с производственным процессом.
Стрелками указаны информационные потоки:
Заказы на изготовление продукции и ТМЦ - поступают от руководства СУ;
Продукцию изготавливает бригада слесарей по изготовлению узлов и систем вентиляции;
Трудовые отношения основываются на статьях и правилах Трудового кодекса РФ (Трудовой договор);
Изделия изготавливаются согласно строительным правилам и нормам (СНиПы);
Сметы на изготовление деталей осуществляет бухгалтерия, начисление заработной платы производит ОТиЗ;
Готовая продукция сортируется в системы (партии) и отправляется на объекты монтажа;
Отчетная документация (наряды) отправляются в отделы ПЭО, ПТО.
На рис 1.5 показана диаграмма A-0, которая отражает основные направления потоков информации, идентифицирующие производственный процесс цеха вентзаготовок.
Ниже на рисунке 1.6 показана схема изготовления каждого принятого заказа.
В таблице Б.1 показана структура документа “Комплектовочная ведомость” как она есть на сегодняшний день. В таблице приводится пример структуры заполнения документа. В настоящем документе “Комплектовочная ведомость” количество (см. столбец № изделия) изделий очень много. В среднем более 50 номеров изделий. Далее приводится недостатки (изъяны) в заполнении данной ведомости.
Пример: В первой строке идут наименование столбцов. Во второй строке указаны город (где находится объект монтажа), объект (объект на котором производится монтаж (СВ и КВ), партия (в её составе множество деталей разных наименований). Галочкой помечены те детали, которые начали изготавливать (они строго должны быть сделаны), т. е. пока деталь (количество деталей) одного наименования не сделаются за изготовление другой приступать нельзя. Исключения составляют если это конец рабочего дня, то тогда работа переносится на следующий день и начнется она именно с наименования этой не изготовленной детали комплектовочной ведомости и чертежа - подмерки.
Пояснения к таблице: Обозначаемые во второй строке в слове партия буквы обозначают: В - вытяжка, ВЕ - вытяжка естественная, П - приточка, ДУ - дымоудаление.
Существенные недостатки в структуре комплектовочной ведомости:
Непонятно кто пометил галочкой ту или иную деталь. В случае обнаружения брака начинается неразбериха - кто делал деталь. Вся бригада загружена работой настолько, что действительно трудно вспомнить, кто изготавливал бракованную деталь;
Часто бывают случаи когда “звеньевой” (ведущий монтажник объекта монтажа) просит отправить ему какую либо партию (детали из партии) из его заказа, так как, её нужно срочно смонтировать, для того чтобы закрыть наряд - ведомость, т.е. скорее заработать деньги для всего участка вентиляции.
Отсюда возникают проблемы, так как все детали любой партии разбросаны по комплектовочной ведомости и приходится каждую искать в чертеже - подмерке (см. ПРИЛОЖЕНИЕ Д). А это значительные временные затраты, которые замедляют процесс изготовления партии, что экономически тоже нецелесообразно.
Помимо выше перечисленных замечаний существуют проблемы, которые исходят от источников информации. Это мастера и начальник участка монтажа СВ и КВ.
Основные проблемы ИС цеха
Внутренние:
Нет точно-слаженного алгоритма поступления информации связанной с заказами в цехе вентзаготовок;
Остаются недоделанные заказы, которые могут состоять из деталей нескольких партий;
Каждое утро поступает новый заказ или несколько заказов, которые нужно срочно выполнять. Иногда не понятно, что в первую очередь стоит изготавливать;
Поступление от мастеров полезной информации около 30%. Остальное всё ненужная информация, т.е. посторонняя, личная, искажённая, несвоевременная, какие-либо причины и т.д.
Второстепенные (внешние) проблемы, существенно влияющие, на работу ИС цеха вентзаготовок представляют собой следующее:
Нет согласованности в плане работ на объектах монтажа между мастерами структурных подразделений треста, т.е. к примеру, между мастерами СУ, СМУ, УМиТ, РСУ. В результате некоторое количество вентзаготовок возвращается обратно, и переделывается, т.к. бывают существенные отклонения от проекта.
1.5 Постановка задачи
1.5.1 Цель и назначение автоматизированного варианта решения задачи
1. Автоматизировать функции управления:
· вычисления площади заготовок;
· поиск документа;
· составление отчёта.
2. Устранить следующие недостатки:
· Недостаточный контроль за качеством производимой продукции;
· Ручной процесс вычисления площади заготовок;
· Устаревшая структура бумажного документа “Комплектовочная ведомость” и не всегда правильное его заполнение;
· Нет электронной версии “Комплектовочная ведомость”;
· Длительное время обработки и получения оперативных данных для принятия управленческих решений;
· Большой объем бумажной документации;
· Нет АРМ бригадира цеха вентзаготовок.
3. На основе вышеперечисленных недостатков автором данной работы принято решение спроектировать малую ИС “Управление изготовлением заказа”.
1.5.2 Общая характеристика организации решения задачи на ЭВМ
Организация решения задач показана в таблице 1.5.1 и основана на требованиях:
Таблица 1.3 - Требования
Проблема |
Требование |
Решение |
Примечание |
|
Большой объем информации на бумажных носителях |
Ежедневный обмен информацией начальника участка №3 (монтаж систем вентиляции и кондиционирования воздуха) с бригадиром цеха вентзаготовок; |
Автоматизация ввода поступающей информации и обработка её на ПК |
Ежедневное составление отчета, ведение архива. |
|
Не своевременный завоз ТМЦ в цех. Вычисление вручную площадей всех заготовок |
Ежемесячный завоз ТМЦ в цех согласно плана заказов на изготовление деталей и узлов СВ и КВ. |
Автоматизация процесса вычисления площади заготовок и планирование завоза ТМЦ |
Для учета объема изготовленной продукции. Ведение архива |
|
Бригада слесарей по изготовлению узлов и деталей СВ И КВ не справляется с большим объемом заказов |
Временный перевод монтажников СВ и КВ в цех для изготовления узлов и деталей на “срочный объект” |
Распределение рабочих по выполняемым функциям - приоритетность расстановки для достижения наилучшего результата выполнения заказов. Отражение этого в модели ИС “TO-BE” |
Приоритетом является “срочный” объект |
|
Слабый контроль за качеством производимой продукции |
Изменить структуру комплектовочной ведомости |
Добавить столбец “Изготовил ФИО”, в комплектовочной ведомости заказа.. Сделать его электронную версию |
Выбранную деталь для изготовления каждый помечает своей фамилией. |
В данном пункте автор раскрывает требования к будущему проекту путем ответов на следующие вопросы:
изменения в функциях подразделения, связанных со сбором, обработкой и выдачей информации;
источники поступления оперативной и условно-постоянной информацией и периодичность ее поступления;
этапы решения задачи, последовательность и временной регламент их выполнения,
порядок ввода первичной информации (названия документов) и перечень используемых экранных форм;
краткая характеристика результатов (названия результатных документов, экранных форм выдачи результатов, перечень результатных файлов, способов их выдачи: на экран, печать или в канал связи) и мест их использования;
краткая характеристика системы ведения файлов в базе данных (перечень файлов с условно-постоянной и оперативной информацией, периодичность обновления, требования защиты целостности и секретности);
режим решения задачи диалоговый;
периодичность решения задачи.
1.5.3 Формализация расчетов
Основной объем расчетов - вычисление объёма произведённой продукции (вентзаготовок) в м2. Все формулы для нахождения площадей фигур (далее по тексту наименование деталей вентзаготовок), взяты из курса геометрии.
Наименование заготовок подлежащих к вычислению их площадей: Труба (прямик), зонт (три вида), отвод, переход (два вида), утка.
Для изготовления конусообразного зонта из куска металла вырезается круг определенного диаметра. Затем из этого круга вырезается определенной величины сегмент. После чего обрезанные края круга зигуются, соединяются вместе и сбиваются. Полученный результат (заготовку) можно увидеть на рис. 1.10.
Площадь конуса можно вычислить по формулам:
Sкруг = рR2 - площадь круга
Sсегм = (рR2 /360) * a, где a - угол сегмента выраженный в градусах
Sзонт = Sкруг - Sсегм (1.3)
Sзонт = сумма площадей всех сторон (равнобедренных треугольников) (1.4)
Sстор = Ѕ * a * h, где a - основание; h - высота треугольника
Sзонт = Sa * 2 + Sb * 2
Вычисление площади отвода с прямой шейкой
При вычислении площади отвода с прямой шейкой сначала вычисляется площадь “шейки”, затем площадь “затылка” и после чего вычисляется площадь фасонной части. Площади “затылка” и “шейки” вычисляются легко. Они представляют собой прямоугольники, вырезанные из металла и вычисляются по формуле S = a * b, где a и b являются смежными сторонами прямоугольника. Труднее вычисляется площадь фасонной части. Сначала вычисляется периметр одной стороны шейки затем другой стороны шейки (в случае если шейка одинакова с обеих сторон). Затем как видно на рис. 1.5.5 остается вычислить площадь сегмента, которая вычисляется по формуле Sсегм = (рR2 /360) * a.
Общая площадь получается из суммы частей всех вычисленных площадей и представляет собой формулу:
Sотв. = Sш. + Sз. + Sф. где (1.5)
Sш. - площадь шейки;
Sз. - площадь затылка;
Sф. - площадь фасонной части.
Далее Sш. = Sз.= a * b, где a и b стороны прямоугольника. Особое внимание уделяется вычислению площади фасонной части как видно на рис 1.5.6 она состоит из трех частей - Sсегм, S1, S2 и вычисляется по формуле:
Площадь перехода вычисляется аналогично площади зонта трапециевидного ((a*b)/2)*h) и представляет собой сумму площадей всех сторон (трапеций).
Вычисление площади перехода этого вида производится следующим образом:
· Вычисляются площади двух сторон (трапециевидных) - ((a*b)/2)*h;
· затем площади оставшихся двух сторон - a * b
· После чего все стороны складываются - Sпер. = S1 + S2 + S3 + S4
Вычисление площади детали “утка”.
Площадь детали “утка” вычисляется следующим образом - Площадь лицевой части умножается на два и прибавляется площадь фасонной части тоже умноженной на два
Sутка = (Sл * 2) + (Sф * 2) (1.8)
Sл = a * b и представляет собой прямоугольник;
Sф = (S1 * 2) + (S2 * 2) + (Sпрям * 2)
Все выше перечисленные формулы будут включены в автоматизируемые функции вычисления и войдут в БД информационной системы.
1.6 Анализ существующих программных продуктов для автоматизации предметной области
Для анализа существующих программных продуктов автором проекта были выбраны существующие на сегодняшний день системы управления базами данных (СУБД).
На сегодняшний день известно более двух десятков форматов данных настольных СУБД, однако наиболее популярными, исходя из числа проданных копий, следует признать dBase, Paradox, FoxPro и Access. Из появившихся недавно СУБД следует также отметить Microsoft Data Engine -- по существу серверную СУБД, представляющую собой «облегченную» версию Microsoft SQL Server, но предназначенную, тем не менее, для использования главным образом в настольных системах и небольших рабочих группах.
Сведения о производителях перечисленных выше СУБД представлены в таблице 1.4.
Далее мы рассмотрим каждую из этих СУБД в отдельности. Начнем с dBase -- СУБД, бывшей некогда необычайно популярной и сегодня по-прежнему не забытой, несмотря на то, что за время своего существования она сменила несколько хозяев и в настоящее время судьба ее до конца не определена.
dBase и Visual dBase
Хранение данных в dBase основано на принципе «одна таблица -- один файл» (эти файлы обычно имеют расширение *.dbf). MEMO-поля и BLOB-поля (доступные в поздних версиях dBase) хранятся в отдельных файлах (обычно с расширением *.dbt). Индексы для таблиц также хранятся в отдельных файлах. При этом в ранних версиях этой СУБД требовалась специальная операция реиндексирования для приведения индексов в соответствие с текущим состоянием таблицы.
Формат данных dBase является открытым. В роли интерпретатора команд xBase выступает обычно либо среда разработки приложения на этом языке, либо среда времени выполнения. Отметим, что для скрытия исходного текста xBase-приложения подобные СУБД обычно содержат утилиты для псевдокомпиляции кода, который затем поставляется вместе со средой времени выполнения.
Отметим, однако, что для работы с данными формата dBase (или иных dBase-подобных СУБД) совершенно необязательно пользоваться диалектами xBase. Доступ к этим данным возможен с помощью ODBC API (и соответствующих драйверов) и некоторых других механизмов доступа к данным (например, Borland Database Engine, некоторых библиотек других производителей типа СodeBase фирмы Sequenter), и это позволяет создавать приложения, использующие формат данных dBase, практически с помощью любого средства разработки, поддерживающего один из этих механизмов доступа к данным.
После покупки dBase компанией Borland этот продукт, получивший впоследствии название Visual dBase, приобрел набор дополнительных возможностей, характерных для средств разработки этой компании и для имевшейся у нее другой настольной СУБД -- Paradox. Среди этих возможностей были специальные типы полей для графических данных, поддерживаемые индексы, хранение правил ссылочной целостности внутри самой базы данных, а также возможность манипулировать данными других форматов, в частности серверных СУБД, за счет использования BDE API и SQL Links.
В настоящее время Visual dBase принадлежит компании dBase, Inc. Его последняя версия -- Visual dBase 7.5 имеет следующие возможности:
Средства манипуляции данными dBase и FoxPro всех версий.
Средства создания форм, отчетов и приложений.
Средства публикации данных в Internet и создания Web-клиентов.
Ядро доступа к данным Advantage Database Server фирмы Extended Systems и ODBC-драйвер для доступа к данным этой СУБД.
Средства публикации отчетов в Web.
Средства визуального построения запросов.
Средства генерации исполняемых файлов и дистрибутивов.
В настоящее время к Visual dBase в качестве дополнения может быть приобретен компонент dConnections, позволяющий осуществить доступ к данным Oracle, Sybase, Informix, MS SQL Server, DB2, InterBase из Visual dBase 7.5 и приложений, созданных с его помощью.
Paradox
Paradox был разработан компанией Ansa Software, и первая его версия увидела свет в 1985 году. Этот продукт был впоследствии приобретен компанией Borland. С июля 1996 года он принадлежит компании Corel и является составной частью Corel Office Professional.
Принцип хранения данных в Paradox сходен с принципами хранения данных в dBase -- каждая таблица хранится в своем файле (расширение *.db), MEMO- и BLOB-поля хранятся в отдельном файле (расширение *.md), как и индексы (расширение *.px).
Однако, в отличие от dBase, формат данных Paradox не является открытым, поэтому для доступа к данным этого формата требуются специальные библиотеки. Например, в приложениях, написанных на C или Pascal, использовалась некогда популярная библиотека Paradox Engine, ставшая основой Borland Database Engine. Эта библиотека используется ныне в приложениях, созданных с помощью средств разработки Borland (Delphi, C++Builder), в некоторых генераторах отчетов (например, Crystal Reports) и в самом Paradox. Существуют и ODBC-драйверы к базам данных, созданным различными версиями этой СУБД.
Отметим, однако, что отсутствие «открытости» формата данных имеет и свои достоинства. Так как в этой ситуации доступ к данным осуществляется только с помощью «знающих» этот формат библиотек, простое редактирование подобных данных по сравнению с данными открытых форматов типа dBase существенно затруднено. В этом случае возможны такие недоступные при использовании «открытых» форматов данных сервисы, как защита таблиц и отдельных полей паролем, хранение некоторых правил ссылочной целостности в самих таблицах -- все эти сервисы предоставляются Paradox, начиная с первых версий этой СУБД.
По сравнению с аналогичными версиями dBase ранние версии Paradox обычно предоставляли разработчикам баз данных существенно более расширенные возможности, такие как использование деловой графики в DOS-приложениях, обновление данных в приложениях при многопользовательской работе, визуальные средства построения запросов, на основе интерфейса QBE -- Query by Example (запрос по образцу), средства статистического анализа данных, а также средства визуального построения интерфейсов пользовательских приложений с автоматической генерацией кода на языке программирования PAL (Paradox Application Language).
Windows-версии СУБД Paradox, помимо перечисленных выше сервисов, позволяли также манипулировать данными других форматов, в частности dBase и данными, хранящимися в серверных СУБД. Такую возможность пользователи Paradox получили благодаря использованию библиотеки Borland Database Engine и драйверов SQL Links. Это позволило использовать Paradox в качестве универсального средства управления различными базами данных (существенно облегченная версия Paradox 7 под названием Database Desktop по-прежнему входит в состав Borland Delphi и Borland C++Builder именно с этой целью). Что же касается базового формата данных, используемого в этом продукте, то он обладает теми же недостатками, что и все форматы данных настольных СУБД, и поэтому при возможности его стараются заменить на серверную СУБД, даже сохранив сам Paradox как средство разработки приложений и манипуляции данными.
Текущая версия данной СУБД -- Paradox 9, поставляется в двух вариантах -- Paradox 9 Standalone Edition и Paradox 9 Developer's Edition. Первый из них предназначен для использования в качестве настольной СУБД и входит в Corel Office Professional, второй -- в качестве как настольной СУБД, так и средства разработки приложений и манипуляции данными в серверных СУБД. Обе версии содержат:
Средства манипуляции данными Paradox и dBase.
Средства создания форм, отчетов и приложений.
Средства визуального построения запросов.
Средства публикации данных и отчетов в Internet и создания Web-клиентов.
Corel Web-сервер.
ODBC-драйвер для доступа к данным формата Paradox из Windows-приложений.
Средства для доступа к данным формата Paradox из Java-приложений.
Помимо этого Paradox 9 Developer's Edition содержит:
Run-time-версию Paradox для поставки вместе с приложениями.
Средства создания дистрибутивов.
Драйверы SQL Links для доступа к данным серверных СУБД.
Отметим, однако, что популярность этого продукта как средства разработки в последнее время несколько снизилась, хотя в мире эксплуатируется еще немало информационных систем, созданных с его помощью.
Microsoft FoxPro и Visual FoxPro
FoxPro ведет свое происхождение от настольной СУБД FoxBase фирмы Fox Software. Разрабатывая FoxBase в конце 80-х годов, эта компания преследовала цель создать СУБД, функционально совместимую с dBase с точки зрения организации файлов и языка программирования, но существенно превышающую ее по производительности. Одним из способов повышения производительности являлась более эффективная организация индексных файлов, нежели в dBase, -- по формату индексных файлов эти две СУБД несовместимы между собой.
По сравнению с аналогичными версиями dBase, FoxBase и более поздняя версия этого продукта, получившая название FoxPro, предоставляли своим пользователям несколько более широкие возможности, такие как использование деловой графики, генерация кода приложений, автоматическая генерация документации к приложениям и т.д.
Visual Fox Pro 6.0 предоставляет следующие возможности:
Средства публикации данных в Internet и создания Web-клиентов;
Средства создания ASP-компонентов и Web-приложений;
Средства создания COM-объектов и объектов для Microsoft Transaction Server, позволяющих создавать масштабируемые многозвенные приложения для обработки данных;
Средства доступа к данным серверных СУБД, базирующиеся на использовании OLE DB (набор COM-интерфейсов, позволяющий осуществить унифицированный доступ к данным из разнообразных источников, в том числе из нереляционных баз данных и иных источников, например Microsoft Exchange);
Средства доступа к данным Microsoft SQL Server и Oracle, включая возможность создания и редактирования таблиц, триггеров, хранимых процедур;
Средства отладки хранимых процедур Microsoft SQL Server;
Средство визуального моделирования компонентов и объектов, являющиеся составными частями приложения -- Visual Modeller;
Средство для управления компонентами приложений, позволяющее осуществлять их повторное использование.
Итак, тенденции развития этого продукта очевидны: из настольной СУБД Visual FoxPro постепенно превращается в средство разработки приложений в архитектуре «клиент/сервер» и распределенных приложений в архитектуре Windows DNA. Впрочем, эти тенденции в определенной степени характерны для всех наиболее популярных настольных СУБД -- мы уже убедились, что и dBase, и Paradox также позволяют осуществлять доступ к наиболее популярным серверным СУБД.
Достоинства и недостатки существующих СУБД
Достоинства: код, контролирующий стандартную ссылочную целостность, содержится в библиотеках, используемых всеми приложениями, работающими с этой базой данных, а сама база данных при этом может содержать описание правил ссылочной целостности.
Недостатки: проблема СУБД заключается в возможности нарушения ссылочной целостности данных, так как единственным механизмом, контролирующим ее, является пользовательское приложение.
1.7 Обоснование проектных решений по видам обеспечения
1.7.1 Обоснование проектных решений по информационному обеспечению (ИО)
Информационное обеспечение - это совокупность средств и методов построения информационной базы.
· Информационное обеспечение должно удовлетворять пользователя по своей упорядоченности, точности, достоверности и своевременности представления информации для решения поставленных задач, а также однозначности и удобства ее восприятия всеми потребителями;
· Свойство объектов системы должны иметь возможность оформляться в виде сложной структуры, ссылающейся на другие объекты и хранящей историческую последовательность значений;
· Структура данных Системы должна обеспечивать расширяемость по номенклатуре и свойствам новых объектов;
· Система должна обеспечивать поддержку иерархической структуры типов объектов, реализующей механизм наследования свойств объектов.
· Совокупность информационных массивов Системы должна быть организована в виде БД на машинных носителях;
· Система должна иметь механизм регистрации событий, который связывает изменение свойств объектов, вызванное каким-либо внешним событием, с последующей реакцией системы на это событие;
· Форма представления выходной информации должна согласовываться с заказчиком (пользователем) системы. При разработке форм выходных документов в выходных документах АИС должны применяться термины и сокращения общепринятые в данной предметной области и согласованные с заказчиком системы;
· Структура процесса сбора, обработки и передачи данных в ИС должна соответствовать процессам, которые выполняются на рабочем месте мастера строительно - монтажных работ.
Внутримашинная информационная база представляет собой физически реализованную базу данных. Носителем данных является жесткий диск, на котором находится СУБД. Доступ к данным осуществляется посредством SQL-запросов к СУБД.
Основные принципы построения внутримашинной информационной базы:
· информационный массив накапливается и хранится в реляционной базе данных;
· проектирование таблиц осуществляется с принципами построения и организации реляционных баз данных;
· уменьшение избыточности данных не должно приводить к усложнению доступа и уменьшению скорости обработки информации.
Во внутримашинной информационной базе осуществляется контроль целостности данных с помощью бизнес-правил, то есть процедур, применяемых к элементам БД в качестве ограничения целостности.
На этапе ввода происходит сопоставление типов вносимых данных с типом поля БД, а также проверка на допустимые значения.
Хорошо спроектированная база данных:
· удовлетворяет всем требованиям пользователей к ее содержимому. Перед проектированием базы необходимо провести исследования требований пользователей к ее функционированию;
· гарантирует непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации;
· обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к ней более “прозрачными” и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы;
· удовлетворяет требованиям пользователей к ее производительности. При больших объемах информации вопросы сохранения производительности начинают играть главную роль, сразу “высвечивая” все недочеты этапа проектирования.
1.7.2 Обоснование проектных решений по технологическому обеспечению
Технологический процесс - последовательность технологических операций, необходимых для выполнения определённого вида работ. Технологический процесс состоит из рабочих операций, которые в свою очередь складываются из рабочих движений.
Под операцией технологического процесса следует понимать комплекс действий, выполняемых над информацией и её носителем на одном рабочем месте.
Технологический процесс включает: сбор и регистрацию исходных данных, передачу их на обработку, хранение, подготовку данных к обработке, ввод данных в ЭВМ, обработку информации по заданным алгоритмам, выдачу результирующей информации и передачу её пользователям.
1.7.3 Обоснование проектных решений по программному обеспечению (ПО)
Требования к использованию типовых и поставляемых программных средств:
ПО сервера: операционная система (ОС): ОС- MS Windows 2003 Server, СУБД: MS SQL Server.
ПО мастера СМР: может быть использованы операционная система (ОС): MS Windows XP Professional (желательно Rus), компоненты Borland Delphi, пакет MS Office ХР/2003, в виду их распространённости.
Конкретные версии компонентов ПО должны определяться на этапе ввода в действие. ПО является покупным и должно быть лицензионным.
Подобные документы
Особенности и этапы создания автоматизированного рабочего места мастера строительно-монтажных работ. Рекомендации по применению информационных технологий в процессе автоматизации функций управления. Выявление проблем и недостатков в ИС цеха вентзаготовок.
дипломная работа [4,7 M], добавлен 30.08.2010Создание АРМ мастера строительно-монтажных работ по вентиляции, выработка рекомендаций по применению информационных технологий в процессе автоматизации функций управления. Расчёт показателей экономической эффективности проекта методом приведённых затрат.
дипломная работа [4,7 M], добавлен 18.07.2010Рассмотрение особенностей структурного разбиения предметной области. Характеристика функциональной и информационной модели бизнес-процессов предметной области. Построение IDEF0- и IDEF1Х-модели заданной предметной области с помощью пакета Design/IDEF.
контрольная работа [486,5 K], добавлен 08.06.2019Понятие и разновидности, подходы к формированию инфологических моделей. Модель информационной системы Захмана, направления ее развития и анализ результатов. Компоненты инфологического уровня описания предметной области. Сбор требований пользователей.
презентация [136,3 K], добавлен 19.08.2013Изучение назначения деканата, как структурного подразделения ВУЗа. Характеристика основных направлений деятельности деканатов относительно учебного процесса. Матрикульная книга - основной документ контроля учебного процесса. Основные понятия ER-модели.
курсовая работа [2,9 M], добавлен 27.10.2010Анализ существующих решений по автоматизации предметной области. Выбор методологии проектирования информационной системы. Сбор и спецификация, анализ, моделирование и аттестация требований. Возможные неисправности и сопровождение информационной системы.
курсовая работа [645,2 K], добавлен 26.05.2015Обоснование необходимости разработки АОС "Информационная безопасность". Построение модели деятельности "Как есть" (AS-IS) и "Как должно быть" (TO-BE). Анализ программных продуктов. Создание модели предметной области. Разработка информационной системы.
отчет по практике [5,3 M], добавлен 31.05.2015Анализ предметной области. Разработка информационной системы для улучшения качества обслуживания клиентов и автоматизации работы кассы столовой. Проектирование логической модели. Определение регламентированных запросов и описание клиентских приложений.
курсовая работа [1,6 M], добавлен 17.02.2013Анализ предметной области и выбор программных средств. Построение концептуальной модели базы данных. Распределение данных и репликация. Управление распределенными транзакциями. Оптимизация запросов: выполнение, монитор производительности и трассировка.
дипломная работа [2,2 M], добавлен 27.12.2014Технико-экономическая характеристика предметной области. Анализ существующих разработок, выбор и обоснование стратегии автоматизации и способа приобретения ИС. Характеристика первичных документов с нормативно-справочной и входной оперативной информацией.
дипломная работа [3,6 M], добавлен 10.03.2013