Дипломная работа: Автоматизированное рабочее место мастера строительно-монтажных работ структурного подразделения ОАО "Сургутнефтегаз"

Дипломная работа: Автоматизированное рабочее место мастера строительно-монтажных работ структурного подразделения ОАО "Сургутнефтегаз"

НОУ ВПО МОСКОВСКАЯ АКАДЕМИЯ ПРЕДПРИНИМАТЕЛЬСТВА

при Правительстве Москвы

Сургутский филиал

Специальность – «Прикладная информатика (в экономике)»

Форма обучения - заочная

ДИПЛОМНЫЙ ПРОЕКТ

Тема: Разработка АРМ мастера строительно-монтажных работ структурного подразделения ОАО «Сургутнефтегаз»

Выполнил студент

Группы 41 ПИЭ

Чернобровкин Виталий Викторович

Научные руководители

к. т. н. профессор Клочков Г.А.

Реферат

Данная работа содержит: листов – 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 – Профиль работ

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

Административно-бытовой корпус;

Склад закрытого типа хранения “арочник”, где ТМЦ имеют большой временной интервал завоза и вывоза;

Склад открытого типа хранения “стеллажи”, с быстрым интервалом завоза-вывоза ТМЦ;

Цех по изготовлению санитарно-технических изделий;

Цех по изготовлению узлов и деталей СВ и КВ.

Цех по изготовлению узлов и систем вентиляции представляет собой производственный корпус: длина 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.2 – Контекстная диаграмма производственного процесса цеха вентзаготовок

Рисунок 1.3 – Диаграмма декомпозиции производственного процесса

1.4 Информационная модель объекта автоматизации

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

Рисунок 1.4 – Информационная модель цеха вентзаготовок

Стрелками указаны информационные потоки:

Заказы на изготовление продукции и ТМЦ – поступают от руководства СУ;

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

Трудовые отношения основываются на статьях и правилах Трудового кодекса РФ (Трудовой договор);

Изделия изготавливаются согласно строительным правилам и нормам (СНиПы);

Сметы на изготовление деталей осуществляет бухгалтерия, начисление заработной платы производит ОТиЗ;

Готовая продукция сортируется в системы (партии) и отправляется на объекты монтажа;

Отчетная документация (наряды) отправляются в отделы ПЭО, ПТО.

На рис 1.5 показана диаграмма A-0, которая отражает основные направления потоков информации, идентифицирующие производственный процесс цеха вентзаготовок.

Рисунок 1.5 – Производственный процесс

Ниже на рисунке 1.6 показана схема изготовления каждого принятого заказа.

Рисунок 1.6 – Изготовление заказа

Диаграмма A1.1 показанная на рис 1.7 раскрывает сущность диаграммы “Обработка заказов”.

Рисунок 1.7 – Диаграмма «Обработка заказа»

В таблице Б.1 (см. ПРИЛОЖЕНИЕ Б) показана структура документа “Комплектовочная ведомость” как она есть на сегодняшний день. В таблице приводится пример структуры заполнения документа. В настоящем документе “Комплектовочная ведомость” количество (см. столбец № изделия) изделий очень много. В среднем более 50 номеров изделий. Далее приводится недостатки (изъяны) в заполнении данной ведомости.

Пример: В первой строке идут наименование столбцов. Во второй строке указаны город (где находится объект монтажа), объект (объект на котором производится монтаж (СВ и КВ), партия (в её составе множество деталей разных наименований). Галочкой помечены те детали, которые начали изготавливать (они строго должны быть сделаны), т. е. пока деталь (количество деталей) одного наименования не сделаются за изготовление другой приступать нельзя. Исключения составляют если это конец рабочего дня, то тогда работа переносится на следующий день и начнется она именно с наименования этой не изготовленной детали комплектовочной ведомости и чертежа – подмерки.

Пояснения к таблице: Обозначаемые во второй строке в слове партия буквы обозначают: В – вытяжка, ВЕ – вытяжка естественная, П – приточка, ДУ – дымоудаление.

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

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

Часто бывают случаи когда “звеньевой” (ведущий монтажник объекта монтажа) просит отправить ему какую либо партию (детали из партии) из его заказа, так как, её нужно срочно смонтировать, для того чтобы закрыть наряд – ведомость, т.е. скорее заработать деньги для всего участка вентиляции.

Отсюда возникают проблемы, так как все детали любой партии разбросаны по комплектовочной ведомости и приходится каждую искать в чертеже – подмерке (см. ПРИЛОЖЕНИЕ Д). А это значительные временные затраты, которые замедляют процесс изготовления партии, что экономически тоже нецелесообразно.

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

Основные проблемы ИС цеха

Внутренние:

Нет точно-слаженного алгоритма поступления информации связанной с заказами в цехе вентзаготовок;

Остаются недоделанные заказы, которые могут состоять из деталей нескольких партий;

Каждое утро поступает новый заказ или несколько заказов, которые нужно срочно выполнять. Иногда не понятно, что в первую очередь стоит изготавливать;

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

Второстепенные (внешние) проблемы, существенно влияющие, на работу ИС цеха вентзаготовок представляют собой следующее:

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

1.5 Постановка задачи

1.5.1 Цель и назначение автоматизированного варианта решения задачи

1. Автоматизировать функции управления:

·          вычисления площади заготовок;

·          поиск документа;

·          составление отчёта.

2. Устранить следующие недостатки:

·          Недостаточный контроль за качеством производимой продукции;

·          Ручной процесс вычисления площади заготовок;

·          Устаревшая структура бумажного документа “Комплектовочная ведомость” и не всегда правильное его заполнение;

·          Нет электронной версии “Комплектовочная ведомость”;

·          Длительное время обработки и получения оперативных данных для принятия управленческих решений;

·          Большой объем бумажной документации;

·          Нет АРМ бригадира цеха вентзаготовок.

3. На основе вышеперечисленных недостатков автором данной работы принято решение спроектировать малую ИС “Управление изготовлением заказа”.

1.5.2 Общая характеристика организации решения задачи на ЭВМ

Организация решения задач показана в таблице 1.5.1 и основана на требованиях:

Таблица 1.3 – Требования

В данном пункте автор раскрывает требования к будущему проекту путем ответов на следующие вопросы:

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

·          источники поступления оперативной и условно-постоянной информацией и периодичность ее поступления;

·          этапы решения задачи, последовательность и временной регламент их выполнения,

·          порядок ввода первичной информации (названия документов) и перечень используемых экранных форм;

·          краткая характеристика результатов (названия результатных документов, экранных форм выдачи результатов, перечень результатных файлов, способов их выдачи: на экран, печать или в канал связи) и мест их использования;

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

·          режим решения задачи диалоговый;

·          периодичность решения задачи.

1.5.3 Формализация расчетов

Основной объем расчетов – вычисление объёма произведённой продукции (вентзаготовок) в м2. Все формулы для нахождения площадей фигур (далее по тексту наименование деталей вентзаготовок), взяты из курса геометрии.

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

Вычисление площади трубы (прямика)

Рисунок 1.8 – Прямик

Sпр= P*L (1.1)

S – площадь заготовки «прямик»;

P – периметр (развёртка) т.е. ширина умноженная на высоту;

L – длина заготовки «труба».

Вычисление площади зонта 1 вид (трапециевидный)

Рисунок 1.9 – Зонт трапециевидный

Sзонт = сумма площадей всех сторон (трапеций) (1.2)

Площадь каждой стороны (трапеции) вычисляется по формуле: ((a*b)/2)*h, где

A – длина нижнего основания трапеции(стороны);

B – длина верхнего основания трапеции;

H – высота трапеции.

Вычисление площади зонта 2 вид (конусообразный)

Sкруга

                                            Sсегм

Рисунок 1.10 – Зонт конусообразный

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

Площадь конуса можно вычислить по формулам:

Sкруг = πR2 - площадь круга

Sсегм = (πR2 /360) * a, где a – угол сегмента выраженный в градусах

Sзонт = Sкруг - Sсегм (1.3)

Вычисление площади зонта 3 вид (пирамидальный)

h

a

Рисунок 1.11 – Зонт пирамидальный

Sзонт = сумма площадей всех сторон (равнобедренных треугольников) (1.4)

Sстор = ½ * a * h, где a – основание; h – высота треугольника

Sзонт = Sa * 2 + Sb * 2

Вычисление площади отвода с прямой шейкой

Затылочная часть (затылок)

                                                                        Фасонная часть

                                                                    Шеечная часть (шейка)

Рисунок 1.12 – Отвод

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

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 и вычисляется по формуле:

Sф. = (Sсегм * 2) + S1 + S2 где (1.6)

Sсегм = (πR2 /360) * a.

S1 = S2 = a * b, где

сторона a = высоте фасонной части отвода;

сторона b = половине длины шейки.

                                                                          S1

Площадь сегмента a

a b

S2 b

Рисунок 1.13 – Фасонная часть

Вычисление площади перехода (1 вид центровой)

Рисунок 1.14 – Переход центровой

Площадь перехода вычисляется аналогично площади зонта трапециевидного ((a*b)/2)*h) и представляет собой сумму площадей всех сторон (трапеций).

