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

2.2 Детальное проектирование

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

Классы - это базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами - атрибутами, операциями, отношениями и семантикой [4].

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

Атрибуты класса определяют состав и структуру данных, хранимых в объектах этого класса. Каждый атрибут имеет имя и тип, определяющий, какие данные он представляет. Для каждого атрибута класса можно задать видимость. Эта характеристика показывает, доступен ли атрибут для других классов [14].

Класс содержит объявления операций, представляющих собой определения запросов, которые должны выполнять объекты данного класса. Каждая операция имеет сигнатуру, содержащую имя операции, тип возвращаемого значения и список параметров, который может быть пустым. Для операций, как и для атрибутов класса, определено понятие «видимость». Закрытые операции являются внутренними для объектов класса и недоступны из других объектов, а остальные образуют интерфейсную часть класса.

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

· покупатель;

· продавец;

· заявка;

· отчет;

· документы;

· идентификация и аутентификация;

· система контроля запасов.

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

Кратность полюса ассоциации указывает, сколько объектов данного класса (со стороны данного полюса) участвуют в связи. Более распространен случай, когда кратность указывается как диапазон возможных значений, и тогда число объектов, участвующих в связи должно находиться в пределах указанного диапазона. При указании кратности используют символ «звездочка», который обозначает неопределенное число [4].

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

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

У остальных атрибутов классов видимость открытая, т.е. атрибут виден для любого другого класса. Например, в классах «Отчет», «Документы» атрибут «Категория» является видимым, что позволяет всем связным с ним классам выбирать перечень отчетов и документов.

Диаграмма классов с интерфейсами представлена на рисунке 6.



Рисунок 6 - Диаграмма классов

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



2.3 Алгоритмическое обеспечение

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

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

Разыгрывание дискретной случайной величины, подчиняющейся закону распределения D= , осуществляется следующим методом. Разбиваем отрезок [0,1] точками вида:;; тогда длинны соответствующих отрезков будут равны вероятностям случайных величин, подчиняющимся закону распределения D. Генерируем случайное числоU от 0 до 1. Находим отрезок, в который попало значение U (? U ? ) и присваиваем Х соответствующее значение из закона распределения, т.е. в данном случае это происходит так:

· если U ? 2/5, тогда Х возвращается число 3;

· если U ? 3/5, тогда Х возвращается число 4;

· если U ? 9/10, тогда Х возвращается число 5;

· если U 9/10, тогда Х возвращается число 6.

Время прихода покупателя случайная величина, подчиняющаяся экспоненциальному закону распределения функции с параметром л=10. Генерирование случайной величины Х рассчитывается по формуле , где U - случайное число от 0 до 1.

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

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

Что касается объема поставки (заявки), то для оптимизации данной величины часто применяют модели экономически обоснованного размера заказа (Economic ordering quantity, EOQ-model) или по-другому модель Уилсона.

EOQ-model основана на минимизации совокупных операционных затрат, которые делятся на две группы:

· затраты по размещению: сумма затрат по завозу товаров, расходы по транспортировке и приемке товаров.

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

· затраты по хранению товаров на складе предприятия как произведение половины среднего объема одной партии поставки сырья и средней стоимости хранения единицы производственного запаса.

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

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

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

,

где оптимальный размер заказываемой партии товара.

Таким образом, основываясь и модифицируя модель Уилсона в рассматриваемой задачи управления запасами, объем заявки на поставку товара на склад (месяц t) будем формировать путем разности между максимальным уровнем запаса склада и остатком товара на момент подачи заявки (месяц t) с учетом возможных объемов продаж склада (время прихода заявки умножить на количество проданных товаров за полный предыдущий месяц t-1) до прихода заявки. Формула расчёта следующая:

.

2.4 Расчет стоимости создания программного продукта

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

Модель жизненного цикла программного обеспечения - структура, содержащая процессы действия и задачи, которые осуществляются в ходе разработки, использования и сопровождения программного продукта [3].

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

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

Четыре главные фазы это:

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

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

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

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

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

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

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

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

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

3. Определение работ. Для каждого модуля системы выделяются основные этапы и лица, ответственные и выполняющие работы в каждом этапе. Работы могут быть либо в последовательном (каскадном), либо в параллельном выполнение.

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

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

Главными достоинствами такой модели являются [5]:

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

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

