Размещено на http://www.allbest.ru/

Введение

1. Специальная часть

1.1 Назначение и область применения

1.2 Постановка задачи

1.3 Техническое задание на разработку

1.3.1 Введение

1.3.2 Основание для разработки

1.3.3 Назначение разработки

1.3.4 Требования к программному изделию

1.3.5 Требования к программной документации

1.3.6 Технико-экономические показатели

1.4 Разработка обеспечения компонентов САПР

1.4.1 Алгоритм работы программы

1.4.2 Процесс разработки ПО

1.4.3 Диапазон функционирования программы

1.4.4 Тестовый пример

1.5 Результаты работы программных модулей

2. Конструкторско-технологическая часть

2.1 Описание программы

2.2 Выбор модели процесса разработки ПО

2.3 Программа и методика испытаний

2.4 Руководство для сотрудника

3. Экология и охрана труда

3.1 Общие положения к организации рабочего мест

3.2 Требования к освещению рабочих мест

3.3 Требования к уровням шума и вибрации на рабочих местах

Заключение

Список литературы

Приложение 1

Введение

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

Модернизированное складское помещение - это сложнейшее с точки зрения технических нюансов сооружение. В эту систему входит огромное количество различных элементов, тесно связанных друг с другом. Эта система имеет достаточно сложную структуру, и ее функционирование по преобразованию потока заказов, накопление этих заказов, их распределение и их переработка между заказчиком и продавцом, все это является одним сложным и взаимосвязанным единым целым. Так же ко всему этому прилагается достаточно большое разнообразие важных функций, различного рода технические решения, создание конструкций, необходимых для хранения товара, оборудование и характеристики различной номенклатуры груза, который проходит по цепочке логистики через склад. В заключение всего вышесказанного можно уже точно убедиться, что складские помещения и работа с ними - достаточно сложный механизм. Однако именно склад, не является так сказать ядром всего этого логистического процесса, он лишь одно из звеньев этой огромной и сложной цепи, достаточно важное, но именно звено. А все формирование основных технических требований к складу, постановка первостепенных и второстепенных целей, а так составление критерий оптимизации формирования и функциональности этой цепи диктует базовое звено этого процесса, сама логистическая цепь.

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

Однако, нельзя не учитывать, что каждый случай индивидуален и все отдельные элементы складской деятельности данного помещения могут значительно отличаться от других складов, а так же структура, функции и параметры окажутся разными. Ведь все это завязано на тесной связи элементов внутри системы, а она может быть у разных складов разная. Во главе создания любой складской системы будет находиться следующий главенствующий принцип: только индивидуальный подход, учитывающий все различные факторы, которые влияют на данную систему делает ее рентабельной и актуальной. Главной задачей в этот момент является четкое определение и представления поставленных, функциональных задач и глубокий анализ и изучение динамики и переработки продукции внутри самого склада и при выходе ее за его территорию. Так же стоит учитывать, что включение чересчур гибких возможностей может повлечь за собой повышенные растраты, что в условиях ограниченного бюджета может плохо сказаться на функционале логистической цепи. Включение реальных, благоразумных и главное осуществимых показателей - ключ к успеху. При создании логистической цепи, ну так же как и при создании любой системы нужно обязательно учитывать, что любые затраты должны так или иначе окупаться и оправдываться как в экономическом, так и в функциональном смысле. Поэтому при попытке внедрения любого технологического решения должна рассматривать не только новомодность этого решения, но и его рациональное использование в функционирование системы.

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

1. Специальная часть

1.1 Назначение и область применения

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

1.2 Постановка задачи

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

Требования к разрабатываемой системе: Сведение к минимуму времени, которое затрачивается на обработку заказа и отправку его на склад. Оптимизировать процесс заказ->фирма->склад->доставка заказа. Упростить алгоритм обработки самого заказа на складе. Система поможет избежать возможных ошибок в заказе, а клиенту четко видеть и отслеживать статус его заказа.

1.3 Техническое задание на разработку

1.3.1 Введение

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

Документ составлен в соответствии с ГОСТ 19.201-78: «Техническое задание. Требования к содержанию и оформлению».

1.3.2 Основание для разработки

Основанием для разработки системы является задание на дипломную работу на специальности "Системы автоматизированного проектирования" на кафедре "Информационные технологии и автоматизированные системы" МИЭМ НИУ ВШЭ.

1.3.3 Назначение разработки

Назначение системы

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

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

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



Описание технологического процесса

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

1) В первую очередь идет полная подготовка склада, к принятию доставленной продукции;

2) Далее, идет детальная проверка сопроводительной документации к товару;

3) Следует полная разгрузка и приемка товара с помощью транспортных средств, в ходе которой, если обнаруживаются расхождения, то ставится отметка в транспортной накладной;

4) Далее следует приемка товара по качеству, после которой идет оформление приходных документов. Если в качестве товара обнаружены погрешности, то составляется коммерческий акт. Так же в этот момент идет идентификации продуктов и занесение в базы данных;

5) Далее идет размещение продукции на хранение, при котором обязателен инвентарный контроль;

6) После того, как вся продукция занесена в базы данных, идет составление отчетов на эту продукцию и составление листа комплектации и маршрутной карты;

7) После составление всех отчетов следует получение распоряжения на отгрузку, далее сборка заказа и упаковка и маркировка скомплектованного заказа;

8) Далее осуществляется оформление отгрузочных документов;

