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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


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


курсовая работа Разработка АСИС Учет поставок

Информация:

Тип работы: курсовая работа. Добавлен: 05.06.2012. Сдан: 2011. Страниц: 14. Уникальность по antiplagiat.ru: < 30%

Описание (план):


Зміст
       Висновок
       Література
Додаток 1
Додаток 2
Додаток 3 

 

Вступ
    Господарством України є сукупність підприємств  і організацій окремих галузей  народного господарства різних форм власності. Підприємства державної форми власності знаходяться у веденні різних міністерств і відомств, а також у веденні місцевих виконкомів. Виробнича діяльність як і господарська, направлені на випуск предметів культурно-побутового призначення, господарського ужитку і ін.
    Таким чином, до складу господарства України  входять підприємства і організації, як сфери матеріального виробництва, так і сфери обслуговування, що як госпрозрахункові, так і перебувають  на державному бюджеті. Найбільше число держбюджетних організацій знаходиться у веденні Міністерства освіти і науки України:  школи, дитячі сади, педагогічні інститути, технікуми, училища і тому подібне (близько 30% загальної кількості організацій); міністерства охорони здоров'я України – лікарні, санаторії, госпитали і ін. лікувальні установи (близько 20%); міністерства культури і освіти України – театри, бібліотеки, музеї і ін. (більше 25% загальної кількості організацій) [3].
    Керівництво місцевим господарством країни організоване як за галузевим принципом (через відповідні міністерства і відомства), так і по територіальному (через місцеві органи управління).
    Підприємства  господарства України проводять  різноманітну продукцію. У її числі  можна знайти кошти виробництва: верстати, машини, металопродукцію, товари народного споживання, предмети побутової хімії і тому подібне
    Для виробництва всієї вищепереліченої  продукції підприємства, незалежно  від форм власності, для свого  нормального і стабільного функціонування  потребують сировини, що комплектують, запчастинах і тому подібне Іншими словами для організації своєї діяльності підприємства стикаються з проблемою своєчасного постачання продукції. Для цих цілей підприємства державної форми власності використовують постачальницькі організації (в даний час даними організаціями користуються спеціалізовані державні підприємства), підприємства ж приватних форм власності проводять відповідні заходи, направлені на своєчасне і безперервне забезпечення необхідною сировиною або матеріалами. Але в даний час практично всі підприємства будь-якої форми власності самостійно займаються пошуком  підприємств-постачальників, а також в міру необхідності організацією постачань.
    Одним з показників тих, що характеризують роботу підприємства є товарообіг, який є планово організаційним процесом звернення засобів виробництва [2], від якого багато в чому залежать і інші економічні показники. У загальний об'єм товарообігу включають всі товари, реалізовані підприємством, тобто отримані від підприємств постачальників продукції. Також  товарообіг показує наскільки швидко підприємство використовує отриману продукцію, тобто якими темпами воно здійснює свою діяльність, чим більше на підприємство здійснюється постачань, тим більше стабільно працює дане підприємство.
    При здійсненні постачань на підприємство проводиться обробка і зберігання великої кількості інформації, пов'язаної з постачаннями, яка включає:
    своєчасне і правильне оформлення документів і контроль за кожною операцією надходження  товарів від постачальників, з  переробки і інших джерел, виявлення розбіжності фактичної наявності і кількості, вказаної в супровідних документах;
    контроль  за своєчасним, повним і правильним оприбутковуванням товарів, що поступили;
    своєчасне і правильне оформлення документації і контроль за кожною операцією відпустки, відвантаження або реалізації товару;
    контроль  за дотриманням нормативів запасу товарів.
      У зв'язку з цим для надійного  функціонування системи постачань  необхідно вести їх систематичний  і безперервний облік, що і  виконуватиме що розробляється ПО.
      Програмний продукт, що розробляється,  відрізнятиметься від аналогічного  програмного забезпечення можливістю  застосування на сучасній електронно-обчислювальній  техніці  [1], зручним інтерфейсом,  низькою вартістю, можливістю його  використання на будь-якому підприємстві. пред'явлення претензій визначені інструкцією про порядок приймання продукції виробничо-технічного призначення і товарів народного споживання по кількості і інструкцією про порядок приймання продукції виробничо-технічного призначення за якістю. Особливості приймання окремих видів продукції визначаються в Гостах  [12.01.005-89], технічних умовах, Особливих умовах постачання і договорах постачання, що передбачають особливі порядки приймання продукції при постачаннях.
    На  підприємствах державної форми власності здійсненням всіх дій пов'язаних з постачаннями і оформленням необхідних документів, за наявності відповідного програмного забезпечення, займається певна кількість персоналу підприємства, але, як правило, розробка такого програмного забезпечення велася на мовах низького рівня програмування, а за останніх 6-8 років розвиток машинних засобів (ПЕВМ), програмних засобів різко збільшилася, тому раніше розроблене ПО не відповідає вищим вимогам, що пред'являються до сучасних програмних продуктів. Що ж до підприємств, фірм різний форм приватної власності, то вони часто не мають зовсім відповідного програмного забезпечення, що значно збільшує трудомісткість процесу контролю і обліку  проведення постачань. Програмний продукт, що розробляється, і покликаний вирішувати дані проблеми.     
 
 
 

 

     1 Загальна характеристика проблеми 

    При здійсненні постачань підприємства виготівники продукції виробничо-технічного призначення вступають у договірні  відносини з підприємствами споживачами (покупцями) як постачальники укладають прямі договори з підприємствами споживачами для збуту продукції і комплексного постачання підприємств-замовників.
    Договори  про постачання необхідно укладати своєчасно. У них указуються умови  постачання товарів, їх кількість, асортимент, якість, комплектність і терміни постачання. Крім того, в договорах передбачені ціни на товари, загальна сума, порядок розрахунків, платіжні і відвантажувальні реквізити постачальника і одержувача продукції. Договори підлягають обов'язковому виконанню за всіма вказаними в них пунктами. Порушення термінів договорів і зобов'язань вабить відповідальність, передбачену “Положенням про постачання продукції виробничо-технічного призначення” і “Особливими умовами постачання.”
    Контроль  за виконанням договорів здійснюють товарні відділи.
    Раціональна організація приймання продукції  від постачальників має важливе  значення для своєчасного, повного, комплексного постачання підприємств  сировиною, матеріалами, паливом, інструментами, устаткуванням і іншими засобами виробництва.
    Правильне приймання і оформлення документами  товарів, що поступили 
    Є надійною основою збереження товарно-матеріальних цінностей.
    Загальний порядок приймання товарно-матеріальних цінностей встановлений “Положенням  про постачання продукції виробничо-технічного призначення”. Порядок і терміни приймання товарно-матеріальних цінностей в певній кількості і якості, оформлення актів приймання і пред'явлення претензій визначені інструкцією про порядок приймання продукції виробничо-технічного призначення і товарів народного споживання по кількості і інструкцією про порядок приймання продукції виробничо-технічного призначення за якістю. Особливості приймання окремих видів продукції визначаються в Гостах  [12.01.005-89], технічних умовах, Особливих умовах постачання і договорах постачання, що передбачають особливі порядки приймання продукції при постачаннях.
    На  підприємствах державної форми  власності здійсненням всіх дій  пов'язаних з постачаннями і оформленням  необхідних документів, за наявності  відповідного програмного забезпечення, займається певна кількість персоналу підприємства, але, як правило, розробка такого програмного забезпечення велася на мовах низького рівня програмування, а за останніх 6-8 років розвиток машинних засобів (ПЕВМ), програмних засобів різко збільшилася, тому раніше розроблене ПО не відповідає вищим вимогам, що пред'являються до сучасних програмних продуктів. Що ж до підприємств, фірм різний форм приватної власності, то вони часто не мають зовсім відповідного програмного забезпечення, що значно збільшує трудомісткість процесу контролю і обліку  проведення постачань. Програмний продукт, що розробляється, і покликаний вирішувати дані проблеми.     

