9. Перевірити: чи досяг підібраний об'єм запасів свого максимального значення - сумарного попиту за всі наступні періоди. Якщо ні, збільшити підібраний об'єм запасів і перейти до кроку 6. Якщо так, перейти до кроку 10.

10. Зберегти оптимальний об'єм запасів для даного періоду, для даного об'єму залишку, в таблицю рішень. Завершити виконання алгоритму.

Схема алгоритму вирішення задачі управління запасами представлена на рисунку 3.3. програмний база даний інтерфейс

Рис. 3.3. Схема алгоритму вирішення задачі управління запасами

За допомогою динамічного програмування можна мінімізувати витрати L, проте спосіб розрахунку витрат L залежить від того, наскільки достовірно відомий майбутній попит.

Для того щоб визначити ймовірності того, що попит в певний період дорівнюватиме значенню x, необхідно:

1. Визначити середньоквадратичне відхилення. Перейти до кроку 2.

2. Визначити математичне очікування. Перейти до кроку 3.

3. Визначити значення функції Лапласа для першого елементу. Перейти до кроку 4.

4. Визначити значення функції Лапласа для другого елементу. Перейти до кроку 5.

5. Визначити ймовірності того, що величина x попаде на інтервал від (x-1) до (x+1). Завершити виконання алгоритму.

Схема визначення ймовірності того, що попит в певний період дорівнюватиме значенню x, представлена на рисунку 3.4.

Рис. 3.4. Схема визначення ймовірності того, що попит в певний період дорівнюватиме значенню x

Розроблено 3 схеми для подальшої розробки промного забезбечення:

1. Схема роботи програми в цілому/

2. Схема визначення найбільш адекватної моделі прогнозування.

3. Схема алгоритму вирішення задачі управління запасами



РОЗДІЛ 4. РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

4.1 Основи процесу розробки програмного забезпечення

Програмне забезпечення розроблене на платформі Microsoft .NET Framework 3.5, мовою програмування С# в середовищі Microsoft Visual Studio 2008. Для доступу до баз даних використана технологія ADO.NET. У якості сервера баз даних слугує сервер MS SQL 2008.

Процес розробки програмного забезпечення - це ітеративний і наростаючий процес, при якому програмне забезпечення не створюється одним великим ударом в кінці проекту, а навпроти розробляється і реалізується по частинах. Схема процесу розробки зображена на рисунку 4.1.

Рис. 4.1. Схема процесу розробки

Першими двома фазами є початок і дослідження. У початковій фазі розробляється економічне обґрунтування проекту і визначаються його межі. Саме на цій фазі спонсор проекту переймає на себе певні зобов'язання щодо подальшої роботи. На початковій фазі розробляється бізнес-план проекту - визначається, яка його приблизна вартість і розмір очікуваного доходу. Слід також визначити межі проекту і виконати деякий попередній аналіз, щоб уявити собі його розміри.

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

- що насправді необхідно створити;

- як це можна реалізувати.

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

1. Ризики, пов'язані з вимогами. Які вимоги до системи? Велика небезпека полягає в тому, що буде розроблено зовсім не ту систему, яка виконуватиме зовсім не те, що потрібно користувачам.

2. Технологічні ризики. З якими технологічними ризиками доведеться зіткнутися? Чи дійсно дозволяє вибрана вами технологія реалізувати проект? Яким чином слід інтегрувати різні частини проекту?

3. Ризики, пов'язані з кваліфікацією персоналу. Чи є змога підібрати штат співробітників з необхідним досвідом і кваліфікацією?

4. Політичні ризики. Чи існують політичні сили, які можуть опинитися на вашому шляху і серйозно вплинути на виконання проекту?

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

Фаза дослідження повинна займати біля однієї п'ятої часу від загальної тривалості проекту. Основними ознаками завершення фази дослідження є наступні дві події:

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

- ідентифіковані всі найбільш серйозні ризики, а найважливіші з них зрозуміли настільки, що вам відомо, як з ними впоратися.

Фаза побудови складається з багатьох ітерацій, на кожній з яких виконуються побудова, тестування і інтеграція високоякісного програмного забезпечення, що задовольняє деякій підмножині вимог до проекту. Кожна ітерація містить всі звичайні фази життєвого циклу програмного забезпечення: аналіз, проектування, реалізація і тестування.

Існує безліч способів планування ітеративного проекту. Важливо розуміти, що план розробляється з метою забезпечити обізнаність всієї команди про хід виконання проекту.

Суть формування плану полягає у встановленні послідовності ітерацій побудови і у визначенні функціональності, яку слід реалізувати на кожній ітерації. Деякі розробники вважають за краще працювати з невеликими варіантами використання і на кожній ітерації завершувати роботу з одним з них. Інші вважають за краще працювати з великими по масштабу варіантами використання і на окремій ітерації розглядати тільки один з сценаріїв, а інші - на подальших ітераціях. Базовий процес при цьому є тим же самим. Отже, опишемо цей процес стосовно невеликих варіантів використання.

В ході планування краще розглядати дві групи осіб: клієнти і розробники.

Клієнтами є особи, які припускають використовувати систему, не виходячи за межі внутрішньо фірмової розробки. Для готової системи представниками клієнта є менеджери. Головна особливість тут полягає в тому, що клієнтами є особи, які можуть робити вплив на бізнес - процеси в тому або іншому варіанті використання, який підлягає реалізації.