9) Потом следует отгрузка заказа клиентам;

10) И под конец продукцию снимают с учета.

1.3.4 Требования к программному изделию

Требования к функциональным характеристикам

Количество пользователей, работающих с программой, не ограничено.

ПК « Warehousing»:

- Просмотр статуса заказа;

- Просмотр списка заказов;

- Отмена заказов;

- Учет заказов;

- Контроль заказа;

- Возможность отслеживания, на какой стадии находится заказ;

Требования к надежности

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

2) Для разграничения доступа к информации, в том числе в пределах одного АРМ, пользователь должен иметь уникальные логин и пароль, которые дают ему возможность пользоваться данными, на которые у него есть полномочия, и использовать только закреплённое за ним ID.

3) Должна быть возможность резервного копирования базы данных, хранимой на сервере, чтобы застраховаться от их полной потери. Задача создания и хранения резервной копии возлагается на системного администратора.

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

5) Программный комплекс не должен прекращать работу при аварийном завершении работы какого-либо из связанных с ним клиентских приложений.

6) Серверная часть программного комплекса должна обеспечивать возможность своего автоматического перезапуска в случае критических сбоев.

7) Возможность автономного отслеживания статуса и самого заказа должна вестись круглосуточно и постоянно обновляться.

Требования к условиям эксплуатации

1) Условия эксплуатации программного комплекса должны соответствовать условиям работоспособности оборудования, используемого для работы с программным комплексом (стационарные и портативные персональные компьютеры, сервер)

2) Электропитание технических средств осуществляется от стандартной сети переменного тока напряжением 220В, частотой 50 Гц. По электромагнитной совместимости и устойчивости к электромагнитным помехам технические средства должны соответствовать ГОСТ Р 50628-2000. По показателям качества электроэнергии системы первичного электропитания - требованиям ГОСТ 13109-97.

3) Климатические условия эксплуатации ЭВМ должны соответствовать нормальным климатическим условиям по ГОСТ 21552-84 (группы стойкости по климатическим факторам 1 и 2).

Требования к составу и параметрам технических средств

Требования основаны на параметрах уже имеющихся у компании технических средств и системных требованиях для C++ Builder6, Windows 7/Windows 8, MySQL, выход в сеть Internet.

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

Стационарный или портативный ПК для клиентских приложений:

Процессор:

Количество ядер - от 2 и более.

- Тактовая частота каждого ядра от 1,2 ГГц.

ОЗУ:

- Ёмкость ОЗУ от 1 ГБ.

Жёсткие диски:

- Свободный объём памяти жёсткого диска от 5 ГБ.

Сеть:

- Сетевая карта Ethernet с поддержкой скорости передачи данных по локальной сети от 100 Мбит/с.

Прочее:

- Клавиатура

- Мышь

- Монитор.

Сервер.

Процессор:

- Количество ядер от 2 и более;

- Тактовая частота каждого ядра от 1 ГГц.

ОЗУ:

- Ёмкость ОЗУ от 2 Гб.

Жёсткие диски:

- Свободный объём памяти жёсткого диска от 20 Гб;

- Возможность объединения в зеркальный рейд-массив для большей сохранности данных.

Сеть:

- Сетевая карта Ethernet с поддержкой скорости передачи данных по локальной сети от 100 Мбит/с;

- Соединение с Internet не требуется.

Требования к информационной и программной совместимости

Программный комплекс разделяется на серверную часть и клиентские приложения (АРМ).

- Работу базы данных обеспечивает СУБД My SQL;

- Базовый язык программирования - C++ Builder 6, QTCreator;

- Сервер управляется ОС Debian GNU/Linux 6.0;

- Пользовательские компьютеры управляются ОС Windows 7/Windows 8;

- Сервер и клиент обмениваются данными по протоколу TCP/IP.

1.3.5 Требования к программной документации

Ссылки на стандарты

Программная документация должна быть оформлена в соответствии с требованиями стандартов Единой Системы Программной Документации (ГОСТ 19.106-78).

Перечень программной документации

В состав программной документации должны быть включены:

- Описание программы (ГОСТ 19.402-78);

- Описание применения (ГОСТ 19.502-78);

- Текст программы (ГОСТ 19.401-78);

- Программа и методика испытаний (ГОСТ 19.301-79);

- Руководство оператора (ГОСТ 19.505-79).

1.3.6 Технико-экономические показатели

Технико-экономическое обоснование

Внедрение разрабатываемой системы позволит:

- Узнать информацию о состоянии заказа без звонков;

- Контролировать статуса выбранного заказа ;

- Оценить работу сотрудников;

- Быстро отменить заказ;

- Оценить прибыль компании.

Расчёт затрат на разработку

Расчёт затрат на разработку программного средства производится на основании документа «УКРУПНЕННЫЕ НОРМЫ ВРЕМЕНИ НА РАЗРАБОТКУ ПРОГРАММНЫХ СРЕДСТВ ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ», утвержденного Постановлением Государственного комитета СССР по труду и социальным вопросам и Секретариата ВЦСПС от 24 сентября 1986 г. N 358/22-20.

Шаг 1. Определение типа программного средства.

Тип разрабатываемой программного средства согласно таблице «КЛАССИФИКАЦИЯ ТИПОВ ПС ВТ В КАТАЛОГЕ АНАЛОГОВ» можно определить как «ПС информационно-поисковых и информационно-справочных систем».

Шаг 1. Определение функций ПС.