1.1 Формулювання завдань 

    Будь-яке  підприємство, здійснюючи свою діяльність, для отримання продукції від постачальників повинно укласти з останніми договір на постачання продукції. Зазвичай на однойменну продукцію підприємство-замовник укладає декілька договорів з підприємствами-постачальниками. Потім замовник у міру потреби в певній продукції висилає постачальникові заявку на постачання продукції і отримує від останнього рахунок, в якому вказано найменування продукції і її відпускну ціну. На підставі цих рахунків підприємство-замовник визначає оптимальну заявку і висилає постачальникові замовлення на постачання продукції. Після отримання замовленої продукції замовник відправляє рахунок в бухгалтерію, яка оплачує його в банці в перебігу терміну, передбаченого договором. Тому для документального забезпечення процесу постачань на підприємство програма повинна створювати (роздруковувати) наступні необхідні документи:
    бланк договору підприємства-замовника з фірмою-постачальником (з вказівкою найменування і юридичних адрес сторін, асортименту продукції для постачань, її кількості і гаданої вартості, а так само умови і терміни дії договору);
    замовлення на постачання необхідної продукції (указується кількість, найменування, номенклатура, терміни постачання).
    Також створювана автоматизована система  за наявними даними про постачальників і знов отриманим даним повинна визначати оптимальний рахунок з точки зору кількість-ціна.
Будь-яке  постачання підприємство-замовник зобов'язане  сплатити у встановлені договором  терміни, тому АС повинна здійснювати  підрахунок суми довга (грошей до виплати) на поточну дату.
На рис 1.1 представлена функціональна схема здійснення постачань на підприємство. 

    Таким чином для розробки АСИС необхідно  виконати наступні завдання:
    реалізація управління доступом до АСИС;
    створити СУБД для роботи АСИС;
    розробити довідкову інформацію по АСИС;
    виконати аналіз і обліку постачань.
      1.2 Мотивація завдань. 

    Підприємство  або фірма, проводячи свою продукцію, потребує постачань сировини від  інших підприємств. Але на одне і  теж сировина у різних виробників-постачальників різна відпускна ціна, тому в цілях зниження собівартості продукції, що випускається, підприємство замовник укладає договори з великою кількістю постачальників і потім висилає постачальникам заявку на  постачання продукції з вказівкою типу і її кількості. Оскільки підприємство-замовник при отриманні вантажів так чи інакше пов'язане з документами, з документальним оформленням постачань, то проектована АСИС повинна створювати всі бланки документів, пов'язаних з постачаннями.
    Оскільки  всі постачальники висилають  замовникові рахунку-фактури (прейскурант цін на замовлену продукцію), то серед їх множини необхідно визначити найбільш вигідне для підприємства-замовника, як за ціною, так і за якістю, що і повинна виконувати створювана АС.
    Оскільки  договори з постачальниками полягають  на певний термін, передбачувана кількість продукції, що поставляється, і на певну суму, то при здійсненні замовлення на постачання продукції, в договорі обмовляється термін, в перебігу якого замовлення повинне бути сплачений, тому необхідно знати суму до оплати на вказане число, як загальну так і по різних постачальниках окремо.
    Оскільки  всі вищеперелічені дії здійснюються впродовж тривалого часу, то при  прийнятті вирішення про продовження  терміну дії договору  доцільно приймати до уваги наступні чинники: якість постачань конкретними постачальниками (є зважаючи на виконання термінів здійснення постачань, відповідність номенклатури поставленій продукції замовленою, відсутність або відсоток браку), його терпимість по відношенню до оплати по постачаннях. Тому необхідно зберігати всю інформацію про постачання на підприємство, що б надалі її можна було б використовувати.
    1.3. Технічне завдання. 
 

    Автоматизована  довідково-інформаційна система (АСИС) “Облік постачань” використовуватиметься  на підприємствах різних форм власності і забезпечуватиме контроль і облік постачань вироблюваних на підприємство. Також при використанні даного ПО буде можливість складання звітності про постачання на підприємство, виявлення заборгованості по оплаті постачань. Що розробляється ПО може бути використано як керівником підприємства, для здійснення контролю вироблюваних постачань на підприємство, так і начальниками цехів, для ведення обліку постачань.
    1.3.1 Призначення розробки
    Метою дипломного проектування є розробка і створення програмного продукту “Облік постачань”. Даний програмне забезпечення призначене для контролю, обліку, автоматизації і систематизації інформації про постачання різного вигляду продукції на підприємство будь-якої форми власності, що займається будь-яким видом виробництва або діяльності.
    Програмний  продукт, що розробляється, повинен  забезпечувати створення інформаційної  бази про здійснені постачання на підприємство, а також здійснювати  створення наступних документів :
    бланк договору підприємства замовника з фірмою-постачальником (з вказівкою найменування і юридичних адрес сторін, що беруть участь в  договорі, асортименту продукції для постачань, її кількості, гаданої вартості, умови і терміни дії договору);
    заявку на постачання необхідній продукції (указується кількість, найменування, номенклатура, терміни постачання, сума постачання);
    замовлення на постачання.
    Комерційна  версія  програмного продукту дозволить  проводити:
    повніший контроль і організацію обліку про постачання на підприємство;
    автоматизувати процес оформлення постачань на підприємство;
    зменшить тимчасові витрати на оформлення документів, пов'язаних з постачаннями;
    обчислювати заборгованість по оплаті здійснених постачань на вказаний період;
    забезпечити користувача   системою допомоги як по поняттях наочної області, так і по користуванню програмним продуктом.
    Що  розробляється автоматизована система  повинна буде реалізувати наступні функції:
    Забезпечення введення даних про постачання на підприємство;
    Аналіз введеної інформації;
    Підрахунок заборгованості підприємства за здійснені постачання;
    Визначати оптимальний рахунок з точки зору “кількість-ціна”;
    Проводить друк документації, пов'язаної з організацією постачань (бланк договору, замовлення, заявки).
 
    1.3.4. Початкові вимоги  до кінцевого результату. 

