НОУ ВПО МОСКОВСЬКА АКАДЕМІЯ ПІДПРИЄМНИЦТВА
при Уряді Москви
Сургутський філія
Спеціальність - «Прикладна інформатика (в економіці)»
Форма навчання - заочна
ДИПЛОМНИЙ ПРОЕКТ
Тема: Розробка АРМ майстра будівельно-монтажних робіт структурного підрозділу ВАТ «Сургутнафтогаз»
Виконав студент
Групи 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.2 Організаційна структура об'єкта автоматизації
1.3 Функціональна структура об'єкта автоматизації
7 Обгрунтування проектних рішень по видах забезпечення
1.7.1 Обгрунтування проектних рішень з інформаційного забезпечення (ІЗ)
2.1.2 Найменування підприємств (об'єднань) розробника і замовника (користувача) системи та їх реквізити
2.1.3 Планові терміни початку і закінчення роботи зі створення системи
2.1.4 Порядок оформлення і пред'явлення замовнику результатів робіт зі створення системи
2.1.5 Призначення системи
2.1.6 Мета створення
2.1.7 Характеристика об'єкта автоматизації
2.2.1 Вимоги до системи в цілому
2.2.4 Вимоги до експлуатації, технічного обслуговування, ремонту і збереження компонентів системи
2.2.7 Вимоги щодо збереження інформації при аваріях
2.2.8 Вимоги до функцій (завдань), що виконуються системою
2.3 Вимоги до видів забезпечення
2.3.1 Математичне забезпечення
2.3.2 Лінгвістичне забезпечення
2.3.3 Інформаційне забезпечення
2.3.4 Програмне забезпечення
2.3.5 Вимоги до технічного забезпечення системи
2.8.1 Структура таблиць створеної бази даних
2.8.2 Опис запитів до бази даних
2.8.3 Порядок контролю і приймання системи
2.8.4 Вимоги до складу та змісту робіт з підготовки об'єкта автоматизації до введення системи в дію
2.8.5 Вимоги до документування
2.8.7 Використовувані класифікатори та системи кодування
2.9 Інформаційна модель цеху вентзаготовок «TO - BE»
в
3.1 Вибір методу оцінки обгрунтування економічної ефективності
Висновок
Список використаної літератури
Програми
Введення
Проблема автоматизації виробничих процесів і процесів управління як засобу підвищення праці завжди була і залишається актуальною в народному господарстві. У сучасному етапі автоматизації управління виробництвом найбільш перспективним є автоматизація планово-управлінських функцій на базі персональних ЕОМ, встановлених безпосередньо на робочих місцях фахівців. Ці системи набули широкого поширення в організаційному управлінні під назвою автоматизованих робочих місць (АРМ).
Автоматизоване робоче місце майстра будівельно-монтажних робіт - це робоче місце, яке оснащене обчислювальною технікою. Воно складається з ПК, принтера, засобів зв'язку - факс / телефон. ПК пов'язаний з іншими ПК за допомогою ЛОМ змішаної топології, яка у свою чергу контролюється системним адміністратором. За допомогою обчислювальної техніки та встановленого необхідного програмного забезпечення можуть вирішуватися ряд проблем, таких як, автоматизація операцій облікового процесу та ін
Зокрема це: операції низки обчислень, таких як, площа заготовок, кількість нормо-годин, кількість забракованих деталей (контроль якості), кількість відпрацьованого металу (облік ТМЦ), складання та відправка звітів. Оперативне прийняття управлінських рішень.
Велика частина роботи майстра пов'язана з накопиченням великої кількості інформації пов'язаним з виробництвом, таким як ведення документації по кожному будується або ремонтованих об'єктів. Це щоденна величезна праця. Більш того, майстри самі в деякому роді є носіями оперативної інформації. Отримуючи її, у вигляді інструкцій від вищого начальства, вони повинні вчасно і правильно прийняти те чи інше управлінське рішення. Однак, при виконанні своїх функціональних обов'язків часто зустрічаються найбільш повторювані помилки, що призводять до певної міри до спотворення інформації. Або несвоєчасної її подачі до потрібного адресата, що в свою чергу призводить певного роду до негативних наслідків у виробничому процесі.
Одна з основних проблем на сьогоднішній день така, що майстри, щодня отримують великий обсяг інформації, часто не встигають своєчасно її обробити. Внаслідок чого випливають такі проблеми: спотворена і не вчасно дана інформація призводить до порушення виробничого процесу. Крім цього дуже часто майстри СМР дають близько 70% непотрібної інформації (особиста, або стороння), що явно заважає запам'ятовувати ту, яка необхідна.
Приклад: Бригада слюсарів з виготовлення деталей та вузлів систем вентиляції отримала три замовлення на виготовлення партій деталей на певні об'єкти. Але через спотворення інформації втрачається пріоритетність виготовлення. Тобто бригада терміново виготовляє деталі на один (декілька) об'єктів, але приходить вказівку призупинити виготовлення. Т. до потрібно терміново виконати роботу для іншого або інших об'єктів.
Проблема полягає в тому, що партія може складатися з великої кількості різних деталей. Виготовлення її потрібно відставити на певне місце, запам'ятати (зазначити) число зроблених деталей і скласти їх в певне місце. А це тимчасові витрати. Потім приступити до виконання іншої партії.
Бувають випадки, коли в замовленні всі деталі позначені галочкою, тобто це означає те, що деталі стануть. Але інший майстер, який відзначає і забирає документи, тобто «Виготовлені замовлення» побачивши таке замовлення, думає, що його вже зробили і забирає документ в архів. Хоча замовлення ще недороблений, тобто тимчасово відсторонений і потім буде дороблятися. Звідси виникають проблеми - скільки залишилося зробити з недоробленою партії. Починається пошук цієї партії в архіві, який є паперовим, тобто документи складені у папки. У ПК його немає. Але так як, бригаді не можна простоювати, то всі приступають до виготовлення наступного замовлення, який лежить на столі замовлень. І це далеко не все. Кожна деталь в залежності від параметрів (розгортки) виготовляється з металу певної товщини (чим більше розгортка, тим товщі метал), який теж у свою чергу пов'язаний з технологією його обробки. Велику товщину, наприклад, 1мм або 1,2 мм простими ножицями по металу дуже важко різати (сповільнюється процес виготовлення). Доводиться перебудовуватися одні інструменти прибирати інші діставати, що теж витрачає часові ресурси.
Як містилося вище, вся основна інформація необхідна для функціонування виробництва, зберігається на паперових носіях, з часом накопичується, представляючи собою великі стоси паперів зшитих в папки. При цьому важко здійснити швидкий відбір потрібних даних по об'єкту монтажу, або по партії відправляється на об'єкт, так як вибір (пошук) необхідного паперового документа являє собою певну часову витрату. Крім цього кожне ранок надходить нова інформація як за новим, так і за попереднім об'єкту монтажу. Плюс до цього бувають зміни і в попередні замовлення. Деякі деталі привозять назад, їх тимчасово прибирають, поки вони не знадобляться. Потім виготовляються інші деталі і вивозяться на монтаж замість привезених деталей.
Актуальність теми дипломного проекту обумовлена тим, що в умовах повсюдного впровадження комп'ютерної обробки інформації об'єктивну необхідність набуває впровадження спеціальних програм для підвищення ефективності роботи майстрів будівельно-монтажних робіт.
Основна мета дипломної роботи полягає у створенні АРМ майстра СМР, виробленню пропозицій та рекомендацій щодо застосування інформаційних технологій в процесі автоматизації функцій управління: аналіз, облік, вироблення планових завдань, складання звітної документації.
Для досягнення поставленої мети визначені наступні завдання:
1. Проаналізувати інформаційну систему цеху.
Надходження інформації: від кого, кому, для чого
Обсяг отриманої інформації
Терміни обробки інформації
Паперова документація та її обсяг
2. Встановити основні проблеми в процесі обробки інформації:
значні витрати часу на пошук потрібного документа;
застаріла структура деяких потрібних для роботи документів;
неточності заповнення цих документів;
створюється декілька паперових копій одного й того ж документа, зайва трата ресурсів;
Документи (комплектувальні відомості) накопичуються, на деяких немає дати замовлення та обсягу роботи в м 2.
3. Розробити АРМ майстра будівельно-монтажних робіт спеціалізація - вентиляція.
облік робочого часу;
видача заявок на виготовлення деталей та вузлів систем вентиляції;
контроль над виготовленням продукції;
ведення встановленої документації по ТМЦ;
підготовка звітної документації;
4. Модернізувати існуючу ІС цеху вентзаготовок, шляхом побудови моделі TO - BE;
5. Автоматизувати процес обчислення обсягу зробленої продукції в м 2.
Практична значимість полягає в тому, що саме впровадження системи автоматизації обліку матеріальних цінностей та складання звітності виробничої інформації дозволить отримувати в будь-який момент необхідні дані про виконану або майбутню роботу, тим самим, підвищивши ефективність роботи майстра будівельно-монтажних робіт.
Розробка АРМ майстра будівельно-монтажних робіт спеціалізація - вентиляція дозволить:
забезпечить правильне та своєчасне отримання інструкцій працівниками цеху з виготовлення систем вентиляції;
підвищить якість виготовленої продукції;
зменшить кількість бракованих деталей;
спростить роботу з документами, підвищить її ефективність;
підвищить продуктивність праці майстра і бригадира за рахунок скорочення часу створення, обробки та пошуку документів, внаслідок чого підвищується продуктивність всієї бригади;
підвищить оперативність доступу до інформації;
скоротить чисельність паперової документації;
збільшить пропускну здатність обробки документації;
заощадить час і кошти на обробку інформації.
Таким чином, автоматизація процесу роботи майстра будівельно-монтажних робіт є потрібним і перспективним процесом, який на думку автора даної роботи, має швидко і ефективно впроваджуватися в кожній організації будівельної галузі.
1. Аналітична частина
1.1 Техніко-економічна характеристика предметної області
Будівельний трест «Сургутремстрой» був заснований в 1979 році як один із структурних підрозділів всього відкритого акціонерного товариства «Сургутнефтегаз». До складу будівельного тресту "Сургутремстрой" ВАТ "Сургутнафтогаз" входять: Ремонтно - будівельне управління, Будівельно - монтажне управління, Спеціалізоване управління, Цех підготовки виробництва, Механоенергетіческая служба, Управління механізації і транспорту. У даній роботі розглянута техніко-економічна характеристика спеціалізованого управління в якому працює автор даної роботи.
Робота спеціалізованого управління в основному заснована на ремонті структурних підрозділів всього акціонерного товариства «Сургутнефтегаз». Основний профіль робіт Спеціалізованого управління - це сантехніка, електромонтажні роботи, термоізоляція, вентиляція. Структура виконуваних робіт спеціалізованого управління показана в таблиці 1.1.
Таблиця 1.1 - Профіль робіт
№ п / п | Найменування робіт | Сутність вироблених Робіт | Підсумок |
1 | Сантехнічні | Установка тепловодних радіаторів (батареї), сантехніки. Монтаж труб опалення. | Забезпечення виробничих об'єктів теплом і сантехнікою, згідно Сніп. |
2 | Термоізоляція | Ізоляція трубопроводів мінеральною ватою. Виготовлення деталей і їх монтаж на трубопроводи. | Термічна ізоляція трубопроводів від зовнішнього середовища (низьких і високих температур) |
3 | Вентиляція | Виготовлення деталей і вузлів СВ і КВ, їх монтаж. Установка вентиляційного устаткування (вентилятори, калорифери, клапана, повітряні фільтри) | Забезпечення необхідною вентиляцією згідно Сніп. |
4 | Електромонтажні | Установлення електрообладнання, монтаж електричних кабелів різного перерізу. | Підведення електрики до джерел споживання. |
Спеціалізоване управління має свою власну базу підготовки виробництва, до складу якої входить:
Адміністративно-побутовий корпус;
Склад закритого типу зберігання "арочнік", де ТМЦ мають великий часовий інтервал завезення та вивезення;
Склад відкритого типу зберігання "стелажі", з швидким інтервалом завезення-вивезення ТМЦ;
Цех з виготовлення санітарно-технічних виробів;
Цех з виготовлення вузлів і деталей СВ і КВ.
Цех з виготовлення вузлів і систем вентиляції являє собою виробничий корпус: довжина 80 м, ширина 40м, висота 8 метрів. Велика частина цеху відведена під виготовлення деталей та вузлів систем вентиляції. Інша частина цеху відведена для виготовлення заготовок термоізоляції. Цех оснащений двома великими кран-балками вантажопідйомністю до 3,5 тонн (включно) для переміщення великовагових вантажів. Для виготовлення заготовок систем вентиляції в цеху знаходяться наступні верстати (механічні пристрої):
Ножиці гільйотинні - 2 одиниці;
Столи для розкрою металу - 7 од;
Верстат листозгин (для загину металу) 1ед;
Свердлильний верстат - 1 од;
Верстат нарубной (нарубает металевий куточок розміром від 20 до 80 мм);
Верстат точильний - 1 од;
Верстат обрізний - 1ед;
Верстат зиговочні (для виготовлення швів на заготовках) - 1 од;
Машина зиговочні (для виготовлення швів відводів) 1 - од.
Автоматизоване робоче місце майстра систем вентиляції та кондиціонування повітря (СВ і КВ) знаходиться в кабінеті АБК і являє собою парк обчислювальної техніки з двох одиниць: персональний комп'ютер класу Pentium 4, копіювальний центр. Із засобів комунікації: тел / факс, радіотелефон, комутатор 3com, локальна обчислювальна мережа тип Ethernet зі змішаною топологією "кільце-зірка" представляє собою кабель, вита пара. На персональному комп'ютері встановлені мережеві карти, працюють, із швидкістю 100 М / біт в секунду. Мережним протоколом для передачі даних є TCP / IP (Nransmission Protocol / Internet Protocol). Для управління локальною мережею використовується сервер, який знаходиться в окремій кімнаті - серверної головного офісу тресту "Сургутремстрой". Даний сервер служить контролером домену і використовується як файл-сервера, сервера баз даних, сервера додатків. ЛВС знаходиться під контролем сисадміна тресту «Сургутремстрой» і входить до складу ЛВС всього відкритого акціонерного товариства «Сургутнефтегаз».
1.2 Організаційна структура об'єкта автоматизації
Організаційна структура Спеціалізованого управління і бази підготовки виробництва, де знаходиться об'єкт автоматизації, показана у додатках А.1, А.2.
Керівництво спеціалізованим управлінням тресту «Сургутремстрой» здійснює начальник управління.
У спеціалізованому управлінні є наступні виробничі ділянки та відділи: Виробничі дільниці з 1-го по 8-й; Відділ кадрів; Бухгалтерія; ОТиЗ; ПЕО; ПТО.
Починаючи з Відділу кадрів і закінчуючи ПТО, ці відділи, здійснюють свої функції для всього будівельного тресту "СРС", тобто для Ремонтно-будівельного управління, Спеціалізованого управління, Будівельно-монтажного управління, Управління механізації і транспорту.
Організаційна структура об'єкта автоматизації (цех вент заготовок) показана на рис.1.1 і являє собою лінійну структуру. Керівництво цехом здійснює Начальник бази підготовки виробництва, він же виконавець робіт. До нього в підпорядкування входять чотири майстри будівельно монтажних робіт кожен за своєю спеціалізацією - це майстер з термоізоліровочним робіт, майстер з сантехнічних робіт, майстер по вентиляційних робіт і один комірник. Два бригадира, одним з яких є розробник даного проекту. Дві бригади, одна працює в цеху сантехнічних заготовок, інша в цеху вентзаготовок.
Малюнок 1.1 - Організаційна структура цеху вентзаготовок
1.3 Функціональна структура об'єкта автоматизації
Функції виконуються бригадою з виготовлення деталей та вузлів СВ і КВ виробничої дільниці № 8 включають в себе процедури виконання замовлення, тобто кожен робочий бригади:
Підходить до комплектувальної відомості і відзначає ту деталь, яку він буде виготовляти. Якщо є, сумніви у виготовленні деталі він дивиться креслення - подмерку, в якій в аксонометрії вказані докладно всі деталі виготовленого замовлення. Відзначати слід строго по порядку зверху вниз. Це робиться для того, щоб навантаження на виготовлення деталей розподілялася рівномірно. Так як, одні деталі виготовляються швидко і легко, інші навпаки довше і важче. Все залежить від параметрів і складності виготовлення деталі;
Вибирає лист металу з товщиною потрібної для виготовлення тієї або іншої деталі, яка залежить згідно СНіПам з виготовлення від перетину деталі. Якщо від 400X400 і вище то товщина металу не повинна бути менше 0,7 мм. Інакше товщина металу - 0,5 мм;
Бере лист металу і починає його розкроювати згідно СНіПам з виготовлення деталей СВ і КВ;
Після розкрою деталь вирізають за наміченим контуру;
Проробляють з нею специфічну обробку: технологічний отвір, або прокатування швів для з'єднання сторін деталі і т.д.;
Кожну готову деталь підписують (строго обов'язково): номер деталі, найменування об'єкта (скорочено) та номер партії;
Кожну підписану деталь становить в партії.
Коли приходить автотранспорт за продукцією, виготовлені партії завантажують у нього і відправляють на об'єкт монтажу.
Всі процедури обробки показані за допомогою контекстної та декомпозиційний діаграм пакету AllFusionModeller на малюнку 1.2 та 1.3.
Малюнок 1.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 - Вимоги
Проблема | Вимога | Рішення | Примітка |
Великий обсяг інформації на паперових носіях | Щоденний обмін інформацією начальника дільниці № 3 (монтаж систем вентиляції та кондиціонування повітря) з бригадиром цеху вентзаготовок; | Автоматизація введення надходить інформації та обробка її на ПК | Щоденне складання звіту, ведення архіву. |
Не на часі завезення ТМЦ в цех. Обчислення вручну площ всіх заготовок | Щомісячний завезення ТМЦ в цех згідно плану замовлень на виготовлення деталей і вузлів СВ і КВ. | Автоматизація процесу обчислення площі заготовок і планування завезення ТМЦ | Для обліку обсягу виготовленої продукції. Ведення архіву |
Бригада слюсарів з виготовлення вузлів і деталей СВ І КВ не справляється з великим обсягом замовлень | Тимчасове переведення монтажників СВ і КВ в цех для виготовлення вузлів і деталей на "терміновий об'єкт" | Розподіл робочих по виконуваних функцій - пріоритетність розстановки для досягнення найкращого результату виконання замовлень. Відображення цього в моделі ІС "TO-BE" | Пріоритетом є "строковий" об'єкт |
Слабкий контроль за якістю готової продукції | Змінити структуру комплектувальної відомості | Додати стовпець "Виготовив ПІБ", в комплектувальної відомості замовлення .. Зробити його електронну версію | Обрану деталь для виготовлення кожен позначає своїм прізвищем. |
У даному пункті автор розкриває вимоги до майбутнього проекту шляхом відповідей на наступні питання:
зміни у функціях підрозділи, пов'язаних зі збором, обробкою і видачею інформації;
джерела надходження оперативної та умовно-постійною інформацією і періодичність її надходження;
етапи рішення завдання, послідовність і тимчасової регламент їх виконання,
порядок введення первинної інформації (назви документів) та перелік використовуваних екранних форм;
коротка характеристика результатів (назви результатних документів, екранних форм видачі результатів, перелік результатних файлів, способів їх видачі: на екран, друк або в канал зв'язку) та місць їх використання;
коротка характеристика системи ведення файлів в базі даних (перелік файлів з умовно-постійної і оперативною інформацією, періодичність оновлення, вимоги захисту цілісності та секретності);
режим рішення задачі діалоговий;
періодичність виконання завдання.
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 коло = πR 2 - площа кола
S сегм = (πR 2 / 360) * a, де a - кут сегмента виражений в градусах
S парасольку = S коло - S сегм (1.3)
Обчислення площі парасольки 3 вид (пірамідальний)
h
a
Малюнок 1.11 - Зонт пірамідальний
S парасольку = сума площ всіх сторін (рівнобедрених трикутників) (1.4)
S стор = ½ * a * h, де a - підстава; h - висота трикутника
S парасольку = S a * 2 + S b * 2
Обчислення площі відводу з прямою шийкою
Потилична частина (потилиця)
Фасонна частина
Шеечная частина (шийка)
Малюнок 1.12 - Відведення
При обчисленні площі відводу з прямою шийкою спочатку обчислюється площа "шийки", потім площа "потилиці" і після чого обчислюється площа фасонної частини. Площі "потилиці" і "шийки" обчислюються легко. Вони являють собою прямокутники, вирізані з металу і обчислюються за формулою
S = a * b,
де a і b є суміжними сторонами прямокутника. Важче обчислюється площа фасонної частини. Спочатку обчислюється периметр одного боку шийки потім іншого боку шийки (у разі якщо шийка однакова з обох сторін). Потім як видно на рис. 1.5.5 залишається обчислити площу сегмента, яка обчислюється за формулою
S сегм = (πR 2 / 360) * a.
Загальна площа виходить із суми частин всіх обчислених площ і представляє собою формулу:
S отв. = S ш. + S з. + S ф. де (1.5)
S ш. - Площа шийки;
S з. - Площа потилиці;
S ф. - Площа фасонної частини.
Далі
S ш. = S з. = A * b,
де a і b сторони прямокутника. Особливу увагу приділяється обчислення площі фасонної частини як видно на рис 1.5.6 вона складається з трьох частин - S сегм, S 1, S 2 і обчислюється за формулою:
S ф. = (S сегм * 2) + S 1 + S 2 де (1.6)
S сегм = (πR 2 / 360) * a.
S 1 = S 2 = a * b, де
сторона a = висоті фасонної частини відведення;
сторона b = половині довжини шийки.
S 1
Площа сегмента a
ab
S 2 b
Малюнок 1.13 - Фасонна частина
Обчислення площі переходу (1 вид центровий)
Малюнок 1.14 - Перехід центровий
Площа переходу обчислюється аналогічно площі парасольки трапецієподібного ((a * b) / 2) * h) і являє собою суму площ усіх боків (трапецій).
S пер. = S 1 + S 2 + S 3 + S 4 (1.7)
Обчислення площі переходу (2 види однобічного)
Малюнок 1.15 - Перехід односторонній
Обчислення площі переходу цього виду проводиться таким чином:
Обчислюються площі двох сторін (трапецієподібних) - ((a * b) / 2) * h;
потім площі залишилися двох сторін - a * b
Після чого всі сторони складаються - S пер. = S 1 + S 2 + S 3 + S 4
Обчислення площі деталі "качка".
Лицьова частина S 1
S 2 S прям
Фасонна частина Лицьова частина
Малюнок 1.16 - Качка
Площа деталі "качка" обчислюється наступним чином - Площа лицьової частини множиться на два і додається площа фасонної частини теж помноженої на два
S качка = (S л * 2) + (S ф * 2) (1.8)
S л = a * b і являє собою прямокутник;
S ф = (S 1 * 2) + (S 2 * 2) + (S прям * 2)
Всі вище перераховані формули будуть включені в автоматизує функції обчислення і увійдуть до БД інформаційної системи.
1.6 Аналіз існуючих програмних продуктів для автоматизації предметної області
Для аналізу існуючих програмних продуктів автором проекту були обрані існуючі на сьогоднішній день системи управління базами даних (СКБД).
На сьогоднішній день відомо більше двох десятків форматів даних настільних СУБД, проте найбільш популярними, виходячи з кількості проданих копій, слід визнати dBase, Paradox, FoxPro і Access. З що з'явилися нещодавно СУБД слід також відзначити Microsoft Data Engine - по суті серверну СУБД, що представляє собою «полегшену» версію Microsoft SQL Server, але призначену, тим не менш, для використання головним чином в настільних системах і невеликих робочих групах.
Відомості про виробників перерахованих вище СУБД представлені в таблиці 1.4.
Таблиця 1.4. - Виробники СУБД
СУБД | Виробник | URL |
Visual dBase | dBase, Inc | http://www.dbase2000.com |
Paradox | Corel | http://www.corel.com |
Microsoft Access 2000 | Microsoft | http://www.microsoft.com |
Microsoft FoxPro | Microsoft | http://www.microsoft.com |
Microsoft Visual FoxPro | Microsoft | http://www.microsoft.com |
Microsoft Visual FoxPro | Microsoft | http://www.microsoft.com |
Microsoft Data Engine | Microsoft | http://www.microsoft.com |
Далі ми розглянемо кожну з цих СУБД окремо. Почнемо з 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, у вигляді їх поширеності.
Конкретні версії компонентів ПЗ повинні визначатися на етапі введення в дію. ПЗ є покупними і повинно бути ліцензійним.
Загальні вимоги до програмного забезпечення:
програмне забезпечення системи повинно бути достатнім для виконання всіх функцій системи, що реалізуються із застосуванням засобів обчислювальної техніки, а також мати засоби організації всіх необхідних процесів обробки даних, що дозволяють своєчасно виконувати всі автоматизовані функції у всіх регламентованих режимах функціонування ІС;
програмне забезпечення системи повинно володіти наступними властивостями:
функціональна достатність (повнота);
надійність (в тому числі відновлюваність, наявність засобів виявлення помилок);
адаптованість;
модифицируемость;
модульність побудови;
зручність експлуатації.
програмне забезпечення системи повинно бути побудовано таким чином, щоб відсутність окремих даних не позначалося на виконанні функцій системи, при реалізації яких ці дані не використовуються;
в програмному забезпеченні системи повинні бути реалізовані заходи по захисту від помилок при введенні і обробці інформації, щоб забезпечити задану якість виконання функцій системи;
всі компоненти програмного забезпечення системи повинні бути сумісні як між собою, так і з системним програмним забезпеченням;
експлуатаційна програмна документація на систему повинна містити відомості, необхідні персоналу системи для використання програмного забезпечення, для його первісної установки, запуску програм системи.
Програмне додаток повинен бути реалізовано 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 червня 2009.
Закінчення роботи 15 лютого 1910.
порядок оформлення і пред'явлення замовнику результатів робіт зі створення системи (її частин), з виготовлення та налагодженню: 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 Вимоги до системи в цілому
Дана ІС повинна мати чітку, послідовну, легковоспрінімаемую організовану структуру. Базу даних. Злагоджено і безперебійно функціонувати: Відкривати форми, запити складати звіти.
Система повинна експлуатуватися як одним, так і декількома користувачами.
Система повинна видавати звіти згідно із затвердженими ГОСТам, а також виконувати функції згідно написаних для них вимог.
При експлуатації система повинна мати зручний і зрозумілий інтерфейс. Кожна кнопка повинна відповідати своєму призначенню.
Якщо в системі є особлива або секретна інформація, то вона повинна мати код доступу (пароль).
Режим функціонування - діалоговий (інтерактивний).
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 Вимоги до технічного забезпечення системи
Процесор Intel Pentium II 400 МГц і вище;
Оперативна пам'ять 128 Мбайт і вище;
Жорсткий диск (200 Мбайт вільного місця) і вище;
Пристрій читання компакт дисків;
SVGA-дисплей;
принтер, формат листів: А4, швидкість друку: 10 сторінок в хвилину і вище;
Клавіатура;
Маніпулятор миша;
відео карта типу SVGA 4-8 Мб VRAM;
мережева карта 100 Мбіт (залежно від мережі);
пристрій друку.
2.3.6 Вимоги до організаційного забезпечення
Вимоги до структури і функцій підрозділів, які беруть участь у функціонуванні системи або забезпечують експлуатацію:
Залишити організаційну і функціональну структуру без змін.
Функціонування ІС буде здійснюватися:
1) по супроводу ПЗ: проектувальником;
2) по супроводу технічних засобів: користувачем системи.
2.4 Склад і зміст робіт по створенню системи
Таблиця 2.1 - Склад і зміст робіт по створенню системи
Стадія створення | Найменування етапу | Зміст робіт | Терміни виконання | Форма звітності |
1.Обследованіе і аналіз ОА | 1.1. Обстеження ОА 1.2. Вивчення матеріалів обстеження 1.3 Аналіз ОА | Інформаційне обстеження ОА та формування вимог до системи | 14.10.2009 - 30.10.2009 | Звіт |
2. Технічне завдання | Розробка та затвердження технічного завдання на розробку системи | Розробка вимог ТЗ | 03.11.2009 - 25.11.2009 | ТЗ |
3. Технічний проект | 3.1. Розробка проектних рішень по системі 3.2. Розробка документації на систему | Розробка проектних рішень щодо реалізації системи | 27.11.2009 -21.12 .. 2009 | Комплект документації Технічного проекту відповідно до ГОСТу |
5. Робочий проект | 5.1. Розробка робочої документації на систему 5.2. Розробка та адаптація програм 5.3. Введення системи в дію | Розробка програмного забезпечення та документації системи, проведення випробувань та введення системи в постійну експлуатацію | 08.01.2010 - 15.02.2010 | Комплект робочої документації відповідно до ГОСТ, акт про приймання системи в постійну експлуатацію |
Склад робіт при проектуванні ІС:
Побудова інформаційної моделі;
Виявлення проблем і недоліків в ІС цеху вентзаготовок;
Визначення області, на яку буде орієнтована ІВ;
Створення бази даних;
Визначення потоків інформації "звідки - куди";
Побудова інформаційної моделі цеху вентзаготовок «TO - BE»;
Прогонка ІС;
Здача ІС в експлуатацію.
2.5 Інформаційна модель
Інформаційна модель, показана на рис 2.1, відображає собою загальну модель цеху, яка безпосередньо пов'язана з виробничим процесом і відображає стан справ на сьогоднішній день, тобто модель "AS - IS".
Малюнок 2.1 - Контекстна діаграма інформаційної моделі цеху вен заготовок
Стрілками вказані основні інформаційні потоки:
Замовлення на виготовлення продукції та ТМЦ - надходять від керівництва СУ;
Продукцію виготовляє бригада слюсарів з виготовлення вузлів і систем вентиляції;
Трудові відносини грунтуються на статтях і правилах Трудового кодексу РФ (Трудовий договір);
Вироби виготовляються згідно з будівельними правилами і нормами (БНіП);
Кошториси на виготовлення деталей, нарахування заробітної плати здійснює Бухгалтерія;
Готова продукція сортується в системи (партії) і відправляється на об'єкти монтажу;
Звітна документація (наряди) відправляються у відділи ПЕО, ПТО.
Потоки інформації та їх обробка показані на малюнку 2.2.
Малюнок 2.2 - Контекстна діаграма потоки інформації
Вся інформація, що надходить після її обробки перетворюється на роботу і в подальшому в готову продукцію. На малюнку 2.2 показано стан справ, як воно є на сьогоднішній день.
Алгоритм надходження, обробки та видачі інформації:
Надходження
Начальник ділянки монтажу вентиляції щомісяця видає план виконання продукції на місяць, який виражається в обсязі через квадратні метри;
Начальник ділянки на початку кожного місяця завозить листовий метал (ТМЦ) різної товщини. Стандартні розміри листа будь-якої товщини довжина - 2500 мм, ширина - 1250 мм. З аркушів виготовляються вузли та деталі СВ і КВ. Чим більше за розмірами деталь, тим товщі береться лист для її виготовлення;
Майстри по монтажу СВ і КВ, кожен з яких веде свій об'єкт монтажу щодня вранці видають замовлення на виготовлення партій СВ і КВ. Кожна партія складається з деталей і вузлів СВ і КВ і має свою назву. П - приточування, В - витяжка, ВЕ - витяжка природна. У свою чергу до складу монтажу будь-якої партії входить, насамперед, вентилятор певної потужності (згідно СНіПам), калорифер (в зимовий час по ньому проходить гаряча вода), кондиціонер, шумоглушник, певного типу клапана (з електроприводом або ручним приводом) а вже потім кріпляться (монтуються) деталі партії.
Обробка
Кожне замовлення це - комплект з двох паперових документів: креслення - який називається подмерка і комплектувальні відомості, в якій зазначений об'єкт монтажу, назва партій (відповідно приточування і витяжка 1), описуються найменування деталей і їх номери (які повинні відповідати з номерами в подмерке) , кількість деталей, їх параметри (висота, ширина 2 і довжина деталі), якщо деталь - відведення, то даний його градус тобто зазвичай це 90 0;
Щодня вранці бригадир, отримавши замовлення, розкладає подмерку і список матеріалів. Робітники, підійшовши до столу, відзначають обрану для виготовлення деталь, якщо їм щось не ясно, як її виготовити, наприклад перехід з однієї розгортки в іншу, то вони дивляться в подмерку, в якій намальований докладне креслення і понумерованно вказані всі Виготовляються деталі. Відзначивши деталь, робочі приступають до її виготовлення;
Після того як всі деталі будуть помічені, а це означає, що замовлення оброблений, бригадир складає обидва документи в папку і так він надходить з кожним замовленням;
Замовлення бувають великими за обсягом (до 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 видно, що:
браковані деталі це неправильно виготовлені деталі. Деформовані деталі йдуть на металобрухт, а зворотніми деталями доукомплектовують партії, що призводить до значних витрат у часі;
Недороблений замовлення це недоукомплектована партія збільшує час на уточнення, Продукція, відкладена на невизначений час, яка займає місце в цеху.
Крім всіх перерахованих вище проблеми існує одна масштабна проблема. Це те, що незважаючи на комп'ютеризацію робочих місць майстрів і начальників ділянок, основний документообіг відбувається в паперовому вигляді. А базові знання володіння комп'ютером залишає бажати кращого. Майстри дуже повільно друкують (складають звіти). Численні розрахунки при різного роду обчисленнях відбуваються вручну за допомогою калькулятора якої програми «Калькулятор» знаходиться в складі ОС Widows.
2.7 Визначення області орієнтування
Область визначення на яку орієнтована ІВ, це створення АРМ майстра СМР спеціалізація - вентиляція. Тобто, це автоматизація деяких обчислювальних процесів з допомогою стандартного додатка MS Access.
2.8 Створення Бази даних
Склад і зміст робіт з проектування БД показано у таблиці 2.1.
Таблиця 2.2-Структура робіт
№ п / п
Найменування роботи
Результат роботи
1
Побудова таблиць
Початкова інформація
2
Побудова простих форм
Первинна обробка даних
3
Побудова простих запитів
Проста вибірка
4
Побудова складних форм
Складна вибірка
5
Побудова звітів
Відображення інформації
6
Написання макросів
Виконання команд,
7
Побудова кнопкової форми
Показ роботи з СУБД
2.8.1 Структура таблиць створеної бази даних
Таблиця 2.3 - Таблиці БД
База даних
Наимен об'єкта
Таблиці
Запити
Форми
Звіти
Код
0 1
0 2
0 3
0 4
1
Партія
Вставка
Короб
Короб
2
Персонал
Короб
Стрічка-кріплення
Вставка
3
Короб
Стрічка-кріплення
Відведення
Відведення
4
Перехід
Рейка
Вставка
Персонал
5
Відведення
Результат
Партія
Рейка
6
Рейка
Відведення
Результат
Стрічка-кріплення
7
Стрічка-кріплення
Перехід
Перехід
Виготовлення
8
Вставка
Виготовлення
Рейка
Ізготовленіе_об
9
Решітка
Ізготовленіе_2
Ізготовленіе_Под
10
Результат