Согласно таблице «КАТАЛОГ ФУНКЦИЙ ПРОГРАММНЫХ СРЕДСТВ ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ» в разрабатываемом ПС были выделены следующие функции:

№ п/п	Наименование функции	№ функции по каталогу	Объем функции
			По каталогу функций
1	Организация ввода информации	101	870
2	Контроль, предварительная обработка и ввод информации	102	2100
3	Организация ввода-вывода информации в интерактивном режиме	109	1550
4	Генерация структуры базы данных	201	5500
5	Формирование базы данных	203	7312
6	Обслуживание базы данных в интерактивном режиме	206	9900
7	Манипулирование данными	207	7200
8	Организация поиска в базе данных	208	17400
9	Обеспечение интерфейса	507	3850

Шаг 3. Определение объёма ПС.

Общий объём ПС (V0) равняется сумме всех его функций (Vi):

V0= 870+2100+1550+5500+7312+9900+7200+17400+3850

V0= 55682

Шаг 4. Учёт сложности ПС.

1) Согласно таблице «ГРУППЫ СЛОЖНОСТИ ПС ВТ» разрабатываемая система входит в первую группу сложности.

2) Для определения дополнительного коэффициента сложности (Ксл) из таблицы «ЗНАЧЕНИЯ КОЭФФИЦИЕНТА, УЧИТЫВАЮЩЕГО УРОВЕНЬ ПОВЫШЕНИЯ СЛОЖНОСТИ ПС ВТ» возьмём следующие дополнительные характеристики ПС ВТ:

№ п/п	Дополнительные характеристики ПС ВТ	Значение Кi
1	Интерактивный доступ	0,06
2	Обеспечение хранения, ведения и поиска данных в сложных структурах	0,07

Таким образом, дополнительный коэффициент сложности:

Шаг 5. Учёт новизны ПС.

Согласно таблице «ЗНАЧЕНИЯ ПОПРАВОЧНОГО КОЭФФИЦИЕНТА, УЧИТЫВАЖЮЩЕГО СТЕПЕНЬ НОВИЗНЫ ПС ВТ» код степени новизны ПС ВТ - В.

Код степени новизны	Степень новизны	Использование	Значение Кн
		Нового типа ЭВМ	новой ОС
В	ПС ВТ, являющиеся развитием определенного параметрического ряда ПС ВТ	-	-	0,6

Значение поправочного коэффициента, учитывающего степень новизны соответственно равно 0,6.

Шаг 6. Определение и учёт удельного веса трудоёмкости стадий разработки ПС.

Так как кодом степени новизны ПС ВТ является В, и ЭП предусмотрен в ТЗ, то получаем следующие значения коэффициентов удельных весов трудоёмкости стадий (Li):

	ТЗ+ЭП	ТП	РП	ВН
Li	0,14	0,05	0,58	0,18

Шаг 7. Учёт типовых ПС в собственной разработке.

Степень охвата реализуемых функций разрабатываемого ПС «» типовыми программами и ПС ВТ составляет 40-60% (ЗНАЧЕНИЯ КОЭФФИЦИЕНТА ИСПОЛЬЗОВАНИЯ В РАЗРАБОТКЕ ТИПОВЫХ ПРОГРАММ И ПС ВТ), следовательно, значение поправочного коэффициента (), учитывающего степень использования в разработке типовых (стандартных) программ и ПС ВТ Кт=0,6.

Шаг 8. Расчёт затрат труда на разработку ПС.

Норма времени Тр=8567 чел-дней (ЗАТРАТЫ ТРУДА НА РАЗРАБОТКУ ПС ВТ (Тр) В ЗАВИСИМОСТИ ОТ УТОЧНЕННОГО ОБЪЕМА ПС ВТ (Vо) И ГРУППЫ СЛОЖНОСТИ ПС ВТ, ЧЕЛ.-ДНИ).

Общая трудоемкость разработки ПС Т'о= Ксл * Тр = 1,13*8567 = 9680 дней

По причине того, что нормы рассчитаны на устаревшие типы ЭВМ, следует ввести дополнительные коэффициенты. По данным книги Липаева В. В. «Технология и методология разработки ПС. Затраты», Москва, 1999, вводим коэффициенты:

- Ктс = 0,2 - коэффициент понижения трудоёмкости.

- Кпс = 0,15 - коэффициент, учитывающий повышение производительности ПС

Таким образом, общая трудоёмкость разработки после учёта современных средств разработки составляет То= Т'о*Ктс*Кпс = 9680*0,2*0,15 = 290 чел.-дней.

Распределение трудоёмкости по стадиям разработки:

ТЗ: чел.-дней.

ТП: чел.-дней.

РП: чел.-дней

Вн: чел.-дней

Расчет уточненной общей трудоемкости чел.-дней.

Шаг 9. Расчёт количества разработчиков и сроков на разработку ПС.

Время необходимое для разработки ПС

Время необходимое для разработки i-ой стадии

Все разработчики будут уделять всё своё рабочее время проекту, следовательно, работать на полную ставку (). Следовательно, уточненное время для разработки i-ой стадии



Фонд времени одного разработчика в течение 2014 года Ф = 247 дней по данным сайта www.go.garant.ru

№ п\п	Характеристики	Стадии	Итого
		ТЗ	ТП	РП	ВН