Sпер. = S1 + S2 + S3 + S4 (1.7)

Вычисление площади перехода (2 вида одностороннего)

Рисунок 1.15 – Переход односторонний

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

·          Вычисляются площади двух сторон (трапециевидных) - ((a*b)/2)*h;

·          затем площади оставшихся двух сторон - a * b

·          После чего все стороны складываются - Sпер. = S1 + S2 + S3 + S4

Вычисление площади детали “утка”.

                            Лицевая часть                            S1

           S2 Sпрям

                        Фасонная часть                       Лицевая часть

Рисунок 1.16 – Утка

Площадь детали “утка” вычисляется следующим образом – Площадь лицевой части умножается на два и прибавляется площадь фасонной части тоже умноженной на два

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.

Таблица 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, в виду их распространённости.

Конкретные версии компонентов ПО должны определяться на этапе ввода в действие. ПО является покупным и должно быть лицензионным.

Общие требования к программному обеспечению:

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

2)         программное обеспечение системы должно обладать следующими свойствами:

·          функциональная достаточность (полнота);

·          надежность (в том числе восстанавливаемость, наличие средств выявления ошибок);

·          адаптируемость;

·          модифицируемость;

·          модульность построения;

·          удобство эксплуатации.

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

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

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

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

Программное приложение должно быть реализовано c помощью пакета MS Office.

Система управления БД – MS Access

SQL (Structured Query Language) - это сокращенное название структурированного языка запросов, предоставляющего средства создания и обработки данных в реляционных БД. Независимость от специфики компьютерных технологий, а также поддержка SQL лидерами промышленности в области технологии реляционных баз данных сделали его основным стандартным языком БД.

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

·          предложения определения данных - определение БД, а также определение и уничтожение таблиц и индексов;

·          запросы на выбор данных - предложение SELECT;

·          предложения модификации данных – добавление, удаление и изменение данных;

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

Особенно важно, что Delphi 7 поддерживает базы данных SQL Server. Система управления БД SQL Server является одной из мощнейших многопользовательских БД, обеспечивающих быстрый доступ к данным и их надежное хранение. Она имеет ряд существенных преимуществ перед другими БД:

·          поддерживает БД сколь угодно большого размера до сотни тысяч мегабайт;

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

·          минимизирует соперничество за данные и гарантирует их согласованность;

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

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

·          имеет режимы спасения и восстановления информации, позволяющие защищать БД от программных и аппаратных сбоев.

1.7.4 Выбор технического обеспечения (ТО)

Так как разработка АРМ не предусматривает капитальной реорганизации существующей технологии, парк технических средств остаётся без изменения. То есть, в системе должны в основном использоваться технические средства (ТС) серийного производства типа IBM–совместимых персональных компьютеров с серийным периферийным оборудованием и серверы баз данных с процессором не ниже Pentium IV.

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

Аппаратная платформа сервера:

·          процессор типа Pentium IV 1ГГц – 2,8 ГГц (не ниже);

·          объем ОЗУ 512 Мб - 1Гб;

·          память на жестком диске SCSI - 20 Гб минимум;

·          ИГП, обеспечивающий работу сервера в течении не менее 30 минут при полностью заряженных батареях ИГП;

·          монитор SVGA;

·          сетевая карта 100 Мбит;

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

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

Аппаратная платформа компьютера мастера СМР состоит из:

·          процессора типа Pentium IV 1ГГц

·          объем ОЗУ 256 MB;

·          HDD 40 Гб;

·          монитор с диагональю 17”-19” с разрешением 1024*768 точек при цветовой палитре 65 536 цветов и удовлетворяющий нормам безопасности ТСО 92 и ТСО 95;

·          видео карта типа SVGA 4-8 Мб VRAM;

·          сетевая карта 100 Мбит;

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

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

·          устройство печати.

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

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

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

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

2. Проектная часть

2.1 Техническое задание

Оформление технического задания осуществлялось на основании ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы; введ. 01.01.1990.

2.1.1 Полное наименование системы и ее условное обозначение

Управление, изготовление заказов (ИС “УИЗ”).

2.1.2 Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты

Заказчик: Специализированное управление треста “Сургутремстрой” ОАО “Сургутнефтегаз”. Начальник производственной базы – Огородов Сергей Викторович ул. Аэрофлотская д. 2 каб 110 тел. 40-12-81

Разработчик: Чернобровкин Виталий Викторович студент 6-го курса МосАП, г Сургут ул. Маяковского д. 47 кв. 39 тел. 89222590472.

Информационная система разрабатывается согласно ГОСТ 34-602-89 ИТ.

2.1.3 Плановые сроки начала и окончания работы по созданию системы

·          Срок начало работы по созданию ИС: 26 06 09.

·          Окончание работы 15 02 10.

·          порядок оформления и предъявления заказчику результатов работ по созданию системы (ее частей), по изготовлению и наладке: 1) демонстрация ИС в приложении PowerPoint написанной с помощью Case – средства BPwin. 2) Демонстрация работы Базы Данных написанной в приложении Access.

2.1.4 Порядок оформления и предъявления заказчику результатов работ по созданию системы

1) Заказчику передается: технический проект, загрузочный модуль, инструкции пользователя

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

·          технический проект: CD, 2 экземпляра, pdf – файл;

·          рабочий проект: CD, 2 экземпляра, pdf – файл;

·          загрузочный модуль: на CD, 2 экземпляра, exe – файл;

·          инструкции пользователя: на CD, 2 экземпляра, pdf – файл.

2.1.5 Назначение системы

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

2.1.6 Цель создания

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

2.1.7 Характеристика объекта автоматизации

Организационная структура:

1) Начальник производственной базы;

2) Мастер СМР;

3) Бригадир по изготовлению СВ И КВ;

4) Рабочие изготовители;

Номенклатура видов предоставляемых услуг: 1 (администрирование БД); Количество отчётов в месяц: 20; Количество запросов информации: 50; Количество функций системы: 6.

1) Учет ТМЦ;

2) Вычисление площади заготовок;

3) Учет бракованных изделий;

4) Учет расписания тех. специалистов;

5) Учет объема дневной выработки;

6) Учет объема месячной выработки.

Количество исполнителей: 1.

2.2 Требования к Информационной системе

2.2.1 Требования к системе в целом

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

2.         Система должна эксплуатироваться как одним, так и несколькими пользователями.

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

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

5.         Если в системе имеется особая или секретная информация, то она должна иметь код доступа (пароль).

6.         Режим функционирования – диалоговый (интерактивный).

2.2.2 Требования к численности и квалификации персонала

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

·          Квалификация пользователей должна быть на уровне “уверенного пользователя”. Т.е. пользователь должен хорошо разбираться и работать в приложении Access из пакета Microsoft Office ОС Windows XP Professional.

2.2.3 Показатели назначения

·          Жизненный цикл системы: 3 года.

·          Степень приспособляемости системы к изменению процессов: открытая система.

·          Допустимый предел модернизации: 40%

2.2.4 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

·          Режим эксплуатации ТС: односменный (8 часов).

·          Виды и периодичность обслуживания ТС системы: по мере возникновения неполадок.

·          Форма обслуживания: специалистами объекта автоматизации

2.2.5 Требования к защите информации

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

2.2.6 Требования к сохранности информации при аварийных ситуациях

АРМ должен гарантированно функционировать 8 часов в сутки, 5 дней в неделю. При аварийных ситуациях предусмотрены действия:

2.2.7 Требования по сохранности информации при авариях

Резервное копирование данных на внешних носителях.