Розробниками є особи, які беруть участь в побудові системи. Вони повинні адекватно оцінювати витрати і об'єми робіт, необхідні для реалізації окремого варіанту використання. Оцінку повинні виконувати саме розробники, а не менеджери. При цьому потрібно бути упевненим, що розробник, що оцінює даний варіант використання, розбирається в цьому найкращим чином.

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

Після того, як це зроблено, розробники повинні оцінити тривалість часу в людино-тижнях, який буде потрібно для реалізації кожного варіанту використання. При виконанні такої оцінки враховується час, необхідний для аналізу, проектування, кодування, тестування модулів, їх інтеграції і підготовки документації. При цьому слід дотримуватися принципу, що всі розробники повністю згодні з вирішеннями один одного без впливу деструктивних аспектів.

Підготувавши такі оцінки в той або інший момент часу, можна зробити висновок про те, чи в змозі ви виконати намічений план чи ні. Необхідно проаналізувати варіанти використання з високим ступенем ризику. Якщо велика частина часу роботи над проектом витрачається на ці варіанти використання, то необхідно виконати додаткове дослідження.

Наступний крок полягає в розподілі варіантів використання по ітераціях.

Варіанти використання, які володіють високим пріоритетом і/або ризиком розробки, слід реалізовувати насамперед. Не можна відкладати розгляд ризику в останню чергу! При цьому може виникнути необхідність розділити дуже великі варіанти використання і, можливо, переглянути попередні оцінки деяких варіантів використання відповідно до порядку їх реалізації [12,13].

Побудова системи виконується шляхом послідовності ітерацій. Кожна ітерація є в деякому розумінні міні-проектом. На кожній ітерації для відповідних до неї варіантів використання повинні бути виконані аналіз, проектування, кодування, тестування і інтеграція. Ітерація завершується демонстрацією результатів користувачам і тестуванням системи, яке проводиться з метою контролю правильності реалізації варіантів використання.

Ітерації на стадії побудови є як інкрементними (нарощуваними), так і такими, що повторюються.

Ітерації є інкрементними в сенсі деякої функції. Кожна ітерація реалізує чергові варіанти використання і додає їх до вже реалізованим в ході попередніх ітерацій.

Ітерації є такими, що повторюються в сенсі програмного коду, що розробляється. На кожній ітерації деяка частина існуючого програмного коду переписується наново з метою зробити його гнучкішим.

Мета ітеративної розробки полягає в тому, щоб зробити весь процес розробки більш послідовним, внаслідок чого команда розробників змогла б отримати готовий програмний продукт. Проте є деякі речі, які не слід виконувати дуже рано. Першою серед них є оптимізація.

Хоча оптимізація і підвищує продуктивність системи, але зменшує її прозорість і розширюваність. Саме тут необхідно ухвалити компромісне рішення - врешті-решт, система повинна бути достатньо продуктивною, щоб задовольняти вимогам користувачів. Дуже рання оптимізація ускладнить подальшу розробку, тому її слід виконувати в останню чергу.

4.2 Діаграма варіантів використання

Що таке варіант використання? Прямої відповіді на це питання не існує. Але спробувати на нього відповісти можна, описавши спочатку сценарій.

Сценарієм є послідовність кроків, що описують взаємодію між користувачем і системою. Таким чином, якщо ми розглянемо реалізований на веб-серверній технології Інтернет-магазин, то можна представити наступний сценарій покупки товарів в цьому магазині [12,13].

Покупець проглядає каталог і поміщає вибрані товари в корзину. За бажання сплатити покупку він вводить інформацію про кредитну картку і здійснює платіж. Система перевіряє авторизацію кредитної картки і підтверджує оплату товару негайно і по електронній пошті.

Подібний сценарій описує тільки одну ситуацію, яка може мати місце. Якщо авторизація кредитної картки виявиться невдалою, то подібна ситуація може послужити предметом вже іншого сценарію.

У такому разі варіантом використання є безліч сценаріїв, об'єднаних разом деякою загальною метою користувача.

Існує безліч способів запису змісту варіантів використання; мова UML в цьому сенсі не визначає ніякого стандарту. При цьому ви можете додати у варіант використання додаткові секції. Наприклад, можна ввести додаткову секцію для передумов, виконання яких є обов'язковим для того, щоб почалася реалізація окремого варіанту використання. Проте не слід включати у варіант нічого зайвого, що не зможе надати реальну допомогу.

Роботу програмного забезпечення можна умовно розділити на два основних етапи: побудова прогнозу і вирішення задачі управління запасами.

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

При вирішенні задачі управління запасами необхідно робити налаштування вартості зберігання одиниці товару, вартості оформлення поставки, та інше.

В обох випадках іноді необхідно переглянути детальну інформацію стосовно одного виду товарів, та редагувати результати вирішення.

Оскілки видів товарів може бути дуже багато, необхідно щоб була можливість обрати лише деякі з них для подальших розрахунків. Відповідно до зазначених вимог розроблена діаграма варіантів використання. Що представлена на рисунку 4.2.

Рис. 4.2. Діаграма варіантів використання



4.3 Проектування систем баз даних

