Анализ проблемы управления запасами; понятие зависимого и независимого спроса. Математическая и алгоритмическая модели динамического программирования для задачи управления запасами. Программный продукт Inventory Managment в среде Visual Studio 2010.
Теория управления запасами позволяет определять уровни запасов материалов, полуфабрикатов, производственных мощностей и других ресурсов в зависимости от спроса на них. В данной работе сделана попытка реализовать решение задачи управления запасами методом динамического программирования. Таким образом, при независимом спросе большую роль в управлении запасами играет прогнозирование, в то время как для зависимого спроса потребность в запасах определяется, исходя из производственного плана. Теория управления запасами объединяет в себе методы анализа задач регулирования запасов некоторого продукта при независимом спросе на этот продукт. Совокупность правил, по которым принимаются такие решения, называется стратегией (системой) управления запасами.using System.Text; using System.Windows.Forms; /// вероятность спроса public void FUNCTIONFIRSTETAP(int NASKLADE, double c_z, double h, double loss, double[] proba) /// public string[] Strategy(int n, double c_z, double h, double loss) string[] str = new string[mass.
Введение
Научно-технический прогресс создает предпосылки для повышения качества управления за счет использования вычислительной техники, математических методов, теории управления, автоматизации управления. Все это нашло конкретную реализацию в автоматизированных системах управления.
Управление заключается в сборе информации, ее переработке и выводе управляющей информации для изменения хода процесса.
Основным путем повышения качества управления является автоматизация управления производством, при которой данные задачи решаются средствами вычислительной техники.
Одной из задач управления предприятием является задача определения оптимального плана производства изделий, обеспечивающего заданный спрос продукции при минимизации затрат на производство и хранение продукции. Это задача оптимального управления запасами. Теория управления запасами позволяет определять уровни запасов материалов, полуфабрикатов, производственных мощностей и других ресурсов в зависимости от спроса на них.
Проблема управления запасами является одной из наиболее важных в организационном правлении. Но, как правило, не существует типовых решений - условия на каждом предприятии или фирме уникальны и включают множество ограничений и различных особенностей. С этим связаны и проблемы, возникающие при разработке математической модели и определении оптимальной стратегии управления запасами.
В данной работе сделана попытка реализовать решение задачи управления запасами методом динамического программирования.
1. Проблематика управления запасами в Украине
1.1 Анализ проблемы управления запасами
Товарно-материальный запас - это запас какого-либо ресурса или предметов, используемых в организации.
С точки зрения практики проблема управления запасами является чрезвычайно серьезной. Потери, которые несут предприятия (особенно промышленные) вследствие нерационального управления запасами, очень велики. Плохо, когда запас мал, недостаточен. Это может привести к нарушению ритмичности производства, росту себестоимости продукции, срыву сроков выполнения работ по договорам, потере прибыли. Однако же, крайне нежелательной является и ситуация, когда запас чрезмерно велик. В этом случае происходит "замораживание" оборотных средств организации. В результате те деньги, которые могли бы "работать", приносить доход покоятся на складах в виде запасов сырья, материалов, комплектующих.
Для эффективного решения проблем, связанных с управлением товарно-материальными запасами требуется применение соответствующих методов. Такие методы существуют, однако, к сожалению, на практике (особенно в России) они пока не находят должного распространения.
Очень показательным является высказывание одного из зарубежных исследователей: "...Слишком многие предприятия, к сожалению, управляют запасами совершенно неудовлетворительно; это говорит о том, что руководство не осознает всей важности материально-технических запасов производства. Но еще чаще бывает, что осознание проблемы существует. Не хватает понимания того, что надо делать и как это делать".
Итак, управление запасами на рациональной основе - весьма актуальная задача. Определяющее значение при построении системы управления запасами имеет характер потребности в хранимом продукте.
1.2 Зависимый и независимый спрос. Предмет теории управления запасами
Основная особенность, определяющая используемые методы планирования и контроля запасов, - характер спроса на эти запасы. Различают зависимый и независимый спрос. Предметы, использующиеся зависимым спросом, как правило, представляют собой подузлы и комплектующие, использующиеся в производстве конечного продукта.
Спрос (т.е. использование) на подузлы и комплектующие определяется объемом производства готовых изделий. Классическим примером здесь является потребность в колесах для выпускаемых автомобилей. Если для каждой машины требуется пять колес, то количество колес, требующихся для производства партии автомобилей, является простой функцией от объема этой партии. Например, для 200 машин требуется 1000 (200•5) колес.
Предметы с независимым спросом - это, чаще всего, готовые изделия, конечная продукция. Обычно готовый продукт продают (или отгружают) заказчику - в производстве какого-либо другого изделия она не участвует. В этом случае, как правило, невозможно точно определить потребность в товаре на какой-либо период времени, так как в спросе обычно присутствует элемент случайности. Таким образом, при независимом спросе большую роль в управлении запасами играет прогнозирование, в то время как для зависимого спроса потребность в запасах определяется, исходя из производственного плана. Теория управления запасами объединяет в себе методы анализа задач регулирования запасов некоторого продукта при независимом спросе на этот продукт. В задачах такого рода необходимо найти рациональное количество запаса, учитывая, что потери возникают как изза неудовлетворенного спроса, так и изза того, что продукт хранится на складе. Проблема управления запасами возникает при рассмотрении разнообразных экономических объектов. Широко распространены задачи управления запасами при анализе розничной торговли. В этом случае рассматриваются запасы некоторого продукта в магазине. Обычно спрос считается случайной величиной с заданным распределением. Запас пополняется за счет доставки товара с оптовой базы по заявке магазина, причем время доставки может быть фиксированным или же является случайной величиной. Перед управляющим встает вопрос: когда подавать заявку на пополнение запаса, и какое количество товара требовать в заявке? На подобные вопросы отвечает теория управления запасами.
Управлять запасами, как уже говорилось, необходимо и на производственных объектах, где нужно определять рациональный уровень запасов сырья, инструментов и т.п. Чрезмерный запас в этом случае приводит к нерациональному использованию оборотных средств, требует значительных затрат на хранение и уход за ним. С другой стороны, нехватка сырья, материалов или инструментов вызывает перебои в производстве. Поэтому установление рационального количества запаса является средством, позволяющим, с одной стороны, ликвидировать ненужные запасы, а с другой стороны - обеспечить ритмичность производства. Управление запасами заключается в установлении моментов и объемов заказов на их восполнение.
Совокупность правил, по которым принимаются такие решения, называется стратегией (системой) управления запасами.
Оптимальной стратегией считается та, которая обеспечивает минимум затрат по доведению продукции до потребителей.
Нахождение оптимальных стратегий составляет предмет теории оптимального управления запасами.
1.3 Основные стратегии управления запасами
Любая стратегия регулирования запасов призвана отвечать на два основных вопроса: когда заказывать очередную партию продукции, и сколько товара заказать?
Выделяют две основные стратегии регулирования запасов: · система с фиксированным размером заказа;
· система с фиксированной периодичностью заказа.
1.3.1 Система с фиксированным размером заказа
Предполагает, что размер поступающих партий - величина постоянная, а очередные поставки осуществляются через разные интервалы времени. Заказ на поставку партии делается при уменьшении размера запаса до заранее установленного критического уровня, называемого "точкой заказа" (в зарубежной литературе используется аббревиатура ROP - Reorder Point). Таким образом, интервалы между поставками зависят от интенсивности потребления продукта.
- величина запаса продукции на складе;
- "точка заказа", ROP (Reorder Point);
= const - объем доставляемой партии;
, продолжительность заготовительного периода.
Рисунок 1.1 - Движение запаса продукции при использовании стратегии с фиксированным размером заказа
Регулируемыми параметрами в такой системе являются: "точка заказа" (S, ROP) и объем заказа ( , ROQ - Reorder Quantity).
Интервал времени между подачей заявки и поступлением партии на склад называется заготовительным периодом. В модели продолжительность заготовительного периода может считаться постоянной, либо быть случайной величиной с заданным распределением. В качестве недостатка первой стратегии обычно называется необходимость регулярного учета материальных ценностей на складе, с тем, чтобы не упустить момент наступления "точки заказа". Стратегия с фиксированным размером более подходит для ответственных, важных материалов, поскольку предусматривает более жесткий контроль за состоянием запасов, следовательно, может быть обеспечена более быстрая реакция на угрозу исчерпания запаса.
1.3.2 Система с фиксированной периодичностью заказа
В данном случае продукция заказывается через равные промежутки времени, а размер запаса регулируется за счет изменения объема партии. Объем партии принимается равным разности между фиксированным максимальным уровнем, до которого производится пополнение запаса, и фактическим его размером в момент заказа.
Ситуацию иллюстрирует рисунок 4.2. На рисунке обозначены: -максимальный (плановый) уровень;
- интервал между заказами (планируемый период).
Рисунок 1.2 - Движение запаса продукции при использовании стратегии с фиксированной периодичностью заказа
Регулируемыми параметрами в такой системе являются: максимальный (плановый) уровень ( ) и интервал времени между двумя заказами ( называемый также планируемым периодом). Достоинство такой системы - отсутствие необходимости регулярного учета материалов. Недостатки: иногда приходится делать заказ на незначительное количество продукции, а при непредвиденно интенсивном потреблении возможно исчерпание запаса до наступления очередного момента заказа.
Рисунок 1.3 - Порядок функционирования основных стратегий управления запасами
1.4 Анализ предметной области
Предметной областью в задании является разработка программного продукта управления запасами. Пользователю этого ПП может понадобиться информация о затратах размещения заказов в месяц, затраты на хранение единицы запаса в месяц, потери при отсутствии материала на складе, количество материалов.
При выводе информации можно узнать следующие сведения: Затраты на всех и каждого материала при определенном спросе.
Распределение вероятностей спроса на следующий месяц.
Оптимальная стратегия, которая показывает, сколько нужно единиц запаса заказать при данном спросе на этот материал.
Такое представление повышает удобство в распределении запасов, в данном случае автоматизированный процесс, повысит скорость определения результатов и поможет избежать больших затрат при распределении запасов.
1.5 Постановка задачи
Целью данной работы является разработка автоматизированного рабочего места управления запасами на предприятии.
Для достижения поставленной цели необходимо решить следующие пользовательные задачи: 1) определить месячные затраты на размещение заказа и хранение запасов на предприятии
2) определить вероятность спроса на следующий месяц.
3) Определить оптимальную стратегию управления запасами на предприятии в условиях стохастического спроса.
4) Разработать UML диаграммы
5) Осуществить программную реализацию
2. Математическая модель динамического программирования для задачи управления запасами
Математической моделью называется совокупность математических соотношений, уравнений, неравенств и т.п., описывающих основные закономерности, присущие изучаемому процессу, объекту или системе. Из всех существующих моделей баз данных наиболее под описание математической модели подходит реляционная модель базы данных.
Мы используем простой пример, который будет служить нам на протяжении всей главы. Несмотря на простоту, пара фраз этого примера находит применение во многих приложениях в области управления запасами, замены оборудования, контроля и регулирования денежных потоков и др.
Каждый год сельгосп предприятие "Корюковка-Агро" проводит химический анализ, почвы. В зависимости от результатов анализа оптимальная стратегия оценивается как 1) не удобрять 2) удобрять.
Пусть или 2 обозначает две возможные (альтернативные) стратегии. Матрицы и , представляющие переходные вероятности и функцию расхода для альтернативы .
, , Задачу сельско-господарского предприятия можно представить как задачу динамического программирования (ДП) с конечным числом этапов следующим образом. Пусть число состояний для каждого этапа (месяца) равно m(3 в примере с магазином электротоваров). Обозначим через оптимальный ожидаемый доход, полученный на этапах от до включительно при условии, что система находится в начале этапа и состоянии .
Обратное рекуррентное уравнение, связывающее и , можно записать в виде где для всех .
Приведенное уравнение основано на том, что накапливающийся доход получается в результате перехода из состояния на этапе в состояние на этапе с вероятностью . Введя обозначение рекуррентное уравнение ДП можно записать следующим образом:
Проиллюстрируем использование рекуррентного уравнения для вычисления величин в задаче для ситуации, когда удобрения не применяются
Эти значения показывают, что если состояние почвы в начале года оказывается хорошим (состояние 1), то при одном переходе ожидаемый годовой доход составляет 5,3. Аналогично, если состояние почвы удовлетворительное, ожидаемый годовой доход составит 3, а в случае плохого будет равен -1.
В этом примере задача решается при данных, заданных матрицами , , , и , Предполагается, что горизонт планирования включает 3 года
Так как значения многократно используются в вычислениях, для удобства они сведены в таблицу. Напомним, что значение соответствует решению "не удобрять", - "удобрять".
1 5.3 4.7
2 3 3.1
3 -1 0.4
Этап 3
Оптимальное решение, k=1 k=2
1 5.3 5.3 5.3 1
2 3 3.1 3.1 2
3 -1 0.4 0.4 2
Этап 2 j Оптимальное решение, k=1 k=2
1 8.19 2
2 5.61 2
3 2.13 2
Этап 1 j Оптимальное решение, k=1 k=2
1 10.74 2
2 7.92 2
3 4.23 2
Оптимальное решение показывает, что в 1-й и 2-й годы предприятие должно применять удобрения независимо от состояния системы (состояния почвы по данным химического анализа). На 3-й год предприятию следует применять удобрения только тогда, когда система находится в состояниях 2 или 3 (т.е. при удовлетворительном или плохом состоянии почвы). Суммарный ожидаемый доход за три года составит = 10,74 при хорошем состоянии системы в 1-й год = 7,92 - при удовлетворительном состоянии системы в 1-й год и = 4,23 - при плохом состоянии.
Задача при конечном горизонте планирования может быть обобщена в двух направлениях. Во-первых, переходные вероятности и функции дохода не обязательно должны быть одинаковы для каждого года. Во-вторых, можно использовать коэффициент переоценки (дисконтирования) ожидаемых доходов для последовательных этапов, вследствие чего значения будут представлять собой приведенные величины ожидаемых доходов по всем этапам.
В первом случае значения доходов и переходные вероятности должны быть функциями этапа . Здесь рекуррентное уравнение динамического программирования принимает вид:
Второе обобщение заключается в следующем. Пусть (< 1) - годовой коэффициент переоценки (дисконтирования), тогда долларов будущего года равны долларам настоящего года. При введении коэффициента переоценки исходное рекуррентное уравнение преобразуется в следующее:
Выводы к разделу 2: В разделе 2 представлена модель динамического программирования с конечным числом этапов. Проведен анализ модели, а также приведен пример задачи по применению модели ДП с конечным числом этапов.
3. Алгоритмическая модель системы минимизации затрат на управление запасов
3.1 Метод прогонки
Этот метод является модификацией метода Гаусса для частного случая разреженных систем - системы уравнений с трехдиагональной матрицей. Такие системы получаются при моделировании некоторых пользовательских задач, а также при численном решении краевых задач для дифференциальных уравнений.
Запишем систему в виде
На главной диагонали матрицы этой системы стоят элементы , над ней - элементы , под ней - элементы При этом обычно все коэффициенты не равны нулю.
Метод прогонки состоит из двух этапов - прямой прогонки (аналога прямого хода метода Гаусса) и обратной прогонки (аналога обратного хода метода Гаусса).
3.1.1 Прямая прогонка
Прямая прогонка состоит в том, что каждое неизвестное выражается с помощью прогоночных коэффициентов
Из первого уравнения системы найдем:
С другой стороны, по формуле (2) Приравнивая коэффициенты в обоих выражениях
Из второго уравнения системы (1) выразим через , заменяя по формуле(2):
Отсюда найдем
Или
, Аналогично можно вычислить прогоночные коэффициенты для любого номера
, . (4)
3.1.2 Обратная прогонка
Обратная прогонка состоит в последовательном вычислении неизвестных . Сначала нужно найти . Для этого воспользуемся выражением (2) при и последним уравнением системы (1). Запишем их:
Отсюда исключаем находим далее используя формулы (2) и выражения для прогоночных коэффициентов (3), (4), последовательно вычисляем все неизвестные , .
При анализе алгоритма метода прогонки надо учитывать возможность деления на нуль в формулах (3). Можно показать, что при выполнении условия преобладания диагональных элементов, т. е. если , причем хотя бы для одного значения имеет место строгое неравенство, деления на нуль не возникает, и система (1) имеет единственное решение.
4. Разработка программного продукта "Inventory Management"
4.1 Теоретические сведения о языке UML
Часто при создании проекта трудно предусмотреть все аспекты его деятельности и его использования. Поэтому для создания объемных проектов используют моделирование. Моделирование - это устоявшаяся и повсеместно принятая пользовательная методика, а модель - схема системы или чертеж.
Моделирование позволяет решить четыре различных задачи [8]: - визуализировать систему в ее текущем или желательном для пользователя состоянии;
- определить структуру или поведение системы;
- получить шаблон, позволяющий затем сконструировать систему;
- документировать принимаемые решения, используя полученные модели.
При разработке программного обеспечения тоже существует несколько подходов к моделированию. Важнейший из них - алгоритмический и объектно-ориентированный.
Алгоритмический метод представляет традиционный подход к созданию программного обеспечения. Основными строительным блокам является процедура или функция, внимание уделяется большего всего вопросам передачи управления и декомпозиции больших алгоритмов на меньшие.
Наиболее современным подходом к разработке программного обеспечения является объектно-ориентированный. В нем в качестве основного элемента выступает объект или класс. Этот подход очень удобен т.к. большинство современных языков программирования являются в той или иной мере объектно-ориентированными.
Первичные цели при создании UML (Unified Modelling Language) были следующими: - предоставить пользователям готовый к использованию язык визуального моделирования, так чтобы они могли разрабатывать и обмениваться выразительными моделями;
- предоставить механизмы расширения и специализации, для расширения заложенных концепций;
- быть независимым от определенного языка программирования и процесса разработки;
- предоставить формальную базу для понимания языка моделирования;
- интегрировать лучший практический опыт разработок.
UML должен и может поддерживать все приемлемые языки программирования. Он также должен и может поддерживать различные методы и процессы построения моделей.
Система обозначений UML или нотация - это средство для того, чтобы выразить и зафиксировать идеи, размышления над архитектурой и поведением системы, возникшие в результате анализа.
Rational Rose, в отличие от подобных средств проектирования, способна проектировать системы любой сложности. CASE Rational Rose являясь объектно-ориентированным инструментом моделирования. Rose базируется на UML, который был разработан компанией Rational именно с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Любая задача программируется при помощи определенных диаграмм. В терминах представления модели UML определяет следующие графические диаграммы [9]: - диаграммы вариантов использования (use case diagram) , - диаграммы классов (class diagram) ;
- диаграммы описания поведения включают: § диаграммы состояния (statechart diagram) , § диаграммы активности (activity diagram) ;
Эти диаграммы предоставляют множественное представление, виды проектируемой системы при анализе и разработке. Лежащая в основе UML модель, интегрирует эти виды так, что внутренне-согласованную систему можно проанализировать и построить.
4.2 Концептуальное проектирование математических моделей с использованием языка UML
Цель концептуального проектирования математической модели состоит в определении принципиальных решений по созданию построению и использованию будущей модели в процессе решения проблемы, стоящей перед исследователем. Математическая модель в подавляющем большинстве случаев вполне достаточна для моделирования любых стратегий. Для достижения этой цели должны быть решены следующие задачи: 1. определение сути исследуемой системы, которую составляют наименование, состав, структура и целевая функция системы;
2. определение сути каждого элемента системы или ее подсистем;
3. выяснение и описание процесса функционирования системы, как последовательности состояний из множества Q (t), возникающих под воздействием внешних и внутренних факторов из множества X(t);
4. определение показателя эффективности функционирования системы, как функции выхода системы Y(t);
5. отбор подмножества наиболее существенных факторов и показателей, характеризующих процесс функционирования системы;
6. определение характера взаимосвязей между входом, состоянием и выходом системы, формализация математической модели процесса в общем виде;
7. постановка задачи на разработку технического, программного и информационного обеспечения моделирования данного процесса на ЭВМ.
4.3 Варианты использования
Диаграммы вариантов использования представляет собой последовательность действий, выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой.
Действующее лицо (actor) - это роль, которую пользователь играет по отношению к системе. Действующее лицо - это физические личность, или пользователь системы. Оно наиболее типично и имеются практически в каждой системе.
Варианты использования - это то, что пользователь ожидает от системы. Рассмотрим каждый фрагмент этого определения по отдельности.
На рисунке 4.1 в качестве актера выступает пользователь. Овалами представлены варианты использования. Во-первых пользователь должен ввести данные о затратах на размещение заказа, хранение запаса на складе и потери при отсутствии материала. Данные вводятся вручную посредством использования графического интерфейса. Вручную пользователь может добавлять новые данные, удалять их и редактировать.
Следующий вариант использования - получение решения. Во время ручного размещения данных система отрабатывает оптимальные стратегии, определяет стохастический спрос на следующий этап и расходы при управлении запасами.
Рисунок 4.1 Диаграмма прецедентов
Диаграммы взаимодействия
Диаграммы взаимодействия (interaction diagrams) являются моделями, описывающими поведение взаимодействующих групп объектов. Как правило, диаграмма взаимодействия охватывает поведение объектов в рамках только одного варианта использования. На такой диаграмме отображается ряд объектов и те сообщения, которыми они обмениваются между собой. Сообщение (message) - средство, с помощью которого объект-отправитель запрашивает у объекта получателя выполнение одной из его операций. Одной из разновидностью диаграммы взаимодействия является диаграмма последовательности. Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования.
Диаграмма последовательности соответствующая варианту использования "Ввод данных о геометрических объектах" представлена на рисунке 4.2:
Рисунок 4.2 Диаграмма взаимодействия
Диаграмма классов
Диаграммы классов являются центральным звеном объектно-ориентированных методов. Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.
Диаграммы классов отражают взаимодействие между классами системы. Классы можно рассматривать как типы объектов. Классы содержат данные и поведение (действия), влияющее на эти данные.
Разработчики используют диаграммы классов для реального создания классов. Такие CASE-средства, как Rational Rose, могут генерировать основу кода классов, которую затем программисты заполняют деталями на выбранном ими языке. С помощью этих диаграмм аналитики могут показать детали системы, а архитекторы системы - понять ее проект. Если, например, какой-либо класс несет слишком большую функциональную нагрузку, это будет видно на диаграмме классов, и архитектор сможет перераспределить ее между другими классами. Если между сообщающимися классами не определено никаких связей, это также будет видно на диаграмме. Диаграммы классов следует создавать, чтобы показать взаимодействующие классы в каждом варианте использования, можно создавать также более общие диаграммы, охватывающие все системы или подсистемы целиком.
Перед тем, как приступить к описанию диаграмм классов, следует обратить внимание на один важный момент, связанный с характером использования этих диаграмм разработчиками. Этот момент обычно никак не документируется, однако оказывает существенное воздействие на способ интерпретации диаграмм и поэтому имеет серьезное отношению к тому, что описывается с помощью модели.
Существуют три различных точки зрения на построение диаграмм классов: • концептуальная точка зрения. Если диаграммы классов рассматриваются с концептуальной точки зрения, то они будут отображать понятия изучаемой предметной области (моделируемой организации). Эти понятия, естественно, будут соответствовать реализующим их классам, однако такое прямое соответствие зачастую отсутствует. На самом деле, концептуальная модель может иметь весьма слабое отношение или вообще не иметь никакого отношения к реализующему ее программному обеспечению, поэтому ее можно рассматривать как независимую от средств реализации (языка программирования);
• точка зрения спецификации. В этом случае модель спускается на уровень ПО, но рассматриваются только интерфейсы, а не программная реализация классов (под интерфейсом здесь понимается набор операций класса, видимых извне);
• точка зрения реализации. В этом случае модель действительно определяет реализацию классов ПО. Эта точка зрения является наиболее распространенной среди программистов.
Понимание точки зрения крайне важно как для построения, так и для чтения диаграмм классов. К сожалению, различия между ними не столь отчетливы, и большинство разработчиков при построении диаграмм допускают смешение различных точек зрения.
При построении диаграммы точка зрения должна быть ясной и единственной. При чтении диаграммы следует выяснить, с какой точки зрения она строилась. Если нужно интерпретировать эту диаграмму правильным образом, то без такого знания не обойтись.
Точка зрения на диаграммы классов не является собственно формальной частью UML, однако при построении и анализе моделей она является крайне важной. Конструкции UML можно использовать с любой из трех точек зрения. Большинство опытных разработчиков-программистов предпочитают точку зрения реализации. С другой стороны, очевидно, что построение диаграмм классов на стадии формирования требований к ПО должно выполняться с концептуальной точки зрения.
Для решения поставленной задачи была разработана диаграмма классов, представленная на рисунке 4.6:
Рисунок 4.4 Диаграмма классов
FUNCTIONFIRSTETAP() - функция генерирования первого этапа
Min() - функция нахождения минимума(значение целевой функции)
SUMMIN() - вспомогательная функция которая понадобится для генерирования следующих этапов.
NEXTETAP() - функция генерирования следующего этапа.
GENERATIONNEXTETAP() - функция генерирования последующих этапов
Strategy() - функция определения оптимальной стратегии
Probability() - распределение вероятностей
FUTUREPROBABILITY() - распределение вероятностей на следующий временной этап.
Диаграмма состояния
Диаграммы состояний являются хорошо известным средством описания поведения систем. Они определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате наступления некоторых событий. В большинстве объектно-ориентированных методов диаграммы состояний строятся для единственного класса и отражают динамику поведения единственного объекта.
На диаграмме имеются два специальных состояния - начальное (start) и конечное (stop). Начальное состояние выделено черной точкой, оно соответствует состоянию объекта, когда он только что был создан. Конечное состояние обозначается черной точкой в белом кружке, оно соответствует состоянию объекта непосредственно перед его уничтожением. На диаграмме состояний может быть одно и только одно начальное состояние. В то же время, может быть столько конечных состояний, сколько вам нужно, или их может не быть вообще.
Рисунок 4.5 Формирование дерева решения
Конечной целью данной работы было создание программного продукта, который бы решал поставленную задачу. В результате была спроектирована и реализована в среде программирования Visual Studio 2010 на языке C#.
4.4 Системные требования
Требования к ЭВМ приведены в таблице 4.1.
Таблица 4.1 - Требования к ЭВМ
Тип ЭВМ IBM PC /совместимый
Операционная система ОС Windows XP SP3, 7
Платформа .Net Framework 4.0
Процессор 1ГГЦ и выше
ОЗУ 64 Мб
Место на HDD 3 Мб
4.5 Руководство пользователя
Рисунок 4.6 - Главное окно программного продукта
Сверху видим меню, состоящее из трех пунктов: · Проект;
Подготовится к расчету
Провести расчет
Выход
· Справка
Подменю "Проект" предназначено для подготовки вычислению, определению оптимальной стратегии.
При нажатии кнопки "Подготовится к расчету" открывается форма для ввода данных
Разработанный программный продукт (ПП) INVENTORYMANAGMENT позволяет определять оптимальную стратегию распределения запасов на предприятии. Комплексный показатель, рассчитываемый программой, учитывает ряд разнородных наукометрических показателей и позволяет определить оптимальную стратегию распределения запасов на предприятии. Разработанный ПП позволяет также проводить анализ полученных результатов. управление запас программный managment
Продукт разработан в среде Visual Studio 2010, на языке C#.
Для функционирования системы необходима ПЭВМ, удовлетворяющая следующим условиям: 1) процессор с частотой 1,1 ГГЦ или выше;
2) не менее 128 Мбайт оперативной памяти;
3) размер свободного места на жестком диске 50 Мбайт;
4) наличие устройств мышь и клавиатура;
5) операционная система Windows XP, Windows 7 или Windows Vista;
6) наличие дисковода.
Интерфейс программы прост и удобен в использовании, INVENTORYMANAGMENT - многооконное приложение, выполненное в стиле операционной системы Windows 7. ПП передается в эксплуатацию пользователю в виде *.exe - файла.
Преимуществами данной программы является разнообразие показателей, используемых для составления комплексной оценки научной деятельности, наглядность результатов, реализованная с помощью графиков и таблиц.
5.2 Состав исполнителей и продолжительность работ
Для руководства ходом работ и ведения всего проекта в целом необходима должность руководителя темы. Для работы с базой данных необходим программист баз данных. Для разработки математической модели системы необходим математик. Для разработки всей системы и ее последующей наладки и введения в эксплуатацию необходимо участие программиста. Продолжительность рабочего месяца в среднем примем равной 22 дням. Состав исполнителей приведен в таблице 6.2.
Таблица 5.2 - Состав исполнителей работы
Должности Должностные оклады, грн.
Месячные Дневные
Руководитель 2500 113,63
Старший программист 2000 90,91
Математик 1500 68,18
Приведем перечни работ для разработчиков программного продукта (таблица 5.3) [19].
Таблица 5.3 - Перечень работ
Номер стадии Наименование стадий и этапов Продолжительность, дни Исполнители, колво Трудоемкость, чел/дни
Руководитель Программист Математик
Разработка технического задания
1.1 Подготовка к созданию ПП 1 1 1
11.2 Разработка ТЗ на постановку задачи 5 1 5
Итого 6 6
Постановка задачи
2.1 Разработка мат. модели и алгоритмов 8 1 8
2.3 Техническое обеспечение 3 1 3
2.4 Разработка тестового примера 3 1 1 6
2.5 Разработка описания задачи и ТЗ 3 1 3
Итого 20 20
Разработка ПП
3.1 Разработка алгоритмов 6 1 1 12
3.2 Разработка интерфейса 8 1 8
3.3 Разработка программы 10 1 1 20
3.4 Разработка документации 3 1 3
3.5 Разработка технологической документации 3 1 3
3.6 Выпуск комплект. раб. документ. 3 1 3
Итого 33 49
Внедрение
4.1 Подготовка и внедрение ПП 10 1 1 20
4.2 Наладка и предварительное испытание 5 1 1 10
5.3 Расчет себестоимости программного продукта
Для расчета затрат на разработку программного продукта, для того, чтобы определить цену на товар, необходимо: 1. Составить перечень работ, которые следует выполнить, затем рассчитать трудозатраты на их выполнение.
2. Рассчитать заработную плату разработчиков.
В затраты на разработку программного продукта также входят: стоимость малоценных и быстроизнашивающихся предметов, стоимость аренды ЭВМ, отчисления с заработной платы и т.д.
В перечень работ, которые необходимо выполнить входит: 1) формулировка постановки задачи;
2) проектирование программного продукта;
3) разработка программного продукта;
4) внедрение продукта.
Расчет себестоимости работ начинается с расчета основной заработной платы разработчиков, с учетом трудозатрат, количества исполнителей и среднедневной заработной платы.
(6.1)
Рассчитаем расходы на материалы и комплектующие, необходимые для написания программы. Данные расходы представлены в таблице 6.4.
Таблица 5.4 - Расходы на материалы
Материал Количество, шт. Цена за единицу, грн Сумма, грн Назначение
Бумага формата А4, пачка (500 л.) 1 45,50 45,50 Документация