2.2.8 Требования к функциям (задачам), выполняемым системой

Структура системы:

1) подсистема «Заготовка»; назначение: вычисление площади; функции:

·          ввод данных об изделии;

·          обновление информации по каждой заготовке;

·          выборка информации по каждому изделию;

·          ввод информации по объектам монтажа;

·          обновление информации по объектам монтажа;

·          выборка информации по партиям;

·          ввод данных по ТМЦ;

·          обновление информации по ТМЦ.

2.3 Требования к видам обеспечения

2.3.1 Математическое обеспечение

·          Состав формул и функций семантически прост и легок в понимании;

·          Построение формул для вычисления согласно ГОСТам применяемых в образовании;

·          Используется метод прямого счета.

2.3.2 Лингвистическое обеспечение

Требования к языкам разработки ИС зависят от метода проектирования:

·          Представляет собой языки программирования на, которых пишется ИС, т.е. SQL,VBA – языки, применяемые в разработке БД в приложении Access.

Требования к языкам ввода – вывода:

·          Ввод-вывод данных осуществляется с использованием типовых инструментов (радиокнопок, флажков, полей редактирования, меток, текстовых кнопок и т.д.).

Требования к языкам манипулирования данными:

·          Используется язык SQL, Формирование кода запроса осуществляется программой и пользователем, который с использованием визуальных компонентов (радиокнопки, выпадающий список и т.д.) задает ключевые параметры запроса.

2.3.3 Информационное обеспечение

Требования к составу, структуре и способам организации данных в системе:

1) Характеристики внутреннего ИО:

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

Структура данных: реляционная.

Способ организации данных: локальный

2) Характеристики внешнего ИО:

Номенклатура документов: заказы на изготовление, чертеж – подмерка, отчеты по выполненным заказам, отчеты использованным ТМЦ, отчеты по объектам.

Порядок хранения документов:

·          место хранения: РМ пользователем мастера СМР;

·          форма хранения: однотипные документы группируются в Дела.

правила выдачи документов:

·          выдача подлинников документов разрешается только сотрудникам организации;

·          выдача документов осуществляется с оформлением листа-заместителя, в котором указывается: наименование документа; дата выдачи; ФИО – сотрудника, взявшего документ; дата возврата документа; роспись сотрудника, взявшего документ.

Требования к информационному обмену между компонентами системы:

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

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

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

·          ОКОНХ – общегосударственный классификатор отраслей;

·          ОКПО - общегосударственный классификатор предприятий и организаций;

·          ИНН – индивидуальный налоговый номер;

·          Документы бухгалтерского учета – положение министерства финансов № 285/2 от 1.01.96. о бухгалтерском учете на крупных предприятиях.

Требования к применению систем управления базами данных:

Используется настольная СУБД MS Access.

Требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных:

·          Сбор данных осуществляется сотрудниками организации (источники: информация от заказчика, тех. специалистов);

·          Обработка данных осуществляется пользователем (мастером СМР) и системой: мастер СМР осуществляет ввод данных в БД; система осуществляет формирование отчетов.

Требования к защите данных от разрушений при авариях и сбоях в электропитании системы:

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

Использование источника бесперебойного питания на компьютере мастера СМР.

Требования к контролю, хранению, обновлению и восстановлению данных:

1) Обновление данных осуществляется пользователем (мастером СМР);

Поставщики обновлений: начальник участка №3, Мастера участка №3, технический специалист (подмерщик), Производитель работ участка №7.

2) Контроль данных осуществляется пользователем (мастером СМР).

3) Хранение данных: данные хранятся в реляционной БД.

4) Восстановление данных осуществляется пользователем (мастером СМР).

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

Для относительно быстрой разработки БД применяется пакет прикладных программ AllFusionModeller, в состав которого программы ERwin, Bpwin (IDEF0). Интегрирующиеся на любую платформу СУБД: Oracle, Access, dBase IV, FoxPro и т. д.

Рекомендуемые технические средства и операционная система: ПЭВМ типа IBM PC с ОС Microsoft Windows XP, Vista, пакет MS Office приложение MS Access.

2.3.5 Требования к техническому обеспечению системы

1.         Процессор Intel Pentium II 400 МГц и выше;

2.         Оперативная память 128 Мбайт и выше;

3.         Жесткий диск (200 Мбайт свободного места) и выше;

4.         Устройство чтения компакт дисков;

5.         SVGA –дисплей;

6.         принтер, формат листов: А4, скорость печати: 10 страниц в минуту и выше;

7.         Клавиатура;

8.         Манипулятор мышь;

9.         видео карта типа SVGA 4-8 Мб VRAM;

10.      сетевая карта 100 Мбит (в зависимости от сети);

11.      устройство печати.

2.3.6 Требования к организационному обеспечению

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

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

Функционирование ИС будет осуществляться:

1) по сопровождению ПО: проектировщиком;

2) по сопровождению технических средств: пользователем системы.

2.4 Состав и содержание работ по созданию системы

Таблица 2.1 – Состав и содержание работ по созданию системы

Состав работ при проектировании ИС:

·          Построение информационной модели;

·          Выявление проблем и недостатков в ИС цеха вентзаготовок ;

·          Определение области, на которую будет ориентирована ИС;

·          Создание базы данных;

·          Определение потоков информации “откуда – куда”;

·          Построение информационной модели цеха вентзаготовок «TO – BE»;

·          Прогонка ИС;

·          Сдача ИС в эксплуатацию.

2.5 Информационная модель

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

Рисунок 2.1 – Контекстная диаграмма информационной модели цеха вен заготовок

Стрелками указаны основные информационные потоки:

Заказы на изготовление продукции и ТМЦ – поступают от руководства СУ;

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

Трудовые отношения основываются на статьях и правилах Трудового кодекса РФ (Трудовой договор);

Изделия изготавливаются согласно строительным правилам и нормам (СНиПы);

Сметы на изготовление деталей, начисление заработной платы осуществляет Бухгалтерия;

Готовая продукция сортируется в системы (партии) и отправляется на объекты монтажа;

Отчетная документация (наряды) отправляются в отделы ПЭО, ПТО.

Потоки информации и их обработка показаны на рисунке 2.2.

Рисунок 2.2 – Контекстная диаграмма потоки информации

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

Алгоритм поступления, обработки и выдачи информации:

Поступление

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

·          Начальник участка в начале каждого месяца завозит листовой металл (ТМЦ) разной толщины. Стандартные размеры листа любой толщины длина – 2500 мм, ширина – 1250 мм. Из листов изготавливаются узлы и детали СВ и КВ. Чем больше по размерам деталь, тем толще берется лист для её изготовления;

·          Мастера по монтажу СВ и КВ, каждый из которых ведет свой объект монтажа ежедневно утром выдают заказ на изготовления партий СВ и КВ. Каждая партия состоит из деталей и узлов СВ и КВ и имеет свое название. П – приточка, В – вытяжка, ВЕ – вытяжка естественная. В свою очередь в состав монтажа любой партии входит, прежде всего, вентилятор определенной мощности (согласно СНиПам), калорифер (в зимнее время по нему проходит горячая вода), кондиционер, шумоглушитель, определенного типа клапана (с электроприводом либо ручным приводом) а уже затем крепятся (монтируются) детали партии.

Обработка

·          Каждый заказ это – комплект из двух бумажных документов: чертеж – который называется подмерка и комплектовочная ведомость, в которой указан объект монтажа, название партий (соответственно приточка и вытяжка[1]), описываются наименования деталей и их номера (которые должны соответствовать с номерами в подмерке), количество деталей, их параметры (высота, ширина[2] и длина детали), если деталь – отвод, то дан его градус т.е. обычно это 900;

·          Ежедневно утром бригадир, получив заказ, раскладывает подмерку и комплектовочную ведомость. Рабочие, подойдя к столу, отмечают выбранную для изготовления деталь, если им что-то не ясно как её изготовить, например переход из одной развертки в другую, то они смотрят в подмерку, в которой нарисован подробный чертеж и понумерованно указаны все Изготавливаемые детали. Отметив деталь, рабочие приступают к ее изготовлению;

·          После того как все детали будут помечены, а это означает, что заказ обработан, бригадир складывает оба документа в папку и так он поступает с каждым заказом;

