Автоматизированная система складского учета в ЗАО "Белгородский бройлер" (стр. 1 из 10)
Оглавление
Введение
Глава 1: Выбор методологии разработки
Глава 2: Исследование
Глава 3: Проектирование
3.1 Платформа .NET
3.2. Обзор ASP.NET
3.2 Проектирование базы данных
3.2.1 Логическое проектирование
3.2.2 Физическое проектирование
Глава 4: Разработка
4.1 Borland Delphi 2005
4.2 Архитектура
4.3 HTML прототипы
4.4 Бизнес логика
4.5 Разработка интерфейса пользователя
Глава 5: Экономический эффект
5.1 План анализа экономической эффективности
5.2 Технико-экономическое обоснование разработки ПО
5.3 Расчет затрат на разработку ПО
5.4 Стоимость внедрения ПО Заказчиком
5.5 Расходы заказчика при эксплуатации ПО
5.6 Эффективность внедрения для Заказчика ПО
5.7 Правовые аспекты
Заключение
Список использованной литературы
Введение
В настоящее время роль компьютерной техники в деятельности предприятий торговли и сферы услуг невозможно переоценить. На смену огромным книгам записи продаж приходят быстрые и компактные базы данных. Вместо выписки счета в несколько сотен позиций вручную, документ оформляется компьютером в несколько секунд. Компьютер способен контролировать все товарно-денежные процессы и делать это намного лучше человека.
Естественно, что для функционирования компьютера необходимо программное обеспечение. И если системное программное обеспечение на сегодняшний день не имеет особо широкого разнообразия для конечного пользователя, то на рынке прикладного программного обеспечения наблюдается довольно жесткая конкуренция. На фоне борьбы крупных программных корпораций за конечного пользователя единичные программные продукты просто незаметны.
В данной работе будут показаны преимущества разработки и внедрения собственного программного продукта в дополнение к имеющемуся типовому решению "1С Предприятие: Торговля и склад".
ЗАО "Белгородский бройлер" было основано в 2000 году. Цель деятельности компании – производство и реализация мяса птицы и сопутствующих товаров. В процессе своего роста, компания стала больше внимания уделять сбыту продукции конечному потребителю. Для этого за несколько лет была создана розничная сеть магазинов, специализирующихся на продаже продукции ЗАО "Белгородский бройлер" и сторонних компаний. Ассортимент продукции компании постоянно расширялся, поэтому и управлять товарно-материальными потоками становилось все сложнее и сложнее. Среди прочих проблем все острее вставал вопрос складского учёта – от производства продукции до ее реализации конечному потребителю.
В отделе сбыта и розничных продаж ЗАО "Белгородский бройлер" используется пакет программ "1С Предприятие". Пока количество филиалов (розничных магазинов) ограничивалось двумя и ассортимент продукции состоял из нескольких наименований особых проблем не было. Но с развитием филиальной сети магазинов (сейчас их семь) появились новые требования к ПО складского учета.
Рисунок 1
На рисунке 1 изображена существующая модель ведения складского учета компании. Её суть заключается в том, что учет ведется в головном офисе и каждый магазин лишь регулярно предоставляет соответствующие данные о продажах. Она обладает рядом недостатков:
· высокий человеческий фактор – так как передача данных производится либо вербально, либо с помощью заполненных вручную документов высока вероятность ошибок;
· низкая актуальность данных – обновление данных происходит не чаще 1 раза в день;
· двойной ввод данных – первый раз – при продаже\поступлении товара, второй раз – при учете этой же операции в системе "1С: Предприятие";
· низкая доступность отчетной информации для пользователей – руководство компании настаивает на создании такой системы, которая бы позволила пользователю получать различную отчетную информацию в любой момент времени при наличии подключения к Интернет.
Таким образом, появилась необходимость в переходе к новой модели ведения складского учета компании:
Рисунок 2
Новая модель позволит достигнуть основной бизнес цели, сформулированной менеджментом компании:
Снижение затрат на сбор данных о движении товаров в розничных магазинах компании.
Для достижения этой цели необходимо:
· Минимизировать человеческий фактор при сборе данных о товарообороте;
· Увеличить скорость сбора данных о товарообороте;
· Создать единую картину товарооборота всех филиалов.
Также для компании немаловажным будет являться побочный эффект от проекта:
· Повышение имиджа компании как IT ориентированной.
В описанной модели под "АС Складского учета" понимается некая автоматизированная система, в которую заносятся данные о движении товара и из которой эти данные попадают в "1С: Предприятие" бухгалтерии головного офиса компании.
При выборе, либо разработке "АС Складского учета" менеджмент также счел важным вопрос лицензирования приложения. Идеальным был бы вариант, при котором стоимость системы не менялась при росте количества пользователей.
По ряду причин для решения поставленных задач заказчику не подошло клиент-серверное решение в формате "1С: Предприятие":
· высокая стоимость решения при росте числа магазинов;
· высокие требования к каналам передачи данных;
· излишний функционал, приводящий к сложностям в восприятии системы рядовыми пользователями;
· отсутствие web-интерфейса.
Было решено, что разработка некоего простого (с точки зрения пользовательского интерфейса) и легкого (с точки зрения системных требований и требований к каналам связи) web-ориентированного приложения с функцией конвертации данных в "1С: Предприятие" будет лучшим решением сложившейся ситуации.
Глава 1: Выбор методологии разработки
Любой проект разработки программного обеспечения в своем развитии проходит определенный жизненный цикл – последовательность этапов и совокупность действий, в результате которых создается первая версия продукта. Реалистичная модель жизненного цикла упрощает выполнение проекта и гарантирует, что в проекте с каждым следующим этапом реализуется все больше запланированных задач. Прежде чем приступить к разработке системы необходимо иметь четкое описание методологии разработки, адаптированной к конкретному проекту. На основе выбранной методологии производится выбор конкретных проектных инструментов и программных средств.
Существует множество различных методологий. Среди них выделяют тяжеловесные и гибкие методологии. Для тяжеловесных методологий необходимо детальное планирование большого объема разработок, большой объем документации, и такой подход работает - однако до тех пор, пока не начнутся изменения. Следовательно, для этих методологий сопротивляться всяким изменениям совершенно естественно. Гибкие же методологии, напротив, изменения приветствуют. В отличие от тяжеловесных, они были задуманы как процессы, которые адаптируют изменения и только выигрывают от них, даже в том случае, когда изменения происходят в них самих. Наиболее известными и популярными гибкими методологиями в настоящее время является RUP (Rational Unified Process) и XP (eXtreme Programming).
RUP и XP исходят из различных философских основ. RUP - это система процессных компонент, методов и техник, которые вы можете применить в любом конкретном программном проекте. Предполагается, что пользователь будет адаптировать RUP. С другой стороны XP - более ограниченный процесс, требующий дополнений для того, чтобы соответствовать полному циклу разработки проекта. Эта разница объясняет предпочтения в сообществе разработчиков программного обеспечения. Разработчики крупных систем рассматривают RUP в качестве решения своих проблем, в то время как сообщество разработчиков малых систем решение своих проблем видит в XP. XP это упрощенный, ориентированный на кодирование процесс, для небольших проектов. Эта технология основана на итерациях, объединяющих некоторые приемы, такие как небольшие релизы, простое проектирование, тестирование и постоянная интеграция. RUP – это итеративная методология, основанная на шести признанных в отрасли лучших технологиях. Основной целью RUP является сокращение рисков. Методология RUP уточнялась в ходе тысяч проектов, выполненных тысячами клиентов и партнеров компании Rational.
У RUP и XP множество различий, но решающим фактором при выборе методологии стал подход к архитектуре проектируемых систем. RUP советует уделять внимание архитектуре во избежание рисков, связанных с превышением времени на разработку, излишним объемом проекта и введением новых технологий. В XP предполагается либо наличие архитектуры, либо архитектура настолько проста и понятна, что может быть выведена непосредственно из кода. XP советует не проектировать на будущее, а реализовывать то, что нужно сегодня. Предполагается, что будущее сможет позаботиться о себе само, если вы будете сохранять проект настолько простым, насколько это возможно. Если даже система или ее часть будут переписываться в будущем, XP отмечает, что это все равно лучше, и зачастую дешевле, чем планировать такую возможность изначально. Для некоторых систем это действительно так, и при использовании RUP рассмотрение риска во время проработки проекта может привести вас к такому выводу. RUP не считает это истинным для всех систем и, как показывает опыт больших, более сложных систем, этот фактор может оказаться катастрофическим.
Учитывая сложность разрабатываемой системы, а также требования к адаптивности, мы выбрали в качестве методологии разработки RUP. Создатели RUP определяют его как итеративный, архитектурно-ориентированный и управляемый прецедентами использования процесс разработки программного обеспечения [9]. Основа RUP: разработка концепции; управление по плану; снижение рисков и отслеживание их последствий; тщательная проверка экономического обоснования; использование компонентной архитектуры; прототипирование, инкрементное создание и тестирование продукта; регулярные оценки результатов; управление изменениями; создание продукта, пригодного к употреблению; адаптация RUP под нужды своего проекта.