Проектирование реализации операций бизнес-процесса (рассматривается деятельность ООО "Биг-хауз")
Содержание:
Введение
Продажи являются двигателем всей экономики, а их анализ позволяет более эффективно строит свою деятельность. В этом заключается актуальность курсовой работы.
Технология продаж основывается на формализованных бизнес процессах работы компании и ключевых показателях деятельности сотрудников отделов продаж.
В настоящей курсовой работе рассматривается деятельность ООО «Биг-хауз». Целью работы является проектирование реализации операций бизнес-процесса «Продажи».
За счет внедрения данной системы общество должно получить экономические выгоды в виде снижения трудоемкости автоматизируемых операций.
Задачами курсовой работы являются:
анализ деятельности предприятия и выявление «узких» мест в его бизнес-процессах;
выбор комплекса задач автоматизации;
определение проектных решений по видам обеспечения;
описание разработанной автоматизированной системы;
Курсовая работа включает в себя две части, введение, заключение.
В аналитической части выполнен комплекс работ, направленных на обоснование необходимости автоматизации: определена сущность задачи, описаны основные свойства системы, дано описание всем существующим бизнес-процессам, рассмотрены вопросы, связанные с анализом существующих разработок в этой области. Также в первой главе обосновываются проектные решения по видам обеспечения.
В результате выбран способ приобретения – самостоятельная разработка, также в качестве языка программирования выбран скриптовый язык PHP, а для хранения данных выбрана свободно распространяемая СУБД MySQL.
Проектная часть посвящена построению информационной модели задачи, проведено моделирование «сущность-связь» (ER-модель), описана структура полей таблиц базы данных, проанализированы все информационные потоки входной, оперативной, нормативно-справочной и результатной информации.
В процессе реализации проектных решений по программному обеспечению построены: дерево диалога (сценарий работы с системой), структурная схема пакета и ряд других компонент проекта, подробно раскрывающих сущность машинной реализации задачи.
Далее описан контрольный пример работы системы, позволяющий более полно понять порядок ее использования.
В заключении сделаны некоторые обобщенные выводы, подведены итоги проделанной работы и рассмотрены перспективы развития системы и возможность ее использования на других предприятиях.
Глава 1. АНАЛИТИЧЕСКАЯ ЧАСТЬ
1.1. Характеристика комплекса задач
1.1.1. Выбор комплекса задач автоматизации
ООО «Биг-хауз» возникло в 1996 году путем объединения крупных московских магазинов объединились под единым брендом , и с этого момента началась непрерывная история развития розничной сети, которой тогда только предстояло стать крупнейшей в России. В 2000 году в Москве было уже 50 магазинов «Биг-хауз».
Компания представляет собой классически построенный сетевой бизнес с централизованным управлением и единой маркетинговой политикой. Основными направлениями деятельности компании является оптовая и розничная торговля обувью.
От обычных магазины ООО «Биг-хауз» отличает, в первую очередь, демократичная стоимость продукции. Во-вторых, в торговом зале представлено максимальное количество обуви всех размеров, имеющихся в наличии. И это неслучайно.
В основе этого лежит идея самообслуживания и экономии времени покупателем: последний может примерить понравившуюся пару, не дожидаясь, когда освободится продавец. Ну, и наконец, это шаговая доступность магазинов.
Учитывая эти факторы, магазины ООО «Биг-хауз» и стали по-настоящему народными и любимыми не только покупателями, но и теми, кто работает в них. Причем в каждом магазине, благодаря слаженной работе продавцов-кассиров, старших продавцов и директоров, создана своя неповторимая атмосфера. Немаловажную роль в этом играют и территориальные директора, за которыми закреплено несколько магазинов. Так, зачастую, именно они организуют и различные конкурсы на выявление лучшего из магазинов, что создает для коллективов розничных точек дополнительный стимул к достижению высоких показателей и помогает персоналу чувствовать себя единой командой.
Четыре позиции (продавец-кассир, старший продавец, директор магазина и территориальный директор) являются наиболее актуальными при найме сотрудников. Связано это с тем, что ООО «Биг-хауз» постоянно движется вперед, открывая новые горизонты.
Не за горами планы выхода компании на зарубежный рынок. Стремиться к подобным перспективам и достигать высоких результатов компании помогают сотрудники бэк-офиса, среди которых дизайнеры и модельеры, сотрудники склада и логисты, персонал IT-службы, а также специалисты маркетинга и рекламы и многие-многие другие.
Важно отметить, что с нового года в компании внедрена новая многоуровневая система мотивации сотрудников, которая обеспечивает справедливую оплату труда и предполагает заинтересованность сотрудников в повышении командных результатов.
Компания гарантирует полное соблюдение трудового законодательства. В ООО «Биг-хауз» существует Центр Корпоративного обучения, и все сотрудники проходят в нем обязательную стажировку. В этом году процессу обучения стало уделяться особое внимание – многие программы пересмотрены. Компания делает все для того, чтобы каждый смог раскрыть и реализовать свой потенциал.
В настоящее время большой упор сделан на развитие корпоративной культуры внутри компании.
В ближайших планах – организация крупных корпоративных мероприятий, объединяющих персонал всех уровней в Москве и регионах, модернизация обучающих процессов, внедрение комплексных информационных ресурсов, связывающих центральный офис в Москве и регионы, а также создание комплекса возможностей для сотрудников, что станет дополнительной нематериальной мотивацией для них.
Организационно ООО «Биг-хауз» состоит из следующих структурных звеньев (рисунок 1.1).
Рисунок 1.1 Организационная структура ООО «Биг-хауз»
11
В качестве процесса автоматизации выбран учет продаж, так как:
- Продажи являются ключевым бизнес-процессом компании;
- Учет продаж компании не автоматизирован;
- В настоящее время при учете продаж допускаются ошибки и неточности, что влияет на всю отчетность компании;
- Неверные результаты учета продаж затрудняют анализ продаж, вернее, приводят к неверным результатам;
- На основании неверных результатов анализа продаж управлением компании могут приниматься неверные решения по стратегическому развитию компании.
1.1.2. Характеристика существующих бизнес –процессов
Основным видом деятельности рассматриваемого предприятия является оптовая и розничная продажа обуви, в том числе франчайзинг. Схема, описывающая общую характеристику деятельности ООО «Биг-хауз», представлена на рисунке 1.2.
На основании схемы, основными процессами компании можно назвать:
- Оформление заказов клиентами;
- Закупка и поставка продукции в соответствии с ранее достигнутыми с поставщиками договоренностями;
- Доставка и хранение продукции, распределение ее между магазинами;
- Собственно продажи, включающие учет продаж и их анализ.
Оформление заказов покупателями происходит в следующем порядке - клиент ознакамливается с предложенным ассортиментом, выбирает необходимую продукцию, определяет ее количество, оформляет заявку на покупку. Заявка попадает менеджеру отдела продаж, где он объединяет все заявки в одну, на основании которой становится ясна потребность в продукции на ближайший период.
Рисунок 1.2 Характеристика деятельности ООО «Биг-хауз»
Декомпозиция основной деятельности приведена на рисунке 1.3.
Рисунок 1.3 Декомпозиция основного процесса
Далее менеджерами отдела закупок на основании плана продаж составляются заявки на поставку продукции от поставщиков, в заявке также указывается, на какой склад необходимо поставить какую продукцию и в каком количестве. После поставки продукции она учитывается в системе складского учета и далее распределяется между магазинами в соответствии с текущими потребностями. После того, как продукция поступила в магазины, осуществляется ее продажа.
Рассмотрим подробнее процесс продаж так, как он происходит на ООО «Биг-хауз» в настоящее время (рисунок 1.4). В соответствии с приведенной схемой, в качестве входных потоков информации используются сведения о продукции, заявки магазинов на поставку ассортимента продукции, денежные средства клиентов. В качестве механизмов здесь приведен менеджер отдела продаж, контролирующими являются такие воздействия, как законы и подзаконные акты РФ, требования руководства общества, а также требования клиентов. На выходе данного процесса имеются аналитика продаж и коммерческая прибыль.
Рисунок 1.4 Характеристика процесса продаж
Рассмотрим декомпозицию данного процесса (рисунок 1.5.)
Рисунок 1.5 Декомпозиция процесса продаж
Таким образом, процесс продаж включает в себя следующие основные подпроцессы:
- планирование продаж, которое осуществляется на основе заявок клиентов;
- продажа продукции;
- оплата продукции и контроль этой оплаты;
- учет продаж, включающий также подготовку отчетной документации.
Отпуск товаров покупателям осуществляется на основе следующих документов: накладных; актов приема-передачи; счетов-фактур; товарно-транспортных накладных; железнодорожных и авианакладных.
При учете продаж товаров следующие два момента могут считаться продажей:
факт отгрузки товаров и предъявление покупателю расчетных документов;
факт поступления оплаты от покупателей на счета в учреждения банков.
Этот фактор определяет момент перехода права владения, пользования и распоряжения реализуемых товаров от поставщика к покупателю. В первом случае, как только товары отгружены и покупателю предъявлены на нее расчетные документы, все права собственности переходят на этот товар к покупателю; во втором – до момента оплаты товар является собственностью поставщика.
Момент продажи товаров обусловливает метод определения выручки от продажи: метод начисления («по отгрузке») или кассовый метод («по оплате»).
Метод определения выручки по отгрузке товаров и предъявлению расчетных документов покупателю повсеместно используется в международной практике.
Фактически в ООО «Биг-хауз» при продаже наружной рекламы применяется кассовый метод "по оплате".
Под учетом продаж подразумевается организация ведения учета продаваемых объектов, оперативный ввод информации по заключаемым договорам, ведение графиков платежей, учет платежей и взаиморасчетов по договорам и получение соответствующих отчетов.
Учёт продажи продукции – это один из составляющих элементов бухгалтерского учёта предприятия. Характеристика данного процесса приведена на рисунке 1.6.
Рисунок 1.6 Декомпозиция процесса учета продаж
Управление продажами заключает в себе функции подбора торгового персонала, организации торгового персонала, прогнозирования и планирования продаж, идентификации потенциальных клиентов, поддержания информации о клиентах, а также создания и управления графиками продаж.
Как выяснено руководством предприятия, в последнее время часто возникает ситуация, когда объемы поставок и продаж не совпадают, несовпадение также может происходить и по наименованию товарных позиций. В результате большое количество товара остается хранится на складе или не может быть поставлено вовремя клиентам. В связи с этим фирма несет убытки.
Таким образом, из-за учета продаж, производимого в настоящее время в ручном режиме, наблюдаются следующие недостатки:
- Низкая скорость учета продаж;
- Низкая скорость и большая вероятность ошибок при анализе результатов продаж;
- Отсутствие возможности произвольного построения отчетов;
- Низкая надежность хранения данных.
1.1.3. Характеристика документооборота, возникающего при решении задачи
Основанием для отгрузки готовой продукции покупателям или отпуска со склада служат приказы-накладные отдела маркетинга организации, в которые включены два документа: приказ складу и накладная на отпуск.
Приказ-накладная оформляется в двух экземплярах: один передается экспедитору для указания количества направляемых мест, суммы оплаченного железнодорожного тарифа за перевозку продукции до станции покупателя; второй экземпляр .остается у кладовщика, по нему в карточках складского учета проставляется количество отпущенной продукции и документ передается бухгалтеру.
На основании приказа-накладной и квитанции транспортной организации бухгалтерия выписывает платежное требование для расчетов с покупателями через банк и счетфактуру. В нем указывается ассортимент, количество, продажная цена, стоимость тары и железнодорожный тариф, оплачиваемый покупателем.
На основании счета-фактуры начисляется ИДС, подлежащий. уплате в бюджет. Покупателю товаров (работ, услуг) счет-фактура необходим для возмещения НДС из бюджета.
Выписывается счет-фактура в двух экземплярах. Первый передается покупателю, а второй остается у организации, продавшей товар (выполнившей работы, оказавшей услуги).
Счета-фактуры, полученные от поставщиков и выставленные покупателям, хранятся в журнале учета счетов-фактур.
Продавцы учитывают счета-фактуры, выставленные покупателям в хронологическом порядке, а покупатели - номера их поступления от продавцов. Счета-фактуры, составленные продавцом, регистрируются в книге продаж. После отгрузки товаров (выполнения работ, оказания услуг) в счет уже полученных платежей в книге продаж делают корректировочную запись, которая уменьшает ранее начисленную сумму налога. Одновременно с этим поставщик выписывает счет-фактуру (в двух экземплярах) на фактическую отгрузку и записывает его в книгу продаж.
Данные платежных требований ежедневно записываются в ведомости учета реализации продукции (работ, услуг).
Схема документооборота документов, используемых в ходе учета продаж, приведена на рисунке 1.7.
Рисунок 1.7 Схема документооборота в процессе учета продаж
Рассмотрим временные характеристики описанных процессов так как, они происходят в настоящее время, и как будут происходить после автоматизации (таблица 1.1).
Таблица 1.1
Сравнение временных затрат
|
Действие |
Среднее количество за рабочий день |
В существующем виде |
При использовании автоматизированной системы |
Ожидаемая экономия, минут |
||
|
Время, необходимое для выполнении одного действия, минут |
Общее время |
Время, необходимое для выполнении одного действия, минут |
Общее время |
|||
|
Формирование приказа-накладной |
25 |
3 |
75 |
1 |
25 |
50 |
|
Формирование платежного поручения |
5 |
15 |
75 |
10 |
50 |
25 |
|
Формирования счета-фактуры |
2 |
20 |
40 |
3 |
6 |
34 |
|
Запись в книге продаж |
3 |
30 |
90 |
5 |
15 |
75 |
|
Заполнение ведомости учета реализации продукции |
1 |
25 |
25 |
5 |
5 |
20 |
|
Подготовка отчета по совершенным продажам |
1 |
35 |
35 |
3 |
3 |
32 |
|
Анализ совершенных продаж |
5 |
15 |
75 |
3 |
15 |
60 |
|
Учет других документов |
2 |
10 |
20 |
1 |
2 |
18 |
|
Подготовка других отчетов |
1 |
25 |
25 |
10 |
10 |
15 |
|
ИТОГО, минут: |
460 |
131 |
329 |
|||
Таким образом, при внедрении данной автоматизированной системы значительно снизятся временные (а значит, и стоимостные) затраты на выполнение рутинных, ежедневных операций, то есть автоматизация описываемого процесса позволит менеджеру отдела продаж обрабатывать большее количество документов за то же самое время, что и до автоматизации.
1.2. Обоснование проектных решений
1.2.1. Обоснование проектных решений по информационному обеспечению
Информационное обеспечение (ИО) подсистемы представляет собой информационную модель работы сотрудников предприятия. Различают внемашинное и внутримашинное обеспечение.
Информационное обеспечение включает в себя: систему классификации и кодирования; систему унифицированной документации, используемой в ИО, информационную базу, т.е. информацию из всех информационных массивов.
Внемашинное обеспечение – это вся совокупность информации, основную часть которой составляют документы. Различат первичные документы (входные) такие, как налоговые декларации и другая отчетность налогоплательщиков, и отчетные (выходные) документы, к которым относятся отчетность налогоплательщиков, обработанная и подготовленная для отдела по работе с налогоплательщиками и отдела камеральных проверок.
Внутримашинное ИО – это представление данных на машинных носителях в виде специальным образом организованных массивов (файлов), БД и их информационных связей. Внутримашинное информационное обеспечение подсистемы создает информационную среду, направленную на выполнение сотрудниками своих профессиональных обязанностей. Эта область характеризуется набором объектов, их свойств и взаимосвязей. Для каждого объекта выделяется набор его характеристик, свойств.
К информационному обеспечению предъявляются следующие общие требования:
информационное обеспечение должно быть достаточным для поддержания всех автоматизируемых функций объекта;
для кодирования информации должны использоваться принятые классификаторы;
для кодирования входной и выходной информации, которая используется на высшем уровне управления, должны быть использованы классификаторы этого уровня;
должна быть обеспечена совместимость с информационным обеспечением систем, взаимодействующих с разрабатываемой системой;
формы документов должны отвечать требованиям корпоративных стандартов или унифицированной системы документации;
структура документов и экранных форм должна соответствовать характеристиками терминалов на рабочих местах конечных пользователей;
графики формирования и содержание информационных сообщений, а также используемые аббревиатуры должны быть общеприняты в этой предметной области и согласованы с заказчиком;
в ИС должны быть предусмотрены средства контроля входной и результатной информации, обновления данных в информационных массивах, контроля целостности информационной базы, защиты от несанкционированного доступа.
В рассматриваемом случае к информационному обеспечению задачи будут относиться входные и результатные документы, классификаторы, а также перечень экранных форм, предназначенных для реализации диалога пользователя и системы.
1.2.2. Обоснование проектных решений по программному обеспечению
Программное обеспечение (ПО) включает совокупность программ, реализующих функции и задачи ИС и обеспечивающих устойчивую работу комплексов технических средств. В состав программного обеспечения входят общесистемные и специальные программы, а также инструктивно-методические материалы по применению средств программного обеспечения и персонал, занимающийся его разработкой и сопровождением на весь период жизненного цикла ИТ [9].
К общесистемному (общему) программному обеспечению относятся программы, рассчитанные на широкий круг пользователей и предназначенные для организации вычислительного процесса и выполнения часто встречающихся вариантов обработки информации. Они позволяют расширить функциональные возможности ЭВМ, автоматизировать планирование очередности вычислительных работ, а также автоматизировать работу программистов. Специальное (функциональное) программное обеспечение представляет собой совокупность программ, разрабатываемых при создании ИТ конкретного функционального назначения. Оно включает пакеты прикладных программ, осуществлявших организацию данных и их обработку при решении функциональных задач ИС [3].
При выборе комплекса технических средств для разработки системы, одним из важнейших критерием является выбор операционной системы. Операционная система управляет техническими средствами компьютера, поддерживает запуск и выполнение тех или иных программ и приложений, обеспечивает защиту данных, выполняет различные сервисные функции. Каждая программа пользуется средствами, предоставляемыми операционной системой. Таким образом, выбор операционной системы очень важен, так как он определяет набор программ и формат исполняемых файлов, а также их взаимодействие с операционной системой.
В настоящее время наиболее распространены следующие ОС:
Windows 7,
Windows Vista,
Linux Ubuntu
Apple Mac OS X.
Сравнение ОС наиболее логично проводить по следующим критериям:
интерфейс;
безопасность;
программное обеспечение;
цена и производительность.
Установленная на компьютерах пользователей операционная система Windows XP является уже устаревшей, а Windows Vista отличается от нее только в худшую сторону.
Сильной стороной Мас OS является практическое отсутствие вирусов для Мacintosh. Минус – это то, что Mac OS устанавливается только на компьютеры Мacintosh производства фирмы Apple.
Большинство дистрибутивов Linux являются бесплатными, их можно свободно и бесплатно использовать. На основе программного кода как самой Linux, так и входящих в неё программ и на их основе создавать свои продукты.[4] Поставляется со стандартным набором прикладного ПО. В Linux пользователь может выбрать тот дистрибутив, который больше подходит для решения его задач, а затем ещё и оптимизировать систему «под себя». Существование графического интерфейса освобождает от необходимости править конфигурационные файлы в неудобном виде. Положение дел с безопасностью в Linux в общем очень похоже на Mac OS X. Она находятся на очень высоком уровне в обеих системах и значительно опережают Windows.
Результатом политики GPL явилось то, что сейчас имеется более тысячи разных дистрибутивов Linux. Не все из них достойны внимания, пользователю трудно разобраться в таком множестве версий и выбрать то, что нужно. Кроме того, бесплатность подразумевает практически полное отсутствие технической поддержки пользователей. Другой минус – не такая уж и бесплатная получается система, ведь нужно либо купить с ней диск, что тоже деньги, либо скачивать.
Основная особенность Windows - ее массовое распространение. Связано это с тем,что это операционная система, созданная для пользователей, она не заставляет пользователя подстраиваться под систему, она подстраивается под его потребности. Это самая распространенная в мире операционная система, несмотря на то, что по общественному мнению она самая нестабильная и ненадежная.
Наиболее правильным в данной ситуации является выбор операционной системы Windows 7 по следующим причинам:
Знакомый пользователям интерфейс;
Отсутствие необходимости переобучения;
Легкость администрирования;
Меньшая стоимость, чем у ОС компании Apple;
Наличие всех необходимых функций.
Для корректной работы информационной системы необходимо провести анализ программных средств, имеющихся на рынке, оценить их производительность, надежность и доступность.
Рациональная работа системы в целом складывается из правильно выбранных программных и аппаратных средств. Система разрабатывается для развивающейся телекоммуникационной компании, поэтому необходимо уделить внимание доступности пакета используемых программ, чтобы итоговая цена разработки оказалась доступной для небольшой компании.
Для выбора языка программирования необходимо провести анализ существующих решений. Для этого выберем наиболее часто используемые языки и проведем сравнение.
Perl (Practical Extraction and Reporting Language) - является одним из наиболее мощных и популярных языков программирования.
Perl – полнофункциональный сложный язык. Он привлекателен тем, что заполняет разрыв между методами программирования командного процессора Unix и С-приложениями, обладая простотой первых и функциональностью последних.
Perl - это интерпретируемый язык, оптимизированный для сканирования произвольных текстовых файлов, извлечения информации из этих файлов и печати отчетов на основе этой информации. С его помощью также можно решать многие задачи системного управления. При разработке этого языка целью была не столько красота (небольшой объем, элегантность и оптимальность), сколько практичность (простота в использовании, эффективность и полнота). Синтаксис выражений Perl находится в полном соответствие с синтаксисом выражений языка С. Perl не ограничивает произвольно объем ваших данных. Рекурсия может быть неограниченной глубины, а, кроме того, язык применяет методы сопоставления с образцом для быстрого сканирования больших объемов данных.
Язык Perl, использующий простые синтаксис, типы данных и структуры, довольно прост в изучении; хорошо написанные Perl-программы легки для чтения и понимания. Однако за этой простотой скрывается относительно богатый набор функций Perl, который включает в себя встроенный символьный отладчик и поддержку объектно-ориентированного программирования. С помощью сложного механизма трассировки потока данных Perl может определить, поступают ли данные из небезопасного источника, и вовремя предотвратить потенциально опасные операции.
Perl легко переносим, он работает на всех основных и многих менее значимых платформах, может получать доступ к соединениям TCP/IP и интегрироваться с языком С. Он обладает также многими специализированными расширениями для доступа к базам данных и каталогам Х.500. Однако главным его достоинством является большое количество новостей и Web-узлов, что обеспечивает программистам на Perl поддержку и ресурсы. Накладываемые ограничения немногочисленны, он исключительно гибок и обладает широкими возможностями поддержки.
Сценарии или программы на языке Perl представляют собой чисто текстовые файлы, преобразуемые на этапе выполнения в байт-кодовые версии, что позволяет выявлять ошибки и выполнять трассировку потоков данных. Перед исполнением интерпретатор Perl конвертирует байт-кодовые представления в машинные коды.
РHP представляет собой скриптовый язык программирования, который применяется в основном в сфере различных Интернет-приложений. Синтаксис основных конструкций PHP похож на язык программирования C++. PHP – это достаточно молодой язык, пришедший на замену Perl, он в большей степени ориентирован на web-программирование, не сложен в изучении, имеет большое количество разнообразных подключаемых модулей, расширяющие его практическое применение. Главной целью применения PHP является создание динамического HTML, позволяющего отображать различный контекст в приложении, в зависимости от действий пользователя.
Такие свойства PHP как расширяемость ядра с помощью модулей, открытость исходного кода, способность взаимодействия с базами данных, поддержка различных протоколов и объектно-ориентированного программирования привели к резкому росту популярности PHP среди создателей веб-сайтов.
Преимуществами PHP по сравнению с популярным языком Perl, является простой синтаксис, что делает его легче в изучении, и более четкий и менее раздутый исходный код, что делает его легче при разработке модулей.
Кроме того, PHP работает как часть веб-сервера, что существенно экономит ресурсы хостинга: PHP, в отличие от сценариев CGI, не приводит к порождению нового процесса в операционной системе. Особенно это преимущество становится заметным, когда посещаемый сайт состоит из множества страниц, на которых выполняются относительно небольшие куски кода PHP. Аналогичный вариант с кодом на Perl порождал бы огромное число новых процессов.
В качестве недостатка PHP 3 выделяют его низкую по сравнению с Perl производительность на сложных приложениях при обработке больших скриптов, то есть в тех случаях, когда сайт состоит из нескольких страниц, но с длинным кодом. В таких ситуациях выгодней использовать CGI. Поэтому при выпуске новой версии PHP 4 основное внимание было уделено повышению быстроты работы. Также были затронуты вопросы безопасности и была внедрена поддержка сессий. Новая версия PHP содержала в себе ядро Zend Engine, которое позволило добиться увеличения производительности и стабильности за счет более качественной поддержки модулей.
В дальнейшем проводились работы по улучшению технологии Zend в части поддержки модели объектно-ориентированного программирования, что вылилось в создание PHP версии 5. Это версия включает в себя ядро Zend Engine 2, поддержку языка разметки XML, в PHP появились такие понятия объектно-ориентированной модели как деструкторы, интерфейсы, клонирование объектов.
Ruby on Rails — это полноценный, многоуровневый фреймворк для построения веб-приложений, использующих базы данных, который основан на архитектуре Модель-Представление-Контроллер (Model-View-Controller, MVC).
Rails предоставляет однородную среду разработки на Ruby для динамичных AJAX-интерфейсов: обработки запросов и выдачи данных в контроллерах. Для работы необходима только — это база данных и веб-сервер.
Rails — это, прежде всего, инфраструктура, поэтому среда подходит для любого типа веб-приложений.
Rails работает со многими веб-серверами и СУБД. В качестве веб-сервера рекомендуется использовать Apache или lighttpd как с FastCGI, так и с SCGI. В качестве СУБД можно использовать MySQL, PostgreSQL, SQLite, Oracle, SQL Server, DB2 или Firebird. Использовать Rails можно на практически любой операционной системе, однако для развертывания рекомендуются системы семейства Unix.
ASP.NET – это часть технологии .NET, используемая для написания мощных клиент-серверных интернет приложений. Она позволяет создавать динамические страницы HTML. ASP.NET возникла в результате объединения более старой технологии ASP (активные серверные страницы) и .NET Framework. Она содержит множество готовых элементов управления, используя которые можно быстро создавать интерактивные web-сайты. Также есть возможность использовать сервисы, предоставляемые другими сайтами, прозрачно для пользователей собственной разработки.
ASP.NET - это унифицированная среда разработки Web-приложений, обеспечивающая разработчиков сервисами, необходимыми для построения приложений уровня предприятия. ASP.NET имеет возможность работы с протоколами. ASP.NET обеспечивает новую модель разработки и инфраструктуру, которые позволяют создавать функциональные приложения нового типа.
ASP.NET является составной частью операционной системы. Использование компилированного кода приводит к автоматическому росту производительности. В результате страницы ASP.NET стали намного более похожими на традиционные приложения.
ASP.NET имеет много программных усовершенствований, например, кэширование, компиляцию кода, а также большую степень простоты и безопасности и обеспечение надежности, которая может сохраняться даже во время аварий на серверах
ASP.NET обеспечивает встроенную поддержку сеансов, которая является переносимой с одной Web-формы на другую. ASP.NET запоминает информацию по состоянию пользователя или запрашивает входные переменные.
Благодаря этим и другим усовершенствованиям ASP.NET намного увеличивает возможности разработчиков – за счет чего она популярна и очень быстро развивается.
На основании проведенного анализа выбран язык PHP.
Для выбора СУБД так же проведем анализ существующих решений. Для этого выберем наиболее часто используемые языки и проведем сравнение.
Выбор системы управления базами данных (СУБД) представляет собой сложную задачу, для решения которой необходимо учесть множество факторов и параметров. Эта задача является одним из самых важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды [1].
В общем случае, перечень требований к СУБД, может изменяться в зависимости от поставленных целей. Тем не менее можно выделить несколько групп критериев:
Структура данных;
Функциональные возможности;
Особенности разработки приложений;
Производительность;
Требования к рабочей среде.
Рассмотрим каждую из этих групп в отдельности.
1. Структура данных. К данной группе требований можно отнести следующие: используемая модель данных (вопрос об использовании той или иной модели должен решаться на начальном этапе проектирования информационной системы), предусмотренные типы данных.
2. Функциональные возможности. В данной группе требований выделяются следующие критерии: мобильность (независимость системы от среды, в которой она работает), масштабируемость (сможет ли данная система соответствовать росту информационной системы), триггеры и хранимые процедуры, сетевые возможности.
3. Особенности разработки приложений. Многие производители СУБД выпускают также средства разработки приложений для своих систем. Как правило, эти средства позволяют наилучшим образом реализовать все возможности сервера, поэтому при анализе СУБД стоит рассмотреть также и возможности средств разработки приложений. К данной группе требований можно отнести следующие: средства проектирования, многоязыковая поддержка, возможности разработки Web-приложений.
4. Производительность. Производительность системы является одним из самых важных показателей, который будет использоваться в статье в качестве основного критерия для выбора СУБД. Существует несколько факторов, которые можно отнести к производительности системы и которые могут учитываться для оценки производительности данной СУБД. Такими факторами являются следующие: рейтинг ТРС (Transactions per Cent), возможности параллельной архитектуры, возможности оптимизирования запросов.
5. Требования к рабочей среде. К данной группе требований можно отнести следующие: поддерживаемые аппаратные платформы, минимальные требования к оборудованию и операционной системе [1].
Рассмотрим 5 различных реляционных СУБД. Согласно методу анализа иерархий, предложенному Т. Саати, проводится попарное сравнение всех СУБД по каждому критерию, в результате чего получается 5 матриц попарных сравнений альтернатив.
В качестве альтернатив рассмотрим следующие СУБД:
DB2;
Oracle;
Microsoft SQL Server;
MySQL;
PostgreSQL.
Сравним выбранные СУБД по критерию «Структура данных».
Все рассматриваемые альтернативы реализуют реляционную модель данных (РСУБД) или объектно-реляционную модель данных (ОРСУБД), следовательно, все рассматриваемые системы подходят для анализа и сравнения. Проводится анализ рассматриваемых альтернатив по предусмотренным типам данных. По результатам этого анализа можно построить матрицу попарных сравнений альтернатив по первому критерию (таблица 1.2), рассчитать вектор приоритетов, главное собственное значение и остальные показатели [3].
Таблица 1.2
Матрица попарных сравнений альтернатив по критерию «Структура данных»
|
DB2 |
Oracle |
MySQL |
MS SQL |
Postgre SQL |
|
|
DB2 |
1 |
1 |
1 |
1 |
1 |
|
Oracle |
1 |
1 |
1/4 |
1/5 |
1/3 |
|
MySQL |
1 |
4 |
1 |
1/2 |
2 |
|
MS SQL |
1 |
5 |
2 |
1 |
2 |
|
Postgre SQL |
1 |
3 |
1/2 |
1/2 |
1 |
Вектор приоритетов: ОД 8 0,08 0,24 0,33 0,17
Главное собственное значение: 5,34. Индекс согласованности (ИС): 0,084. Отношение согласованности (ОС): 0,07. Как видно, ОС в пределах нормы.
Сравним выбранные СУБД по критерию «Функциональные возможности».
Пункт «Триггеры и хранимые процедуры» определяет наличие в некоторой СУБД класса процедур, функций. Триггер -программа базы данных, вызываемая всякий раз при вставке, изменении или удалении строки таблицы. Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти изменения будут приняты. Хранимая процедура - программа, которая хранится на сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются непосредственно на сервере баз данных, обеспечивается более высокое быстродействие, нежели при выполнении тех же операций средствами клиента БД [1]. Проведем анализ альтернатив по данному пункту (таблица 1.3).
Таблица 1.3
Анализ альтернатив по пункту «Триггеры и х ранимые процедуры»
|
Триггер |
Функция |
Процедура |
|
|
DB2 |
+ |
+ |
+ |
|
Microsoft SQL Server |
+ |
+ |
+ |
|
MySQL |
+ |
+ |
+ |
|
Oracle |
+ |
+ |
+ |
|
PostgreSQL |
+ |
+ |
+ |
Пункт «Масштабируемость» предполагает возможности рассматриваемой СУБД по увеличению объема данных со временем и в случае необходимости [4]. Необходимо рассмотреть максимально возможный объем хранимых данных для каждой альтернативы (таблица 1.4).
Таблица 1.4
Анализ альтернатив по пункту «Масштабируемость»
|
Размер БД |
Размер таблицы |
Размер строки |
||
|
DB2 |
512ТБ |
512 ТБ |
32677 В |
|
|
Microsoft SQL Server |
524258 ТБ |
524258 ТБ |
∞ |
|
|
MySQL |
∞ |
256ТВ |
64KB |
|
|
Oracle |
∞ |
4 Гб* Размер блока |
8KB |
|
|
Postgre SQL |
∞ |
32 ТБ |
1,6 ТБ |
|
Таким образом, проведен анализ рассматриваемых альтернатив по пунктам критерия «Функциональные возможности». По результатам анализа можно построить матрицу попарных сравнений альтернатив по второму критерию (таблица 1.5, рассчитать вектор приоритетов и основные показатели.
Таблица 1.5
Матрица попарных сравнений альтернатив по критерию «Функциональные возможности»
|
DB2 |
Oracle |
MySQL |
MS SQL |
Postgre SQL |
|
|
DB2 |
1 |
1/4 |
2 |
1/7 |
1/5 |
|
Oracle |
4 |
1 |
1 |
1/4 |
1/2 |
|
MySQL |
1/2 |
1 |
1 |
1/4 |
1/2 |
|
MS SQL |
7 |
4 |
4 |
1 |
3 |
|
Postgre SQL |
5 |
2 |
2 |
1/3 |
1 |
Вектор приоритетов: 0,07 0,13 0,09 0,49 0,22
Главное собственное значение: 5,45. Индекс согласованности (ИС): ОД 11. Отношение согласованности (ОС): 0,09.
Рассмотрим критерий «Особенности разработки приложений». При рассмотрении этого критерия необходимо оценить трудозатраты на администрирование баз данных. Основные задачи такого администрирования: установка и конфигурирование базы данных, текущее администрирование базы данных, резервное копирование/восстановление [5].
Таким образом можно построить матрицу попарных сравнений альтернатив по третьему критерию (таблица 1.6), рассчитать вектор приоритетов и основные показатели.
Таблица 1.6
Матрица попарных сравнений альтернатив по критерию «Особенности разработки приложений»
|
DB2 |
Oracle |
MySQL |
MS SQL |
Postgre SQL |
|
|
DB2 |
1 |
1 |
1 |
1/6 |
1 |
|
Oracle |
1 |
1 |
1 |
1/4 |
1 |
|
MySQL |
1 |
1 |
1 |
1/4 |
1 |
|
MS SQL |
6 |
4 |
4 |
1 |
3 |
|
Postgre SQL |
1 |
1 |
1 |
1/3 |
1 |
Главное собственное значение: 5,04. Индекс согласованности (ИС): 0,01. Отношение согласованности (ОС): 0,01.
Сравним выбранные СУБД по критерию «Производительность».
Для тестирования производительности применяются различные средства, и существует множество тестовых рейтингов. Одним из самых популярных и объективных является ТРС-анализ производительности систем. Показатель ТРС - это отношение количества запросов, обрабатываемых за некий промежуток времени, к стоимости всей системы. Следует отметить, что для СУБД PostgreSQL не проводится тест ТРС, а система MySQL проводит собственные тесты производительности. Результаты теста производительности ТРС-С представлены в таблица 1.12 [6].
Таблица 1.7
Результаты теста TPC
|
Название |
Количество транзакций, tpmC |
Стоимость транзакции, долл./tpmC |
Монитор транзакций |
|
Microsoft SQL Server 2005 х64 |
661,475 |
1.16USD |
Microsoft COM+ |
|
Oracle Database Standard |
631,766 |
1.08 USD |
Microsoft COM+ |
|
IBM DB2 9.5 |
1,200,011 |
1.99 USD |
Microsoft COM+ |
По имеющимся данным оценим рассматриваемые СУБД по критерию «Производительность», построим матрицу попарных сравнений альтернатив (таблица 1.8).
Таблица 1.8
Матрица попарных сравнений альтернатив по критерию «Производительность»
|
по |
DB2 |
Oracle |
MySQL |
MS SQL |
Postgre SQL |
|
DB2 |
1 |
4 |
5 |
3 |
5 |
|
Oracle |
1/4 |
1 |
3 |
1/2 |
3 |
|
MySQL |
1/5 |
1/3 |
1 |
1/4 |
1 |
|
MS SQL |
1/3 |
2 |
4 |
1 |
4 |
|
Postgre SQL |
1/5 |
1/3 |
1 |
1/4 |
1 |
Вектор приоритетов: 0,47 0,15 0,07 0,24 0,07
Главное собственное значение: 5,14. Индекс согласованности (ИС): 0,036. Отношение согласованности (ОС): 0,03.
Рассмотрим критерий «Требования к рабочей среде». В таблица 1.9 приводятся результаты анализа альтернатив по критерию «Поддерживаемые операционные системы» [3].
Таблица 1.9
Поддерживаемые ОС рассматриваемых систем
|
DB2 |
MS SQL Server |
MySQL |
Oracle |
Postgre SQL |
|
|
Windows |
+ |
+ |
+ |
+ |
+ |
|
Mac OS |
+ |
+ |
+ |
+ |
+ |
|
Linux |
+ |
+ |
+ |
+ |
+ |
|
BSD |
- |
+ |
+ |
- |
+ |
|
UNIX |
+ |
+ |
+ |
+ |
+ |
|
AmigaOS |
- |
+ |
+ |
- |
- |
|
Symbian |
- |
+ |
+ |
- |
- |
Оценим рассматриваемые СУБД относительно критерия «Требования к рабочей среде», построим матрицу попарных сравнений альтернатив (таблица 1.10).
Таблица 1.10
Матрица попарных сравнений альтернатив по критерию «Требования к рабочей среде»
|
DB2 |
Oracle |
MySQL |
MS SQL |
Postgre SQL |
|
|
DB2 |
1 |
1 |
1/4 |
1/4 |
1/3 |
|
Oracle |
1 |
1 |
1/4 |
1/4 |
1/2 |
|
MySQL |
4 |
4 |
1 |
1 |
3 |
|
MS SQL |
4 |
4 |
1 |
1 |
3 |
|
Postgre SQL |
3 |
2 |
1/3 |
1/3 |
1 |
Пусть производительность имеет наибольшую важность по сравнению с другими критериями, требования к рабочей среде также важны, так как при выборе СУБД на ранних этапах поднимается вопрос о совместимости рассматриваемой системы с существующими программными и аппаратными средствами.
Построим матрицу попарных сравнений критериев (таблица 1.16), для удобства пронумеруем критерии от 1 до 5.
Таблица 1.11
Матрица попарных сравнений критериев
|
1 |
2 |
3 |
4 |
5 |
|
|
1 |
1 |
1 |
1/2 |
1/6 |
1/4 |
|
2 |
1 |
1 |
1/2 |
1/6 |
1/3 |
|
3 |
2 |
2 |
1 |
1/5 |
1/2 |
|
4 |
6 |
6 |
5 |
1 |
2 |
|
5 |
4 |
3 |
2 |
1/2 |
1 |
Вектор приоритетов альтернатив: 0,07 0,07 0,12 0,49 0,25
Главное собственное значение: 5,03. Индекс согласованности (ИС): 0,01. Отношение согласованности (ОС): 0,01.
Таким образом, веса рассматриваемых СУБД распределены следующим образом: MySQL (0.32), DB2 (0.28), MS SQL Server (0.16), Oracle (0.13), PostgreSQL (0.11).(рисунок 1.10).
Рисунок 1.8 Результаты анализа СУБД
На основании данного сравнения выбираем для использования СУБД MySQL.
Глава 2. ПРОЕКТНАЯ ЧАСТЬ
2.1. Информационное обеспечение задачи
2.1.1. Информационная модель и её описание
Информационная модель представляет собой схему движения входных, промежуточных и результативных потоков и функций предметной области. Кроме того, она объясняет, на основе каких входных документов и какой нормативно-справочной информации происходит выполнение функций по обработке данных и формирование конкретных выходных документов. Информационная модель представлена на рис. 2.1.
Рисунок 2.1 Информационная модель системы
На схеме приведено отображение следующих условных зон информационной модели:
- область заполнения справочников на основании входных документов и с помощью экранных форм;
- область учета продаж;
- область формирования отчетных документов;
- область справочников и таблиц системы.
2.1.2. Характеристика нормативно-справочной, входной и оперативной информации
В качестве входной информации для системы учета продаж используются следующие документы:
- Прайс-лист;
- Договоры о продажах;
- Список менеджеров отдела.
Прайс-лист содержит следующие реквизиты:
- Наименование товара;
- Группа товара;
- Тип товара;
- Модель;
- Артикул;
- Стоимость.
Из такого документа, как Договор о продаже, используются следующие реквизиты:
- Наименование клиента;
- Огрформа;
- Контакты;
- Должностные лица.
Список менеджеров отдела содержит фамилию, имя и отчество менеджера, а также наименование его должности.
В системе используются справочники, приведенные в таблице 2.1.
Таблица 2.1
Перечень используемых справочников
|
Название справочника |
Ответственный за ведение |
Средний объём справочника в записях |
Средняя частоту актуализации |
Средний объем актуализации, % |
|
Товары |
Пользователь |
10000 |
1 раз в неделю |
10 |
|
Клиенты |
Пользователь |
500 |
1 раз в месяц |
10 |
|
Персоны |
Администратор |
10 |
1 раз в месяц |
10 |
|
Типы обуви |
Пользователь |
10 |
1 раз в неделю |
25 |
|
Группы обуви |
Администратор |
10 |
1 раз в неделю |
25 |
|
Типы оргформ |
Пользователь |
23 |
1 раз в неделю |
25 |
|
Сотрудники |
Администратор |
75 |
1 раз в неделю |
10 |
Справочник Товары включает в себя следующие реквизиты:
- наименование;
- модель;
- артикул;
- тип;
- группа;
- стоимость.
Справочник Клиенты включает в себя следующие реквизиты:
- Наименование;
- Тип оргформы;
- Полное наименование;
- Юридический адрес;
- Фактический адрес;
- ИНН;
- КПП;
- ОКПО;
- ОГРН .
Справочник Персоны включает в себя следующие реквизиты:
- ФИО ;
- Код;
- Артикул;
- Серия по умолчанию;
- Товар;
- Комментарий.
Справочник Валюты включает в себя наименование и условное обозначение валюты.
Справочник Причины списания включает в себя следующие реквизиты:
- Наименование;
- Код;
- Описание.
Справочник Причины оприходования включает в себя следующие реквизиты:
- Наименование;
- Код;
- Описание.
Справочник Договоры включает в себя следующие реквизиты:
- Номер;
- Дата;
- Дата проведения;
- Организация;
- Контрагент;
- Код;
- Сумма договора;
- Валюта;
- Комментарий.
Справочник Сотрудники включает в себя следующие реквизиты:
- Имя для входа;
- Имя пользователя ;
- Имя;
- Отчество;
- Фамилия;
- E-mail;
- Язык;
- Пароль;
- Обращение;
- Телефон;
- Мобильный телефон;
- Факс;
- ICQ;
- Skype ;
- Город ;
- Адрес ;
- Почтовый индекс;
- Описание;
- Роль в системе.
2.1.3. Характеристика результатной информации
Результатной информацией для задачи автоматизации учета продаж являются следующие документы:
- Счет-фактура;
- Список счет фактур;
- Отчет по продажам за клиента за произвольный период;
- Отчет по продажам за товар за произвольный период;
- Отчет по продажам за группу товара за произвольный период;
- Отчет по продажам за тип товара за произвольный период;
Счет-фактура формируется при учете продаж и содержит следующие реквизиты:
- Номер документа;
- Дата документа;
- Наименование клиента;
- Номер по списку;
- Наименование товара;
- Артикул товара;
- Модель товара;
- Группа товара;
- Стоимость товара;
- Количество товара;
- Общая стоимость;
- Общее количество наименований.
Другие документы формируются по необходимости. Список счет фактур содержит следующие реквизиты:
- Номер по списку;
- Дата документа;
- Номер документа;
- Наименование клиента;
- Общее количество наименований;
- Общая сумма.
Отчет по продажам за клиента за произвольный период содержит следующие реквизиты:
- Наименование клиента;
- Дата начала периода;
- Дата окончания периода;
- Общее количество наименований;
- Общая сумма продаж.
Отчет по продажам за товар за произвольный период содержит следующие реквизиты:
- Наименование товара;
- Дата начала периода;
- Дата окончания периода;
- Общее количество наименований;
- Общая сумма продаж.
Отчет по продажам за группу товара за произвольный период содержит следующие реквизиты:
- Наименование группы товара;
- Дата начала периода;
- Дата окончания периода;
- Общее количество наименований;
- Общая сумма продаж.
Отчет по продажам за тип товара за произвольный период содержит следующие реквизиты:
- Наименование типа товара;
- Дата начала периода;
- Дата окончания периода;
- Общее количество наименований;
- Общая сумма продаж.
Кроме того, для функционирования системы формируются такие справочные документы, как:
- Список клиентов;
- Список контактов клиентов;
- Список менеджеров;
- Список товаров;
- Список групп товаров;
- Список типов товаров.
2.2. Программное обеспечение задачи
2.2.1. Общие положения (дерево функций и сценарий диалога)
Разрабатываемая информационная система призвана автоматизировать функции менеджеров отдела продаж по учету продаж и их анализу. На основании данных функции построено дерево функций системы, которое представляет декомпозицию функций системы и формируется с целью детального исследования функциональных возможностей системы и анализа совокупности функций, реализуемых на различных уровнях иерархии системы.
Работу с системой осуществляет менеджер отдела продаж. Дерево функций системы представлено на рисунке 2.2.
Как видно из представленной схемы, менеджер при работе в системе имеет возможность заполнения справочников, в том числе добавления, удаления записей, поиска по ним и получения списка записей, содержащихся в справочниках.
Основным документом является счет-фактура, которая формируется по факту продаж и служит основным отчетным документом.
Рисунок 2.2 Дерево функций системы для менеджера отдела продаж
Сценарии диалога, формирующийся на основе дерева функций, приведен на рис. 2.3.
Рис. 2.3 Сценарий диалога для пользователя
2.2.2. Характеристика базы данных
Инфологическая (концептуальная) модель — это формализованное описание предметной области, выполненное безотносительно к используемым в дальнейшем программным и техническим средствам.[3] Инфологическая модель должная быть динамической и позволять легкую корректировку. К основным требованиями, предъявляемым к инфологической модели, можно отнести следующие:
- инфологическая модель должна содержать всю необходимую и достаточную информацию для последующего проектирования базы данных;
- инфологическая модель должная быть понятна лицам, принимающим участие в создании системы.
ER-модель представляет собой логическую структуру информации об объектах системы. Компонентами ER-модели являются сущности (объекты) и отношения (связи между объектами). Объект имеет множество реализаций или экземпляров. Экземпляр объекта образуется совокупностью конкретных значений реквизитов и должен однозначно определяться, т.е. идентифицироваться значением ключа объекта, который состоит из одного ли нескольких ключевых реквизитов.
ER-диаграммы используются для разработки данных и представляют собой стандартный способ определения данных и отношений между ними. Таким образом, осуществляется детализация хранилищ данных. ER-диаграмма содержит информацию о сущностях системы и способах их взаимодействия, включает идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Сущность изображается в виде прямоугольника, вверху которого располагается имя сущности. В прямоугольнике могут быть перечислены атрибуты сущности; атрибуты ER-диаграмм, набранные полужирным шрифтом, являются ключевыми. ER-диаграмма базы данных разработанной информационной системы приведена на рис. 2.4.
Рис. 2.4 ER-диаграмма базы данных
Описание каждой таблицы базы данных приведено ниже.
Таблица 2.2
Структура таблицы Счет-фактуры
|
Поле |
Тип |
Описание поля |
Null |
По умолчанию |
|
idchet |
int(11) |
Код записи |
Нет |
|
|
idklientchet |
int(11) |
Код клиента |
Нет |
|
|
idprodchet |
int(11) |
Код продукции |
Нет |
|
|
kolvochet |
int(11) |
Количество |
Нет |
|
|
datechet |
text |
Дата |
Нет |
|
|
Nomer |
int(11) |
Номер счет-фактуры |
Нет |
|
Таблица 2.3
Структура таблицы Типы товаров
|
Поле |
Тип |
Описание поля |
Null |
По умолчанию |
|
iddolg |
int(11) |
Код записи |
Нет |
|
|
namedolg |
varchar(45) |
Наименование типа |
Да |
NULL |
|
udald |
int(1) |
Флаг удаления |
Нет |
0 |
Таблица 2.4
Структура таблицы Клиенты
|
Поле |
Тип |
Описание поля |
Null |
По умолчанию |
|
idKlient |
int(11) |
Код записи |
Нет |
|
|
namekl |
varchar(255) |
Наименование |
Да |
NULL |
|
krnamekl |
varchar(45) |
Краткое наименование |
Да |
NULL |
|
adresskl |
varchar(45) |
Адрес фактический |
Да |
NULL |
|
uradrkl |
varchar(45) |
Адрес юридический |
Да |
NULL |
|
banrekKl |
varchar(45) |
Банк |
Да |
NULL |
|
kontlizoKl |
varchar(45) |
Контактное лицо |
Да |
NULL |
|
tlfKl |
varchar(45) |
телефон |
Да |
NULL |
|
emailKl |
varchar(45) |
|
Да |
NULL |
|
dateregKl |
timestamp |
Дата регистрации |
Нет |
CURRENT_TIMESTAMP |
|
tipkl |
int(1) |
Тип клиента |
Нет |
|
|
udalKl |
int(1) |
Флаг удаления |
Нет |
0 |
|
nameorg |
varchar(255) |
Наименование оргформы |
Нет |
|
|
login |
varchar(25) |
Логин |
Нет |
|
|
parol |
varchar(25) |
Пароль |
Нет |
|
|
tel |
varchar(30) |
Доп. Телефон |
Нет |
0 |
|
opistel |
varchar(100) |
Описание доп. Телефона |
Нет |
0 |
|
adres |
varchar(255) |
Адрес доп. |
Нет |
0 |
|
|
varchar(30) |
Email доп. |
Нет |
0 |
|
opisemail |
varchar(100) |
Описание |
Нет |
0 |
|
Продолжение таблицы 2.6 |
||||
|
namec |
varchar(255) |
Наименование дополнительного контакта |
Нет |
0 |
|
idconka |
int(11) |
Описание дополнительного контакта |
Нет |
|
Таблица 2.5
Структура таблицы Группы товаров
|
Поле |
Тип |
Описание поля |
Null |
По умолчанию |
|
ido |
int(100) |
Код записи |
Нет |
|
|
nameob |
varchar(255) |
Наименование группы товаров |
Нет |
|
|
udalo |
int(1) |
Флаг удаления |
Нет |
0 |
Таблица 2.6
Структура таблицы Персоны
|
Поле |
Тип |
Описание поля |
Null |
По умолчанию |
|
idper |
int(11) |
Код записи |
Нет |
|
|
firma |
int(11) |
Код клиента |
Нет |
|
|
namep |
varchar(255) |
Фамилия |
Нет |
|
|
imap |
varchar(255) |
Имя и отчество |
Нет |
|
|
datep |
text |
Дата |
Нет |
|
|
dolgp |
int(11) |
Должность |
Нет |
|
|
telp |
varchar(255) |
Телефон |
Нет |
|
|
emailp |
varchar(255) |
|
Нет |
|
|
primp |
text |
Примечание |
Нет |
|
|
udalp |
int(1) |
Флаг удаления |
Нет |
0 |
Таблица 2.7
Структура таблицы Товары
|
Поле |
Тип |
Описание поля |
Null |
По умолчанию |
|
idprod |
int(11) |
Код записи |
Нет |
|
|
nameprod |
text |
Наименование |
Да |
NULL |
|
art |
varchar(45) |
артикул |
Да |
NULL |
|
idvz |
int(11) |
Код группы |
Да |
NULL |
|
idtz |
int(11) |
Код типа |
Да |
NULL |
|
model |
varchar(255) |
Модель |
Да |
NULL |
|
prise |
varchar(45) |
Стоимость |
Да |
NULL |
|
primP |
text |
Примечание |
Да |
NULL |
|
udalPr |
int(1) |
Флаг удаления |
Нет |
|
|
optst |
varchar(255) |
Стоимость опт |
Нет |
|
|
Продолжение таблицы 2.9 |
||||
|
rozst |
varchar(255) |
Стоимость розница |
Нет |
|
|
edizmpr |
varchar(255) |
Единица измерения |
Нет |
|
Таблица 2.8
Структура таблицы Менеджеры
|
Поле |
Тип |
Описание поля |
Null |
По умолчанию |
|
idsotr |
int(11) |
Код записи |
Нет |
|
|
name |
varchar(45) |
Фамилия |
Да |
NULL |
|
dolg |
varchar(45) |
Должность |
Да |
NULL |
|
login |
varchar(45) |
Логин |
Да |
NULL |
|
parol |
varchar(45) |
Пароль |
Да |
NULL |
|
dates |
timestamp |
Дата регистрации |
Нет |
CURRENT_TIMESTAMP |
|
surname |
varchar(45) |
имя, отчество |
Да |
NULL |
|
datebor |
varchar(45) |
Дата рождения |
Да |
NULL |
|
udal |
int(1) |
Флаг удаления |
Нет |
Таблица 2.9
Структура таблицы Типы оргформ
|
Поле |
Тип |
Описание поля |
Null |
По умолчанию |
|
idtipagent |
int(11) |
Код записи |
Нет |
|
|
nametipagent |
varchar(255) |
Наименование |
Нет |
|
|
krnametipagent |
varchar(255) |
Краткое наименование |
Нет |
|
|
udalnametipagent |
int(1) |
Флаг удаления |
Нет |
0 |
2.2.3. Структурная схема пакета (дерево вызова программных модулей)
Программные модули, образующие структуру пакета, можно подразделить на три класса: управляющие модули, предназначенные для загрузки меню и передачи управления другому модулю; модули, выполняющие служебные функции; модули, связанные с вводом, хранением, обработкой и выдачей информации. От класса модуля зависит его функциональность.
Система состоит из двух основных модулей – базы данных MySQL и приложения для взаимодействия с базой данных, реализованного на языке программирования PHP и c использованием HTML.
Работа с системой осуществляется через любой браузер. Вызов программных модулей обеспечивается при помощи браузера.
Структурная схема пакета представлена на рис. . 2.5.
Рисунок 2.5 Схема вызова программных модулей
Характеристика программных модулей представлена в таблице 2.12.
Таблица 2.10
Характеристика программных модулей
2.2.4. Описание программных модулей
Схема описания работы программного модуля представляет собой блок-схему и состоит из:
- символов данных, указывающих на наличие данных (символы данных могут также указывать вид носителя данных);
- символов процесса, указывающих операции, которые следует выполнить над данными, а также определяющих логический путь, которого следует придерживаться;
- линейных символов, указывающих потоки данных между процессами;
- специальных символов, используемых для облегчения написания и чтения блок-схемы.
Схема модуля учета товаров приведена на рис. 2.6.
Рисунок 2.6 Схема программного модуля
Листинг программных модулей приведен в Приложении.
2.3. Контрольный пример реализации проекта и его описание
В данном пункет рассмотрим контрольны пример работы системы учета продаж.
После прохождения авторизации пользователю необходимо произвести первоначальное заполнение справочников (рисунок 2.7).
Рисунок 2.7 Учет типов обуви
Справочник Типы обуви хранит информацию о типах обуви. Для формирования справочника Товары также необходимо заполнить Справочник Группы обуви.
Рисунок 2.8 Справочник Группы товаров
Справочник товаров хранит информацию о товарах, а именно об обуви, которая находится в ассортименте торгового дома.
Рисунок 2.9 Экранная форма для заполнения справочника Товары
Для того, чтобы добавить товар, необходимо выбрать Тип товара, группу товара, ввести модель, артикул и стоимость, а также при необходимости – описание.. После ввода данных формируется список товаров.
Рисунок 2.10 Список товаров
Для учета продаж также необходим учет клиентов (рисунок 2.11)
Рисунок 2.11 Учет клиентов
Для учета клиентов необходимо выбрать его оргформу, тип, ввести наименование, а также назначить куратора из числа менеджеров отдела продаж.
Каждому из клиентов можно назначить необходимое количество персон, то есть сотрудников данной фирмы. Также имеется возможность учета контактов разного типа.
Рисунок 2.12 Список клиентов
Рисунок 2.13 Список контактов
Рисунок 2.14 Список персон для ЗАО «Удача»
При наличии данной информации появляется возможность учета продаж путем формирования счет-фактуры (рисунок 2.15).
Рисунок 2.15 Экранная форма учета продаж
Для учета продаж необходимо вначале сформировать счет-фактуру, выбрав клиента из выпадающего списка и введя дату документа.
Рисунок 2.16 Создание счет-фактуры
После этого менеджер проводит заполнение созданной счет-фактуры путем последовательного выбора товаров и ввода его количества (рисунок 2.17).
Рисунок 2.17 Формирование счет-фактуры
При этом менеджер имеет возможность как удаления всей счет-фактуры, так и ее отдельных строк, либо может ее сохранить. Просмотреть счет-фактуру можно, найдя ее по датам формирования (рисунок 2.18).
Рисунок 2.18 Список счет-фактур
Нажав на иконку с изображением документа, можно просмотреть его содержание (рисунок 2.19).
Рисунок 2.19 Содержание счет-фактуры
При этом подсчитываются итоги в виде количества наименований и общей стоимости реализованного товара.
Заключение
Проектируемая информационная система позволит компании осуществить автоматизацию процесса учет продаж. Данная система спроектирована с использованием современных методик автоматизации бизнес-процессов компании. Применение данной системы приема позволит эффективно управлять работой элементов отдела продаж и иметь достоверную информацию по продажам и работе менеджеров.
Использование данной системы позволяет сократить временной цикл операции и обеспечить достоверность информации на выходе.
Теоретическая часть работы содержит краткую характеристику исследуемого предприятия. В данной части работы нам удалось описать его организационную структуру и представить характеристику его основных бизнес-процессов. Также имеется декомпозиция бизнес-процессов до процесса продаж, дается описание бизнес-процесса и выявляется его место в совокупных процессах, характерных для исследуемого предприятия. Практическая часть работы заключалась в построении модели информационной системы и описании информационной системы. Также нами было проведено описание и обоснование базовых технологий, применяемых при разработке информационной системы.
Для реализации поставленных задач были использованы следующие методики:
- Моделирование бизнес-процессов с использованием методологии IDEF0;
- Использование принципов процедурного подхода к моделированию бизнес-процессов;
- Использование методики построения диаграмм сущность-связь при проектировании базы данных;
- Использование экспертных систем при создании таблиц базы данных по ER-модели.
В результате исследования была получена модель бизнес-процесса, отвечающая требованиям, предъявляемым к системе автоматизации бизнес-процессов в компаниях, с учетом специфики деятельности исследуемой организации. Так же по имеющейся модели бизнес-процессов была построена структура информационной системы, позволившая провести разработку программного продукта.
Последовательно решив обозначенный в начале исследования ряд задач, нам удалось достичь цели самого исследования и проведения на его основе проектирования, то есть разработать комплексный теоретически обоснованный подход к автоматизации технической поддержки пользователей, а также спроектировать и реализовать программный продукт, позволяющий решить ряд проблемных задач, выделенных в процессе исследования.
Полученные в ходе проведенного исследования и проектирования программного продукта результаты должны иметь практическую значимость, выражающуюся в общественной и производственной пользе при использовании данных разработок.
Разработанная информационная система может использоваться на любом аналогичном рассмотренному предприятии с учетом доработок под конкретные виды товарных позиций.
Таким образом, основные задачи курсовой работы выполнены.
Список использованной литературы
- Введение в системы баз данных – СПб: Издательский дом "Вильямс", 2013. - 848 с.;
- Вендров А.М., CASE-технологии. Современные методы и средства проектирования информационных систем - М.: Финансы и статистика, 2016.
- Гаджинский А.М. Основы логистики: Учеб.пособие/ Инфоpм.-внедpен.центp "Маpкетинг".- М., 2015.- 121, с.: ил., табл.
- Дейв Крейн, Эрик Паскарелло, Даррен Джеймс. AJAX в действии: Учебник – М.: Вильямс, 2016. 450 – 490 с.
- Джексон Г. Проектирование реляционных баз данных для использования с микро-ЭВМ М.: Финансы и статистика, 2011.
- Диго С.М. Базы данных: проектирование и использование: Учебник. – М.: Финансы и статистика, 2015. – 592 с.
- Дэвид Флэнаган. JavaScript. Подробное руководство: Учебник – М.: Символ Плюс, 2015. 243 – 249 с.
- Зеленков Ю.А. Введение в базы данных. Центр Интернет ЯрГУ, 2016.
- Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения / Пер. с англ. — М.: Мир, 2012. — 386 с., ил.
- Ивлиев М.К., Порошина Л.А. Автоматизация оперативного и бухгалтерского учета товаров, 2014.
- Информационные системы: Учебник для вузов. 2-е изд. СПб: "Питер", 2015 г - 656 стр.
- Керри Н. Праг, Майкл Р. Ирвин, Access 2000 - Библия пользователя, Диалектика, 2014.
- Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 2014.
- Кристиан Дари, Богдан Бринзаре, Филип Черчез-Тоза, Михай Бусика. AJAX и PHP. Разработка динамических веб-приложений: Учебник – М.: Символ Плюс, 2016.
- Лифшиц Н.И., Левин Е.Т Механизация и автоматизация процессов отборки и комплектования заказов на складах М., 2014.
- Практическое руководство по программированию / Пер. с англ. Б. Мик, П. Хит, Н. Рашби и др.; под ред. Б. Мика, П. Хит, Н. Рашби. — М.: Радио и связь, 2014. — 168 с., ил.
- Проектирование и использование баз данных: Учебник. М.:Финансы и статистика, 2015г. – 191 с.;
- Разработка программного обеспечения - СПб : "Питер", 2014 г - 592 стр.
- Реляционные базы данных: практические приемы оптимальных решений. – СПб.: БХВ-Петербург, 2015 – 400с.:ил;
- Симионов Ю.Ф., Боромотов В.В. Информационный менеджмент. — Ростов н.Д: Феникс, 2016, 250с., ил.;
- Фокс Дж. Программное обеспечение и его разработка / Пер. с англ. — М.: Мир, 2015. - 368 с., ил.
- Язык компьютера. Пер. с англ, под ред. и с предисл. В. М. Курочки-на. — М.: Мир, 2016. - 240 с., ил. Глушаков С.В., Ломотько Д.В. Базы данных, 2000.
- Защита сетевой инфраструктуры предприятия
- Менеджмент человеческих ресурсов (Управление человеческими ресурсами как составная часть менеджмента)
- Кадровая стратегия в системе стратегического управления организацией
- Учет труда и заработной платы
- Проектирование реализации операций бизнес-процесса «Складской учет»
- Архитектура современных компьютеров
- Правовое регулирование качества продукции, работ, услуг (Общая характеристика правового регулирования качества товаров, работ и услуг).
- Право собственности крестьянского (фермерского) хозяйства.
- Счета и двойная запись
- Учет труда и заработной платы (Порядок начисления по листам нетрудоспособности)
- «Учет финансовых результатов и составления отчетности»
- Доказательства трудового стажа (Понятие и значение трудового стажа в праве социального обеспечения)