·          Заказы бывают большими по объему (до 400 м2), средними (до 250 м2), малыми (до 15 м2), среднем в день выдается до 300 м2, все зависит от время года, количества рабочих, и объектов монтажа. Так например летом делается больше объема, а в зимнее время соответственно меньше.

Выдача

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

2.6 Выявление проблем и недостатков в ИС цеха вентзаготовок

Выявление проблем в ИС цеха вентзаготовок распределено по информационным потокам и разбито на 3 этапа:

Первый этап - Проблемы в поступлении информации

На каждый объект монтажа чертится (рисуется) схема (подмерка) систем вытяжной и приточной вентиляции. После чего создается заказ на изготовление и по подмерке составляется комплектовочная ведомость см. ПРИЛОЖЕНИЕ Г. Но каждая подмерка имеет погрешность примерно в 10 - 15%. т.е. замерщик не может точно до конца вымерить все системы, так как это практически не возможно. В основном все системы подвешиваются на определенной (иногда на большой) высоте. И для замеривания замерщику нужно подняться на высоту, что не всегда возможно, поэтому он берет приблизительную величину. В дальнейшем при монтаже звеньевые домеряют нужные расстояния и заказывают мастерам, что бы те в свою очередь составили заказ и передали его в цех на изготовление. Рабочий день мастера по монтажу СВ и КВ начинается в цехе вентзаготовок, где он делает заказ. Затем он забирает выполненный заказ и отправляет его на объект монтажа. После чего он сам едет на объект монтажа, на котором, находится максимум два часа и уезжает на другой объект, так как, все мастера ведут сразу несколько объектов. Объекты монтажа находятся на разных расстояниях и чтобы добраться до них, требуется время. Все зависит от дальности объекта.

Проблема заключается в том, что дополнительные заказы с каждого объекта фактически невозможно за один день передать в цех вентзаготовок. Так как мастеру их надо собрать со всех ведомых объектов. Утвердить у начальника участка по изготовлению СВ и КВ, передать в цех, дождаться их изготовления и развести по объектам монтажа. А иногда дополнительный заказ по объему бывает большой. Либо если объект монтажа большой, то дополнительных заказов бывает много, а то и несколько на день. Чтобы решить эту проблему мастера связываются по мобильному телефону с бригадиром и начинают диктовать наименование деталей их параметры и количество, соответственно указывая объект монтажа. Но и тут иногда выявляется проблемы. Из-за огромного объема информации мастера иногда путают наименования деталей, их параметры и объект монтажа. Из-за этого получается путаница в изготовлении, что приводит пусть к небольшим, но негативным экономическим последствиям. Проблемы при поступлении показаны на рисунке 2.3.

Рисунок 2.3 – Проблемы при поступлении информации

Исходя из рис. 2.3 можно увидеть основные проблемы при поступлении информации:

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

·          Увеличение времени на принятие информации и начальную (первичную) обработку информации по всем заказам. Происходит путаница в уточнении. К примеру: один мастер говорит одну информацию по объекту, через короткий промежуток времени начальник участка (либо другой мастер) по монтажу СВ и КВ дает другую информацию по этому же объекту.

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

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

Принятая на обработку информация в основном своем содержании имеет более трети ненужной информации (информационный шум). В основном происходит дублирование информации. Т. е. сначала мастера звонят с объекта и просят записать некоторые дополнительные заказы, затем старшие по объекту (звеньевые) выдают туже информацию, тем самым, отвлекая бригадира от работы. Помимо этого некоторые мастера, прибыв в цех, вместо того, чтобы сразу выдать на бумаге дополнительный заказ, начинают оправдываться в своих оплошностях при ведении того или иного объекта (абсолютно не нужная бригадиру информация). Обычно любой дополнительный заказ пишется на бумаге формата А4, в котором указан объект монтажа, дата заказа, наименования деталей, их количество. Он немного схож с таблицей Комплектовочная ведомость, только не имеет самой таблицы. Но при осмотре некоторых дополнительных заказов были обнаружены грубые нарушения:

·          нет даты заказа;

·          нет наименования объекта;

·          у некоторых деталей нет половины параметров;

·          некоторые дополнительные заказы написаны на клочке бумаги;

На рисунке 2.4 можно увидеть основные проблемы при обработке информации, это:

·          Увеличение времени обработки информации. Нет ежедневного (приблизительного) плана изготовления продукции;

·          Из-за значительного числа заказов, уменьшается темп их обработки. Идет выявление приоритетности заказа, в котором в свою очередь тоже идет приоритетность изготовления. Всё зависит от объема заказа;

·          Если нет приоритетности, то начинается изготовление нескольких заказов одновременно. Что в свою очередь не правильно, так как, всей бригаде приходиться перестраиваться на другой темп и лад работы. Например, детальщики[3] становятся на изготовление труб.

Рисунок 2.4 – Обработка информации

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

Третий этап - Проблемы в выдаче информации

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

Рисунок 2.5 – Выдача информации

Исходя из рисунка 2.5 видно, что:

1.         бракованные детали это неправильно изготовленные детали. Деформированные детали идут в металлолом, а возвратными деталями доукомплектовывают партии, что приводит к значительным затратам во времени;

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

Помимо всех вышеперечисленных проблемах существует одна масштабная проблема. Это то, что несмотря на компьютеризацию рабочих мест мастеров и начальников участков, основной документооборот происходит в бумажном виде. А базовые знания владения компьютером оставляет желать лучшего. Мастера очень медленно печатают (составляют отчеты). Многочисленные расчеты при разного рода вычислениях происходят вручную при помощи калькулятора либо приложения «Калькулятор» находящегося в составе ОС Widows.

2.7 Определение области ориентирования

Область определения на которую ориентирована ИС, это создание АРМ мастера СМР специализация - вентиляция. То есть, это автоматизация некоторых вычислительных процессов с помощью стандартного приложения MS Access.

2.8 Создание Базы данных

Состав и содержание работ по проектированию БД показан в таблице 2.1.

Таблица 2.2– Структура работ

2.8.1 Структура таблиц созданной базы данных

Таблица 2.3 – Таблицы БД

Таблица 2.4 – ПЕРСОНАЛ

Таблица 2.5 – ВСТАВКА

Таблица 2.6 – КОРОБ

Таблица 2.7 – ОТВОД

Таблица 2.8 – ПЕРЕХОД

Таблица 2.9 – РЕЙКА

Таблица 2.10 – Лента_КРЕПЁЖ

Таблица 2.11 – РЕШЁТКА

Таблица 2.12 – РЕЗУЛЬТАТ

Результат создания таблиц показан на рисунке 2.7.

Рисунок 2.7 – Таблицы

2.8.2 Описание запросов к базе данных

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

Запрос 1

Имя файла  запроса: Вставка_Запрос

Текст на SQL:

Вывести общую информацию из таблицы “ВСТАВКА”.

SELECT Заготовка_ВСТАВКА.[№п/п], ВСТАВКА.[Наимен заготовки], ВСТАВКА.[Развертка выс], ВСТАВКА.[Развертка шир], ВСТАВКА.[Длина мм], ВСТАВКА.[Площадь м кв]

Данная операция вычисляет площадь заготовки “Вставка”:

FROM ВСТАВКА

WHERE (((ВСТАВКА.[Площадь м кв]) Like 'In(SELECT(([ВСТАВКА].[Развертка выс]*[ВСТАВКА].[Развертка шир])*[ВСТАВКА].[Длина мм])*2'));

Запрос 2

Имя файла  запроса: Короб_Запрос

Текст на SQL:

Вывести общую информацию из таблицы “КОРОБ”.

SELECT КОРОБ.[№п/п], КОРОБ.[Наимен заготовки], КОРОБ.[Развертка выс], КОРОБ.[Развертка шир], КОРОБ.[Длина мм], КОРОБ.[Площадь м кв]

Данная операция вычисляет площадь заготовки “КОРОБ”:

FROM Заготовка_КОРОБ

WHERE (((КОРОБ.[Площадь м кв]) Like 'In (SELECT(([КОРОБ].[Развертка выс])*([КОРОБ].[Развертка шир]))*([КОРОБ].[Длина мм])))'));

Запрос 3

Имя файла  запроса: Отвод_Запрос

Текст на SQL:

Вывести общую информацию из таблицы “ОТВОД”.