Вимоги  по функціональності.
    АСИС, що розробляється, повинен забезпечувати  автоматизований контроль, а так  само облік постачань на підприємство (цех цього підприємства), для  цього створювана система винна:
    Забезпечувати введення, пов'язаних з постачаннями на підприємство і обробку  цих даних;
    Створювати звітні документи і документи для організації грузопоставок; ( Додаток 3)
    Мати систему допомоги за програмою;
    При введенні даних про найменування  товарів повинен використовуватися довідник “Номенклатура товарів”;
    Створювані документи повинні відповідати галузевим стандартам, прийнятим на підприємстві.
 
Умови експлуатації
      Створюваний програмний продукт повинен буде використовуватися директором підприємства, начальником цеху, начальником складу, залежно від місця експлуатації продукту. Задані характеристики функціонування повинні забезпечуватися за умов, які визначаються конкретним носієм даних, на якому зберігаються дані.  Найбільш поширеними носіями даних в даний час є жорсткі диски, для яких оптимальним є функціонування при температурах від 5 до +35оС і відносній вологості від 10 до 60 відсотків.
Вимоги  до складу і параметрів технічних засобів
      Програма  повинна функціонувати на персональних комп'ютерах з наступною конфігурацією:
    IBM PC/AT сумісних ПЕВМ не нижче Pentium 100;
    з об'ємом ОЗУ не менше 16 мегабайт;
    Об'єм необхідного дискового простору - не менше 10 мегабайт.
Вимоги  до інформаційної  і програмної сумісності
  Створювана  програма повинна функціонувати, легко  інсталюватися, настроюватися і  коректно працювати  при виконанні  наступних вимог:
    наявність операційної системи типу Windows 95, Windows 98, Windows NT 4.x, Windows 2000 і сумісних з ними;
    наявність бази даних LocalInterBase або сумісних з нею;
    введення дати обов'язкове у формі маски;
    введення цифр обов'язкове.
    Вимоги  по захисту.
    Для забезпечення захисту від несанкціонованого  доступу до інформації, пов'язаної з  постачаннями на підприємство буде передбачена  система паролів при завантаженні програми в оперативну пам'ять. Для  забезпечення захисту даних про  збої в мережі живлення ПК або аварійному завершенні роботи програми буде передбачений режим автозбереження.   

    2 Плановані показники ефективності. 

      В результаті виконаної роботи передбачається досягти наступних ефектів:
      зменшення часу необхідного для обліку постачань проведених на підприємство;
      автоматизація контролю постачань;
      можливість тривалого зберігання інформації про постачання на підприємство великого терміну давності, для можливості повнішого розрахунку ефективності діяльності підприємства;
      постійна популярність про терміни оплати здійснених постачань. 
    2.1 Аналіз представлення  моделей даних. 

    Для ефективного функціонування АСИС, що розробляється, “Облік постачань” буде розроблений СУБД. Тому нижче розглянуті логічні і концептуальні моделі даних.
    2.2 Вибір логічної моделі даних. 

    2.2.1 Ієрархічна модель  даних. 

    Ієрархічна  модель даних є ієрархією у вигляді дерева. Дана модель даних базується на сегменті, який є сукупністю полів, що характеризують даний сегмент. Сегменти розрізняються за типом, а кожен тип характеризується фіксованою довжиною і конкретним розбиттям на поля даних. Два зв'язані сегменти, розташованих на суміжних рівнях називаються початковим (більш високого рівня) і породженим (нижчого). Ієрархічний запис – система взаємозв'язаних сегментів, в якій кожен породжений сегмент представлений стільки раз, скільки необхідно для повного розкриття даного сегменту. У ієрархічній структурі є сегмент, який не має початкового і називається головним або кореневим. У цьому сегменті зазвичай розташовується ідентифікатор об'єкту, властивості якого розкриваються в сегментах другого і нижчих рівнів ієрархії.
    Для реалізації даної моделі на фізичному  рівні використовується ряд стандартних  методів розміщення даних на пристроях, що запам'ятовують, які можуть розміщувати  сегменти наступними ієрархічними способами доступу: послідовний, індексно-послідовний, прямою, індексно-прямою. Відповідно до способів розміщення сегментів встановлюється порядок доступу до них. Встановлений порядок доступу до сегментів обуславливает процедурна мови запитів і вимагає від користувача знання шляхів доступу до даним, що проходять по гілках дерева ієрархічного запису. Що є одним з недоліків даної моделі. Як інші недоліки можна відзначити наступні:
    Складність реалізації “багато до багатьом”, що вимагає надмірності даних на фізичному рівні, що приведе до небажаного і не виправданого збільшення БД;
    вимога підвищеної коректності до операції видалення, оскільки видалення початкового сегменту спричиняє за собою видалення породжених;
    доступ до будь-якого породженого сегменту можливий тільки через початковий, що збільшує час відповіді а запит до БД.
