База данных формирования заказов

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

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

Содержание

Введение

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

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

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

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

1.3.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.2 Постановка задачи

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

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

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

1.3.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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



Рис. 1 Типовой технологический процесс

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

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

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

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

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

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

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

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

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

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

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

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

ПК « Wаrеhоusing»:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования основаны на параметрах уже имеющихся у компании технических средств и системных требованиях для С++ Buildеr6, Windоws 7/Windоws 8, MySQL, выход в сеть Intеrnеt.

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

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

Процессор:

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

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

ОЗУ:

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

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

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

Сеть:

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

Прочее:

Клавиатура

Мышь

Монитор.

Сервер.

Процессор:

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

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

ОЗУ:

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

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

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

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

Сеть:

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

Соединение с Intеrnеt не требуется.

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

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

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

Базовый язык программирования - С++ Buildеr 6, QTСrеаtоr;

Сервер управляется ОС Dеbiаn GNU/Linux 6.0;

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

Сервер и клиент обмениваются данными по протоколу TСР/IР.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расчёт затрат на разработку программного средства производится на основании документа «Укрупненные нормы времени на разработку программных средств вычислительной техники», утвержденного Постановлением Государственного комитета СССР по труду и социальным вопросам и Секретариата ВЦСПС от 24 сентября 1986 г. N 358/22-20.

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

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

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

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

Таблица 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. Учёт сложности ПС.

Согласно таблице «Группы сложности ПС ВТ» разрабатываемая система входит в первую группу сложности.

Для определения дополнительного коэффициента сложности (Ксл) из таблицы «Значения коэффициента, учитывающего уровень повышения сложности ПС ВТ» возьмём следующие дополнительные характеристики ПС ВТ:

Таблица 2

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

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

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

Согласно таблице «Значения поправочного коэффициента, учитывающего степень новизны ПС ВТ» код степени новизны ПС ВТ - В.

Таблица 3

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

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

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

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

Таблица 4

	ТЗ+ЭП	ТП	РП	ВН
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 дней по данным сайта

Таблица 5

№ п\п	Характеристики	Стадии	Итого
		ТЗ	ТП	РП	ВН
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.3.6.3 Расчёт экономических показателей

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

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

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

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

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

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

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

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

ЗПдо= (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 Разработка обеспечения компонентов САПР

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В написании моего ПО использовался так же JSОN. Это текстовый формат обмена данными, который основан на JаvаSсriрt. Именно на засчет свой лаконичности формат JSОN используется в создании приложений , работающих с задачами обмена данными между серверами или между браузером и сервером.

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

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

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

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

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

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

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

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

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

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

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

Рис. 2

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

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

Рис. 3



Рис. 4

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

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

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

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

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

Рис. 5

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

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



Рис. 6

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

Рис. 7

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

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

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

- полный список складов компании

Рис. 8

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

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

Рис. 9

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

Далее работник может отслеживать «приходы» нового товара на склады его компании:

Рис. 10

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

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

Рис. 11

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

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

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

Рис. 12

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

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



Рис. 13

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

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

Рис. 14

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

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

Рис. 15

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

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



Рис. 16

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

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

Рис. 17

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

Рис. 18

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

Рис. 19

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

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

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

Рис. 20

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

Рис. 21

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



Рис. 22

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

Рис. 23

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

Рис. 24

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

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

Рис. 25

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

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

Рис. 26

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

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

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

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

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

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

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

Процессор:

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

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

ОЗУ:

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

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

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

Сеть:

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

Прочее:

- Клавиатура

- Мышь

- Монитор.

- Сервер.

Процессор:

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

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

ОЗУ:

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

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

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

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

Сеть:

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

- Соединение с Intеrnеt требуется.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процессор:

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

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

ОЗУ:

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

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

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

Сеть:

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

Прочее:

Клавиатура

Мышь

Монитор.

Сервер.

Процессор:

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

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

ОЗУ:

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

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

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

Сеть:

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

Соединение с Intеrnеt требуется.

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

программа заказ автоматизированный

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

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

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

Рабочие столы следует размещать так, чтобы мониторы были ориентированы боковой стороной к световым проемам и естественный свет падал преимущественно слева.

Рабочие места с ЭВМ при исполнении работы в творческом стиле, требующей значительного умственного напряжения или высокого концентрированного внимания, рекомендуется изолировать друг от друга пеерегородками высотой 1,5-2,0 м.

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

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

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

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

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

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

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

Освещенность на поверхности стола в зоне размещения рабочего документа должна быть300-500 лк. Освещение не должно создавать бликов на поверхности экрана. Освещенность поверхности экрана не должна быть более 300 лк.

Следует ограничивать неравномерность распределения яркости в поле зрения пользователя ЭВМ при этом соотношение яркости между рабочими поверхностями не должно превышать 3:1-5:1, а между рабочими поверхностями и поверхностями стен и оборудования -- 10:1.

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

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

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

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

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

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

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

При выполнении работ с использованием ПЭВМ в производственных помещениях уровеньвибрациине должен превышать допустимых значений вибрации для рабочих мест (категория 3, тип “в”) в соответствии с действующими санитарно-эпидемиологическими нормативами.

Заключение

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

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

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

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

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

...