Існують два основні підходи до проектування систем баз даних: низхідний і висхідний. При висхідному підході робота починається з самого нижнього рівня атрибутів (тобто властивостей суті і зв'язків), які на основі аналізу зв'язків, що існують між ними, групуються у відносини, що представляють типи суті і зв'язку між ними. Нормалізація передбачає ідентифікацію необхідних атрибутів з подальшим створенням з них нормалізованих таблиць, заснованих на функціональних залежностях між цими атрибутами [14].

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

Більш відповідною стратегією проектування складних баз даних є використання низхідного підходу. Починається цей підхід з розробки моделей даних, які містять декілька високо-рівневі суті і зв'язки, потім робота продовжується у вигляді серії низхідних уточнень низькорівневої суті, зв'язків і атрибутів, що відносяться до них. Низхідний підхід демонструється в концепції моделі "суть-зв'язок". В цьому випадку робота починається з виявлення суті і зв'язків між ними, що цікавлять дану організацію найбільшою мірою.

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

Моделі даних можуть використовуватися для демонстрації розуміння розробником тих вимог до даних, які існують на підприємстві. Якщо обидві сторони знайомі з системою позначень, використовуваній для створення моделі, то наявність моделі даних сприятиме продуктивнішому спілкуванню користувачів і розробників.

Оптимальна модель даних повинна відповідати наступним критеріям [15]:

- структурна достовірність - відповідність способу визначення і організації інформації на даному підприємстві;

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

- виразність - здатність представляти відмінності даними, зв'язки між даними і обмеження;

- відсутність надмірності - виключення зайвої інформації, тобто будь-яка частина даних повинна бути представлена тільки один раз;

- здатність до сумісного використання - відсутність приналежності до якогось особливого застосування або технології і. отже, можливість використання моделі в багатьох застосуваннях і технологіях;

- розширюваність - здатність розвиватися і включати нові вимоги з мінімальною дією на роботу вже існуючих застосувань;

- цілісність - узгодженість із способом використання і управління інформацією усередині підприємства;

- схематичне уявлення - можливість представлення моделі за допомогою наочних схематичних позначень.

Перший етап процесу проектування бази даних називається концептуальним проектуванням бази даних. Він полягає в створенні концептуальної моделі даних для аналізованої частини підприємства. Ця модель даних створюється на основі інформації, записаної в специфікаціях вимог користувачів. Концептуальне проектування бази даних абсолютно не залежить від таких подробиць її реалізації, як тип вибраної цільової СУБД. набір створюваних прикладних програм, використовувані мови програмування, тип вибраної обчислювальної платформи, а також від будь-яких інших особливостей фізичної реалізації. При розробці концептуальна модель даних постійно піддається тестуванню і перевірці на відповідність вимогам користувачів. Створена концептуальна модель даних підприємства є джерелом інформації для етапу логічного проектування бази даних.

Другий етап проектування бази даних називається логічним проектуванням бази даних. Його мета полягає в створенні логічної моделі даних для досліджуваної частини підприємства. Концептуальна модель даних, створена на попередньому етапі, уточнюється і перетвориться в логічну модель даних. Логічна модель даних враховує особливості вибраної моделі організації даних в цільовій СУБД (наприклад, реляційна модель).

Якщо концептуальна модель даних не залежить від будь-яких фізичних аспектів реалізації, то логічна модель даних створюється на основі вибраної моделі організації даних цільовою СУБД. Інакше кажучи, на цьому етапі вже повинно бути відомо, яка СУБД використовуватиметься як цільова - реляційна, мережева, ієрархічна або об'єктно-орієнтована. Проте на цьому етапі ігнорується решта всіх характеристик вибраної СУБД, наприклад, будь-які особливості фізичної організації її структур зберігання даних і побудови індексів.

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

Фізичне проектування є третім і останнім етапом створення проекту бази даних, при виконанні якого проектувальник приймає рішення про способи реалізації бази даних, що розробляється. Під час попереднього етапу проектування була визначена логічна структура бази даних (яка описує відносини і обмеження в даній прикладній області). Хоча ця структура не залежить від конкретної цільової СУБД, вона створюється з урахуванням вибраної моделі зберігання даних, наприклад реляційною, мережевою або ієрархічною. Проте, приступаючи до фізичного проектування бази даних, перш за все необхідно вибрати конкретну цільову СУБД. Тому фізичне проектування нерозривно пов'язане з конкретною СУБД. Між логічним і фізичним проектуванням існує постійний зворотний зв'язок, оскільки рішення, що приймаються на етапі фізичного проектування з метою підвищення продуктивності системи, здатні вплинути на структуру логічної моделі даних.

Як правило, основною метою фізичного проектування бази даних є опис способу фізичної реалізації логічного проекту бази даних. У разі реляційної моделі даних під цим мається на увазі наступне [16]:

- створення набору реляційних таблиць і обмежень для них на основі інформації, представленої в глобальній логічній моделі даних;

- визначення конкретних структур зберігання даних і методів доступу до них, що забезпечують оптимальну продуктивність СУБД;

- розробка засобів зашиті створюваної системи.

Проектування бази даних - це ітераційний процес, який має свій початок, але не має кінця і складається з нескінченного ряду уточнень. Його слід розглядати перш за все як процес пізнання. Як тільки проектувальник приходить до розуміння роботи підприємства і сенсу оброблюваних даних, а також виражає це розуміння засобами вибраної моделі даних, придбані знання можуть показати, що потрібний уточнення і в інших частинах проекту. Особливо важливу роль в загальному процесі успішного створення системи грає концептуальне і логічне проектування бази даних. Якщо на цих етапах не вдасться отримати повне уявлення про діяльність підприємства, то завдання визначення всіх необхідних призначених для користувача уявлень або забезпечення захисту бази даних стає надмірно складним або навіть нездійсненним. До того ж може виявитися скрутним визначення способів фізичної реалізації або досягнення прийнятної продуктивності системи. З іншого боку, здатність адаптуватися до змін є одним з ознак вдалого проекту бази даних. Тому цілком має сенс витратити час і енергію, необхідні для підготовки якнайкращого можливого проекту.

При розробці реляційної моделі бази даних враховувались наступні бізнес правила:

- всі товари одного виду мають однакову вартість зберігання;

- одному виду товарів відповідає один постачальник;

- якщо у постачальника змінюється ціна на товар, то цей товар необхідно вважати новим товаром;

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

- замовлення обов'язково буде виконане;

- довжина періоду є постійною.

Розроблена база даних включає наступні сутності:

1 GlobalTypeOfArticles - перелік унікальних видів товарів. До атрибутів входять ідентифікаційний номер та назва виду товарів.

TypeOfArticles - перелік всіх видів товарів. Відповідно до бізнес-правил, якщо у виду товарів змінюється вартість зберігання, вартість оформлення поставки, чи інше, то це вже буде вважатися інший вид товарів. Тобто він буде відноситись до того ж глобального виду товарів, але буде мати свої власні параметри. До атрибутів входять: ідентифікаційний номер глобального виду товарів id_globalTypeOfArticle, вартість зберігання одиниці товару costOfStorage, вартість оформлення поставки costOfDelivery, втрати від дефіциту одиниці товару lossesAtDeficit та порядковий номер постачальника id_supplier.

Periods - зберігає перелік періодів, в який входять як минулі, так и майбутні періоди.

GlobalArticles - перелік унікальних товарів. Для кожного товару зберігається назва name, ідентифікаційний номер глобального виду товару id_globalTypeOfArticle та додаткова інформація description.

Articles - перелік усіх товарів. Відповідно до бізнес-правил, якщо у товару змінюється вартість, то цей товар вже буде вважатися іншим товарів. Тобто він буде відноситись до того ж глобального товару, але буде мати свої власні параметри. До атрибутів входять ідентифікаційний номер товару, порядковий номер глобального товару id_GlobalArticles та ціна price.

DemandOnATypeOfArticles - реалізує відношення «багато до багатьох» між сутностями Articles та Periods. Зберігає значення попиту value на вказаний вид товарі у вказаний період.

DemandOnAArticles - реалізує відношення «багато до багатьох» між сутностями TypeOfArticles та Periods. Зберігає значення попиту value на вказаний товар у вказаний період.

Orders - перелік замовлень, де кожному замовленню вказані об'єм value, дата оформлення date, ідентифікаційний номер товару id_articles та періоду id_periods до початку якого замовлення має бути виконане.

Suppliers - зберігає перелік постачальників. Для кожного постачальника зберігається його ідентифікаційний номер id_suppliers, назва name та додаткова інформація description.

Реляційна модель бази даних представлена на рисунку 4.3.



Рис. 4.3. Реляційна модель бази даних

4.4 Опис інтерфейсу користувача

Вікно вибору видів товарів дозволяє завантажити базу даних, та обрати ті товари, для яких необхідно вирішити задачу управління запасами. Вікно вибору видів товарів представлено на рисунку 4.4.

Рис. 4.4. Вікно вибору видів товарів

Після того як потрібні види товарів обрано, необхідно натиснути кнопку «Далі». Після натискання кнопки «Далі» з'являється вікно налаштування процесу прогнозування (рисунок 4.5.). В цьому вікні, для кожного виду товарів, показані: вартість зберігання одиниці товару, вартість оформлення замовлення, витрати через дефіцит та число, якому повинний бути кратний об'єм замовлення. Поле «Модель прогнозування» дозволяє обрати модель, за допомогою якої буде будуватися прогноз. Поле «Кількість періодів» дозволяє вказати, на скільки періодів треба робити прогноз. Кнопка «Обрати види товарів» дозволяє повернутися до попереднього вікна. Кнопка «Побудувати прогноз» дозволяє перейти до наступного етапу.

Якщо двічі кліпнути на назву виду товарів, то з'явиться вікно (рисунок 4.6.), в якому можна переглянути наявну статистику по обраному виду товарів.

Рис 4.5. Вікно налаштування процесу прогнозування

Рис. 4.6. Вікно з детальною інформацією по обраному виду товарів



Після того як налаштування процесу прогнозування зроблені, необхідно натиснути кнопку «Побудувати прогноз». З'являється вікно, «Прогноз споживацького попиту» (рисунок 4.7.). В цьому вікні показано, яка модель прогнозування використовувалася для кожного із видів товарів.

Поле «Модель управління запасами» дозволяє обрати модель, за допомогою якої, на наступному етапі, буде вирішуватися задача управління запасами. Кнопка «Налаштувати прогнозування» дозволяє повернутися до попереднього етапу.

Якщо двічі кліпнути на назву виду товарів, то з'явиться вікно (рисунок 4.8.), в якому можна переглянути прогнозований споживацький попит для обраного виду товарів.

Рис. 4.7. Вікно що відображає модель прогнозування для кожного із видів товарів

Рис. 4.8. Вікно що відображає прогнозований споживацький попит для обраного виду товарів



Кнопка «Вирішити задачу управління запасами» дозволяє перейти до наступного етапу - вирішення задачі управління запасами. Після того як ця кнопка натиснута, запускається алгоритм, що вирішує задачу управління запасами, відповідно до обраної моделі, методом динамічного програмування. В залежності від об'ємів товарів та кількості періодів, процес вирішення задачі може зайняти деякий час. В результаті з'являється вікно 4.9., на якому представлені витрати фірми при різних стратегіях управління запасами.

Колонка «Одне замовлення» показує сумарні витрати фірми, у випадку, якщо буде зроблено тільки одне замовлення. Колонка «Рішення» показує витрати фірми, якщо замовлення будуть зроблені відповідно до рішення що надає програма. Колонка «Замовлення кожний період» показує сумарні витрати фірми, у випадку, якщо буде замовлення будуть робитися кожний період.

Кнопка «Повернутися до прогнозів» дозволяє повернутися до попереднього етапу. Кнопка «Зберегти рішення» дозволяє зберегти звіт, у форматі HTML, про отримане рішення.

Рис. 4.9. Вікно з витратами фірми при різних стратегіях управління запасами

Якщо двічі кліпнути на назву виду товарів, то з'явиться вікно (рисунок 4.10.), в якому можна переглянути детальну інформацію про рішення, а саме:

- номер періоду;

- прогнозований попит в даний період;

- залишок товарів на початок періоду;

- об'єм товарів, до якого необхідно довести запас ;

- об'єм товарів який необхідно замовити;

- вартість організації постачання;

- вартість зберігання надлишку;

- загальні витрати в кожний із періодів, та загальні витрати за всі періоди.

Рис. 4.10. Вікно з детальними даними про об'єм поставок

Розроблений інтерфейс програмного рішення є інтуїтивно зрозумілим і не потребує від користувача спеціальних знань або навиків[17].

На основі алгоритмічного забезпечення розроблене програмне рішення, яке допомагає вирішати такі питання:

1. Налаштування процесу прогнозування.

2. Детальна інформація по обраному товару.

3. Відображення моделі прогнозування для кожного виду товару.

4. Показує прогнозований споживацький попит доя обраного виду товару.

5. Показує витрати фірми при різних стратегіях управління.

6. Вивід детальних даних про об'єм поставок.



РОЗДІЛ 5. РЕЗУЛЬТАТИ ЧИСЕЛЬНИХ РОЗРАХУНКІВ

5.1 Опис чисельного прикладу

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

Вхідні дані, на основі яких проводяться розрахунки, отримані від торгівельної фірми «NetCraft Computers».

«NetCraft Computers» займається продажем електронного устаткування. Товари від виробників постачаються на центральний склад, і з центрального складу до пунктів роздрібної торгівлі. Вільне місце складу здається в оренду іншим фірмам. Замовлення нових партій товару від виробників виконується не частіше ніж раз на місяць. Всі товари поділені на п'ять видів, і кожний вид має підвиди:

1) комп'ютерна техніка та комплектуючі:

- процесори;

- материнські плати;

- оперативна пам'ять;

- відео карти;

- монітори;

- жорсткі диски;

- приводи (CD, DVD);

- корпуса для комп'ютерів.

1) портативна техніка:

- ноутбуки;

- комплектуючі для ноутбуків;

- комунікатори;

- електронні книги.

2) мультимедіа:

- Web - камери;

- TV - тюнери;

- звукові карти;

- MP3 плеєри.

3) акустичні системи:

- колонки;

- навушники.

4) оргтехніка:

- сканери;

- принтери;

- витратні матеріали.

Приводити чисельні розрахунки для всіх підвидів товарів недоцільно.

Таблиця 5.1 Статистичні дані продаж

Періоди	Підвиди товарів
	Процесори	Колонки	Ноутбуки	Web - камери	Сканери
01.03.2006	93	96	96	9	88
01.04.2006	73	82	82	10	59
01.05.2006	68	61	72	14	61
01.06.2006	64	65	85	14	60
01.07.2006	94	90	97	10	62
01.08.2006	124	117	101	14	104
01.09.2006	122	122	107	6	104
01.10.2006	117	123	114	6	112
01.11.2006	116	122	134	6	108
01.12.2006	92	85	152	5	93
01.01.2007	101	109	89	8	106
01.02.2007	89	93	89	9	98
01.03.2007	99	102	103	11	93
01.04.2007	74	84	94	12	60
01.05.2007	73	65	84	15	66