У зв'язку з тим, що ієрархічна модель володіє великою  кількістю недоліків вона не буде застосуються для моделювання АСИС, що розробляється.
 

2.2.2 Мережева модель  даних 

    Мережа [5] – більш загальна структура  порівняно з ієрархією. Вузлами  мережі є окремі екземпляри запису. Вузли запису є одиницею доступу  до БД. Оскільки окремий вузол може мати декілька безпосередньо старших  вузлів, так само, як і декілька безпосередньо підлеглих, то дана структура забезпечує пряме представлення відношення “багато до багатьом”. Для зв'язку між записами-вузлами існує запис, що пов'язує, всі екземпляри якого поміщаються в ланцюжок для зв'язку двох екземплярів.
    Основною  конструкцією мережевої моделі даних є набір. Для кожного типу набору, визначуваного в схемі, повинен  бути вказаний певний тип запису власника набору, а так само довільне число типів запису членів набору. Кожен екземпляр набору складається з одного екземпляра-власника і одного або більш за екземпляри записів-членів.
    Кожен екземпляр запису-набору представляє  ієрархічні зв'язки між екземпляром  запису-власника і відповідними екземплярами записів-членів. Це є наслідком того обмеження, що жоден екземпляр запису-члена  з набору на може належати більш, ніж одному екземпляру набору. Спосіб, яким кожен екземпляр запису власника зв'язується з відповідними екземплярами записів-членів, визначається в схемі мережі. Одним із способів організації таких зв'язків є встановлення ланцюжка покажчиків, що виходять з екземпляра запису-власника, записів-членів, що проходять через всі екземпляри, і що повертаються назад до екземпляра запису-власника, що забезпечує високу швидкість обробки запитів.
    Головний  недолік мережевої моделі полягає  в складності структур пам'яті. Користувач повинен знати, які ланцюжки існують і які відсутні. В результаті мова запитів процедурна і вимагає навиків програмістів.
 

     2.2.3 Реляционная модель  данных.
Реляційна модель – множинним відношенням  яке є підмножина декартова твори списку доменів [27,20]. Домен – це безліч значень, з якої витягуються значення для даного атрибуту. Іншими словами в основі реляційної моделі лежать прості таблиці, які задовольняють певним обмеженням, а тому можуть розглядатися як математичні відносини. Рядки таких таблиць називаються кортежами, імена стовпців – атрибутами. Слід зазначити, що всі кортежі різні, а порядок стовпців довільний, чим спрощується процес обробки кортежів. У відношенні (таблиці)  виділяється декілька атрибутів, що однозначно ідентифікують кортежі і званих ключами.
Особливість реляційної моделі полягає в тому, що у відмінності від мережевої  і ієрархічної моделей реальні  об'єкти і взаємозв'язки між ними представляються в базі даних  одноманітно у вигляді нормалізованих відносин [24].
Основний  недолік реляційної моделі даних  зв'язується з низькою продуктивністю реляційної СУБД. Але розробка сучасних СУБД таких як, ORACLE, InterBase, Acsses і ін. дозволило подолати і цей недолік.
Достоїнства реляційної моделі можна розділити  на дві групи:
    достоїнства для користувача:
      реляційна БД є набором таблиць з якими користувач звик працювати;
      не потрібно пам'ятати шляху доступу даним і будувати алгоритми і процедури обробки свого запиту;
      реляційні мови легкі для вивчення і освоєння, тоді як мови спілкування з ієрархічною і мережевою моделями призначені для програмістів і мало придатні для користувачів;
    достоїнства обробки даних реляційною БД:
      зв'язність. Реляційне уявлення дає ясну картину взаємозв'язків атрибутів з різних відносин;
      точність. Направлені зв'язки в реляційній БД відсутні. Відносини за своєю природою володіють точнішим сенсом і піддаються маніпулюванню з використанням таких засобів, як алгебра і числення відносин [5], забезпечуючу наочність і гнучкість моделі даних;
      гнучкість. Операції проекції і об'єднання [17] дозволяють розрізати і склеювати відносини, так що програміст може отримувати різноманітні файли в потрібній формі;
      секретність. Контроль секретності спрощується. Для кожного відношення є можливість завдання правомірності доступу, засекречені показники можна виділити в окремі відносини з перевіркою прав доступу.
      Простота впровадження. Фізичне розміщення однорідних (табличних) файлів набагато простіше, ніж розміщення ієрархічних і мережевих структур.
      Незалежність даних. БД повинна допускати можливість розширення, тобто додавання нових атрибутів і відносин.
Вивід: оскільки серед перерахованих логічних моделей даних реляційна володіє значними перевагами і малими недоліками, то вона і буде узята в основу для побудови СУБД. 

    2.3 Вибір концептуальної моделі. 

Для вибору концептуальної моделі даних розглянемо три їх різновиди:
    Семантична модель;
    Фрейми;
    Модель “суть-зв'язок”.
Семантична  модель грунтується на побудові семантичної мережі. Під семантичною мережею розуміють орієнтований граф, що складається з помічених вершин і дуг і задаючий об'єкти і відносини наочної області. Семантичні мережі володіють поряд достоїнств, а саме:
    Опис об'єктів наочної області відбувається природною мовою;
    Всі записи, що поступають в БД накопичуються в щодо однорідній структурі.