SELECT ОТВОД.[№п/п], ОТВОД.[Наимен заготовки], ОТВОД.[Развертка шир], ОТВОД.Градусы, ОТВОД.[Длина затылка], ЗОТВОД.[Ширина затылка], ОТВОД.[Длина шейки], ОТВОД.[Ширина шейки], ОТВОД.[Площадь в м кв] AS Выражение1

Данная операция вычисляет площадь заготовки “ОТВОД”:

FROM ОТВОД

WHERE ((([ОТВОД].[Площадь в м кв]) Like 'In(SELECT((((((3,14)*(([ОТВОД].[Развертка шир])*([ЗОТВОД].[Развертка шир])))/4)+([ОТВОД].[Длина шейки]*[ОТВОД].[Развертка

шир])*2)+([ОТВОД].[Длина шейки]*[ОТВОД].[Развертка шир])+([ОТВОД].[Длина затылка]*[ОТВОД].[Развертка длина])))))) ';

Запрос 4

Имя файла  запроса: Переход_Запрос

Текст на SQL:

Вывести общую информацию из таблицы “ПЕРЕХОД”.

SELECT ПЕРЕХОД.[№п/п], ПЕРЕХОД.[Наимен заготовки], ПЕРЕХОД.[Развертка выс макс], ПЕРЕХОД.[Развертка выс мин], Заготовка_ПЕРЕХОД.[Развертка шир макс], ПЕРЕХОД.[Развертка шир мин], ПЕРЕХОД.[Длина мм], ПЕРЕХОД.[Площадь м кв]

Данная операция вычисляет площадь заготовки “ПЕРЕХОД”:

FROM ПЕРЕХОД

WHERE (((ПЕРЕХОД.[Площадь м кв]) Like 'In(SELECT((((([ПЕРЕХОД].[Развертка выс макс]+[ПЕРЕХОД].[Развертка шир макс])*[ПЕРЕХОД].[Длина мм]))*(0,5))*2)+(((([ПЕРЕХОД].[Развертка выс мин]+[ПЕРЕХОД].[Развертка шир мин])*([ПЕРЕХОД].[Длина мм])*(0,5))*2)))))'));

Запрос 5

Имя файла  запроса: Рейка_Запрос

Текст на SQL:

Вывести общую информацию из таблицы “РЕЙКА”.

SELECT РЕЙКА.[№п/п], РЕЙКА.[Наимен заготовки], РЕЙКА.[Развертка длина], РЕЙКА.[Развертка шир], РЕЙКА.[Площадь м кв]

Данная операция вычисляет площадь заготовки “РЕЙКА”:

FROM РЕЙКА

WHERE (((РЕЙКА.[Площадь м кв]) Like 'In(SELECT([РЕЙКА].[Развертка длина]*[РЕЙКА].[Развертка шир]))'));

Запрос 6

Имя файла  запроса: Лента_Крепёж_Запрос

Текст на SQL:

Вывести общую информацию из таблицы “ ЛЕНТА_КРЕПЁЖ ”.

SELECT ЛЕНТА_КРЕПЁЖ.[№п/п], ЛЕНТА_КРЕПЁЖ.[Наимен заготовки], ЛЕНТА_КРЕПЁЖ.[Длина мм], ЛЕНТА_КРЕПЁЖ.[Ширина мм], ЛЕНТА_КРЕПЁЖ.[Площадь м кв]

Данная операция вычисляет площадь заготовки “ ЛЕНТА_КРЕПЁЖ ”:

FROM ЛЕНТА_КРЕПЁЖ

WHERE (((ЛЕНТА_КРЕПЁЖ.[Площадь м кв]) Like 'In(SELECT([ЛЕНТА_КРЕПЁЖ].[Длина мм]*[ЛЕНТА_КРЕПЁЖ].[Ширина мм]))'));

Запрос 7

Имя файла  запроса: Решётка_Запрос

Текст на SQL:

Вывести общую информацию из таблицы “ РЕШЁТКА ”.

SELECT РЕШЁТКА.[№п/п], РЕШЁТКА.[Наимен заготовки], РЕШЁТКА.[Длина мм], РЕШЁТКА.[Ширина мм], РЕШЁТКА.[Площадь м кв]

Данная операция вычисляет площадь заготовки “ РЕШЁТКА ”:

FROM РЕШЁТКА

WHERE (((РЕШЁТКА.[Площадь м кв]) Like 'In(SELECT([РЕШЁТКА].[Длина мм]*[РЕШЁТКА].[Ширина мм]))'));

Запрос 8

Имя файла  запроса: Отходы_Запрос

Текст на SQL:

Вывести общую информацию из таблицы “ ОТХОДЫ ”.

SELECT ОТХОДЫ.[№п/п], ОТХОДЫ.Материал, ОТХОДЫ.[Площадь мат м кв], ОТХОДЫ.Заготовка, ОТХОДЫ.[Площадь заг м кв], ОТХОДЫ.[Количество шт], ОТХОДЫ.[Общая площадь загот], ОТХОДЫ.Отходы

Данная операция вычисляет площадь материала, который остается после изготовления деталей:

FROM ОТХОДЫ

WHERE (((ОТХОДЫ.[Общая площадь загот]) Like 'In(SELECT([ОТХОДЫ].[Площадь заг м кв]*[ОТХОДЫ].[Количество шт])') AND ((ОТХОДЫ.Отходы)='In(SELECT([ОТХОДЫ].[Площадь мат м кв]-[ОТХОДЫ].[Общая площадь загот])'));

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

Запрос 9

Имя файла  запроса: Результат_Запрос

Текст на SQL:

Вывести итоговую информацию из таблицы 2.12 – РЕЗУЛЬТАТ, которая отражает: какое количество деталей можно сделать из остатков металла полученных при изготовлении определенной заготовки.

SELECT РЕЗУЛЬТАТ.[№п/п], РЕЗУЛЬТАТ. Материал, РЕЗУЛЬТАТ.[Площадь листа], РЕЗУЛЬТАТ.[Наимен заготовки], РЕЗУЛЬТАТ.[Площадь заготовки м кв], Abs([Площадь листа]-[Площадь заготовки м кв]) AS Остаток, Round([Остаток]/[Площадь заготовки м кв]) AS [Заготовка из остатка шт]

FROM РЕЗУЛЬТАТ;

Результат создания запросов показан на рисунке 2.8.

Рисунок 2.8 – Запросы

На рисунке 2.9 показан результат создания форм.

Рисунок 2.9 - Формы

Главная форма в режиме Конструктора показана на рис. 2.10.

Рисунок 2.10 – Главная форма

Разработанная СУБД “Производственный процесс”в приложении Access в режим Просмотр показана на рисунке 2.11.

Рисунок 2.11 – Разработанная СУБД

2.8.3 Порядок контроля и приемки системы

·          Статус приемочной комиссии: вневедомственная;

·          Испытание системы осуществляется с использованием контрольного примера;

Место – База подготовки производства специализированного управления треста «Сургутремстрой» ОАО «Сургутнефтегаз», 10.02.2010.

2.8.4 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

1) Установка программы на ПК мастера СМР (пользователя);

2) Обучение пользователя основам работы в программе;

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

2.8.5 Требования к документированию

·          Документация на разрабатываемую программную систему включает:

·          Техническое задание в соответствии с ГОСТ 34.602-89;

·          Информационное обеспечение РД 50-34.698-90;

·          Технологическая сеть проектирования;

·          Постановка задачи РД 50-34.698-90;

·          Руководство Пользователя (см ПРИЛОЖЕНИЕ Е);

2.8.6 Источники разработки

1) Методическое пособие по MS Access.

2) Рабочая документация: чертежи - подмерки, комплектовочные ведомости, заказы на изготовления.

3) Литература по CRM – концепции.

2.8.7 Используемые классификаторы и системы кодирования

В составе информационного обеспечения рассматриваемого комплекса задач важное место отводится классификаторам экономической информации:

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

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

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

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

Системы кодирования делятся на регистрационные и классификационные.

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

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

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

После регистрации всех данных и/или в конце отчётного периода, формируется файл отчёта в соответствии с тем, какой отчёт необходим. Для кодирования данного файла было определено несколько признаков классификации. Среди них: дата создания документа, заказ, объект монтажа, система[5], вид отчета. После анализа структуры была выбрана комбинированная система кодирования

На рисунке 2.12 показана структура кодируемого элемента.

XXXXXX.X. X. XX. XXХ

Вид отчета.

Система.

Объект монтажа.

Заказ.

Дата создания документа.