Рис. 5.1. Графічна інтерпретація статистики продажів

Параметри, необхідні для розрахунків сумарних витрат представлені у таблиці 5.

Таблиця 5.2 Параметри, необхідні для розрахунків сумарних витрат

Назва підвиду товарів	Вартість зберігання, грн./од.	Вартість оформлення поставки, грн.	Втрати від недостачі, грн./од.
Процесори	0,2	100	40
Колонки	0,5	50	10
Ноутбуки	1	200	70
Web - камери	0,1	50	10
Сканери	2	100	20

5.2 Виконання розрахунків

Вирішення задачі управління запасами складається з двох етапів:

1) побудова прогнозу попиту;

2) визначити оптимальний об'єм замовлень для кожного періоду.

За допомогою розробленого програмного рішення, побудуємо прогноз попиту на вказані підвиди товарів. Для того, щоб в подальшому можна було порівняти моделі управління запасами, прогнозування буде виконуватися на основі даних із 01.03.2006 по 01.02.2009.

В таблиці 5.3 показано, яка модель прогнозування, в даному випадку, виявився найбільш адекватним конкретному підвиду товарів.

Таблиця 5.3. Відповідність моделей прогнозування підвидам товарів

Назва підвиду товарів	Модель прогнозування, що в даному випадку виявилась найбільш адекватною
Процесори	Yt = b0 + b1*Yt-12
Колонки	Yt = b0 + b1*Yt-12
Ноутбуки	Yt = b0 + b1*Yt-12 + b2*Yt-24
Web - камери	Yt = b0 + b1*Yt-12 + b2*Yt-24
Сканери	?Yt = b0 + b1*?Yt-12