Але не дивлячись на ці переваги, семантична модель даних володіє поряд недоліків, один з яких і найбільш істотний, полягає в тому, що побудова реляційної моделі даних на основі семантичних  мереж утруднена.
Фрейми  виражаються структурами даних з прив'язаними процедурами обробки цих даних. Фрейми можуть бути наступних видів: подієві, характеристики, логічні предикати. Використання фреймової моделі так само недоцільно, оскільки дана модель не відображає типи зв'язків [14] в реляційній моделі даних.
    Модель  “суть-зв'язок”  описується в термінах суть, зв'язок, значення. Суть – поняття яке може бути ідентифіковане. Зв'язок – з'єднання суті. Для представлення зв'язків і суті введений спеціальний метод: ER-диаграма [27]. Розрізняється суть трьох основних класів: стрижньові, асоціативні і характеристичні. Стрижньова суть – це незалежна суть (їй властиве незалежне існування). Асоціативна суть або асоціація розглядається як зв'язок між двома або більш суттю типу "багато -ко- багатьом" або подібні до них. Характеристична суть (або характеристика) є суттю, єдина мета якої, в рамках даної наочної області, полягає в описі або уточненні деякій іншій суті. ER-диаграма – графічне представлення взаємозв'язків суті. Кожна безліч суті представляється прямокутником, а безліч зв'язків – ромбом. Зв'язки можуть бути трьох типів: “один до одного”, “один до багатьом”, “багато до багатьом”. дані типи зв'язку властиві реляційній моделі, як і суть, якій в реляційній моделі відповідають таблиці.
 

     2.4 Процес моделювання. 

    2.4.1 Виділення суті 

    Суть  “постачальник” є стрижньовою суттю  моделі, що розробляється. З постачальником полягає договір, на підставі якого  ведеться решта всієї діяльності підприємстві по постачаннях, відправлення заявки постачальникам, отримання від них рахунку-фактури, відправлення замовлення на постачання, отримання товару, оплата постачання. Як ключ для даної суті вводиться атрибут № Постачальника.
Вся суть, їх атрибути і ключі представлені в табл. 2.1.
    Таблиця 2.1
Назва суті Атрибут Ключ
Договір №Договора, дата договору, сума договору, термін дії. №Договора
Постачальник  №Поставщика, найменування постачальника, адреса, телефон. №Поставщика
Асортимент  товарів  №Товара, найменування товару. №Товара
Заявка №Заявки, асортимент заявки, номер договору, дата заявки. №Заявки
Замовлення  №Заказа, №Договора, асортимент замовлення, дата замовлення, номер рахунку. №Заказа
Рахунок №Счета, асортимент рахунку, ціна за одиницю товару, сума рахунку. №Счета
 
 

3. Проектування алгоритмів  довідково-інформаційної системи обліку і контролю постачань на підприємство.
    Алгоритмізація  в найзагальнішому вигляді може бути визначена як процес направленої  дії проектувальника (групи проектувальників), необхідний для вироблення алгоритмів, достатніх для реалізації створюваного об'єкту (системи), що задовольняє заданим вимогам [19]. Завершуючим етапом алгоритмізації є випуск набору алгоритмів, що відображає рішення, прийняті проектувальником, у формі, необхідній для виробництва об'єкту (системи). При проектуванні системи я використовував три класи алгоритмів:
    Алгоритми, пов'язані з проектуванням АСИС;
    Алгоритми реляційної алгебри, необхідні для роботи з БД;
    Алгоритми розрахунку необхідних показників (обчислення заборгованості підприємства по оплаті постачань, визначення оптимального рахунку-фактури).
     
    3.1 Вибір методу проектування  АСИС. 

Метод — це послідовний  процес створення моделей, які описують цілком певними засобами різні сторони  програмної системи, що розробляється [18]. Методи важливі з кількох причин. По-перше, вони упорядковують процес створення складних програмних систем. По-друге, вони дозволяють менеджерам в процесі розробки оцінити ступінь просування і ризик.
    Обычно  методы проектирования делятся на три  основные группы;
      Метод проектирования сверху вниз;
      Метод потоков данных;
      Объектно-ориентированное проектирование.
Для структурного проектування характерна алгоритмічна декомпозиція. Слід зазначити, що більшість  програм написана відповідно до цього  методу. Проте структурний підхід не дозволяє виділити абстракції і забезпечити обмеження доступу даним; він також не надає достатніх засобів для організації паралелізму. Структурний метод не може забезпечити створення гранично складних систем, і він, як правило, неефективний в об'єктних і об'єктно-орієнтованих мовах програмування. Тому даний метод не використовувався для проектування АСИС “Облік постачань”.
У методі потоків даних програмна система  розглядається як перетворювач вхідних  потоків у вихідні. Метод потоків  даних з успіхом застосовувався при вирішенні ряду складних завдань, зокрема, в системах інформаційного забезпечення, де існують прямі зв'язки між вхідними і вихідними потоками системи і де не потрібно приділяти особливої уваги швидкодії. Але оскільки однією з основних вимог що пред'являються до проектованої АСИС є збільшення швидкості автоматизації обліку постачань і зменшення тимчасових витрат на оформлення постачань на підприємстві, те застосування даного методу також недоцільно для проектування АСИС.
Об'єктно-орієнтоване  проектування (object-oriented design, OOD) — это підхід в основі якого лежить уявлення про те, що програмну систему потрібно проектувати як сукупність об'єктів, що взаємодіють один з одним, розглядаючи кожен об'єкт як екземпляр певного класу, причому класи утворюють ієрархію. Об'єктно-орієнтований підхід відображає топологію новітніх мов високого рівня, таких як Object Pascal, C++, Smalltalk [23] і ін. Моделі, для проектування якої використовується вищеназваний підхід проектування властиві чотири головні елементи:
    Абстрагування;
    Інкапсуляція;
    Модульна;
    Ієрархія.