Рисунок 2.12 – Структура кодируемого элемента

Дата создания документа.

Формат: ДД ММ ГГ.

Например: 010209– 1 февраля 2009г.

Заказ.

Формат: 1

Трёхзначное число;

Объект монтажа

Формат: 1

1 – наименовании.

Система.

Формат:1 – 2

1 – Вытяжка;

2 – Приточка.

Вид отчёта.

Формат: 1- 3.

1 – отчёт по сделанным партиям;

2 – отчёт по каждому рабочему;

3 – отчет по всем рабочим.

2.8.8 Характеристика входной оперативной информации

Описание входной оперативной информации.

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

1.         Для решения задач вычисления площади вентзаготовок используется документ “Комплектовочная ведомость”. Таблица “Комплектовочная ведомость” является многострочным документом. Количество документострок от 20 до 50. Число документов в среднем около 70 в месяц. Макет размещения информации представлен в приложении 3;

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

2.8.9 Характеристика результатной информации

Результатная информация может быть как в электронном виде, так и в виде бумажного документа.

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

·          объему выполненных работ;

·          площадь заготовки;

·          информация о рабочих бригады по изготовлению СВ и КВ.

Итоговые отчеты показаны в приложениях 5 и 6.

2.8.10 Определение потоков информации «откуда» - «куда»

На рисунке 2.13 отражено направление потоков информации в цехе вентзаготовок.

Рис. 2.13 – Потоки информации в цехе вентзаготовок

2.9 Информационная модель цеха вентзаготовок «TO - BE»

На рис 2. 14 отражена информационная модель «TO - BE» цеха вентзаготовок.

Рисунок 2.14 – Модель «TO - BE» ИС цеха вентзаготовок

Рисунок 2.15 показывает как происходит получение и обработка заказов в цехе вентзаготовок модели «TO – BE».

Рисунок 2.15 – Получение и обработка заказов

Рисунок 2.16 отражает нужное направление информации при комплектации заказов, их распределение на рабочий день, а также распределение по объектам монтажа в модели «TO – BE».

Рисунок 2.16 – Декомпозиция «Получение и обработка заказов»

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

Рисунок 2.17 - Приоритетность изготовления заказов

3. Обоснование экономической эффективности проекта

3.1 Выбор метода оценки обоснования экономической эффективности

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

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

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

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

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

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

З = Р + ЕnK (1.1.)

В свою очередь приведенные затраты зависят от объема обработанной информации и складываются из:

Р – эксплуатационные расходы на функционирование системы;

К – капитальные (единовременные) затраты на разработку системы;

Еn - нормативный коэффициент приведения затрат к единому году. Для вычислительной техники Еn = 0,25 ¸0,35.

Капитальные затраты на обработку системы

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

К = Кпр + Коб + Квс + Кпм + Кмит (1.2.)

Кпр – затраты на проектирование системы, руб.;

Коб – затраты на основное оборудование, руб.;

Квс – затраты на вспомогательное оборудование, руб.;

Кпм – затраты на строительство и ремонт помещений, руб.;

Кмит – затраты, связанные с монтажом, наладкой и транспортировкой оборудования.

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

(1.3.)

Зi – заработная плата работников i – категории, руб. в месяц;

Т – время работы, месяцев;

f – коэффициент отчислений на заработную плату;

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

Дпр – прочие расходы (затраты на командировку, телефон и почтовые услуги), как правило, равные 0,7 стоимости оборудования.

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

Затраты на основное оборудование:

Коб = Соб (1 + kус), (1.4.)

где kус - коэффициент установки; kус = 0,01 ¸0,02;

Соб- балансовая стоимость оборудования, руб.

Затраты на вспомогательное оборудование определяются либо прямым счетом, либо пропорционально стоимости оборудования:

Квс = (0,15 ¸0,02) Соб.(1.5.)

Затраты на монтаж, наладку и транспортировку оборудования зависят от сложности оборудования, его количества, а так же способа и стоимости перевозки. Для предварительных расчетов затраты принимаются на уровне 10 - 20% стоимости основного оборудования:

Кмнт = (0,10 ¸0,20) Соб.(1.6.)

Затраты на строительство и реконструкцию помещения определяется либо прямым счетом, либо относительно стоимости основного оборудования:

Кпм = (0,20 ¸0,50) Соб.(1.7.)

Таким образом, общая величина капитальных (единовременных) затрат составляет 2,16 ¸ 2,62 балансовой стоимости основного оборудования.

Эксплуатационные расходы на функционирование системы

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

Р = Росн + Рауп + Робщ (1.8.)

Росн – заработная плата основного производственного персонала, руб.;

Рауп - заработная плата административно - управленческого персонала (АУП). руб.;

Рауп = 0.25 Росн (1.9.)

Робщ – общепроизводственные расходы, руб.

Общепроизводственные расходы включают в себя:

Робщ = Рэн + Рм + Ррем + Рзап + Ркс + Рпр (1.10.)

Рэн – затраты на оплату электроэнергии, руб.; зависят от количества оборудования, потребляемой мощности, кВт/ч;

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

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

Рзап – затраты, связанные с приобретением запчастей для ремонта оборудования, руб.; Ркс – затраты на аренду каналов связи, руб.;

Рпр – прочие расходы, руб., чаще всего Рпр = 0,6 Робщ.

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

= Э(1.11.)

где Р0 – расходы до разработки системы, руб.;

Р1 – расходы после разработки системы, руб..

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

Тр = К / Э, (1.12.)

Обратная величина будет представлять расчетный коэффициент приведения:

Ер = Э / К, (1.13.)

Ер – расчетный коэффициент приведения.

Этот показатель необходимо сравнить с нормативным коэффициентом приведения (Еn = 0,25 ¸0,35). В данном случае необходимо, чтобы соблюдалось следующее соотношение:

Ер< Еn.(1.14.)

3.2 Расчёт показателей экономической эффективности проекта методом приведённых затрат

Исходные данные по заработной плате персонала, расценкам и нормативным коэффициентам приведены в таблице 3.1.

Таблица 3.1 - Исходные данные

За один месяц потребление электроэнергии – 300 кВт/ч.

Рэн = 300*12*1=3600,00 руб.

Расходы на материалы за 12 месяцев составили:

Рм = 2020,00*12=24240 руб.

Расходы на ремонт (цена договорная):

Ррем =1000,00 руб.

Рзап =1000,00 руб.

Поскольку Робщ + Рпр = 3600,00+24240,00+1000,00+1000,00=29840,00 руб., то

Рпр =0,6*29840,00=17904,00 руб., следовательно,

Робщ = 29840,00+17904,00=47744,00 руб.

Расходы на материалы до внедрения ИС приведены в таблице 3.2.

Таблица 3.2 - Расходы на материалы до внедрения ИС

До разработки ИС работал начальник БПП, мастер СМР и ведущий специалист.

Так как учётом выполненного объема производства занимается только ведущий специалист, рассчитаем стоимость часа его работы.

Стоимость часа работы ведущего специалиста приведена в таблице 3.3.

Таблица 3.3 – Стоимость работы сотрудников

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

Таблица 3.4 – Затраты времени ведущего специалиста без использования автоматизированной системы

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

Таким образом расходы до внедрения ИС (Р0) составят:

Расчетный период –12 месяцев.

Росн= (50000,00+40000,00+30000,00)*12*0,26= 374400 руб.

Рауп = 0,25 *374400= 93600 руб.

Таким образом, эксплуатационные расходы до разработки и внедрения автоматизированной системы составляют:

Р =374400 + 93600 + 47744,00 = 515744 руб.

Теперь рассчитаем приведенные затраты после разработки и внедрения ИС.

Разработкой системы занимается 1 ведущий специалист, месячная заработная плата – 30000,00 рублей. Фактическое время, затраченное на разработку системы приведена в таблице 3.5.

Таблица 3.5 – Временные этапы разработки ИС

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

К = Кпр

Кпр = 30000,00*4*0,26 = 31200

К = 120000 + 31200 = 39312

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

Расходы на электроэнергию – 350 кВт/ч.

Рэн = 350*12*1=4200,00 руб.

В таблице 3.6 приведены расходы на материалы после внедрения ИС.

Таблица 3.6 - Расходы на материалы после внедрения ИС

Расходы на материалы за 12 месяцев составили:

Рм = 16800,00 руб.

