|
Показатели
|
Значение
|
|
|
|
Доход компании,
млн руб.
|
44,5
|
|
Численность
сотрудников, чел.
|
420
|
|
Количество
заказов, ед.
|
42000
|
|
Количество
клиентов, ед.
|
6500
|
2.
Предпроектное исследование
.1
Описание организационной модели
При создании информационной системы первым этапом работ
является проведение предпроектного обследования предприятия. На этом этапе
производится сбор информации о предприятии, его целях и задачах, структуре и
финансово-хозяйственной деятельности. Также изучаются внешние процессы,
взаимодействующие с предприятием, и среда, в которой предприятие осуществляет
свою деятельность. В результате предпроектного обследования должно быть
сформировано описание организационной структуры предприятия, описание
функционального взаимодействия подразделений предприятия и информационная
схема, содержащая информационные потоки предприятия, места получения и
накопления информации и прочие информационные аспекты деятельности предприятия.
В целом в результате предпроектного обследования должно быть получено
комплексное описание предприятия и его бизнеса.
С широким распространением доступа в интернет, получил
распространение новый вид распространения товаров и услуг. Благодаря интернету
стал доступен любой сегмент потребителя. В настоящее время многие магазины
создают системы интернет-коммерции.
Компания «Март» специализирующаяся на продажах электроники,
бытовой и компьютерной техники изначально построило свой бизнес на
распространение товаров через интернет, снизив за счет этого затраты на
дополнительный персонал и дополнительные офисы продаж. Экономия отразилась на конечной
цене товара для покупателя, цены магазина «Март» значительно ниже
среднерыночных, что и привлекает все большее количество клиентов, даже в
условиях кризиса.
Особую актуальность для компании «Март» в связи с ростом
продаж через интернет приобретает задача автоматизации обработки поступающих
через сайт интернет-магазина заявок, автоматизация выставления счетов на оплату
и приема денежных средств.
Интернет магазин возглавляет руководитель интернет-магазина
(директор) - это ключевой сотрудник Интернет-бизнеса. От его видения зависит
стратегия и тактика развития проекта. Именно он будет набирать персонал,
распределять их зоны ответственности, контролировать эффективность работы
каждого отдела вплоть до сотрудника и вместе со своим персоналом будет добиваться
достижения целей и задач.
Руководитель интернет-магазина должен не только разбираться в
Интернет, но и изначально понимать объемы продаж и перспективную
организационную структуру интернет-магазина в разрезе года, трех и даже пяти
лет.
В обязанности руководителя интернет-магазина входят -
бюджетирование, организация бизнес-процессов, стратегическое планирование,
определение ассортиментной политики, подбор ключевого персонала и контроль
эффективности работы ключевых отделов Интернет-магазина.
Руководитель интернет-магазина несет ответственность за
проект в целом, и за каждое направление, находящееся в его ответственности в
частности. Именно поэтому он должен хорошо ориентироваться, как в основах
IT-технологий, SEO, WEB-дизайне так и в нюансах интернет эквайринга,
особенностях работы контент-менеджеров и логистов.
Бухгалтерия. Несмотря на распространенное представление, о
том, что в Интернете всё бесконтрольно, Интернет-магазин подчиняется всем
принятым законам ведения бухгалтерского учета. Интернет-магазин, как и любой
другой магазин, совершает сделки купли-продажи, сопровождающиеся оформлением
соответствующих документов, а также предоставляет необходимую финансовую
отчетность в контрольные органы.
Юрист. К помощи юриста Интернет-магазины обычно прибегают на более
поздних стадиях, когда критичным становится вопрос взаимодействия с
поставщиками. Обычно это происходит при превышении объема продаж в 500 заказов
в месяц. При таком объеме продаж, уже необходимо иметь небольшой товарный
запас, что требует заключения договоров отсрочки либо договоров с возможностью
возврата нереализованного товара или брака. Таким образом, услуги юриста
становятся необходимыми для снижения таких рисков.
Технический отдел
Программист. В задачи программиста входит - развитие и
поддержка существующих сервисов Интернет-магазина, а также борьба с различными
чрезвычайными ситуациями - отключение сервера, хакерская атака и т.д.
Отдел IT. В задачи IT отдела входит настройка серверов,
периферических компьютеров, АТС, а также настройка бухгалтерской информационной
системы (1С, например). Обычно с этой задачей сложно справиться одному
специалисту, в связи с чем в штат берут нескольких специалистов либо эти услуги
аутсорсят.дизайн. Так же, как и программирование, дизайн сайта постоянно
требует развития. В задачи дизайнера входят - разработка дизайна сайта,
баннеров и рассылок в единой концепции ресурса.
Отдел продвижения(Search Engine
Optimization). Специалисты SEO представляют одну из наиболее значимых служб
Интернет-магазина. Целью SEO-оптимизаторов является увеличение релевантного
трафика и, следовательно, увеличение продаж, посредством оптимизации внутренней
и внешней сред сайта. Фактически SEO-специалисты формулируют конкретные
рекомендации по формированию внутреннего контента (а в некоторых случаях
самостоятельно реализуют их), а также повышают авторитетность контента сайта за
счет размещения ссылок на сайт. Эти ссылки в конечном итоге приводят к
увеличению трафика и продаж. Таким образом, SEO-оптимизаторам удается
сформировать достаточно большой целевой трафик и, следовательно,
продажи.(Social Media Optimization). Это достаточно молодое направление в
Рунете. В этой области обычно работают блогеры и маркетологи, а также люди с
опытом работы в социальных медиа. SMO-продвижение может также строиться через
сотрудников, хорошо знающих товар, целевую аудиторию и, наконец, умеющих
хорошо, интересно. Одним из множества вариантов SMO-продвижения является
ведение корпоративного блога.
Данное направление в настоящее время набирает все большие
обороты. Как известно «вирусный маркетинг» является наиболее эффективным
методом формирования общественного мнения о товаре и бренде в целом, а также
эффективным инструментом продаж, в том числе в Интернет.
Отдел интернет-маркетинга
Интернет-маркетологи это специалисты с опытом классического
маркетинга и продвижения Интернет-ресурсов. В задачи Интернет-маркетолога
входит детальный анализ внешней среды сайта (включая всесторонний анализ сайтов
конкурентов), планирование маркетинговой стратегии развития Интернет-ресурса, планирование
трафика, объема продаж и бюджета продвижения, развитие различных инструментов
стимулирования продаж посредством работы с внешней и внутренней средой сайта и,
наконец, контроль эффективности работы сайта, как с точки зрения Usability, так
и с точки зрения качества контента.
На первый взгляд связь Интернет-маркетолога и Usability сайта
может показаться не совсем понятной. Но на самом деле всё объяснятся тем, что
Интернет-маркетолог - это специалист основным инструментом которого является
статистическая информация по сайту. Маркетолог отслеживает реакцию аудитории
сайта на каждое изменение или добавление новой страницы сайта.
Интернет-маркетолог знает всё о своей аудитории, начиная от того, сколько
человек посетили сайт и приобрели товар, заканчивая тем, почему конкретно они
выполнили то или иное действие на сайте, какая страница сайта интересна
пользователям, какая вызывает негативную реакцию и, наконец, куда клиенты
уходят после посещения сайта.
Интернет-маркетолог должен не только влиять на перемещение
посетителя по ресурсу, но и уметь расставлять различные ловушки, заставляющие
клиента покупать необходимый товар.
Контент-менеджер, специалист, отвечающий непосредственно за
внутреннее содержание сайта. Это одна из ключевых ролей Интернет-магазина, ведь
именно от того, как изложен контент (текст и фотографии) во многом зависит
результат работы Интернет-магазина. Именно контент, в конечном счете, является
магнитом для трафика и одним из ключевых факторов конвертации посетителя
карточки товара в покупателя. Контент-менеджер должен обладать абсолютной
грамотностью и работать строго в соответствии с инструкциями SEO-оптимизатора и
менеджера по продажам. В задачи контент-менеджера входит описание товара и в
соответствии с инструкциями размещение на сайте описаний и фотографий товара. В
зарубежных Интернет-магазинах специалист по контенту считается одним из
ключевых факторов успеха Интернет-магазина. Именно поэтому в большинстве книг
посвященных развитию Amazon.com (один из самых успешных и пожалуй первый известный
на весь мир интернет-магазин) большое значение придается работе
контент-менеджеров и редакторов.
Рис. 3.1. Организационная структура интернет-магазина
2.2
Создание функциональной модели
В настоящее время эффективная работа с платежными системами в
компании налажена недостаточно четко, организация и контроль платежей
осуществляются в ручном режиме. Фактически последовательность действий при
приеме платежа через систему WebMoney на стороне back-офиса интернет-магазина
компании представляется в виде следующей последовательности действий:
- согласование заявки с клиентом;
- согласование способа оплаты заказа через ПИС WebMoney;
оператор сообщает клиенту номер кошелька компании «УлМарт» в
системе WebMoney;
клиент переводит на электронный кошелек компании сумму;
оператор осуществляет контроль поступления денежных средств
на счета компании «Март»;
оператор передает данные по заказу в отдел выполнения
заказов.
Рис. 3.2 - Процесс обработки заказа
Целью работы является повышение эффективности проведения платежей,
поэтому рассмотрим подробнее задачи:
1. Подготовки счета для клиента;
. Контроля оплаты товара.
На стороне клиента в осуществляется выбор товара -
формирование заполненной корзины покупателя в интернет-магазине и ввод данных
заказа (сведения, необходимые для оформления счета на оплату в соответствии с
выбранным методом оплаты и ввод сведений, необходимых для исполнения в
последующем оплаченного заказа: адрес доставки, согласованное время доставки и
т.п., реквизиты получателя товара).
Все данные по заказу в магазине автоматически вносятся в базу
данных, формирование счета может производиться также без участия оператора
сервиса, в автоматическом режиме.
Рис. 3.3 - Декомпозиция задачи «Контроль оплаты товара»
При оплате клиентами счетов через WebMoney данные об этом не поступают в базу данных
интернет-магазина, они становятся доступными лишь в рамках работы с WebMoney Keeper в системе пользователя компании. Это означает, что контроль
поступления денежных средств на кошельки WebMoney Keeper
должен осуществляться операторами интернет-магазина вручную
Также на основании полученных через WebMoney Keeper
данных, операторы должны вводить данные об оплате в базу данных
интернет-магазина, затем в бухгалтерскую систему предприятия и передавать
сведения об исполнении оплаченного заказа в службу доставки. Естественно, что
подобная последовательность работ вызывает задержки при отгрузке, возможны
ошибки при оформлении заказов и при внесении данных в бухгалтерский комплекс
компании.
Другой не менее важной проблемой является оплата счета на стороне
клиента. При оплате счета появляется необходимость самостоятельно открыть на
своем рабочем компьютере WebMoney keeper провести авторизацию в платежной системе
и ввести платежные параметры заказа. Статистика показывает, что именно на этом
этапе многие отказываются от покупки, предпочитая запросить альтернативные
способы оплаты, либо отказаться от покупки.
Данный модуль должен полностью автоматизировать следующую
последовательность операций:
формировать счет на оплату с детализацией пунктов оплаты и прочих
сведений, представляющих интерес для клиента;
при успешной авторизации клиента предлагать ему оплатить
сформированный системой счет;
при оплате счета автоматически передавать сведения об оплате в
базу данных интернет-магазина и информировать оператора сервиса и оператора
отдела доставки об успешной оплате заказа.
2.3
Создание информационной модели
Клиент, входя в систему, наполняет корзину товарами магазина,
заполняет форму заказа, вводит параметры заказа адрес, Ф.И.О., время доставки,
номер электронного кошелька.
Информация о выбранных клиентом товарах хранится в таблице
«корзина», информация о заказе в таблице «заказы».
После совершения операции клиент получает отчет о проведенной
операции, купленные товары, размер списания, остаток на счете и т.д.
Менеджер получает либо сообщение об успешном проведении
платежа и дает заказ в отдел доставки, либо получает сообщение о не выполненном
платеже - операция приостанавливается.
Рис. 3.3 - Информационная модель платежной системы компании
2.4
Определение миссии, выделение критических факторов успеха и проблем предприятия
Миссия - определение перечня текущих и перспективных
направлений деятельности предприятия, выделение приоритетов в стратегии, т.е.
тех основополагающих принципов и норм ведения деятельности, которые будут
определять образ организации в перспективе. Отличительной особенностью миссии
является то, что она должна быть выполнена по истечению определенного периода
времени.
Срок выполнения миссии должен быть обозримым и достаточно
небольшим. Как показывает практика, чаще всего этот срок составляет пять лет.
Делается это для того, чтобы поколение работников, присутствующих при принятии
положения о миссии, могло увидеть результаты своего труда.
Следует различать широкое и узкое понимание миссии.
В широком понимании миссия рассматривается как констатация
философии и предназначения, смысла существования предприятия. Философия
предприятия определяет ценности, верования, принципы, в соответствии с которыми
предприятие намеревается осуществлять свою деятельность. Именно предназначение
определяет действия, которые предприятие намеревается осуществлять, и то,
какого типа предприятием оно намеревается быть. Философия предприятия обычно
редко меняется. Хотя она может меняться, например, со сменой собственника. Что
касается второй части миссии, то она может меняться в зависимости от глубины
изменений, которые могут происходить на предприятии и в среде его
функционирования.
В узком понимании миссия - сформулированное утверждение
относительно того, для чего или по какой причине существует предприятие, т.е.
миссия понимается как утверждение, раскрывающее смысл существования
предприятия, в котором проявляется отличие данного предприятия от ему подобных.
Положение о миссии предприятия является первой ступенью
переосмысления бизнеса. Положение о миссии - выражение видения своего бизнеса,
своей компании. Миссия помогает достичь ясности цели внутри компании, служит
фундаментом для принятия всех важных решений, вносит элемент обязательности при
достижении целей предприятия, приводит к пониманию и поддержке компании во
внешней среде в достижении ее целей.
Самым трудным во всем процессе планирования является
формулирование положения о миссии, осуществляемое на первой ступени работы по
созданию или совершенствованию бизнеса. Делать это нужно до того, как процесс
планирования закончится в целом. Зачастую положение о миссии неоднократно
переписывается, по мере того, как меняются знания о конкурентах и о других
элементах внешней среды. Положение о миссии функционирует как средство
коммуникации, для того чтобы помочь предприятию добиться преимущества перед
конкурентами. Положение передает намерения предприятия, цели и указания людям,
вовлеченным в данный бизнес. Оно действует как катализатор активности каждого,
кто вовлечен в конкретный бизнес:
владелец предприятия;
ключевой менеджмент (люди, занимающие ключевые посты в
бизнесе);
сотрудники. Нужно помочь им понять цели и задачи предприятия
и их роль в достижении этих целей;
поставщики. Необходимо помочь им понять цели данного
предприятия и возможности своего воздействия;
потребители. Следует помочь им понять, на чем фокусируется
конкретное предприятие и что именно они являются сосредоточием усилий.
В современном мире происходят постоянные изменения и
усовершенствования методов продажи товаров покупателю, появляются новые
возможности, традиционные магазины уступают место интернет магазинам.
Исследуемый интернет магазин был создан в первую очередь для
пользователя, для удобства и удовольствия от процесса покупки, быстрого заказа
и получения качественного товара по привлекательным ценам. Мы предлагаем только
качественный товар от ведущих мировых производителей (с гарантией определяемой
производителем).
Преимущества магазина можно охарактеризовать удобством
навигации, возможностью выбора товаров по параметрам (помощь в выборе товаров),
грамотной консультацией специалистов, внимательному отношению к клиентам,
широким ассортиментом.
С целью оптимизации работы и повышения уровня
удовлетворенности клиентов поставлена задача совершенствования системы приема
платежей. Объектом рассмотрения является финансовый учет организации. Далее
выделяем задачу по «Учету и обслуживанию физических лиц». Данная задача
относится к классу задач «Анализа деятельности предприятия» и необходима для
определения текущего состояния и тенденций развития этого предприятия.
Результаты решения данной задачи являются основой для принятия стратегических
управленческих решений. Поэтому задача «Учет и обслуживание физических лиц»
является важной и неотъемлемой частью управленческого анализа хозяйственной
деятельности предприятия.
Приведем подробное описание следующих бизнес - процессов:
Работа с клиентами
Описание бизнес-процесса:
Данный бизнес-процесс включает в себя работу с новыми
клиентами, работу с клиентами, с которыми уже заключены договоры, отправку
информации, а также сбор и анализ документов.
На шаге «PRSA01.01. Выбор клиентов, с которыми заключены
договоры» производится проверка наличия клиентов, с которыми не истекли сроки
заключенных ранее договоров. Клиенты, с которыми имеются действующие договоры,
заносятся в список. По каждому клиенту в списке должна быть отражена следующая
информация:
полное наименование;
контактное лицо (желательно с должностью);
юридический адрес;
контактный адрес;
имя сотрудника, отвечающего за взаимодействие с этим
клиентом;
выбранный информационный канал;
адрес (в выбранном информационном канале).
При выполнении шага «PRSA01.02. Работа с новыми клиентами»
проводится работа с клиентами, а также анализ заключенных ранее договоров. Общий
список должен содержать следующую информацию о клиенте:
полное наименование;
краткое наименование;
юридический адрес;
контактный адрес;
телефон (с кодом страны и города);
список контактных лиц клиента;
имя сотрудника, отвечающего за взаимодействие с этим
клиентом;
дату последнего изменения информации о клиенте;
все существующие адреса клиента (в различных
информационных каналах).
На шаге «PRSA01.03. Ввод новых клиентов в справочник»
происходит ввод информации, полученной при выполнении шага процесса «PRSA01.02
Работа с новыми клиентами».
Затем, на шаге «PRSA01.04. Подготовка сводного списка
клиентов», подготавливается сводный список клиентов, с которыми будет вестись
дальнейшая работа.
Далее на шаге «PRSA01.05. Составление списка клиентов, и работа
с договорами» составляется список клиентов, которые ожидают решения.
Основные участники бизнес-процесса:
Ответственный за работу с клиентами.
Входящее событие процесса:
Необходимость предприятия осуществлять свою основную
деятельность.
Входящие документы бизнес-процесса:
Список клиентов.
Исходящее событие бизнес-процесса:
В результате выполнения процесса должен быть создан
список клиентов.
Исходящие документы бизнес-процесса:
Список клиентов;
Запросы.
При ручном учете каждое подразделение предприятия для
выполнения возложенных на них функций переписывает по существу одни и те же
данные из первичных документов, на основе которых составляются отчетные и
другие выходные документы бухгалтерского, оперативного и статистического учета.
Применение ручной не автоматизированной обработки информации перестало отвечать
современным требованиям. Оно приводит к многократному дублированию информации,
увеличению времени и в конечном итоге стоимости ее обработки.
Главное назначение автоматизированной системы является:
повысить эффективность выполнения основных функций,
поскольку, как можно увидеть, функционирование блока выписки связано с очень
большим документным и информационным потоком;
улучшить оперативность принятия решений;
повысить производительность труда;
снизить количество вычислительных ошибок при помощи
автоматизации процесса обработки информации;
содействовать эффективному и безопасному хранению и доступу к
информации.
Сотрудники более половины рабочего времени затрачивают на
выполнение многочисленных трудоемких учетно-технических операций обработки
информации, связанных с оперативным учетом. Выполнение элементарных процедур
обработки данных не требует специальных знаний. По мере роста объема информации
доля таких работ возрастает. Это ведет к уменьшению времени на выполнение таких
важных творческих работ, как изучение конъюнктуры рынка ценных бумаг.
Массовые, повторяющиеся операции по оформлению, ведению
оперативного учета относятся к числу задач, поддающихся формализации и,
следовательно, автоматизации.
Автоматизация оперативного управления процессами требует
тщательной проработки состава переменной и постоянной информации.
Поэтому для документального обеспечения процесса на
предприятие программа должна создавать (распечатывать) следующие необходимые
документы:
бланк договора;
приходно-кассовые ордера.
Любую операцию заказчик обязан оплатить в установленные
договором сроки, поэтому АС должна осуществлять подсчет суммы долга (денег к
выплате) на текущую дату.
3.
Проектирование информационной системы
3.1
Определение целей и задач информационной системы
Понятие информационного обеспечения возникло с созданием
автоматизированных систем управления (АСУ).
Информационное обеспечение состоит из внутримашинного,
которое включает массивы данных (входные, промежуточные, выходные), программы
для решения задач, и внемашинного, которое включает системы классификации и
кодирования оперативных документов.
Одно из важных требований к информационному обеспечению - это
достоверность данных информационной базы.
Необходимая достоверность данных в информационных базах
обеспечивается высокой степенью контроля на всех стадиях работы с данными.
Особенности технологии обработки данных связаны с такими
факторами, как: функционирование в режиме диалога с пользователем, наличие
накопителей информации, исключение бумажных технологий для обработки
информации.
Благодаря диалоговому режиму отсутствует четко установленная
заранее последовательность операций по обработке данных.
В состав технологических операций входят:
загрузка программы;
ввод данных;
контроль информации и возможность корректировки;
справочно-информационное обслуживание;
формирование информационных массивов;
вывод информации.
Существует несколько способов регистрации первичной
информации:
документальный;
документальный с регистрацией на машинном носителе;
автоматический.
В проекте будет использоваться как первый, так и второй
способы регистрации информации. Ввод, обработка и выдача информации
производятся в диалоговом режиме.
В основе диалогового режима лежит динамическое взаимодействие
машины и человека посредством приема и передачи данных через устройства ввода /
вывода. При диалоговом режиме обеспечивается поиск необходимой информации,
быстрая обработка команд, сообщений, активное воздействие пользователя на ход
обработки данных.
Организация диалога осуществляется посредством установки
связей между данными, которые представляют собой информационные модели.
По способу установления связей между данными различают
реляционную, иерархическую и сетевую модели. Реляционная модель является
простейшей и наиболее привычной формой представления данных в виде таблиц.
Иерархическая и сетевая модели предполагают наличие связей между данными,
имеющими какой-либо общий признак. В иерархической модели такие связи могут
быть отражены в виде дерева-графа, в сетевой возможны связи «всех со всеми».
В настоящее время реляционные системы лучше соответствуют техническим
возможностям персональных компьютеров. Скоростные характеристики этих СУБД
поддерживаются специальными средствами ускоренного доступа к информации -
индексирование баз данных.
Информационное обеспечение - совокупность единой
системы классификации и кодирования информации, унифицированных систем
документации, схем информационных потоков, циркулирующих в организации, а также
методология построения баз данных.
К информационному обеспечению предъявляются следующие общие
требования:
· информационное обеспечение
должно быть достаточным для поддержания всех автоматизируемых функций объекта;
· для кодирования
информации должны использоваться принятые классификаторы;
· для кодирования входной и
выходной информации, которая используется на высшем уровне управления, должны
быть использованы классификаторы этого уровня;
· должна быть обеспечена
совместимость с информационным обеспечением систем, взаимодействующих с
разрабатываемой системой;
· формы документов должны
отвечать требованиям унифицированной системы документации;
· структура документов и
экранных форм должна соответствовать характеристиками терминалов на рабочих
местах конечных пользователей;
· графики формирования и
содержание информационных сообщений, а также используемые аббревиатуры должны
быть общеприняты в этой предметной области;
· в ИС должны быть
предусмотрены средства контроля входной и результатной информации, обновления
данных в информационных массивах, контроля целостности информационной базы,
защиты от несанкционированного доступа.
В состав информационного обеспечения должны входить:
потоки входной информации, к которым относятся сведения о
поступившем товаре, его количестве, наименованиях, дате отгрузки и поступления
на склад и т.д.
потоки выходной информации, к которым можно отнести сведения
о количестве товара, находящегося на складе, дате его выдачи, наименование
получателя, объемы выданного товара и наименование позиций, результаты
проводимых ревизий и так далее.
Алгоритмизация в самом общем виде может быть определена как
процесс направленного действия проектировщика (группы проектировщиков),
необходимый для выработки алгоритмов, достаточных для реализации создаваемого
объекта (системы), удовлетворяющего заданным требованиям. Завершающим этапом
алгоритмизации является выпуск набора алгоритмов, отображающий решения,
принятые проектировщиком, в форме, необходимой для производства объекта
(системы). При проектировании системы я использовала три класса алгоритмов:
1. Алгоритмы, связанные с проектированием АСИС;
2. Алгоритмы реляционной алгебры, необходимые для
работы с БД;
. Алгоритмы расчета необходимых показателей.
Поэтому для компании «Март» актуальной становится задача
разработки и внедрения автоматизированной системы приема платежей клиентов с
использованием ПИС Webmoney, исключающей необходимость введения каких-либо данных
(помимо проведения авторизации) на стороне клиента при совершении сделок.
Данные модуль должен полностью автоматизировать следующую последовательность
операций:
формировать счет на оплату с детализацией пунктов оплаты и
прочих сведений, представляющих интерес для клиента;
автоматически открывать на рабочем компьютере клиента Webmoney Keeper;
при оплате счета автоматически передавать сведения об оплате
в базу данных интернет-магазина и информировать оператора сервиса и оператора
отдела доставки об успешной оплате заказа.
3.2
Оценка степени значимости бизнес-процессов
Для обоснования необходимости использования вычислительной
техники осуществим анализ информационных потоков. Оценка информационных потоков
представлены в таблице 4.1 [7].
Таблица 4.1. Показатели информационных потоков процесса
|
Операции
|
Частота
выполнения в день
|
Затрачиваемое
время, мин на ед.
|
|
Формирование
счета на оплату через ПИС WebMoney
|
» 40
|
4
|
|
Контроль оплаты
заявки через ПИС WebMoney
|
» 30
|
5
|
|
Внесение данных
по оплате в базу данных компании и в бухгалтерскую систему учета и контроля
|
» 15
|
20
|
|
Подготовка
документов на отгрузку оплаченных заявок
|
» 15
|
6
|
|
Отчет по
исполненным заказам с оплатой через ПИС WebMoney
|
» 2
|
20
|
|
Корректировка
внесенных в БД сведений
|
» 2
|
40
3.3
Проектирование баз данных
При проектировании модуля автоматизированного приема платежей
через ПИС WebMoney в основе системы лежит сложившаяся структура интернет-магазина
компании «УлМарт». В основе программного комплекса интернет-магазина
единственным вариантом программирования серверов для придания им динамичности в
настоящее время определен подход, использующий технологию CGI на основе языка PHP. С помощью сценариев для
сервера для организации работы магазина можно получить доступ к файлам, базам
данных и другим ресурсам, хранимым на сервере, а также к централизованным
ресурсам сервера, таким как электронная почта или факс-служба.
Рис. 4.1 - Схема работы интернет-магазина компании «УлМарт»
. Клиент заходит на сайт компании;
. Осуществляется запрос к веб-сервису, на котором физически
расположен сервер магазина;
. Веб-сервис производит идентификацию запроса, и, в
соответствии с настройками, которые были указаны при регистрации, производит
подгрузку прайс-листа, каталогов магазина в динамически формируемую базу
данных;
. На основе этих данных динамически формируются таблицы цен
по секциям магазина и виртуальная корзина товаров клиента.
Виртуальная витрина магазина передаётся веб-сервисом клиенту,
который он и видит на экране своего компьютера.
Интернет-магазин включает разделы:
каталог;
виртуальная корзина;
справочная часть магазина.
Виртуальная покупательская корзинка содержит товары,
добавленные покупателем, позволяет произвести пересчет или удаление товаров и
перейти к окончательным фазам Интернет-продажи. На этом этапе производится
регистрация покупателя и уточнение адреса доставки. В данном проекте применяется
упрощенная схема корзины. Полная схема покупательской корзины включает в себя
возможность заказа товаров одним покупателем на различные адреса и хранение
истории предыдущих покупок и адресов, по которым они были доставлены,
виртуальный кошелек, набор скидок и другие интересные виды сервиса
Интернет-торговли. Упрощенная схема позволяет покупателю заказывать товары и
выбирать адрес доставки. После подключения Интернет-магазина к ПИС WebMoney покупатель сможет
выбирать наиболее удобную для него систему оплаты и оплачивать товар с помощью
платежных ПИС, не отходя от компьютера и даже не покидая страницы сайта
компании «УлМарт».
Теперь определим технологию взаимодействия модуля приема
платежей с серверной системой ПИС WebMoney. Отметим, что могут использоваться только
те технологии, которые официально поддерживаются платежной системой. В
настоящее время существует 3 способа автоматического приема WebMoney на сайте:
· Web Merchant Interface
· Click&Buy Interface
· Выписка WM-счета с последующей проверкой
оплаты. Реализуется с помощью XML-интерфейсов X1 и X3. [20]
Поскольку разрабатывается модуль для крупного
интернет-магазина, он должен обладать функциональной автономностью и допускать
модернизацию и модификацию в соответствии с меняющимися реалиями работы магазина.
По этой причине предпочтительно использовать наиболее технологически сложный,
но и наиболее перспективный подход на основе XML-интерфейсов,
обеспечивающий максимальную масштабируемость системы приема платежей.
Автоматизация приема WM-платежей позволит:
· выполнять заказ моментально после его
оплаты;
· принимать платежи круглосуточно, без
остановок и без ручного участия сотрудников.
Общий принцип работы системы, использующей XML-интерфейсы для
установления связи с платежным сервером системы WebMoney, представлен на рис.
4.2. На сайте интернет-магазина формируется необходимая информацию о заказе
(точка А) и система отправляет ее на адрес автоматизированной обработки
интернет-платежей в системе WebMoney по адресу https://merchant.webmoney.ru (т.н.
Мерчант-сервер). Одновременно с этим и покупатель попадает на этот сайт для
совершения платежа. Мерчант-сервер авторизует покупателя, предлагает выбрать
способ оплаты, проверяет наличие нужной суммы на кошельке или WM-карте, т.е.
проводит ряд необходимых идентификаций и проверок. После этого Мерчант-сервер
списывает WM с кошелька или карты покупателя. В тот же момент уплаченная сумма
поступает на кошелек компании «Март».
Таким образом, при осуществлении контроля платежей по заказам
нет необходимости проверять кошелек компании «Март», чтобы узнать, поступил
платеж, или нет. Это делает единожды созданный робот. Всё работает
автоматически, беспрерывно и без участия персонала.
Рис. 4.2 - Схема взаимодействия сайта с Мерчант-сервером
3.3.1
Характеристика базы данных
На рис. 4.3 представлена схема логической структуры БД
платежной системы компании «Март» [4].
Рис. 4.3 - Схема логической структуры БД платежной системы
компании «Март»
3.3.2
Характеристика результатной информации
Результатными документами системы являются три формы:
. Отчет о проведенной операции;
. Сообщение о выполненном платеже;
. Сообщение о невыполненном платеже.
Внешний вид форм приведен на рис. 4.4-4.6.
Рис. 4.4 - Отчет о проведенной операции
Рис. 4.5 - Сообщение о выполненном платеже
Рис. 4.6 - Сообщение о невыполненном платеже
3.4
Проектирование интерфейса системы
Схема технологического процесса обработки информации
представлена на рис. 4.7 [12].
Рис. 4.7 - Схема технологического процесса обработки
информации платежной системы
При открытии базы данных на экран в первую очередь выводится
главная форма базы данных, с помощью которой и производится в дальнейшем управление
базой данных.
4.
Реализация алгоритма работы программы
Дерево функций платежной системы компании «Март» приведено на
рис. 5.1 [16].
Рис. 5.1 - Дерево функций платежной системы компании «Март»
Программный модуль автоматизированного приема платежей в
интернет-магазине компании «Март» состоит из трёх взаимосвязанных, совместно
работающих блоков:
. Блок генерации и формирования базы данных
в корне комплекса за инициализацию этого блока и управление
им отвечает скрипт inst.php, а скрипты второго уровня расположены в папке Admin.
admin.php - скрипт администрирования базы данных
goodcreate.php - скрипт, реализующий в выбранной категории
(подкатегории) информационный блок о новой товарной позиции,
proizvodcreate.php - скрипт, создающий в базе данных произвольно
глубоко расположенные подкатегории. Ввиду важности этого элемента программного
комплекса исходный скрипт файла proizvodcreate.php вынесен в Приложение 5.
catcreate.php - скрипт, создающий новую категорию в базе
данных,
Все настойки по работе с базой данных SQL (пароли, сервера и т.п.)
внесены в файлы config.inc, cnfadm.inc и config1.inc, образующие отдельную папку cfg.
. Блок работы с бизнес-кодом, т.е. та часть программы,
которая отвечает за создание HTML-кодов страниц, передаваемых в браузер
посетителей магазина при подготовке счетов для оплаты и при оплате выбранного
комплекса товарных позиций.
Практически весь этот блок умещается в следующие скрипты:
index.php
order.php - непосредственно реализует просмотр каталога
товаров в браузере клиента, выбор товара, заказ, получение подтверждения
(резервирование), получение счета.
. Блок Back-офиса, обеспечивающий для персонала компании
«УлМарт» работу с содержимым базы данных и изменение бизнес-кода программного
модуля автоматизированного приема платежей через ПИС WebMoney. В свою очередь, back-офис программного
комплекса состоит из трех логических подблоков: подблока внесения редакционных
изменений в содержание базы данных, подблока контроля поступления платежей по
счетам и подблока работы с клиентами. Первый подблок образуют следующие
скрипты:
catedit.php - скрипт, реализующий внесение изменений в
выбранную категорию в базе данных,
proizvodedit.php - скрипт, реализующий внесение изменений в
описание выбранной подкатегории (сколь угодно глубоко расположенной),
goodedit.php - скрипт, реализующий редактирование информации
о выбранном товаре.
Второй подблок организован на основе скрипта news.php, обеспечивающего
возможность контроля новых поступлений на WM-кошелек компании
«УлМарт».
Третий подблок включает в себя следующие программные модули:
archive.php - учет всех параметров по работе с клиентом,
ведение журнала посещений системы
akkaunt.php - поддержка мультисессионности при работе с
клиентом, что позволяет исключить использование kookies на стороне клиента, а
это было отдельно было оговорено при составлении технического задания на
разработку.
sendpassw.php - идентификация ранее авторизованных
пользователей интернет-магазина, что позволяет организовывать безопасный вход в
административный интерфейс при работе с удаленного компьютера.
5.
Обоснование набора тестов
При разработке программного обеспечения модульное
тестирование играет ключевую роль в обеспечении должного уровня качества и
выполнении контрольных задач. Хотя основная часть разработчиков согласна с тем,
что модульные тесты важны, многие из них не уделяют времени написанию модульных
тестов в конце цикла разработки продукта. Для решения этой проблемы и была
задумана методология разработки через тестирование (TDD). Использующие эту
методологию разработчики пишут модульные тесты для отдельных компонентов до
реального применения этих компонентов. Этот процесс позволяет разработчику
«вывернуть наизнанку» интерфейс API и рассмотреть его внутренние процессы, что
позволяет упростить проект настолько, насколько возможно.
Сегодня многие разработчики, работающие в C# и Visual Basic,
следуют методологии TDD, создавая модульные тесты для проверки методов на еще
не написанных классах и затем применяя необходимый для компиляции теста минимум
кода. После того как тест скомпилирован и дал негативный результат, разработчик
пишет только код, необходимый для его успешного прохождения в следующий раз.
При каждом цикле модульные тесты запускаются снова, чтобы убедиться в отсутствии
возвратных ошибок. Затем код приложения и модульного теста регистрируется в
системе контроля исходного кода. Разрабатываемый метод проверяется минимум
дважды каждым из модульных тестов.
Чтобы быть полезным, модульное тестирование должно
устанавливать собственную среду выполнения перед применением, чтобы иметь
последовательно проверять возможность код, который следует протестировать.
После того как тест реализован и проверен, он регистрируется в системе контроля
исходного кода, и его результаты будут использованы в течении остатка
жизненного цикла продукта, чтобы обеспечить требуемое поведение метода.
1. Получите новейшие проекты тестов и баз данных от
системы контроля исходного кода и добавьте новую хранимую процедуру к проекту
базы данных. Настройте параметры ввода и вывода процедуры.
2. Щелкните новую хранимую процедуру правой кнопкой
мыши и выберите «создать модульные тесты». Добавьте модульный тест к
существующему проекту теста. Новый тестовый класс добавляется к проекту теста с
использованием T-SQL, который исполнит новую хранимую процедуру с параметрами
ввода по умолчанию.
. Измените параметры ввода, чтобы они содержали
ожидаемые значения, и добавьте тестовое условие, чтобы убедиться в возвращении
ожидаемых результатов хранимой процедурой.
. Выполните тест. В ходе установки теста проект базы
данных развертывается на локальном экземпляре SQL Server, при этом исполняется
план автоматического создания данных для заполнения свежеразвернутой базы
ожидаемыми тестовыми данными. Тест выполняется на локальном экземпляре SQL
Server и дает отрицательный результат (что ожидаемое, поскольку логика хранимой
процедуры еще не применена).
. Реализуйте логику хранимой процедуры и запустите
тест снова. Обновленная хранимая процедура развертывается, и тест проходит
успешно.
. Выполните все тесты для проверки базы данных, затем
добавьте хранимую процедуру и код модульного теста в систему контроля исходного
кода.
В число возможностей, предоставляемые DBPro, входят
следующие: создание модульных тестов-заглушек T-SQL из существующих функций,
хранимых процедур или триггеров, автоматическое развертывание обновлений проекта
базы данных в локальном экземпляре «песочницы», создание данных в качестве
части установки тестовой среды с использованием плана автоматического создания
данных и исполнение тестов T-SQL на целевой базе данных. Хотя эти возможности
можно использовать вместе, это не обязательно. Например, модульный тест базы
данных можно написать с нуля, а автоматическое создание данных не обязательно
исполнять перед каждым запуском теста.
Функция модульного тестирования баз данных отражает две
отчасти конкурирующие цели: стремление разработчика базы данных использовать
знакомые сценарии T-SQL для выражения логики модульного теста и желание
воспользоваться широкими возможностями языков, предназначенных для
Microsoft®.NET Framework, таких как C# или Visual Basic. Противоречие между
этим целями разрешается путем инкапсулирования теста в код T-SQL и затем
размещения T-SQL в коде C# или Visual Basic.NET. Конструктор модульных тестов
создает и то, и другое, позволяя изменять любую процедуру (или обе) под
конкретные нужды.
Модульное тестирование баз данных с помощью Team System
предоставляет или поддерживает все функции, которые только может пожелать
разработчик среды тестирования баз данных. При этом необходима возможность
исполнения теста в правильном контексте. Например, необходимо использовать
учетные данные, которые будет использовать уровень сети при подключении к базе
данных, или иметь возможность использовать иной набор учетных данных для
доступа к базовым таблицам или их изменения до или после исполнения теста.
Полезны также возможности выполнить сценарий до и после каждого теста в группе
тестов, для установки или сброса состояния базы данных и выполнить сценарий
(для отдельного теста) до и после теста для установки или сброса состояния базы
данных.
Наконец, желательно иметь возможности расширения доступных
тестовых условий путем добавления условий, специфичных для существующей базы
данных, использования транзакций для контроля изменений в состоянии базы данных
и использования данных для управления многократными выполнениями теста с
различными параметрами ввода и вывода. В некоторых случаях для использования
этих возможностей необходим дополнительный код. Давайте посмотрим, к чему это
ведет.
С точки зрения кода, модульное тестирование баз данных
создает код на C# или Visual Basic.NET, предназначенный для среды модульного
тестирования в Visual Studio. В среде модульного тестирования класс
используется как контейнер для размещения тестов (каждый тест определен как
метод). В конструкторе модельного тестирования имеется ряд возможностей по
добавлению сценариев для поддержки описанных мной функций сценариев. Все
сценарии, за исключением тестовых сценариев, исполняются с использованием
привилегированного контекста, поскольку они предназначены для установки или
проверки тестовой среды. Сценарий будет исполнен один или несколько раз в
зависимости от того, где он добавлен, так что давайте взглянем более
внимательно на сценарии и на то, как они исполняются (см. табл. 6.1).
Таблица 6.1
|
Сценарий
|
Исполнение
|
|
Инициализация
теста
|
Этот сценарий
T-SQL используется для подготовки тестовой среды перед исполнением каждого
теста. Он исполняется перед каждым тестом в классе.
|
|
Предтестовая
настройка
|
Настройка перед
исполнением конкретного теста. Предтестовый сценарий доступен для выполнения
действия настройки для теста или проверки того, что база данных находится в
подходящем для теста состоянии.
|
|
Тест
|
Сам тест
|
|
Послетестовая
очистка
|
Очистка после
выполнения конкретного теста. Предоставляется послетестовый сценарий,
позволяющий восстановить или проверить состояние базы данных.
|
|
Тестовая
очистка
|
Этот сценарий
T-SQL используется для восстановления тестовой среды после исполнения теста.
Он исполняется после каждого теста.
|
Заключение
Итак, целью данной работы являлось повышении эффективности
обработки заказов интернет-магазина компании «Март» путем разработки
программного модуля автоматизированного приема платежей.
В первой главе настоящей курсовой работы были рассмотрены
следующие вопросы:
. Приведена общая характеристика компании «Март» и ее
деятельности.
. Проведен анализ существующей системы работы
интернет-магазина компании «Март».
. Выявлены недостатки в организации системы платежей и
отгрузки товаров, заключающейся в высокой трудоемкости задачи контроля оплаты
товара через ПИС и внесения информации в БД компании.
. Определенна миссия компании и критические факторы влияющие
на реализацию данной миссии.
Для решения существующих проблем было проведено
проектирование и разработка платежной системы компании «Март».
В проектной части курсовой работы были решены следующие
вопросы:
проведено проектирование информационной и даталогической
моделей программного модуля автоматического приема электронных платежей,
описание входных, нормативно справочных и результатных информационных массивов
функционирования модуля.
построена технологическая схема взаимодействия программных
модулей и блоков платежной системы компании «Март».
разработана технологическая схема процесса сбора, передачи,
обработки и выдачи информации.
Таким образом, задачи курсового проектирования можно считать
выполненными, а цель курсового проектирования достигнутой.
Список
литературы
1. ГОСТ
2.105-95. Единая система конструкторской документации. Общие требования. -
Взамен ГОСТ 2.105-79, ГОСТ 2.906-71. Введ. 1.07.96.-М.: ИПК Издательство
стандартов, 1996.-36 с.
2. ГОСТ
19.791-01 (ИСО 5807-85). Единая система программной документации. Схемы
алгоритмов, программ, данных и систем. Условные обозначения и правила
выполнения. - Взамен ГОСТ 19.002-80, ГОСТ 19.003-80. Введ. 1.01.01. - М.: ИПК
Издательство стандартов, 2001.-26 с.
. Аткинсон Л.
MySQL. Библиотека профессионала, М., Изд-во O’Reilly, 2009, 316 стр.
. Атре
Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика,
2008. - 320 с.
. Атре
Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика,
2008. - 320 с.
. Балабанов
И.Т. - Торговля через виртуальный магазин / «Электронная коммерция»/ 2010 г. С.
195-197
. Баронов
В.В. Автоматизация управления предприятием. - М.: ИНФРА-М, 2010. - 239 с., стр.
218
. Благодатских
В.А. Экономика, разработка и использование программного обеспечения ЭВМ:
Учебник.-М.: Финансы и статистика, 2009. - 288 с.
. Васкевич
Д. Стратегии клиент / сервер. - К: «Диалектика», 2011, 244
стр.
. Григоренко
Г.П., Данелян Т.Я. Системы автоматизированной обработки экономической
информации (САОЭИ): Учебное пособие / Моск. эконом. - стат. ин-т. - М.,
2007-126 с.
. Гурвиц
Г.А. Разработка приложения в среде клиент-сервер, ДВГУПС 2006, 204 с.
. Иванцов
А.А., Серегин С.П., Программирование интерфейсов под Windows, DHV, СПб, 2008,
214 стр.
. Имери
В. Бизнес в Internet - технологические аспекты. - К.; М.; СПб., 2009. - 336
стр.
. Информационные
Системы в экономике: Учебник / Под ред. проф. В.В. Дика - Москва.:Финансы и
Статистика, 1996. - 340 стр.: ил.
. Карминский
А.М., Нестеров П.В. Информатизация бизнеса. - М.: Финансы и статистика, 2007. -
416 с.: ил.
. Куницына
Л.Е. Информационные технологии и системы в экономике: Методический комплекс. -
Ростов-на-Дону: РГЭА, 2008.-175 с.
Похожие работы на - Разработка платежной системы для компании 'Март'
|