Абстрагування дозволяє виділити істотні характеристики проектованого об'єкту, що відрізняють його від інших об'єктів;
Інкапсуляція  – процес відділення один від одного елементів об'єкту, що визначають його пристрій і поведінку. Вона дозволяє ізолювати контрактні зобов'язання абстракції від їх реалізації.
Модульна  – властивість системи, яка була розкладена на внутрішньо зв'язкові, але слабо зв'язані між собою модулі.
Ієрархія  – впорядковування абстракцій, розташування їх по рівнях.
Абстракція і інкапсуляція доповнюють один одного. Абстрагування направлене на спостереження поведінки об'єкту ззовні, а інкапсуляція визначає чіткі межі між різними абстракціями, тобто спостереження за поведінкою об'єкту зсередини.
Використання  цих елементів проектування і дозволяє значно збільшити продуктивність будь-якої проектованої системи.
Таким чином, для проектування АСИС використовується об'єктно-орієнтований підхід. 

    3.2. Аналіз алгоритмів  роботи з базою  даних 

    Система управління розробленою БД використовує реляційний підхід для побудови бази даних [20]. Подібні системи засновані на реляційній моделі даних, які  використовуються для моделювання взаємозв'язків між об'єктами реального миру і для зберігання даних про ці об'єкти. Застосування реляційної моделі даних [27] обумовлене використанням реляційної алгебри і відповідних алгоритмів і операцій для виконання дій над даними. Використання алгоритмів реляційної алгебри [20] дозволяє забезпечити високу продуктивність роботи з базою даних.
    Основні операції реляційної алгебри були вперше запропоновані Коддом [26]. Він довів, що запити, що формулюються за допомогою мови числення можуть бути сформульовані в мовах реляційної алгебри і навпаки [18], т.е запити представлені за допомогою мови реляційної алгебри можуть бути використані для виконання запитів до розробленої БД. Нижче приведений ряд запитів до БД: 
 

    SELECT nomer_dogovora, postav.nomer_postav, dogovor.nomer_postav,
                    naimen_post
    FROM    postav, dogovor
    WHERE postav.nomer_postav=dogovor.nomer_postav 

    SELECT select nomer_zajavki, zajavka.nomer_dogovora,           
                   dogovor.nomer_dogovora, naimen_post,postav.nomer_postav,
                   dogovor.nomer_postav            
    FROM    from zajavka,dogovor,postav
    WHERE (zajavka.nomer_dogovora=dogovor.nomer_dogovora)
                   AND (postav.nomer_postav=dogovor.nomer_postav) 

    SELECT nomer_zakaza, zakaz.nomer_dogovora, dogovor.nomer_dogovora,
                    naimen_post,postav.nomer_postav, dogovor.nomer_postav
    FROM    zakaz, dogovor, postav
    WHERE (zakaz.nomer_dogovora=dogovor.nomer_dogovora)
                   AND (postav.nomer_postav=dogovor.nomer_postav)
    Розглянемо  чотири операції над відносинами [20]:
    Селекція;
    Проекція;
    Теоретико-множественное об'єднання;
    З'єднання.
    Селекція  (selected_on – піддані селекції по) зменшує кількість рядків в таблиці, і її можна представити як результат розрізання таблиці по горизонталі і видалення непотрібних кортежів. Формально селекція записується так:
    R selected_on [<предикат>] { синтаксис мови запитів (SQL)}
    Тут <предикат> - це логічний вираз, який може містити порівняння значень  одних атрибутів із значеннями інших  в тому ж кортежі або з константами. В результаті зберігаються тільки рядки, що задовольняють <предикату>.
    Операція  селекції відповідає програмам, які  вибирають записи з файлів і друкують ці записи. Проте умови відбору  можуть відноситься тільки до окремо узятих записів. Наприклад, неможливо  вибрати запис, виходячи з того, що значення якого-небудь її поля рівно або більше, ніж значення цього поля в записі, що передйде. Насправді майже неможливо змоделювати поведінку автомата з кінцевим числом станів, який змінює свій стан для кожного запису, змінюючи тим самим критерії відбору для наступного запису.
    Проекція (projected_to – спроектоване на) зменшує кількість стовпців в таблиці; дану операцію можна уявити собі як розрізання по вертикалі назва операції має своїм джерелом поняття проекції безлічі точок N-мерного простору в простір з меншою кількістю вимірювань. Наприклад, в результаті проекції безлічі точок площини (Х,у) на вісь Х виходить безліч крапок, розташованих на цій осі. На жаль, значення проекцій деяких “крапок” можуть співпадати; це відбудеться у тому випадку, коли проекція видалить стовпець, що входить в ключ, так що частини двох “укорочених” кортежів, що залишилися, можуть бути ідентичними. Тоді доведеться видалити дублікати і тим самим зменшити кількість рядків, тобто розмір БД. Якщо хоч би один з можливих ключів при виконанні проекції залишиться незачепленим, то дублікатів не буде.
    Формально проекція записується таким чином:
    R projected_to <имя-атрибута>{, <имя-атрибута>}
    Де  список <імен-атрибутів> означає  імена стовпців, що зберігаються.
    Операція проекції відповідає програмі відбору декілька іншого роду, чим операція селекції, а саме, вона друкує певні поля з кожного запису. Видалення дублікатів зазвичай досягається в результаті сортування записів по необхідних полях, після чого записи пропускаються до тих пір, поки не зміниться значення поля. На практиці при одному перегляді файлу операція проекції зазвичай відбувається з операцією селекції.
    Теоретико-множественное об'єднання (union) має два операнди; вона бере рядки двох таблиць і розміщує їх один за одним, формуючи одну довгу таблицю. Це можливо лише у тому випадку, коли обидві таблиці мають один і той же тип, тобто мають співпадаючі назви (імена) і типи стовпців. Такі таблиці називають “сумісними по об'єднанню”. Всі дублікати рядків повинні бути видалені з відношення-результату. Дана операція аналогічна об'єднанню множин в алгебрі, але вона є додатковою по відношенню до обмеження, оскільки є можливість відновити відношення шляхом об'єднання двох доповнюючих один одного результатів операції селекції.
    Операція  теоретико-множественного відношення відповідає відомій операції “злиття” файлів. Якщо відомо, що файли не перетинаються, і якщо порядок записів не грає ролі, то досить скопіювати один файл в кінці іншого. Проте, як правило, файли підтримуються в порядку первинних ключів, і тоді використовуються прості алгоритми злиття., записи, що прочитують по черзі, з кожного файлу залежно від того, в якому з файлів запис має ключ з меншим значенням полів, так що в новий файл запису також поміщатимуться в порядку первинних ключів.
    З'єднання  (joined_to – з'єднання з) має два операнди; вона визначена для будь-яких двох таблиць. Якщо ці дві таблиці не мають стовпців із співпадаючими іменами, то з'єднання поводиться, як декартовий твір, сполучаючи кожен рядок першої таблиці по черзі з кожним рядком другої таблиці. Якщо імена всіх стовпців цих двох таблиць співпадають, то з'єднання поводиться як теоретико-множественное перетин, і створює таблицю, що складається з тих рядків, які зустрічаються в кожній з даних двох таблиць (така таблиця може бути і порожній, аналогічно порожній множині). Якщо у двох таблиць-операндів співпадають лише деякі імена стовпців, то в результаті з'єднання виходить таблиця, що містить всі імена стовпців першої таблиці, а також все ті імена стовпців другої таблиці, які не зустрілися в першій. Рядки результату вибираються з першої таблиці, а додаткові значення конкатенуються (приєднуються) з тих рядків другої таблиці, у яких значення в загальних стовпцях співпадають. До деякої міри з'єднання є доповненням проекції, якщо здійснити проекцію “початкового” відношення так, щоб вийшов набір відносин, кожне з яких зберігає первинний ключ початкового, то з'єднання цього відношення відновить початкове за додаткової умови, що кожен стовпець початкового відношення зустрічається хоч би в одній з проекцій.
    При формулюванні запитів операція з'єднання  є вирішальною, якщо в запиті використовується більш за одне відношення. Як правило, для формування запиту використовується з'єднання декількох таблиць, а  потім селекція необхідних рядків, і, нарешті, проекція на необхідні стовпці при друці.
    Операція  з'єднання більше всього відповідає операції “селективної вибірки”, при  виконанні якої список ключів представлений  у вигляді записів у файлі  транзакцій [19], і потрібно вибрати або записати у вихідний файл відповідні записи з основного файлу. Ключі у файлі транзакцій можуть співпадати, наприклад, із стороннім ключем в основному файлі або ж з частиною первинного ключа, і в цих випадках для кожного запису у файлі транзакцій  може бути вибране декілька записів з основного файлу. Таким чином, використовується з'єднання як узагальнений перетин [20].