Расходы на ремонт (цена договорная):

Ррем =1000,00 руб.

Рзап =1000,00 руб.

Робщ + Рпр =4200,00+16800,00+1000,00+1000,00=23000,00 руб.

Рпр =0,6*23000,00=13800,00 руб.

Робщ = 23000,00+13800,00=36800,00 руб.

После разработки и внедрения ИС также остались работать начальник БПП, мастер СМР и ведущий специалист.

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

Таблица 3.7 – Затраты времени ведущего специалиста с использованием ИС

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

Расходы за расчетный период (12 месяцев) после внедрения ИС составили:

Росн=(50000,00+40000,00+11999,904)*12*0,26=318239,7 руб.

Рауп = 0,25 * 318239,7 = 79559,92 руб.

Таким образом, эксплуатационные расходы после разработки и внедрения ИС составляют:

Р = 318239,7 + 79559,92 + 36800,00 = 434559,62 руб.

Р1= 434559,62 руб.

Приведенные затраты:

З = 434559,62 + 0,25 * 39312 = 444387,62 руб.

Условный экономический эффект = 515744 – 444387,62 = 71356,38 руб.

Срок окупаемости:

Тр = 39312 / 71356,38 = 0,55 месяцев

Расчетный коэффициент:

Ер = 71356,38 / 39312 = 1,8

Результаты расчета представлены в таблице 8.

Таблица 3.8 – Результаты расчёта экономической эффективности проекта

Заключение

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

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

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

Данная система позволяет:

Ø   Вычислять площади вентзаготовок любой сложности изготовления;

Ø   производить быстрый поиск документов по их кодам и названиям;

Ø   выводить отчеты на печать.

В дальнейшем планируется расширение базы данных:

·          Добавление информации по складу ТМЦ;

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

·          Учет ТМЦ

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

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

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