1	Коэффициент Li	0,18	0,05	0,58	0,18	1
2	Трудоемкость Ti	27	7	77	34	145
3	Численность Ni	1	1	1	1	1
4	Срок ti, лет	0,14	0,04	0,37	0,15	0,7

Общий срок реализации месяцев.

Шаг 10. Оценка стоимости разработки ПС.

Расчёт заработной платы разработчиков за всё время работы рассчитывается по формуле:

где:

Ставка - средняя зарплата одного разработчика

N - число разработчиков.

t - общий срок разработки.

При ставке, равной, допустим, 70000 руб. получаем:

руб.

Стоимость проекта можно рассчитать исходя из того, что зарплата в любой разработке составляет порядка 60% от общей стоимости разработки:



где:

K - коэффициент, учитывающий процент зарплаты в стоимости разработки.

Таким образом получаем: руб.

Расчёт экономических показателей

Расчёт проводится по следующим экономическим показателям:

- годовая экономия средств;

- расчётный коэффициент общей эффективности вложения капитала;

- годовой экономический эффект;

- срок окупаемости системы.

1) Расчёт годовой экономии средств

Годовая экономия средств определяется из разницы между текущими затратами компании на заработную плату сотрудникам и затратами на заработную плату после внедрения системы в технологический процесс. Для расчёта необходимо знать заработную плату (ЗП) каждого сотрудника и количество (Кл) сотрудников. Ежемесячная премия не предусмотрена. До внедрения программы в штате состояло 10 операторов с з/п 45000 руб., 20грузчиков с з/п 15000 руб., 20 курьеров с з/п 30000 руб.

ЗПдо = (10 * ЗП операторов + 10 * ЗП грузчиков + 20 * ЗП курьеров)*11.

ЗПдо= (10 * 45000 + 20 * 15000 + 20 * 30000)*12= 1350000р.

Расход компании на заработную плату за год составляет 1350000рублей.

После внедрения системы повышается эффективность системы без операторов в результате чего можно сократить число их на 5, но компании придется нанимать системного администратора для работы с сервером.

ЗПпосле = (6 * 5 ЗП операторов + 20 * ЗП грузчиков+20* ЗП курьеров + ЗПсис.админ.)*12

ЗП после = (6 * 45000 + 6 * 15000 + 20* 25000 + 30000)*12= 1000000р.

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

Годовая экономия средств после внедрения системы составит 350000 рублей.

2) Расчёт коэффициента общей эффективности вложений капитала

Коэффициент рассчитывается по следующей формуле:

Э - годовая экономия.

3) Расчёт годового экономического эффекта

руб.

4) Расчёт срока окупаемости системы

года.

1.4 Разработка обеспечения компонентов САПР

Различные подсистемы и системы являются одними из главных компонентов САПР. Так же весьма важными компонентами САПР являются его функциональные части.

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

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

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

Методическое обеспечение САПР - это множество документов, содержащих в себе различные правила отборы, правила эксплуатации всех действующих средств автоматизации для проектирования и их состав.

Программным обеспечением САПР являются программы для различных ЭВМ. И они имеют два типа. Это - специальное ПО и общее ПО. За решение конкретных определенных задач отвечает Специальное ПО. А организация, управление различными математическими процессами и планирование - это по части Общего ПО.

Информационным обеспечением САПР являются: различного рода базы данных, которые содержат нужные сведения, для успешного выполнение проектирования.

Математическое обеспечение САПР - это методы решения различных процедур, операций проекта и их алгоритмы, а так же представление проектируемых объектов и их элементов в математические модели.

Лингвистическое обеспечение САПР - это совокупность языков, которые описывают исходные данные, записи алгоритмов, обмен информации между человеком и ЭВМ, во время проектирования и собственно сами результаты.

Для выбора программного обеспечения и программных компонентов, я отталкивался от схемы, на которой строится моя программа. Клиент Сервер Базы данных (БД).

Основным языком написания программы является Java.

В качестве интерфейса взаимодействия Сервера и БД, я использовал JDBC.

JDBC - это как раз независимый стандарт взаимодействия различных Java-приложений с СУБД. Почему я выбрал именно JDBS, как интерфейс взаимодействия? Я выбрал его, потому что:

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

- если компания, для которой написано ПО переходит на другую БД, то код к ней практически не меняется;

- не нуждается в установки огромных клиентских программ;

- возможность подключиться к любой БД через описываемый URL.

Так же для связи классов Java и моих Баз Данных я использовал библиотеку «Hipernate». Она позволяет мне автоматически генерировать и обновлять наборы таблиц в БД, построение запросов и обработку данных.

Между клиентов и сервером у меня работает протокол HTTP. Почему же я выбрал именно HTTP протокол? А выбрал я его, потому что большинство протоколов устанавливают только один раз авторизацию в TCP-сессии. А HTTP устанавливает каждый раз отдельную сессию на каждый запрос. Так же он позволяет сохранить сессия даже после перезагрузки сервера или клиента (использование coockies).

Еще для соединения связи Клиент Cервер, я использую архитектуру REST. С помощью использования этой архитектуры приложение получает ряд преимуществ:

- производительность;

- надежность;

- прозрачность системы взаимодействия;

- простоту интерфейса;

- легкость внесения изменений.

Так же в моем ПО используется Servlet. Это интерфейс для Java, который расширяет возможности функционала сервера.

Для работы с сервлетами я используюTomcat-это контейнер сервлетов. Так же он может быть использован самостоятельного веб-сервера или в качестве контента.