· возможность гибкого проектирования;

· уменьшение рисков заказчика;

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

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

Таблица 2 - Затраты по проекту создания системы

Модули системы / работы	Работники	Время в проекте, час	Тариф работы в час, руб	Начисленная з/п за проект, руб	Налоги по з/п, руб	Прочие расходы, перенесенные на стоимость ПО, руб	Цена модуля ПО, руб
Интернет-магазин		132	377,93	49 886,36	14 965,91	2 999,99	81 422,72
анализ,выявление требований к системе	менеджер проекта	8	227,27	1 818,18	545,45	181,82	3 054,54
стоимость этапа	1 818,18	545,45	181,82	3 054,54
проектирование	проектировщик ИС	48	284,09	13 636,36	4 090,91	638,58	22 039,02
	дизайнер	24	170,45	4 090,91	1 227,27	319,29	6 764,97
	программист	4	340,91	1 363,64	409,09	53,21	2 191,13
	менеджер проекта	6	227,27	1 363,64	409,09	79,82	2 223,06
стоимость этапа	20 454,55	6 136,36	1 090,91	33 218,18
программиров-ие	программист	40	340,91	13 636,36	4 090,91	826,44	22 264,46
	менеджер проекта	4	227,27	909,09	272,73	82,64	1 517,36
стоимость этапа	14 545,45	4 363,64	909,09	23 781,81
тестирование	тестировщик	20	227,27	4 545,45	1 363,64	413,22	7 586,78
	менеджер проекта	2	227,27	454,55	136,36	41,32	758,68
стоимость этапа	5 000,00	1 500,00	454,54	8 345,45
отладка	программист	16	340,91	5 454,55	1 636,36	126,48	8 660,87
	тестировщик	3	227,27	681,82	204,55	47,43	1 120,55
	менеджер проекта	0,5	227,27	113,64	34,09	7,91	186,76
стоимость этапа	6 250,00	1 875,00	181,82	9 968,18
документиров-ие	менеджер проекта	8	227,27	1 818,18	545,45	181,82	3 054,54
стоимость этапа	1 818,18	545,45	181,82	3 054,54
База данных		236	371,00	87 556,82	26 267,05	5 000,01	142 588,65
анализ, ыявление требований к системе	менеджер проекта	19	227,27	4 318,18	1 295,45	402,54	7 219,42
стоимость этапа	4 318,18	1 295,45	402,54	7 219,42
проектирование	проектировщик ИС	90	284,09	25 568,18	7 670,45	1 114,35	41 223,59
	дизайнер	32	170,45	5 454,55	1 636,36	396,21	8 984,55
	программист	16	340,91	5 454,55	1 636,36	198,11	8 746,82
	менеджер проекта	16	227,27	3 636,36	1 090,91	198,11	5 910,46
стоимость этапа	40 113,64	12 034,09	1 906,78	64 865,41
программиров-ие	программист	78	340,91	26 590,91	7 977,27	1 562,41	43 356,71
	менеджер проекта	4,5	227,27	1 022,73	306,82	90,14	1 703,62
стоимость этапа	27 613,64	8 284,09	1 652,55	45 060,33
тестирование	тестировщик	36	227,27	8 181,82	2 454,55	717,85	13 625,05
	менеджер проекта	2,25	227,27	511,36	153,41	44,87	851,57
стоимость этапа	8 693,18	2 607,95	762,71	14 476,62
отладка	программист	13	340,91	4 431,82	1 329,55	100,44	7 034,16
	тестировщик	5	227,27	1 136,36	340,91	62,77	1 848,06
	менеджер проекта	0,5	227,27	113,64	34,09	6,28	184,81
стоимость этапа	5 681,82	1 704,55	169,49	9 067,03
документиров-ие	менеджер проекта	5	227,27	1 136,36	340,91	105,93	1 899,85
стоимость этапа	1 136,36	340,91	105,93	1 899,85
Документооборот		120	363,26	43 590,91	13 077,27	2 727,27	71 274,54
анализ,выявление требований к системе	менеджер проекта	10	227,27	2 272,73	681,82	227,27	3 818,18
стоимость этапа	2 272,73	681,82	227,27	3 818,18
проектирование	проектировщик ИС	42	284,09	11 931,82	3 579,55	556,82	19 281,82
	дизайнер	20	170,45	3 409,09	1 022,73	265,15	5 636,36
	программист	5	340,91	1 704,55	511,36	66,29	2 738,64
	менеджер проекта	5	227,27	1 136,36	340,91	66,29	1 852,27