1.         Алфимов Р.В., Красникова С.А., Золотухина Е.Б. Способ описания функциональных требований к системе и ее функций с использованием стандартов и универсального языка моделирования. – (http://www.interface.ru/home.asp?artId=16728)

2.         Благодатских В.А. Стандартизация разработки программных средств: Учебн. Пособие. – М.: Финансы и статистика, 2005.

3.         Багиев Г.Л. Маркетинг: Информационное обеспечение. Бенчмаркинг. Диагностика - СПб: СПб ГУЭФ, 1998.

4.         Вендров А.М. Практикум по проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2006.

5.         Вендров А.М. Проектирование программного обеспечения экономических информационных систем: учебник. – М.: Финансы и статистика, 2006.

6.         Грекул В. И. Проектирование информационных систем, 2005.

7.         Жоголев Е.А. Технология программирования. - М.: Научный мир, 2004.

8.         Иванова Г.С. Технология программирования: Учебник для вузов.- М.: Изд-во МГТУ им. Н.Э. Баумана, 2002.

9.         Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. Учебное пособие: М.: Финансы и статистика, 2006.

10.      Кролл П., Кратчен Ф. Rational Unified Process – это легко. Руководство по RUP для практиков. Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2004. – 432 с

11.      Липаев В.В. Программная инженерия. Методологические основы : Учеб.: Гос. ун-т — Высшая школа экономики. — М. : ТЕИС, 2006.

12.      Колясников С.А. Корпоративные информационные системы. Взгляд изнутри Москва МИСИС, 2000.

13.      Корпоративные информационные системы // http://www.nyagan.ru/

14.      Курчеева Г.И. Лекции Производственный менеджмент в КИС, 2009.

15.      Клочков Г.А. CASE – средства разработки информационных систем. Учебное пособие. Сургут, 2008.

16.      Кузнецов А.И. Microsoft Access 2003 Русская версия Учебный курс, 2006.

17.      Клуб информатиков – Технологические операции. www.northerncrown.ru Лиходедов Н.П., Товстых Л.Е. Информационные ресурсы для бизнеса. – СПб: Питер, 1999.

18.      Маклаков С.В. Создание информационных систем с AllFusion Modeling Suite.- М.: ДИАЛОГ-МИФИ, 2003.

19.      Мацяшек Л. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. – М.: Вильямс, 2002.

20.      Мирошниченко Г.А. Реляционные базы данных: практические приёмы оптимальных решений. СПб 2005.

21.      Орлик С., Булуй Ю. Введение в программную инженерию и управление жизненным циклом ПО: [электронный ресурс] http://www.sorlik.ru/swebok/3-software_engineering.pdf - доступ свободный.

22.      Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: реинжиниринг организации и информационные технологии. – М.: Финансы и статистика, 1998.

23.      Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. “Проектирование ЭИС” учебник Москва, 2003.

24.      Структура ТЭО, разработка, содержание ТЭО. http://www.bparkadia.ru/publication20.htm.

25.      Техническое задание Требования к содержанию и оформлению. www.nist.ru

26.      Технико – экономический анализ и обоснование рыночной новизны программного продукта. revolution.

27.      Федотова Д.Э., Семёнов Ю.Д., Чижик К.Н. CASE-технологии: практикум.- М.: Горячая линия –Телеком, 2005.

Приложения

Комплектовочная ведомость

Таблица А.1 – Комплектовочная ведомость

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

Приложение Б

Комплектовочная ведомость Отчет

№ Изделия 1

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

Сечение в мм 500x500

Длина в мм 2000

Центр угол 0

Площадь в мм 2 4

Количество шт 10

Партия П1

Объект монтажа УМиТ

Город Сургут

21 января 2010 г. Страница 1 из 1

Г.2 Персонал Отчет

№п/п 1

Ф И О раб Картавых Евгений

Должность слесарь по изг сист вентил

Разряд 5

Адрес г. Челябинск ул. Профсоюзов д12 кв7

Телефон 89222113409

Примечание Добросовестный, ответственный

№п/п 2

Ф И О раб Мансуров Марат

Должность слесарь по изг сист вентил

Разряд 4

Адрес Пермь ул Седова д10а кв134

Телефон 89121043546

Примечание Часто выпивает

№п/п 3

Ф И О раб Карагулов Ильдар

Должность слесарь по изг сист вентил

Разряд 4

Адрес Казань ул Ленина 35-108

Телефон 89224356676

Примечание

21 января 2010 г. Страница 2 из 2

Приложение В

Руководство пользователя

1.         Окно базы данных

Особым окном в Access является окно базы данных, которое позволяет получить доступ ко всем объектам базы данных и выбрать режим работы с объектом. В левой части окна находится панель объектов, которая содержит ярлыки для каждого из объектов Access: Таблицы (Tables), Запросы (Queries), Формы (Forms), Отчеты (Reports), Страницы (Pages), Макросы (Macros), Модули (Modules) (рис. 1).

Рисунок 1 – Окно базы данных Access 2000

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

·           в виде мелких значков;

·           в виде крупных значков;

·           в виде списка;

·           в виде таблицы.

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

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

1.         Щелкнуть правой кнопкой мыши на любом свободном участке окна базы данных.

2.         Из контекстного меню выбрать команду Выстроить значки (Line Up Icons).

Представление перечня объектов в виде списка не позволяет располагать значки произвольным образом в окне базы данных, но их можно "перетаскивать" за пределы окна базы данных (это один из способов активизировать объект, например открыть таблицу). Представление в виде таблицы позволяет для каждого объекта посмотреть не только его имя, но и описание (столбец Описание (Description)), дату и время последнего изменения (столбец Дата изменения (Modified)), дату и время создания (столбец Дата создания (Created)), а также тип объекта.

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

1.         Щелкнуть правой кнопкой мыши на любом свободном участке окна базы данных.

2.         Из контекстного меню выбрать команду Упорядочить значки (Arrange Icons).

3.         Из раскрывающегося меню выбрать способ упорядочения: по имени (By Name), по типу (By Type), по дате создания (By Created), по дате изменения (By Modified).

Чтобы объекты в окне базы данных упорядочились автоматически, необходимо:

1.         Щелкнуть правой кнопкой мыши на любом свободном участке окна базы данных.

2.         Из контекстного меню выбрать команду Упорядочить значки (Arrange Icons).

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

Чтобы отменить автоматическое упорядочение, необходимо снова выбрать команду автоматически (Auto Arrange) в меню Упорядочить значки (Arrange Icons). Метка команды будет удалена, а режим автоматического упорядочения выключен.

С каждым объектом базы данных можно работать в двух режимах. Первый режим назовем режимом выполнения (условно, т. к. он несколько различается для разных типов объектов):

·           для таблиц, запросов, форм и страниц доступа к данным этот режим означает открытие соответствующего объекта и называется, соответственно, режим Таблицы (для таблиц и запросов), режим Формы, режим Страницы;

·           для отчета — это режим предварительного просмотра;

·           для макроса — это действительно режим выполнения;

·           для модуля этот режим отключен.

Второй режим — это режим Конструктора. Данный режим применяется ко всем типам объектов и предназначен для создания и изменения объектов.

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

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

·           первая кнопка имеет изменяющееся название, в зависимости от того, какой объект выбран. Если выбраны таблица, запрос, форма, страница или группа Избранное (Favorites), кнопка приобретает вид Открыть (Open). Если выбран отчет — Просмотреть (Preview), если макрос или модуль — Запустить (Run). При этом значок рядом с названием соответственно изменяется. Название этой кнопки в каждом варианте наглядно отражает назначение;

·           вторая кнопка Конструктор (Design) постоянна для всех объектов и предназначена для редактирования ранее созданного объекта;

·           третья кнопка Создать (New) имеет постоянное название, но при этом изменяются значки на ней, в соответствии с типом объекта.

1.         Выделить ее в списке и нажать кнопку Открыть (Open).

2.         Перетащить значок таблицы мышью за пределы окна базы данных.

3.         Дважды щелкнуть кнопкой мыши по имени таблицы.

4.         Один раз щелкнуть левой кнопкой мыши по имени таблицы, если установлен флажок Одним щелчком (Single-click open) в диалоговом окне Параметры (Options).

Чтобы открыть любой объект в режиме Конструктора, необходимо выделить этот объект в списке и нажать кнопку Конструктор (Design).

Чтобы удалить объект из списка, нужно:

1.         Выделить объект в списке и нажать кнопку Удалить (Delete) в верхней части окна базы данных или клавишу <Delete> на клавиатуре или щелкнуть правой кнопкой мыши по имени объекта и из контекстного меню выбрать команду Удалить (Delete).

2.         В появившемся диалоговом окне, запрашивающем подтверждение на удаление объекта, необходимо нажать кнопку Да (Yes).

Чтобы переименовать объект, нужно:

1.         Выделить необходимую таблицу в списке.

2.         Щелкнуть левой кнопкой мыши на имени таблицы или щелкнуть правой кнопкой мыши на имени таблицы и из контекстного меню выбрать команду Переименовать (Rename).

3.         В поле имени таблицы ввести новое имя.

4.         Нажать клавишу <Enter> или щелкнуть левой кнопкой мыши на любом свободном месте в правой части окна.

Чтобы скопировать или переместить объект, можно воспользоваться стандартными программами копирования/вставки. Например, чтобы скопировать таблицу в буфер обмена (Clipboard), необходимо сделать одно из двух действий:

·           выделить требуемую таблицу в списке и нажать на кнопку Копировать (Сору) на стандартной панели инструментов База данных (Database);[ Эта панель отображается на экране, когда активным является окно базы данных. ]

·           щелкнуть правой кнопкой мыши на имени таблицы и из контекстного меню выбрать команду Копировать (Сору).

Чтобы вырезать таблицу в буфер обмена (Clipboard), нужно осуществить одну из двух операций:

·           выделить необходимую таблицу в списке и нажать на кнопку Вырезать (Cut) на панели инструментов База данных (Database);

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

Чтобы вставить таблицу из буфера обмена, нужно:

1.         Открыть список таблиц в окне базы данных.

2.         Нажать на кнопку Вставить (Paste) на панели инструментов База данных (Database) или щелкнуть правой кнопкой мыши на свободном поле в списке таблиц и из контекстного меню выбрать команду Вставить (Paste).

3.         В появившемся окне Вставка таблицы (Paste Table As) в поле Имя таблицы (Table Name) ввести имя новой таблицы, в группе Параметры вставки (Paste Option) выбрать вариант вставки таблицы: Только структура (Structure only), Структура и данные (Structure and Data), Добавление данных в таблицу (Append Data to Existing Table) и нажать кнопку ОК.

Режим вставки Только структура (Structure only) предназначен для копирования структуры таблиц, т. е. списка полей таблицы с указанием типа каждого поля и с его описанием. При этом не предусматривается копирование данных. В режиме Структура и данные (Structure and Data) таблица копируется целиком вместе со своим содержимым. В режиме Добавление данных в таблицу (Append Data to Existing Table) необходимо в поле Имя таблицы (Table Name) ввести имя существующей таблицы, после чего будет осуществлено добавление данных из таблицы, находящейся в буфере обмена, в указанную таблицу.

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

Чтобы посмотреть свойства объекта, необходимо проделать одну из следующих операций:

·           щелкнуть правой кнопкой мыши на имени объекта и из контекстного меню выбрать команду Свойства (Properties);

·           выделить объект из списка в окне базы данных и выбрать команду Вид, Свойства (View, Properties) из главного меню Access.

Рисунок 2 – Окно свойств таблицы

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

·           Тип (Туре) — тип объекта (в данном случае Таблица (Table));

·           Описание (Description) — описание таблицы, определяемое пользователем;

·           Создан (Created) — дата создания таблицы;

·           Изменен (Modified) — дата последнего изменения таблицы;

·           Владелец (Owner) — владелец (создатель) таблицы;

·           Атрибуты (Attributes): Скрытый (Hidden) — позволяет скрыть таблицу из окна базы данных, Реплицируемый (Replicated) — позволяет управлять реплицируемостью объекта.

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

На панели объектов можно размещать также папки, которые содержат ярлыки к различным объектам баз данных. Таким образом, можно объединять разные типы объектов в группы. По умолчанию в этой части панели объектов размещается одна папка — Избранное (Favorites). Щелкнув мышью по папке, можно увидеть список объектов, входящих в данную группу (рис. 3).

Чтобы добавить новую папку на панель объектов, нужно:

1.         Щелкнуть правой кнопкой мыши на панели объектов и выбрать из контекстного меню команду Новая группа (New Group).

2.         В диалоговом окне Новая группа (New Group) ввести имя создаваемой папки и нажать кнопку ОК.

Рисунок 3 – Ярлыки объектов, входящих в группу Поставщики

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

Другой способ добавления объекта в группу:

1.         Откройте список объектов нужного типа в окне базы данных.

2.         Щелкните правой кнопкой мыши по нужному объекту и из контекстного меню выберите команду Добавить в группу (Add to Group).

3.         Выберите в раскрывшемся меню нужную папку или создайте новую папку, выбрав команду Новая группа (New Group).

2. Архивирование, сжатие и восстановление баз данных

Чтобы застраховаться от потери данных, создайте резервную копию базы данных или проекта Access 2002. Чтобы увеличить производительность базы данных и уменьшить ее размер, используйте операцию сжатия базы данных или проекта Access 2002. Начиная с версии Access 2000, сжатие и восстановление базы данных объединены в один процесс.

3.         Защита информации с помощью шифрования

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

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

Чтобы выполнить операцию шифрования или дешифрования:

1.         Запустите Access 2002, не открывая базу данных.

2.         Выберите команду Сервис, Защита, Шифровать/дешифровать (Tools, Security, Encrypt/Decrypt Database).

3.         Появится диалоговое окно База данных для шифрования или дешифрования (Encrypt/Decrypt Database). Укажите имя базы данных, которую требуется зашифровать или дешифровать, и нажмите кнопку ОК.

4.         Если выбранная на предыдущем шаге база данных не является зашифрованной, появится диалоговое окно Шифрование базы данных под именем (Encrypt Database As), иначе появится диалоговое окно Дешифрование базы данных под именем (Decrypt Database As). Укажите имя, диск и папку для конечной базы данных и нажмите кнопку Сохранить (Save).

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

[1] Их может быть несколько.

[2] Высота и ширина детали называется развертка, т.е. вид детали в разрезе.

[3] Детальщики – рабочие по изготовлению именно деталей СВ и КВ, так называемой фасанины.

[4] Брак может быть в виде неправильной детали, к примеру деформированной или неправильно вычисленной. Однако это может быть правильная деталь но ненужная на данном объекте.

[5] Подразумевается система вентиляции, это может быть либо “Приточка” либо “Вытяжка”.

[6] База подготовки производства