Отриманий прогноз приведений в таблиці 5.4.

Таблиця 5.4 Прогноз попиту

Періоди	Види товарів
	Процесори	Колонки	Ноутбуки	Web - камери	Сканери
01.03.2009	125	130	121	13	127
01.04.2009	103	116	112	12	85
01.05.2009	88	80	114	16	81
01.06.2009	79	80	120	17	76
01.07.2009	119	116	127	15	81
01.08.2009	152	143	138	16	122
01.09.2009	177	178	148	11	141
01.10.2009	156	164	177	8	140
01.11.2009	124	132	165	9	112
01.12.2009	131	121	187	8	125
01.01.2010	120	129	142	11	120
01.02.2010	108	114	119	12	103

Після побудови прогнозу, необхідно визначити оптимальний об'єм замовлень для кожного періоду. Для визначення оптимального об'єму замовлень реалізовано дві моделі:

1) модель із детермінованим динамічним попитом;

2) модель із вірогідним нестаціонарним попитом.

Результати вирішення задачі управління запасами, з використанням першої моделі представлені в таблиці 5.5. Результати вирішення задачі управління запасами, з використанням другої моделі представлені в таблиці 5.6.

Таблиця 5.5 Оптимальні об'єми замовлень товарів, отримані з використанням моделі із детермінованим динамічним попитом

Періоди	Види товарів
	Процесори	Колонки	Ноутбуки	Web - камери	Сканери
01.03.2010	395	130	233	148	115
01.04.2010	0	116	0	0	85
01.05.2010	0	160	234	0	81
01.06.2010	0	0	0	0	76
01.07.2010	271	116	265	0	81
01.08.2010	0	143	0	0	122
01.09.2010	457	178	325	0	141
01.10.2010	0	164	0	0	140
01.11.2010	0	132	352	0	112
01.12.2010	359	121	0	0	125
01.01.2011	0	129	261	0	120
01.02.2011	0	114	0	0	115

Таблиця 5.6. Оптимальні об'єми замовлень товарів, отримані з використанням моделі із вірогідним нестаціонарним попитом

Періоди	Види товарів
	Процесори	Колонки	Ноутбуки	Web - камери	Сканери
01.03.2010	420	153	253	148	127
01.04.2010	0	116	0	0	85
01.05.2010	0	155	234	0	81
01.06.2010	0	0	0	0	76
01.07.2010	271	121	265	0	81
01.08.2010	0	143	0	0	122
01.09.2010	457	178	325	0	141
01.10.2010	0	164	0	0	140
01.11.2010	0	132	352	0	112
01.12.2010	333	121	0	0	125
01.01.2011	0	220	241	0	120
01.02.2011	0	0	0	0	103

5.3 Аналіз результатів

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

Розрахунок сумарних витрат підприємства на зберігання процесорів та оформлення замовлень на процесори, якби воно керувалось результатами розрахунків за допомогою моделі із детермінованим динамічним попитом, представлені в таблиці 5.7.

Таблиця 5.7 Розрахунок витрат підприємства на процесори, при використанні моделі із детермінованим динамічним попитом

Період	Попит, од.	Об'єм замовлень, од.	Витрати на зберігання, грн.	Витрати на оформлення поставок, грн.	Втрати від дефіциту, грн.	Сумарні витрати за період, грн.
01.03.2009	118	395	277	200	0	477
01.04.2009	114	0	163	0	0	163
01.05.2009	93	0	70	0	0	70
01.06.2009	79	0	0	0	630	630
01.07.2009	119	271	152	200	0	352
01.08.2009	148	0	4	0	0	4
01.09.2009	167	457	294	200	0	494
01.10.2009	154	0	140	0	0	140
01.11.2009	126	0	14	0	0	14
01.12.2009	132	359	241	200	0	441
01.01.2010	117	0	124	0	0	124
01.02.2010	107	0	17	0	0	17
Разом	2926

Сумарні витрати підприємства на зберігання процесорів та оформлення замовлень на процесори, при використанні моделі із детермінованим динамічним попитом, дорівнювали би 2926 грн.