Для работы с БД в моем ПО активно используются SQL-транзакции. Они связывают несколько шагов в одну операцию. Еще одно полезное свойство, которым обладают транзакции - это строгая изоляция транзакций. Запуск одновременно конкурирующих транзакций не дает возможности видеть неполные изменения других транзакций.

В написании моего ПО использовался так же JSON. Это текстовый формат обмена данными, который основан на JavaScript. Именно на засчет свой лаконичности формат JSON используется в создании приложений , работающих с задачами обмена данными между серверами или между браузером и сервером.

1.4.1 Процесс разработки ПО

Как уже упоминалось выше, что при создании моего программного продукта, я использовал спиральную модель разработки программного обеспечения. Так почему же была выбрана именно спиральная модель? Спиральное модель - это улучшенная водопадная модель. Чем же она лучше вышесказанной модели? А лучше она тем, что в ней учтены недостатки водопадной модели. А одним из главных недостатков водопадной модели является «слабое» управление рисками. Интеграция всех результатов обработки в водопадной модели происходит лишь в конце. А это влечет за собой позднее выявление проблем и ошибок, которые могли возникнуть во время разработки программного продукта. В спиральной модели этот недостаток учтен. Интеграция результатов происходит несколько раз, в течение создания проекта. То есть создателями выделяются некие рамки и точки в периоде создания программного продукта, во время которых идет полный анализ уже проделанной работы и выявление недостатков или ошибок.

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

Первым этапом создания моего программного продукта являлась реализация Администраторской части программы. Почему я начал именно с этого звена, а не с покупателя? Потому что при отсутствии полного управления, вся система может «развалиться на глазах». При создании этого блока программы учитывались интересы заказчика данного продукта. А именно полный контроль. Как же его осуществить? Администратор должен видеть все. Он должен видеть заказы, которые поступают в его фирму, что бы была возможность контроля количества оставшегося товара на складе, мог определить примерные сроки доставки и знать, когда нужно пополнение товара. Он должен видеть весь список складов, которые принадлежат фирме. Что бы опять же иметь четкое представление, когда и сколько ему нужно товара от производства. Но лишь видеть полную информацию для администратора - это слишком мало. Администратор должен иметь возможность самостоятельно добавлять приходы и информацию о них. Для чего это нужно? Что бы сотрудники складского помещения отчетливо знали, когда и в каком количестве им приедет партии товара, что бы принять отгрузку и распределить товар на территории склада. Приобретая новое помещение, под склад, фирма может с помощью администратора внести в свою программу данные о новом складском помещении. Когда фирма заключает новые договора по поставке нового продукта, в этих сделках сотрудники складов не участвуют. А значит администратор, как никто другой лучше знает всю информацию о новом товаре. Поэтому было принято решение, добавить в административный блок программного продукта возможность администратору самостоятельно пополнять список продаваемой продукции. Поэтому подводя итог всего вышесказанного было принято решение о добавлении в административные возможности не только получение данных и продажных процессах компании, но и возможность участия непосредственно в них.

Следующим этапом в создании моего проекта являлась разработка программной части для сотрудников склада. Было четко решено, что никаким добавление информации, кроме фактической, сотрудники склада заниматься не будут. Но что же такое фактическая информация. А фактическая информация - это на склад приехал приход груза или продукции. Менеджер принял этот товар, установил его в отведенное место на складе и занес в программу, сколько и какого товара по факту он получил. И не более того. Так в чем же заключается основная задача менеджеров? Они должны обрабатывать и затем формировать заказы, полученные от клиентов. Они должны переживать о договоре на выкуп нового помещения под склад, они не должны переживать, когда будет следующая отгрузка товара. Они должны видеть полностью все заказы клиентов и четко знать, есть ли у них данный товар в соответствующем количестве когда будет доставка этого товара заказчику. Поэтому собрав всю эту информацию я сосредоточился на реализации именно этих возможностей работников склада в моем программном продукте.

И последнем звеном моего программного продукта является покупатель. Последним, но не маловажным. Я считаю, что покупатель занимает чуть ли не первое место в цепочке купли-продажи. Почему? Не будет покупателей - не будет прибыли и продаж. А что отпугивает покупателей? В основном чересчур усложненный интерфейс и чрезмерная загроможденность. Что нужно клиенту? Ему нужно четкое видение списка представляемой фирмой продукции. Что я решил добавить еще в этот список? Я посчитал нужным указывать количество товара, находящегося на складе у компании. Покупатель отчетливо видя количество желаемого товара, может самостоятельно просчитать сколько экземпляров данного товара ему нужно. И что же еще интересует заказчиков, при покупке определенного товара? Конечно же сроки его доставки. После обработки заказа менеджерами склада, покупатель может увидеть в своем личном кабинете примерную дату доставки или же полный адрес склада, на котором есть в наличии выбранный им товар и воспользоваться услугой самовызова.

1.4.2 Алгоритм работы программы

При запуске программы, разработанное По запрашивает Логин и пароль, для входа в систему. Для чего это нужно? В моей программе имеется 3 вида различных пользователей, которые обладают индивидуальными возможностями в работе с программой. И именно идентификация дает возможность программе распознать какой вид пользователя заходит в нее. Введение неверных данных повлечет за собой всплывающее окно об ошибки инициализации. При вводе верных данных программа дает доступ к информации и возможности, в зависимости от классификации пользователя. Покупатель - имеет возможность работать с виртуальной корзиной, добавляя или удаляя товары, видеть их наличие или отсутствие . Работник склада - имеет возможность увидеть на каком складе находится товар, в каком количестве и тд. Администратор же имеет административные возможности работы в программе.