стоимость этапа	18 181,82	5 454,55	954,54	29 509,09
программиров-ие	программист	42	340,91	14 318,18	4 295,45	921,63	23 442,32
	менеджер проекта	1,5	227,27	340,91	102,27	32,92	571,32
стоимость этапа	14 659,09	4 397,73	954,54	24 013,64
тестирование	тестировщик	18	227,27	4 090,91	1 227,27	387,56	6 846,89
	менеджер проекта	1	227,27	227,27	68,18	21,53	380,38
стоимость этапа	4 318,18	1 295,45	409,09	7 227,27
отладка	программист	8	340,91	2 727,27	818,18	68,46	4 336,69
	тестировщик	3	227,27	681,82	204,55	41,07	1 112,92
	менеджер проекта	0,3	227,27	68,18	20,45	4,11	111,29
стоимость этапа	3 477,27	1 043,18	113,64	5 560,91
документиров-ие	менеджер проекта	3	227,27	681,82	204,55	68,18	1 145,45
стоимость этапа	681,82	204,55	68,18	1 145,45
Модуль управления запасами		240	372,87	89 488,64	26 846,59	7 454,55	148 547,73
анализ, выявление требований к системе	менеджер проекта	24	227,27	5 454,55	1 636,36	745,46	9 403,64
стоимость этапа	5 454,55	1 636,36	745,46	9 403,64
проектирование	проектировщик ИС	80	284,09	22 727,27	6 818,18	1 380,47	37 111,11
	дизайнер	32	170,45	5 454,55	1 636,36	552,19	9 171,72
	программист	16	340,91	5 454,55	1 636,36	276,09	8 840,40
	менеджер проекта	16	227,27	3 636,36	1 090,91	276,09	6 004,04
стоимость этапа	37 272,73	11 181,82	2 484,85	61 127,27
программиров-ие	программист	78	340,91	26 590,91	7 977,27	2 290,58	44 230,51
	менеджер проекта	4,5	227,27	1 022,73	306,82	132,15	1 754,03
стоимость этапа	27 613,64	8 284,09	2 422,73	45 984,55
тестирование	тестировщик	40	227,27	9 090,91	2 727,27	1 176,26	15 593,33
	менеджер проекта	2,25	227,27	511,36	153,41	66,16	877,12
стоимость этапа	9 602,27	2 880,68	1 242,43	16 470,46
отладка	программист	18	340,91	6 136,36	1 840,91	182,71	9 791,98
	тестировщик	6	227,27	1 363,64	409,09	109,63	2 258,82
	менеджер проекта	1	227,27	227,27	68,18	18,27	376,47
стоимость этапа	7 727,27	2 318,18	310,61	12 427,27
документиров-ие	менеджер проекта	8	227,27	1 818,18	545,45	248,49	3 134,55
стоимость этапа	1 818,18	545,45	248,49	3 134,55
Передача системы заказчику		80	264,20	21 136,36	6 340,91	1 818,18	35 154,54
сборка	программист	16	340,91	5 454,55	1 636,36	323,23	8 896,97
	менеджер проекта	2	227,27	454,55	136,36	40,40	757,58
стоимость этапа	5 909,09	1 772,73	363,64	9 654,55
тестирование и отладка	программист	6	340,91	2 045,45	613,64	102,27	3 313,64
	тестировщик	24	227,27	5 454,55	1 636,36	409,09	9 000,00
	менеджер проекта	2	227,27	454,55	136,36	34,09	750,00
стоимость этапа	7 954,55	2 386,36	545,45	13 063,64
установка ПО заказчику	специалист по внедрению	16	170,45	2 727,27	818,18	323,23	4 642,42
	менеджер проекта	2	227,27	454,55	136,36	40,40	757,58
стоимость этапа	3 181,82	954,55	363,64	5 400,00
обучение персонала заказчика	специалист по внедрению	24	170,45	4 090,91	1 227,27	545,45	7 036,36
стоимость этапа	4 090,91	1 227,27	545,45	7 036,36
ИТОГО:		808		291 659,09	87 497,73	20 000,00	478 988,18