Розрахунок сумарних витрат підприємства на зберігання процесорів та оформлення замовлень на процесори, якби воно керувалось результатами розрахунків за допомогою моделі із вірогідним нестаціонарним попитом, представлені в таблиці 5.8.

Таблиця 5.8 Розрахунок витрат підприємства на процесори, при використанні моделі із вірогідним нестаціонарним попитом

Період	Попит, од.	Об'єм замовлень, од.	Витрати на зберігання, грн.	Витрати на оформлення поставок, грн.	Втрати від дефіциту, грн.	Сумарні витрати за період, грн.
01.03.2009	118	420	302	200	0	502
01.04.2009	114	0	188	0	0	188
01.05.2009	93	0	95	0	0	95
01.06.2009	79	0	16	0	0	16
01.07.2009	119	271	168	200	0	368
01.08.2009	148	0	20	0	0	20
01.09.2009	167	457	310	200	0	510
01.10.2009	154	0	156	0	0	156
01.11.2009	126	0	30	0	0	30
01.12.2009	132	333	231	200	0	431
01.01.2010	117	0	114	0	0	114
01.02.2010	107	0	7	0	0	7
Разом	2437

Таблиця 5.9 Сумарні витрати на зберігання товарів та оформлення замовлень

Моделі управління запасами	Процесори, грн.	Колонки, грн.	Ноутбуки, грн.	Web - камери, грн.	Сканери, грн.	Разом, грн.
Модель із детермінованим динамічним попитом	2926	808	2107	124,3	1672	7637,3
Модель із вірогідним нестаціонарним попитом	2437	605	2307	124,3	1452	6925,3



Сумарні витрат підприємства на зберігання та оформлення замовлень на інші підвиди товарів розраховуються аналогічно. В таблиці 6.9 представлені дані про сумарні витрати на зберігання товарів та оформлення замовлень всіх підвидів товарів.

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

Витрати на управління запасами при використанні моделі із вірогідним нестаціонарним попитом становлять на 712 грн. менше, ніж при використанні модель із детермінованим динамічним попитом. Отже, можна зробити висновок, що, при описаних вхідних даних і описаних методах прогнозування, використання моделі із вірогідним нестаціонарним попитом є більш доцільним, ніж використання моделі із детермінованим динамічним попитом.

Для визначення найбільш доцільної моделі управління запасами для даної предметної області, були проведені чисельні розрахунки. За допомогою розробленого програмного рішення були визначені терміни та обсяги замовлень. Потім були розраховані сумарні витрати підприємства, при використанні кожної із моделей. На основі розрахунків зроблено висновок, що, при описаних вхідних даних і описаних методах прогнозування, використання моделі із вірогідним нестаціонарним попитом є більш доцільним, ніж використання моделі із детермінованим динамічним попитом.



ВИСНОВКИ

В ході виконання даної дипломної роботи роботи було розроблено алгоритмічне забезпечення та програмне рішення процесу управління запасами в умовах централізованої системи постачання.

Отже, Централізована система постачання - управління процесом постачання, яке здійснюється через єдину службу підприємства, котра збирає від підрозділів заявки на закупівлю матеріально-технічних ресурсів і розміщує консолідовані замовлення у постачальників (виробників).

Ця система дає можливість збільшення масштабу закупівельної діяльності всього підприємства, що дозволяє зменшити витрати за збільшити доходи. Недоліком цієї системи постачання є збільшення часу на планування потреби і розміщення замовлень.

Розглянута класифікація методів прогнозування. Необхідно було обрати метод для прогнозування попиту по багатьом видам товарів. Експертні методи не підходять через велику вартість побудови прогнозу. Казуальні методи не підходять через необхідність виконання великого обсягу робіт по визначенню чинників, що впливають на поведінку прогнозованого показника. Найбільш прийнятними є методи прогнозування часових рядів, серед яких була обрана методологія Бокса-Дженкінса. В методології Бокса-Дженкінса не передбачається якої-небудь особливої структури в даних часових рядів, для яких робиться прогноз.

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

Після цього розроблено 3 схеми для подальшої розробки програмного забезбечення:

1. Схема роботи програми в цілому/

2. Схема визначення найбільш адекватної моделі прогнозування.

3. Схема алгоритму вирішення задачі управління запасами

На основі алгоритмічного забезпечення розроблене програмне рішення, яке допомагає вирішувати такі питання:

1. Налаштування процесу прогнозування.

2. Детальна інформація по обраному товару.

3. Відображення моделі прогнозування для кожного виду товару.

4. Показує прогнозований споживацький попит доя обраного виду товару.

5. Показує витрати фірми при різних стратегіях управління.

6. Вивід детальних даних про об'єм поставок.

Для визначення найбільш доцільної моделі управління запасами для даної предметної області, були проведені чисельні розрахунки. За допомогою розробленого програмного рішення були визначені терміни та обсяги замовлень. Потім були розраховані сумарні витрати підприємства, при використанні кожної із моделей. На основі розрахунків зроблено висновок, що, при описаних вхідних даних і описаних методах прогнозування, використання моделі із вірогідним нестаціонарним попитом є більш доцільним, ніж використання моделі із детермінованим динамічним попитом.