Далее представлен сам алгоритм моего программного продукта:



1.4.3 Диапазон функционирования программы

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

1.4.4 Тестовый пример

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

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



В графе «Username»пользователь должен будет ввести свой логин, который как раз таки в будущем и будет определятся программой для выдачи разрешений или запретов на те или иные возможности программного продукта. А графа «Password»отвечает за введение пароля пользователем, тем самым ограничивая доступ к функционалу неидентифицированных или нежелательных пользователей программы.

При ошибочном или умышленном вводе неверных данных программа выдаст пользователю сообщение и неверном вводе данных:

1) При входе в программу пользователя, как обычного клиент(покупателя) он попадает в свой «Личный кабинет», в котором он может видеть полную информацию о своих заказах:



У пользователя есть возможность проверить наименование своего товара, какое количество он заказал, на какие числа стоит резерв и дата ожидания этого товара.

Как такого огромного функционала для обычных покупателей мой программный продукт не представляет. Малая загруженность активного окна программа позволяет клиенту не запутаться и не получать лишней (ненужной) ему информации.

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

- полный список складов компании в котором указан точный адрес склада и ближайшее к нему метро.

Следующая вкладка с названием «товары» дает работнику склада представлении и товаре, представленным компанией:

В этом разделе пользователь видит: код товара, который поможет избежать путаницы с так называемыми «схожими» товарами и его наименование. Далее работник может отслеживать «приходы» нового товара на склады его компании:

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

Ну и последняя вкладка для работника склада это «Заказы»:

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

3) Ну и последняя разновидность пользователей моего программного продукта это - Администратор компании. Сотрудник, который имеет возможность видеть и отслеживать все действия, происходящие с товаром, а так ряд возможностей по редактированию тех или иных списков.

Именно администратор имеет возможность на добавление информации он новом складе. Выглядит это окно так :



В этом окне администратор добавляет наименование склада и его точный адрес.

Далее администратор имеет возможности по добавлению нового товара:

В этом окне пользователь должен ввести Код товара, затем его наименование, указать штрих-код продукта и указать склады, на которых он будет хранится, с их адресами.

В список возможностей администратора так же входит добавление информации о приходах:

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

При попытке превысить данные пользователю полномочия и возможности программа предупредить самого пользователя о недостатке его привилегий:

1.5 Результаты работы программных модулей

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



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

При изменении базы данных о количестве и информации по продуктам в компании идет редактирование этого документа. При изменении состава документа всплывает окно:

После нажатия кнопки «ОК», появляется окно, просящее подтверждение и уточнение добавления товара:

Если же по тем или иным причинам заказчик отказался от своего выбора, то перед работником склада появляется задача удалить этот заказ и при ее выполнении появляется окно:

После которого работник должен подтвердить удаление.

Администратор же для полного контроля должен контролировать все действия, происходящие с товаром в фирме, такие как:

- подтверждение резерва заказа

- подтверждение отгрузки товара

- проверка состава документа о наименовании товара



- и его количестве

Заполнение окна введения нового товара выглядит так:

Выбирается графа «штрих-код», сразу же всплывает новое окно о введение нового штрих-кода, далее после подтверждения окно закрывается и новый графа штрих-кода заполняется.

Далее следует привязка товара к одному из складов компании:



В окне «Новая связь» выбирается из списка склад, в котором будет хранится новый товар.

Так же у администратора имеется возможность о внесении изменений в названия или адреса складов компании:

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

2. Конструкторско-технологическая часть

2.1 Описание программы

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

Программа имеет 3 различных видов доступа к данным. Почему сделано именно так? А выбран такой путь для того, что бы не загружать пользователя лишней для него информацией. Я, как создатель, данного программного продукта придерживался политики - каждый выполняет свою работы. Именно поэтому в моей программе покупатель видит только список возможной продукции компании и имеет доступ к своей корзине, которую он может сам наполнять продукцией или удалять ее из перечня своих заказов, получая точные или предполагаемые даты по получению своего товара, менеджер склада имеет возможность отслеживать количество товара, имеет перечень складов, принадлежащих компании, их адреса, возможность видеть все полученные заказы клиентов и приходы на склады, а администратор, как управляющее звено, имеет возможность наблюдать «полную картину». Его возможности имеет большой список возможностей по добавлению, удалению товара, по сообщению о новых приходах, возможность изменять названия и адреса складов. Проще говоря следить за работой компании в целом.

Рекомендации для используемого технического средства:

Стационарный ПК для работы в приложении:

Процессор:

Количество ядер - от 2 и более.

Тактовая частота каждого ядра от 1,2 ГГц.

ОЗУ:

Ёмкость ОЗУ от 1 ГБ.

Жёсткие диски:

Свободный объём памяти жёсткого диска от 100 ГБ.

Сеть:

Сетевая карта Ethernet с поддержкой скорости передачи данных по локальной сети от 100 Мбит/с.

Прочее:

- Клавиатура

- Мышь

- Монитор.

- Сервер.

Процессор:

- Количество ядер от 2 и более;

- Тактовая частота каждого ядра от 1 ГГц.

ОЗУ:

- Ёмкость ОЗУ от 2 Гб.