Алгоритми, які виконують вищеперелічені операції, реалізуються на рівні системи управління базою даних. Їх зміст формується на основі визначень цих операцій. Для їх реалізації використовуються або стандартні функції мови програмування, або формується SQL-запрос.  

    4. Вибирання засобів  для розробки АСИС, опис структури  АСИС.
                 4.1 Вибирання апаратних засобів.
    При вибиранні апаратних засобів для розробки АСИС найбільшу роль грає чинник швидкодії роботи ПЕВМ. Оскільки саме від нього залежить час розробки ПО, а відповідно витрат на розробку і його собівартості.
    Швидкість функціонування ПЕВМ в основному  визначається наступними параметрами:
    Об'ємом оперативної пам'яті (ОП);
    Швидкодією процесора;
    Об'ємом відеопам'яті (ВП).
    Виходячи  з вимог що пред'являються до використовуваних програмних засобів розробки (Delpi 3.0 InterBase 4.2) мінімальне значення вищеперелічених параметрів складає ОП – 12 Мб, процесор – на базі Intel 486, ВП – 1 Мб.
    При мінімальних значеннях параметрів функцмонирование розробленою АСИС малоефективно, тому рекомендується є комп'ютер з наступними значеннями параметрів:
    Процесор – intel 586-100 Мгц;
    Оперативна памть – 16 Мб;
    Відеопам'ять – 1 Мб;
 
    4.2. Аналіз і вибирання  програмних засобів  розробки АСИС. 

    Сучасні засоби розробки ПО характеризуються великою різноманітністю критеріїв, используюя які розробник має можливість автоматизувати процес розробки додатків. Так, в даний час інструментальні засоби дозволяють:
    створювати інтерфейс испльзуя стандартні компоненти;
    передавати управління різним процесам, залежно від стану системи;
    створювати оболонки для баз даних, як і самі бази даних;
    розробляти надійніше ПО, шляхом обробки виняткових ситуацій що виникають при некоректній роботі ПО.
    Сучасні засоби розробки характеризуються наступними параметрами:
    підтримка об'єктно-орієнтованого стилю програмування;
    можливість використання CASE-технологий, як для проектування системи, що розробляється, так і для розробки моделей реляційних баз даних;
    використання візуальних компонент для наочного проектування інтерфейсу;
    підтримка БД;
    можливість використання алгоритмів реляційної алгебри для управління реляційними базами даних;
    можливість синхронізації складових частин проекту (надається при розробці великих програмних комплексів).
    При створенні програмного продукту АСИС “Облік постачань” головним критерієм  вибирання програмних засобів розробки були:
    швидкість розробки додатків;
    можливість швидкого внесення змін в програму;
    можливість редагування і проглядання БД, використовуючи засоби розробки.
 

    4.3 Опис програми.
    4.3.1. Опис інтерфейсу. 

         
    Після запуску файлу postavki.exe на виконання на моніторі з'являється головне меню (рис 4.1): 

    Рис 4.1 Головне меню АСИС
         
    Для початку роботи з програмою необхідно  з'єднатися з базою даних, для  чого клацнути по команді меню з'єднається  з БД. Якщо на комп'ютері користувача  встановлений InterBase Local Server і створена база даних, то з'явиться запит на підтвердження права доступу до БД (рис 4.2):  

    Рис 4.2 Вікно введення пароля
    Пароль  доступу Khai.
    У випадку, якщо з'єднання пройшло  успішно, то користувач допускається до роботи з АСИС.
 

     4.3.2 Робота з режимами АСИС 

    Робоче  вікно АСИС виглядає таким чином (рис 4.3): 

         
 
    Рис 4.3 Робоча область АСИС
    Нижче описана робота з АСИС.