В таблице 3 представлены помесячные затраты компании разработчиков системы на её создания.

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

Таблица 3 - Помесячные затраты компании по проекту создания системы

Расходы по созданию ПО	Себестоимость ПО	Цена ПО
Месяц	Начисленная зарплата работников по проекту	Налоги по з/п	Прочие расходы, перенесенные на стоимость ПО
1	66 210,52	19 863,15	4 000,00	90 073,67	108 088,41
2	65 296,61	19 588,98	4 000,00	88 885,59	106 662,71
3	64 441,74	19 332,52	4 000,00	87 774,26	105 329,11
4	65 625,00	19 687,50	4 000,00	89 312,50	107 175,00
5	30 085,23	9 025,57	4 000,00	43 110,80	51 732,95
ИТОГО:	291 659,09	87 497,73	20 000,00	399 156,82	478 988,18

Таблица 4 - Инвестиционный план проекта создания ПО

Месяц	Операционные потоки	Коэф. дисконт.	Дисконт. денежные потоки	Суммарный накопленный дисконт. поток
	Расходы по проекту	Инвестиции по проекту	Итого операционные потоки
1	-90 074	81 423	-8 651	1,000	-8 651	-8 651
2	-88 886	0	-88 886	0,877	-77 970	-86 621
3	-87 774	213 863	126 089	0,769	97 021	10 401
4	-89 313	0	-89 313	0,675	-60 283	-49 883
5	-43 111	183 702	140 591	0,592	83 241	33 359

Таким образом, проект по созданию ПО является эффективным с точки зрения чистой приведенной стоимости (NPV) равной 33 359 рублей. По нормам окупаемости в связи с финансированием после сдачи каждого модуля проект окупится только к концу срока, а именно спустя 4 месяца и 13дней. По нормам доходности проект является не рискованным, т.к. IRR составляет 36% при выбранной ставке дисконтирования 14%.

Таким образом, при выбранной модели создания ПО (спиральной), а так же при выбранной схеме финансирования проекта (после разработки каждого этапа системы), проект для разработчика является эффективным и не рискованным с рентабельностью 20%.



ЗАКЛЮЧЕНИЕ

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

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

В рамках постановки задачи автоматизации были определены основные моменты в части процессов автоматизации ИС, выполняющиеся цели, задачи и предназначения системы и описаны основные характеристики системы.

В выпускной работе на основе нотации BPMN 2.0 исследована предметная область в части взаимодействия работы склада и клиентов и выбора системы управления запасами.

В проектной части работы были выявлены функциональные требования к системе и основные пользователи. Это представлено на диаграмме вариантов использования UML. Для представления статической структуры проектируемой системы разработана диаграмма классов.

Рассчитана стоимость программного продукта согласно спиральной модели жизненного цикла системы.

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

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



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

1. BPMN 2.0 Графический язык моделирования бизнес-процессов. Версия 2.0. Нотация. - Введ. 2005. - М.: Изд-во стандартов, 2005. - 299 с.

2. Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. - М.:Лори, 2004. - 510 с.

3. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений / Г. Буч, Р. А. Максимчук, М. У. Энгл. - 3-е изд. - М.: Вильямс, 2008. - 720 с.

4. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Д. Рамбо, А. Джекобсон. - 2-е изд. - М.: ДМК, 2006. - 496 с.

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

6. Воронцовский, А. В. Инвестиции и финансирование: Методы оценки и обоснования / А. В. Воронцовский. - СПб. : Изд-во С.-Петербургского ун-та, 1998. - 528 с.

7. ГОСТ 34.003-90. Автоматизированные системы термины и определения. - Введ. 01.01.1992. - М.: Изд-во стандартов, 1992. 23 с.

8. ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы. - Введ. 01.01.1990. - М.: Изд-во стандартов, 1990. 12 с.

9. Заренков, В. А. Управление проектами: учебное пособие / В. А. Заренков. - 2-е изд. - М.: Изд-во АСВ, 2006. - 312 с.

10. Иванов, Д. Ю. Унифицированный язык моделировния UML: учебное пособие / Д. Ю. Иванов. - СПб.: Изд-во политехн. ун-та, 2010. - 249 с.

11. Информационные системы и технологии в экономике и управлении / Под ред. В. В. Трофимова. - М.: Высш. образование, 2006. - 480 с.