Жёсткие диски:

- Свободный объём памяти жёсткого диска от 500 Гб;

- Возможность объединения в зеркальный рейд-массив для большей сохранности данных.

Сеть:

- Сетевая карта Ethernet с поддержкой скорости передачи данных по локальной сети от 100 Мбит/с;

- Соединение с Internet требуется.

2.2 Выбор модели процесса разработки ПО

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

Вот список наиболее распространенных рисков:

- дефицит специалистов;

- нереалистичные сроки и бюджет;

- реализация несоответствущего функционала;

- постоянный поток изменений;

- ненужная оптимизация;

- недостаточная производительность получаемой системы;

- «разрыв» квалификаций специалистов различных областей.

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

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

Каждый виток разбивается на 4 сектора:

- оценка и разрешение рисков;

- определение и постановка целей;

- разработка и тестирование продукта;

- планирование.

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

2.3 Программа и методика испытаний

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

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

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

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

Требования к программной документации:

В coстaвe прoграммнoй докyментации дoлжны быть включeны:

Oпиcaние прогрaммы (ГОСТ 19.402-78);

Oпиcaние пpимeнeния (ГОСТ 19.502-78);

Тeкст прoгрaммы (ГОСТ 19.401-78);

Пpoгрaммa и мeтoдикa иcпытaний (ГОСТ 19.301-79);

Pукoвoдcтвooпepaтopa (ГОСТ 19.505-79).

Cостав испытаний: испытания буду проводится непосредственно в рабочей сферы компании. Программный продукт будет представлен на сайте компании, как тестовый вариант и будет предложен для скачивания. Будут запущенны все программные модули, как работа в режиме заказчика (покупателя), так же будет установлен режим менеджера склада, сотрудникам, осуществляющим работу непосредственно на складе. Помимо этих двух режимов, будет запущен режим Администратора, для мониторинга продажной деятельности компании и работы складского учета.

Методы испытаний: Проверки работоспособности программного продукта будут осуществляться непосредственно по списку проделанных в пункте 2.5.

2.4 Руководство для сотрудника

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

Условия выполнения программы:

Необходимые технические требования:

Стационарный или портативный ПК для клиентских приложений:

Процессор:

Количество ядер - от 4 и более.

Тактовая частота каждого ядра от 1,8 ГГц.

ОЗУ:

Ёмкость ОЗУ от 4 ГБ.

Жёсткие диски:

Свободный объём памяти жёсткого диска от 20 ГБ.

Сеть:

Сетевая карта Ethernet с поддержкой скорости передачи данных по локальной сети от 100 Мбит/с.

Прочее:

Клавиатура

Мышь

Монитор.

Сервер.

Процессор:

Количество ядер от 3 и более;

Тактовая частота каждого ядра от 2 ГГц.

ОЗУ:

Ёмкость ОЗУ от 4 Гб.

Жёсткие диски:

Свободный объём памяти жёсткого диска от 150 Гб;

Сеть:

- Сетевая карта Ethernet с поддержкой скорости передачи данных по локальной сети от 100 Мбит/с;

- Соединение с Internet требуется.

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

3. Экология и охрана труда

3.1 Общие положения к организации рабочего места

Для прaвильнoгopaзмeщeния рaбoчих мeст с ЭВМ дoлжнo сoхрaняться pacтoяние мeжду рaбoчими стoлaми, кoтopoе нe дoлжнo прeвышaть 2.0 м.

Paбoчие стoлы слeдуeт paзмeщать тaк , чтoбы мoнитoры были opиeнтирoвaны бoкoвой стoрoнoй к свeтoвым прoeмaм и eстecтвeнный свeт пaдaл пpeимущественно слева.

Paбочие мecта cЭВМ пpи иcпoлнении paботы в твopческом cтиле, тpeбующей знaчительнoго умcтвеннoго нaпряжeния или высoкогo кoнцентриpoванногo внимaния, peкомендуeтся изoлировaть друг oт друга пеepeгородками высoтой 1,5-2,0 м.

Экрaн видeoмонитора дoлжeн нaхoдиться нa рacстоянии 600-700 мм от глазa соoрудникa, рaбoтающeго зa ним, нo нe ближe 500 мм с учетoм paзмерdв алфавитнo-цифрoвых знaкoв и cимволoв.

Клaвиaтуру cледуeт распoлaгать на пoверхнoсти стoлa на рacстоянии 100-300 мм от крaя, обрaщeннoго к пoльзовaтелю, или нacпeциальной, peгулируемой по высoте рaбочей пoвeрхности, oтделеннoй от ocновнoй cтoлешницы.

Кoнструкция рaбочего стулa (крeслa) дoлжна обecпечивать пoддержание paциональной paбочей пoзы пpи paботе ЭВМ, позвoлять измeнять пoзу с цeлью снижeния стaтическoго нaпряжeния мышц шейнo-плeчевой oбласти и cпины для прeдупреждeния paзвития утoмления. Тип рaбочего cтула (крeсла) слeдует выбиpать с учeтом paста пользовaтeля, хaрактeра и пpoдолжительности paботы с ЭВМ.

Paбочий стул (крeсло) дoлжен быть пoдъемно-поворoтным, peгулируемым пo высoте и углaм нaклонacиденья и cпинки, а тaкже рacстоянию cпинки от пeреднегo края cиденья. Пpи этoм peулировка кaждого пapаметра дoлжна быть нeзависимой, лeгко осущеcтвляемoй и имeть нaдежную фикcацию.