Робота  з договорами
Робота  з договорами включає:
-  Робота з постачальниками;
-  Робота з договорами;
-  Робота з товарами;
-  Робота з укладеними договорами;
-  Робота з асортиментом договорів;
     Договір полягає підприємством-замовником  з підприємством-постачальником  на постачання певного вигляду  і асортименту продукції. З  одним постачальником може бути  поміщене декілька договорів. Як атрибути договору є наступні поля: номер договору, код постачальника, дата договору, сума договору, термін дії договору. Всі атрибути, окрім терміну дії договору є обов'язковими для заповнення. На підставі договору проводиться подальша діяльність по постачаннях на підприємстві. Вона полягає в:
-  Робота із заявками;
-  Робота з рахунками;
-  Робота із замовленнями.
     Для автоматизації використання  АСИС “Облік постачань” реалізована  можливість друку бланків документів  договору, заявки, замовлення.
    Додавання нового договору здійснюється  шляхом вибору відповідної закладки  і введенні тексту в поля-атрибути  таблиці. Додавання за умови,  що для договору, що додається,  відомий постачальник.
    Редагування відбувається при  натисненні клавіші Enter на вибраному записі. Відбувається автоматична зміна всіх полів інших таблиць пов'язаних з номером редагованого договору. Ця зміна необхідна для підтримки посилальної цілісності в БД.
    Для видалення певного договору  необхідно двічі клацнути правою кнопкою миші на договорі, що видаляється. Автоматично віддаляться всі записи пов'язані з договором, що видаляється (заявки, рахунки-фактури, замовлення).
Робота  з постачальниками
    Робота з постачальниками   полягає в додаванні нового  постачальника, його атрибутів, видаленні постачальника, редагуванні атрибутів постачальника: код постачальника (для кожного постачальника код унікальний), найменування постачальника, адреса і телефон постачальника. Всі атрибути, окрім телефону є обов'язковими для заповнення, у разі їх незаповнення виникає помилка.
    Додавання постачальника проводиться  таким чином: користувач вибирає  відповідну таблицю і заповнює  атрибути постачальника.
    Для редагування таблиці “постачальники” потрібно вибрати запис для редагування, натиснути клавішу Enter і змінити необхідну інформацію. Змінені атрибути постачальника автоматично змінюються в інших таблицях.
Видалення запису “постачальник” відбувається шляхом подвійного клацання мишею на записі, що видаляється. При цьому потрібний запит на підтвердження видалення запису.
Робота  з товарами
     Таблиця “товарами” є довідник товарів, які поставляються на підприємство. Атрибути цієї таблиці містять унікальний код для кожного товару і найменування товару. При укладенні кожного нового договору необхідно заповнити таблицю асортимент договору.
      Додавання новому запису в  таблицю здійснюється шляхом  введення інформації про товар  в рядки таблиці товари. Редагування  – натисненням клавіші Enter на редагованому рядку і зміні інформації.
Видалення – подвійним клацанням миші на рядку, що видаляється.
Робота  з укладеними договорами
    Робота з даною таблицею для  користувача обмежена, оскільки  даними для її заповнення служать  раніше заповнені таблиці (договір,  постачальник).
Робота  з асортиментом договорів
     Робота з асортиментом договорів  полягає в додаванні, редагуванні  і видаленні найменування товару  або товарів, які постачальник  зобов'язується поставити замовникові  на підставі переліку товарів,  що поставляються, указуваному  в укладеному договорі. Вищезгадані операції проводяться аналогічно операціям в роботі з договорами.
Робота  із заявкамиОскільки  дане ПО є спеціалізованим і орієнтовано  більшою мірою на промислові підприємства, то для його реклами буде застосуються “пряма поштова реклама”. З причини невеликої кількості передбачуваних продажів і малої вартості даного виду реклами,   витрати на рекламу однієї копії складуть: 1 грн.                                                          (3)
    Вартість  обслуговування покупця АСИС при  покупці однієї копії складає  12 грн. і включає: установку АСИС, надання керівництва користувача.                                                                                      (4)
    Відрахування  до пенсійного фонду, на соц. страх і страхування на випадок безробіття складають 37,5% від пункту (4) і рівні: 4,5 грн.                      (5)
    Собівартість  однієї копії складає суму 1-5: 26,97 грн.
    Прибуток  від однієї копії складає 100% собівартості: 26,97 грн.   (6)
    Ціна  однієї копії складатиме суму прибули  і собівартості однієї копії: 53,94 грн.
    Ціна  однієї копії з урахуванням ПДВ (20%) буде рівна:
                             1,2*(26,97+26,97)=64,73 грн.
    Податок на прибуток складає 30%, тому чистий дохід, отриманий від реалізації одою копії рівний різниці між прибутком і податком на неї і складає: 26,97-0,3*26,97=  18,88 грн. 
 
 
 
 
 
 

 


    Безпека життєдіяльності
Робота  ПЕВМ пов'язана з присутністю  на робочому місці людини – оператора, тому питання охорони праці розглядатимуться з погляду забезпечення безпечних умов праці і умов праці що зберігають здоров'я оператора, користувача.
    При роботі в приміщенні лабораторії  по виробництву ПО слід виділити наступні шкідливі і небезпечні  чинники:
    Метеорологічні умови середовища (мікроклімат лабораторії);
    Аномальне освітлення;
    Високий рівень шуму;
    Підвищений рівень іонізуючого випромінювання;
    Небезпека поразки електричним струмом;
    Підвищені психофізіологічні навантаження;
    Пожароопасность.
Вимоги  по вологості, що пред'являються до радіоелектронної техніки і норми мікроклімату, необхідні для нормальної життєдіяльності людини різні. Це пояснюється тим, що при експлуатації ПЕВМ вологість повітря в приміщенні згідно Гостам 12.1.005-86 повинна бути одній (не більше 40-60%), а вологість для оператора інший (не менше 70%). Тому, оптимальна вологість в лабораторії для оператора і ПЕВМ прийнята 50%.  Знижена вологість викликає у людини відчуття сухості слизистих оболонок верхніх дихальних шляхів, погіршує самочувтсвие і знижує працездатність.
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.