СПИСОК ЛІТЕРАТУРИ

1. Сверчков П. А. Підхід до прийняття рішення про централізацію закупівельної діяльності / Логістика та управління ланцюгами поставок. -- 2012. -- №3. -- 174с.

2. Руделіус В., Азарян О.М. та ін. -- 2-е видання. -- К.: НМЦ «Консорціум із удосконалення менеджмент-освіти в Україні» -- 2008. -- 648 c.

3. Болт Г.Дж. Практическое руководство по управлению сбытом: Пер с англ. - М.: МТ-Пресс. -- 2007. -- 268 c.

4. Букан Д., Кенигсберг Э. Научное управление запасами. Пер. с англ. М. -- 2007. -- 423 c.

5. Ханк Д.Э., Уичерн Д.У., Райтс А.Дж. Бизнес прогнозирование, 7-е издание.: Пер. с англ.-М.: Издательский дом «Вильямс». -- 2003. -- 645 c.

6. Четыркин Е.М. Статистические методы прогнозирования. Изд. 2-е, перераб. и доп.-М., «Статистика». -- 1977 -- 200 c.

7. Григорьев М.Н., Долгов А.П., Уваров С.А. Управление запасами в логистике: методы, модели, информационные технологии: Учебное пособие. - СПБ.: Изд. Дом «Бизнес-пресса». -- 2006. -- 200 c.

8. Ледин М.И. Управление запасами (экономико-математические методы).-М.: Знание. -- 1978. -- 64 с.

9. Лотоцкий В.А., Мандель А.С. Модели и методы управления запасами.-М.: Наука. -- 1991. -- 188 с.

10. Шрайбфедер Дж. Эффективное управление запасами: Пер. с англ. - 2-е изд.-М.: Альпина Бизнес Букс. -- 2006. -- 304 с.

11. Зергман П.Н. Практика управления товарными запасами, - М.: Дело. -- 2006. -- 308 c.

12. Фаулер М., Скотт К. UML. Основы. - Пер. с англ.-СПБ: Символ-Плюс. -- 2002. -- 192 с.

13. Гома Х. UML. Проектирование систем реального времени, параллельных и распределенных приложений: Пер. с англ.-М: ДМК Пресс. -- 2002. -- 704 с.

14. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.-СПБ: Питер. -- 2002. --656 с.

15. Конолли Т. Базы данных: проектирование, реализация и сопровождение.-М.: «Вильямс». -- 2001. -- 1120 с.

16. Хомоненко А.А., Цыганков В.М., Мальцев М.Т. Базы данных.-СПБ.: Корона. -- 2002. -- 848 с.

17. Чекалов А.П. Базы данных: от проектирования до разработки приложений.-СПБ.: БХВ - Петербург. -- 2003. -- 383 с.



АНОТАЦІЯ

У даній дипломній роботі було розроблено програмне забезпечення для вирішення задачі управління запасами. Структура роботи представлена вступом, п'ятьма розділами, висновком та списком літератури. У вступі визначено актуальність і мету теми, об'єкт та предмет дослідження, поставлені задачі. Зроблені висновки про виконану роботу і підведений підсумок дослідження. У роботі використано 9 таблиць, 24 рисунків, список використаної літератури з 17 найменувань. Загальний обсяг дипломної роботи становить 87 сторінок.

Тема: «Розроблення програмного забезпечення підтримки прийняття рішень процесу управління запасами в умовах централізованої системи постачання».

Мета роботи: розробка програмного забезпечення підримки прийняття рішень для визначення оптимального об'єму запасів, тобто такого при якому сумарні витрати на зберігання товарів і оформлення замовлень, на постачання товарів, будуть мінімальні.

Об'єкт дослідження: процес управління запасами в умовах централізованої системи постачання.

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

Задачі дослідження:

1. Розглянути теоретичні аспекти процесу управління запасами в централізованій системі постачання.

2. Обрати математичну модель управління запасами та метод прогнозування попиту.

3. Побудувати алгоритм вирішення задачі управління запасами.

4. Розробити програмне забезбечення для моделювання поставленних вище задач.

5. Провести чисельні розрахунки та вирішити, яка математична модель є більш доцільною

Наукова новизна роботи.

Практична цінність роботи.

In this thesis work has developed software to solve the problem of inventory management. The structure of the entry is represented by five chapters, conclusion and bibliography. The introduction defines relevance and purpose theme, object and subject of study of the problem. The conclusions of the work done and summed up the research. The paper used 9 tables, 24 figures, list of references with 17 titles. The total volume of the thesis is 87 pages.

Theme: « The development of software support decision process of inventory management in a centralized delivery system.».

The purpose of the work: software development backed up by a decision to determine the optimal amount of inventory, this is where the total cost of storage of goods and processing orders for goods to be minimal.

Object of study: inventory management process in a centralized delivery system.

Subject of study: software and algorithms provide decision support for inventory control models with deterministic dynamic transient and likely demand.

Objectives of the study:

1. Theoretical aspects of inventory management in a centralized supply system.

2. Select mathematical model of inventory management and demand forecasting method.

3. Build an algorithm for solving the problem of inventory management.

4. To develop software support for modeling mooring above problems.

5. Carry out numerical calculations and decide which mathematical model is more appropriate

Scientific novelty.

Practical value.

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