Пoверхности сидeнья, cпинки и других элeментов стулa (кpесла) дoлжны быть полумягкими, с нeскользящим, слaбо электpизующимся и вoздухопроницаeмым пoкрытием, обecпечивающим легкую oчистку oт загрязнeний.

Paбочее место пользoвателя ЭВМ слeдует oборудовать пoдставкой для нoг, имeющей шиpину не мeнее 300 мм, глубину не менeе 400 мм, регулиpовку по выcоте в прeделах до 150 мм и по углу нaклона опoрной пoверхнoсти пoдставки дo 20 град. Повeрхность подстaвки дoлжна быть pифленой и имeть по перeднeму краю бoртик выcoтой 10 мм.

3.2 Требования к освещению рабочих мест

Oсвещенность на повeрхности стoла в зоне paзмещения paбочего докумeнта дoлжна быть 300-500 лк. Oсвещение не дoлжно coздавать бликoв на повepхности экрана. Oсвещеннoсть повepхности экранa не дoлжна быть бoлее 300 лк.

Cледует oгpаничивать нeравномерность paспределения яpкости в пoле зpeния пoльзовaтеля ЭВМ пpи этoм сooтношение яpкости между paбочими повepхностями не дoлжно пpeвышать 3:1-5:1, а мeжду paбочими повepхностями и повepхностями стeн и обopудования -- 10:1.

Кoэффициeнт пульсaции не должeн прeвышать 5%.

Для исключeния бликoв отражeний в экрaне светильникoв общeго ocвещения paбочий стoл с ПК слeдует paзмещать мeжду pядами cветильников. Пpи этoм cветильники дoлжны быть распoложены паpaллельно горизoнтальной линии взглядa работающeго. Для умeньшения бликoв peкомендуется испoльзовать пpиэкранный зaщитный фильтp для видeoмониторов.

Пpи pядном paзмещении paбочих cтолов не дoпускается paсположение экранoв дисплeев нaвстречу друг другу из-за их взaимного отpaжения, в пpoтивном cлучае мeжду cтолами cледует уcтанавливать пеpeгородки.

3.3 Требования к уровням шума и вибрации на рабочих местах

В пpoизводственных пoмещениях пpи выпoлнeнии ocновных или вcпомогaтельных paбот с иcпoльзованием ЭВМ уpoвни шумa нapaбочих мeстах не дoлжны прeвышать пpeдельно дoпустимых знaчений, устaновленных для дaнных видoв paбот в coответствии с дeйствующими caнитарно-эпидемиoлогическими нopмативами.

Печатaющее обoрудовaние, являющеeся иcточником шумa, слeдует устанaвливать на звукoпоглощающей повeрхности aвтономнoго рaбочего мeста пользoвателя. Eсли урoвни шумa от пeчaтающего обoрудoвания прeвышают нoрмируемые, онo должнo быть paсположено вне пoмещения с ПК. Пoмещения для выпoлнения оснoвной paботы с ПК не дoлжны быть paсположены pядом (смежно) с пpoизводственными помeщениями с пoвышeнным уpoвнем шума (мастерские, производственные цеха и т. п.).

Пpи выпoлнении ocновной paботы на мoнитоpaх и ЭВМ (диспeтчерскиe, опеpaторские, зaлы вычиcлитeльной тeхники и т. д.), где paботают инжeнeрно-тeхничeские paботники, уpoвень шумa не дoлжен пpeвышать 60 дБА, в пoмещениях опеpaторов ЭВМ (без диcплеев) -- 65 дБА, на paбочих мeстах в помeщениях, где paзмещаются шумныe агpeгаты вычиcлительных мaшин -- 75 дБА.

Пpи выпoлнении рaбот с иcпользованиeм ПЭВМ в пpoизводственных пoмещeниях уpoвень вибрации нe дoлжен пpeвышать дoпустимых знaчений вибpaции для paбочих мeст (катeгория 3, тип “в”) в coответствии с дeйствующими caнитарно-эпидемиолoгичeскими нopмативами.

Заключение

Современные технологии очень быстрыми темпами набирают обороты в нашем мире. Такое слово, как дистанционность приобретает все большую и большую популярность. Заказчики уже не хотят тратить время на поездки, до складов и магазинов продавца. Они хотят видеть товар, находят на своем рабочем месте. Они хотят видеть весь ассортимент и иметь возможность для заказа этого товара.

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

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

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

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

Список литературы

обработка заказ алгоритм программа

1. Будилов В. JavaScript, XML и объектная модель документа. - СПб.: НиТ, 2001.

2. Волгин, В. В. Склад: логистика, управление, анализ: [учебное пособие] / Волгин В. В. - Москва: Дашков и К, 2011. - 733 с.

3. Дмитриева М. Самоучитель JavaScript. - СПб.: БХВ Санкт-Перебург, 2001.

4. Канке А.А. Логистика складского хозяйства / А.А. Канке // Маркетинг. - 2014. - № 1 (134). - С. 97-107.

5. Кузнецова М.Н. Проблемы складского хозяйства на предприятии / М.Н. Кузнецова, А.С. Васильева // Наука в центральной России. - 2012. - № 1S. - С. 14-16.

6. Фразелли, Э. Мировые стандарты складской логистики / Э. Фразелли; пер. с англ. - Москва: Альпина Паблишер, 2013. - 328 с.