12. Каталевский, Д.Ю. Основы имитационного моделирования и системного анализа в управлении: учебное пособие; 2-е изд., перераб. и доп. / Д.Ю. Каталевский. -- М.: Издательский дом «Дело» РАНХиГС, 2015. -- 496 с.

13. Кугаенко А.А. Методы динамического моделирования в управлении экономикой: Учебное пособие с компакт-диском / Под ред. П.Е. Кондрашова. - 2-е изд., испр. и доп. - М.: Университетская книга, 2005. - 456 с.

14. Ларман, Крэг. Применение UML и шаблонов проектирования. 2-е изд.: Пер. с англ. / Крэг Ларман - М.: Издательский дом «Вильямс», 2004. - 624 с.

15. Леоненков, А.В. Самоучитель UML. / А. В. Леоненков. - СПб.: БХВ-Петербург, 2001. - 304 с.

16. Мазур, И.И. Управление проектами: учеб. пособие для студентов, обучающихся по специальности «Менеджмент организации» / И. И. Мазур, В.Д. Шапиро.- 6-е изд. - М.: Издательство «Омега-Л», 2010. - 960 с.

17. Марголин, А. М. Экономическая оценка инвестиционных проектов: учебник для вузов / A.M. Марголин. - М.: ЗАО Издательство Экономика, 2007. - 367 с.

18. Методические рекомендации по оценке эффективности инвестиционных проектов и их отбору для финансирования / Госстрой России, Министерство экономики РФ, Министерство финансов РФ, Госкомпром России 31 марта 1994 г. № 7-12/47. - М., 2006.

19. Рамбо, Д. UML 2.O. Объектно-ориентированное моделирование и разработка / Д. Рамбо, М. Блаха. - 2-е изд. изд. - СПб.: Питер, 2007.
- 544 с.

20. Разу, М.Л. Управление проектом. Основы проектного управления: Учебник / М.Л. Разу. - М.: КНОРУС, 2007. - 749 с.

21. Рыжиков, Ю.И. Теория очередей и управления запасами: учебник для вузов / Ю.И. Рыжиков. - СПб.: Питер, 201. - 384 с.

22. Светлов, Н.М. Информационные технологии управления проектами: учебное пособие / Н. М. Светлов, Г. Н. Светлова. - М.: ФГОУ ВПО РГАУ-МСХА им. К.А. Тимирязева, 2007. -- 144 с.

23. Смирнова, Г. Н. Проектирование экономических информационных систем / Г. Н. Смирнова, А. А. Сорокин, Ю. Ф. Тельнов. - М.: Финансы и статистика, 2003. - 512 с.

24. Теплова, Т. В. Финансовые решения: стратегия и тактика : учеб. пособие / Т. В. Теплова. - М.: ИЧП "Издательство Магистр", 1998. - 264 с.

25. Фёдоров, И. Г. Моделирование бизнес-процессов в нотации BPMN 2.0: Монография / И.Г. Фёдоров. - М.: МЭСИ, 2013. - 255 с.

26. Четыркин, Е. М. Финансовый анализ производственных инвестиций / Е. М. Четыркин. - М.: Дело, 1998. - 256 с.

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

28. Goods4Cast [Электронный ресурс]: сайт. - Режим доступа: http://goodsforecast.ru/Solutions/replenishment-short/

29. Inventor System [Электронный ресурс]: сайт. - Режим доступа: http://www.inventorsoft.ru/inventor/

30. Deductor Inventory Stock Optimization [Электронный ресурс]: сайт. - Режим доступа: https://dglab.tiu.ru/p3631097-deductor-inventory-stock.html

31. STOCK-M [Электронный ресурс]: сайт. - Режим доступа: http://stockm.ru/

32. ЦБТ [Электронный ресурс]: сайт. - Режим доступа: http://cbt.ua/1s_soft/instrument-planirovaniya-kompani-tsbt#jpreview

33. Forecast NOW [Электронный ресурс]: сайт. - Режим доступа: http://fnow.ru/

34. SIMPLE-system [Электронный ресурс]: сайт. - Режим доступа: http://genobium.ru/

35. Stock-solver [Электронный ресурс]: сайт. - Режим доступа: http://stocksolvers.com/

36. Dream Button [Электронный ресурс]: сайт. - Режим доступа: http://dreambutton.pro/

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