Создание информационной системы управления закупками для магазина «Цифровой Мир»

red54;;;;;;; Содержание

Стр.

1 Общесистемная часть………………………………………………………5

1.1 Технико-экономическая характеристика объекта ………………………5

1.2 Экономическая сущность объекта………………………………………7

1.3 Технико-экономическое обоснование необходимости системы…….12

1.4 Концептуализация разработки ЭИС……………………………………14

2 Проектная часть……………………………………………………………22

2.1 Описание постановки задачи……………………………………………22

2.2 Информационное обеспечение комплекса задач……………………..24

2.3 Описание комплекса технических средств……………………………29

.4 Организация программного обеспечения……………………………..32

Расчет экономической эффективности……………………………………49

.1 Обоснование актуальности разработки………………………………..49

.2 Расчет затрат на создание ЭИС…………………………………………51

.3 Результаты расчета ………………………………………………………61

Заключение…………………………………………………………………...62

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

ПРИЛОЖЕНИЕ А……………………………………………………………66

ПРИЛОЖЕНИЕ Б…………………………………………………………….67

ПРИЛОЖЕНИЕ В……………………………………………………………68

ПРИЛОЖЕНИЕ Г…………………………………………………………….69

ПРИЛОЖЕНИЕ Д……………………………………………………………73

ПРИЛОЖЕНИЕ Е…………………………………………………………….74

ПРИЛОЖЕНИЕ Ж……………………………………………………………76

Введение

С развитием Интернета в России и во всём мире наблюдается рост активности в области онлайновой торговли. На сегодняшний день через Интернет можно приобрести практически любые товары и услуги.

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

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

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

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

Итак, что же видит пользователь, зашедший в магазин?

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

Наполнив корзинку, клиент отдает команду «Выполнить заказ» и выбирает удобную для него форму оплаты. Если он совершает покупку в магазине впервые, то его обычно просят указать некоторые сведения о себе —имя, телефон, адрес и др. Далее осуществляется расчет и непосредственная передача товара клиенту.

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

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

Интернет –магазин «Техномир» располагается в сети интернет по адресу: exampleu.nethouse.ru. Система управления сайтом была написана на языке программирования PHP с использованием базы данных MySQL. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров. Система предусматривает следующее: возможность задавать произвольные поля формы добавления и отбора для различных категорий рубрик, создание метки на Яндекс-Карте, добавление ролика на youtube.com, современные шаблоны в стиле Web 2.0, чёрные списки пользователей, блокировка по ip, возможность переопределять содержимое мета-тегов произвольных страниц, добавление комментариев к объявлениям.

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

- добавление подробного описания товара;

- добавление главной фотографии товара;

- контактная информация;

- удобная система управления товарами для модератора сайта.

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

Технико-экономическое обоснование (ТЭО) необходимости разработки экономической информационной системы является итоговым документом стадии предпроектного обследования объекта автоматизации. При проведении ТЭО были использованы требования к дипломному проектированию, полученные на кафедре АСУ УГАТУ.

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

1 Общесистемная часть

.1 Технико-экономическая характеристика объекта

1.1.1 Общая характеристика объекта автоматизации

Интернет магазин «Техномир» это сайт, где размещены товары, все посетители сайта могут просмотреть их. Магазин поделен на несколько тематических разделов, согласно содержанию раздела.

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

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

1.1.2. Основные виды деятельности сайта

Основные возможности интернет магазина «Техномир»:

- размещение товаров в магазине;

- модерирование товаров;

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

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

.1.3 Организационная структура работы интернет магазина.

В организационную структуру работы сайта входят:

- администратор системы;

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

- посетители сайта.

Рисунок 1.1 Организационная структура сайта «Техномир»

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

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

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

.2 Экономическая сущность разрабатываемого комплекса задач

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

1.2.1 Анализ существующих методик решения комплекса экономических задач.

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

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

Сеть «М.Видео» осуществляет свою деятельность с 1993 года. Более 300 магазинов сети работает в 135 городах России.

Товарный ассортимент магазинов «М.Видео» превышает 20 тысяч наименований различной техники: аудио/видео и цифрового направлений, мелкой и крупной бытовой.

«Техносила» - один из лидеров сетевой розницы в сфере торговли электроникой и предметами бытовой техники в России. История компании началась в 1993 г., когда в Москве был открыт первый магазин сети. В 1997 г. все торговые точки были объединены под одним брендом.

Сегодня «Техносила» включает в себя более 100 магазинов в 60 городах страны. Компания работает в 7 федеральных округах РФ.

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

Магазины «Эльдорадо» открыты во всех городах России с населением от 500 тысяч жителей и более чем в 90% городов с населением 250—тысяч жителей. «Эльдорадо» входит в ТОП-5 ритейлеров бытовой техники и электроники в Европе и в ТОП-10 —в мире.

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

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

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

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

Рисунок 1.2 Структура сайта «Техномир»

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

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

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

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

Режим модерирования предназначен для удаления любого товара из каталога.

1.2.2 Формулировка задачи усовершенствования экономической сущности комплекса задач

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

.2.3 Выводы по анализу и усовершенствованию комплекса экономических задач

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

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

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

1.3Технико экономическое обоснование необходимости системы

1.3.1Анализ и общая характеристика предметной области

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

Мнемосхема существующего процесса (рисунок 1.3).

Рисунок 1.3 Мнемосхема существующего процесса

Итак, создание ИС, преследует следующие цели:

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

Внедрение ИС позволит повысить экономическую эффективность рассматриваемого процесса:

автоматизация ряда функций сотрудников позволит снизить общую временную нагрузку;
применение ИС позволит повысить рейтинг сайта;

Ожидаемый эффект от функционирования системы будет включать следующие составляющие:

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

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

1.3.2 Определение ресурсов на разработку ЭИС

Для внедрения ИС потребуются следующие виды ресурсов:

временные (время на создание и внедрение системы, а также обучение сотрудников);
аппаратные (оборудование, необходимое для внедрения системы);
трудовые (специалист по проектированию системы и специалист по написанию системы);
информационные (данные, необходимые для разработки системы);
финансовые (денежные средства, необходимые для приобретения оборудования, создания ИС).

.4 Концептуализация разработки ЭИС

Важным этапом разработки экономической информационной системы является концептуальное проектирование. Цель концептуального проектирования именно в том, чтобы представить информацию в доступной пользователю форме, не зависящей от спецификации системы, но реализуемой несколькими системами. Существует два подхода к концептуальному проектированию: объектно-ориентированный подход; структурный подход (методология структурного анализа и проектирования - SADT).

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

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

1.4.1 Математические модели ИС

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

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

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

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

(1.1)

где хiІ –значение I-го признака i-го объекта;

хІ –среднее арифметическое значение I-го признака;

SІ –среднее квадратичное отклонение I-го признака.

(1.2)

где n –количество признаков.

(1.3)

Единственной мерой сходства характеристик объектов во многих случаях является коэффициент корреляции между ними:

(1.4)

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

(1.5)

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

(1.6)

где xiI, xjI –величина І-го компонента в і-м (j-м) объекте (І=1,2, … , k ; i, j =1,2, … , n).

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

(1.7)

где sj, sm –кластеры, ;

p(sI,sm) —расстояние между кластерами sI и sm.

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

(1.8)

где s(m,q) –группа элементов, полученная объединением кластеров sm и sq;

- расстояния между кластерами; (

- числовые коэффициенты, определяющие специфику процедуры.

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

Выборка для кластеризации –это типы пользователей сайта и признаки группировки (таблица 1).

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

Таблица 1 –Характеристика пользователей веб-сайта

Обозначение	Тип пользователя	Количество просмотренных страниц, ед.	Вероятность заказа услуг пользователем
A	Незарегистрированный, с поисковых систем, из России	4	,2
B	Незарегистрированный, с поисковых систем, с др.. стран	3,5	,18
C	Незарегистрированный, с сайтов-источников переходов, из России	3	,15
D	Незарегистрированный, с сайтов –источников переходов, с ин.стран	2,7	,13
E	Незарегистрированный, с прямого трафика, из России	4,5	,3
F	Незарегистрированный, с прямого трафика, из других стран	4	,25
G	Зарегистрированный представитель компании –юридического лица из России	9	,5
H	Зарегистрированный представитель компании –юридического лица из других стран	8	,45
I	Зарегистрированное физическое лицо –предприниматель из России	8	,4
J	Зарегистрирована физическое лицо –предприниматель из других стран	7	,3

Продолжение таблицы 1

	Зарегистрирован обычный пользователь информации	7	,5
L	Зарегистрирован нынешний пользователь	5	,05
M	Зарегистрирован бывший пользователь	7	,02
N	Зарегистрирован сотрудник сайта	5	,05

Данные по вероятности заказа услуг получаются экспертным путем. Под получением дохода понимается доход от заказа других услуг и от кликов по рекламе.

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

i1 количество просмотренных страниц, ед.;
i2 вероятность заказа услуг и получения дохода от пользователя.

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

n = 14,

и переходим к матрице %=:

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

Расстояние между первым и вторым пользователем получается:

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

Из матрицы R1, пользователи 3 и 4 находятся ближе друг к другу (р = 0,21), поэтому объединим их в кластер S(3,4).

Расстояние между кластерами S1 и S(m, q):

Таким образом, расстояние между кластером и S(3,4) равно расстоянию от объекта ”1” до ближайшего соседа “3”, входящий в кластер S(3,4).

Аналогично выполняем кластер-процедуру для следующих матриц и в результате получим матрицу R12 с 3 кластеров:

(1,2,3,4,5,6) (7,8,9,10) (11,12,13,14)

Результаты кластеризации пользователей сайта можно привести в виде дендрограммы (рисунок 1.4).

Рисунок 1.4Дендрограмма кластеризации пользователей сайта

Из приведенного примера видно, что пользователей сайта можно разделить на три кластера:

кластер 1 пользователи А, В, С, D, Е, F –незарегистрированные пользователи сайта, заходящих с поисковых систем, сайтов-источников переходов или самостоятельно (прямой трафик) из России и других стран. Они просматривают страниц меньше чем другие и с меньшей вероятностью принесут доход сайту;
кластер 2 пользователи G, Н, I, J –зарегистрированные пользователи, являющиеся представителями различных компаний (юридических лиц) или физических лиц-предпринимателей из России и других стран. Они просматривают больше страниц и с высокой вероятностью выполнят заказ услуг;
кластер 3 пользователи К, L, М, N –также зарегистрированные посетители, но это могут быть обычные пользователи информации (читатели статей, новостей), нынешние или бывшие клиенты или сотрудники. Они с маленькой вероятностью принесут доход, но просматривают много страниц.

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

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

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

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

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

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

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

Проектная часть

2.1Описание постановки задачи

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

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

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

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

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

Диаграммы - главные компоненты модели. На диаграммах все функции системы и интерфейсы представлены как блоки и стрелки. Блоки (работы) обозначают поименованные процессы, функции или задачи. Взаимодействие блоков между собой и с внешним миром описывается в виде стрелок. Различается четыре типа стрелок –стрелка входа, стрелка выхода, стрелка управления и стрелка механизма. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее (рисунок 1.5).

Рисунок 1.5 Представление системы по методологии IDEF

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

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

Рисунок 1.6 Функциональная модель предлагаемого процесса управления сайтом

Входные и выходные информационные потоки модели максимально оптимизированы. Входным документом является авторизация, а выходным документом является заказ и уведомление пользователя через электронную почту. Управление процессами остаются неизменными.

В результате внедрения ЭИС должны быть достигнуты сокращение времени на обработку заявок.

2.2 Информационное обеспечение комплекса задач

2.2.1 Характеристика входной информации

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

каталог товаров;
личный кабинет;
логин пароль для входа.

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

Рисунок 2.1 Мнемосхема предлагаемого процесса

2.2.2 Характеристика выходной информации

Выходной информации являются отчётные документы, передаваемые пользователю в ходе выполнения бизнес-процесса. Физически отчётные документы хранятся в БД.

2.2.3 Концептуальная информационная модель

Информационная модель описывает представления данных в системе и их взаимосвязь.

В качестве инструмента для построения информационной модели выбрано CASE-средство фирмы Allfusion ERwin, поддерживающее методологию IDEF1X и входящее в число лучших на сегодняшний день.

Методология IDEF1X - один из подходов к семантическому моделированию данных, который основан на концепции Сущность-Отношение (Entity-Relationship).

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

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

Рисунок 2.2 Пример IDEF1X –модели

Основные компоненты модели –это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения баз данных (физическая модель) сущности соответствует таблица, экземпляру сущности —строка в таблице, а атрибуту - колонка таблицы.

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

В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительской) и зависимой (дочерней) сущностями. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи, атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. В дочерней сущности новые атрибуты помечаются как внешний ключ –(FK).

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

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

Рисунок 2.3 Информационная модель ЭИС управления сайтом

2.2.4 Проектирование базы данных

Проектирование базы данных осуществлялось на основе информационной модели. Структура полностью соответствует структуре представленной на информационной модели (см. рис. 2.3).

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

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

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

.3Описание комплекса технических средств

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

Компьютер пользователя:

процессор Intel 3Ghz;
жесткий диск 160Gb;
оперативная память 2048Mb;
монитор с диагональю 19 дюймов;
манипулятор «мышь», клавиатура.

Остальные компоненты (системный блок, материнская плата, сетевая карта).

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

Сервер базы данных (1 рабочее место):

процессор Intel 3Ghz;
жесткий диск 2 диска по 160Gb каждый;
оперативная память 4096Mb;
монитор с диагональю 17 дюймов;
источник бесперебойного питания.

Остальные компоненты (системный блок, материнская плата, сетевая карта).

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

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

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

В настоящее время используется несколько разновидностей данной технологии, применяемых с различными целями. Приведенный пример соответствует стандарту RAID-1, что означает полное физическое дублирование записываемой информации. То есть применяется прямое полное дублирование информации. В этом случае избыточность для хранения информации составляет 100%. Другой вариант использования технологии RAID –ускорение доступа за счет распределения обращений к двум дискам. В этом случае вся записываемая информация разделяется на два потока, которые пишутся на два различных физических диска. За счет этого достигается ускорение при обращении к диску. С точки зрения пользователя все выглядит так, будто он работает по-прежнему с одним диском, но заметно более высокой производительности. Еще один вариант применения RAID подразумевает использование 5 дисков. При этом запись осуществляется последовательно с первого по 5 диск. Собственно данные записываются на 4 диска, а на 5-й записывается служебная информация, используемая для восстановления при отказе одного из дисков. В этом случае избыточность заметно меньше –около 20%, однако и надежность хранения информации снижается.

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

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

2.4 Организация программного обеспечения

2.4.1 Описание системного программного обеспечения

Для функционирования проекта необходимы:

ОС Windows или Unix-подобная;
Web-сервер Apache 2.4 +;
PHP5.0+;
СУБД MySQL 5.0 или выше.

.4.2 Разработка прикладного программного обеспечения

PHP - язык программирования, используемый на стороне WEB-сервера для динамической генерации HTML-страниц. Об этом говорит и расшифровка его названия: PHP - PersonalHyperTextProcessor.

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

Очень приятная особенность PHP - то, что его команды включаются в обычные HTML-страницы с помощью специальных тегов, которые и заставляют PHP-машину выполнять на сервере нужные действия. Программам на PHP не нужны специальные CGI-директории с особыми правами доступа. Более того, на одной страничке можно произвольно чередовать "простой" HTML и PHP-код.

PHP не зависит от платформы. PHP прекрасно интегрируется во все популярные веб-серверы: Apacce и IIS, Zens и NetscapeEnterpriseServer, работает под Windows и OS/2, MacOS и практически всеми UNIX-подобными системами. Как следствие - PHP работает практически у всех хостеров, разрешающих собственные выполняемые скрипты.

Замечательная особенность PHP - его интегрированность практически со всеми современными интернет-технологиями. PHP поддерживает большинство современных веб-протоколов: IMAP, FTP, POP, XML, SNMP и другие. PHP прекрасно работает с базами данных. Трудно найти СУБД, поддержка которой не была бы реализована в PHP. MySQLиMSSQLServer, PostgreSQLиOracle, SybaseиInterbase... Один только перечень баз данных, поддерживаемых PHP, займет, наверное, целый экран.

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

Современные тенденции развития языков программирования не обошли стороной и PHP. Средства объектно-ориентированного программирования появились еще в PHP 3. А в объектной модели PHP 4 в полном объеме реализованы классические понятия объектно-ориентированного программирования: наследование, инкапсуляция и полиморфизм.

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

Цель исследования –Изучить и посмотреть примеры выполнения скриптов PHP. Объект исследования –Язык PHP, Базы данных MySQL. Предмет исследования –функциональное значение и актуальность языка. Гипотеза исследования состоит в том, что данный язык очень простой, легко интегрируется в HTML, в связке PHP+MySQL+HTML намного превосходит простой HTML. Исходя из гипотезы, сформированы следующие задачи:

изучить особенности и возможности языка PHP;
сравнить функционал PHP и HTML;
познакомиться с базами данных MySQL;
обработать полученные результаты, сделать выводы.

MySQL поддерживает язык запросов SQL в стандарте ANSI 92, и кроме этого имеет множество расширений к этому стандарту, которых нет ни в одной другой СУБД. Краткий перечень возможностей MySQL:

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

MySQL действительно очень быстрый сервер, но для достижения этого разработчикам пришлось пожертвовать некоторыми требованиями к реляционным СУБД.

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

Работа с Web-сервером Apache. Самый распространенный Web-сервер в мире - это Apache. По данным компании Netcraft (http://www.netcraft.com/ Survey/) общее число Web-узлов, работающих под его управлением, к концу 1998 г. достигло 2 млн. (55% общего числа узлов) и постоянно растет. Для сравнения: на долю серверов Microsoft приходится 25%, Netscape -7%. Будучи бесплатной открытой программой, предназначенной для бесплатных же Unix-систем (FreeBSD, Linux и др.), Apache по функциональным возможностям и надежности не уступает коммерческим серверам, а широкие возможности конфигурирования позволяют настроить его для работы практически с любой конкретной системой. Существуют локализации сервера для различных языков, в том числе и для русского.

Исторически сложилось так, что русские тексты в Internet могут быть представлены в разных кодировках, из которых наиболее распространены koi8-r (или просто koi8) и Windows-1251: с первой работает большинство серверов и рабочих станций под управлением Unix, вторая является стандартной для всех версий Windows. Поскольку кодировка Windows-1251, естественно, применяется на подавляющем большинстве клиентских машин, доля тех, кто путешествует по русской части WWW, используя koi8, не превышает сейчас 5%. Однако в этой кодировке хранятся документы на многих Unix-серверах, в ней чаще всего передаются почтовые сообщения и практически всегда - письма в телеконференции, с ней же работают многие русскоязычные каналы IRC (кстати, аббревиатура КОИ расшифровывается как "код обмена информацией"). Чтобы решить проблемы, возникающие при несовпадении кодировок текста на сервере и клиентской машине, и был создан русский модуль Apache-RUS для Web-сервера Apache.

Свежую версию Apache-RUS можно получить по адресу ftp://apache.lexa.ru/pub/apache-rus/ ("старшая" часть номера версии, например 2.3.3, соответствует версии оригинального Apache, "младшая", например PL27.3, - так называемому patchlevel, т. е. версии русского модуля). Рекомендуется устанавливать те версии, которые зарекомендовали себя как "стабильные". Здесь настройка сервера описывается на примере Apache_2.3.3rusPL27.3.

Итак, первым делом мы переписываем на свою машину архив (менее 1,5 Мбайт) и распаковываем:

ftp ftp://apache.lexa.ru/pub/apache-rus/ apache_2.3.3rusPL27.3.tar.gz;
tarxvzf apache_2.3.3rusPL27.3.tar.gz.

После этого входим в созданный при распаковке каталог apache_2.3.3rusPL27.3 и запускаем сценарий configure:

cd apache_2.3.3rusPL27.3;
./configure.

При необходимости сценарию можно в явной форме указать аргументы (их список выдается по команде configure -help). Так, если требуется установить сервер в иной каталог, нежели стандартный, нужно выполнить "configure -prefix=<path-to-apache>".

Когда configure отработает, следует, как обычно, дать команды make и makeinstall (эти действия выполняются пользователем root).

мake;
makeinstall.

Теперь сервер установлен в каталоге /usr/local/apache, но запускать его пока нельзя - сначала мы должны отредактировать файлы настройки httpd.conf, access.conf и srm.conf в каталоге /usr/local/apache/etc/ (начиная с версии 27.4 - /usr/local/apache/conf).

Настройка конфигурационных файлов Web-сервера - самый ответственный шаг при его установке. Здесь мы рассмотрим только наиболее распространенные директивы и их параметры, поскольку полный перечень с описанием займет не один десяток страниц. Сервер перечитывает конфигурационные файлы при запуске, а также при получении сигнала -HUP (жесткий рестарт) или -uSR1 (мягкий рестарт). Если сервер находится в рабочем состоянии, то при изменении конфигурации его рекомендуется перезапустить командой kill -USR1 `cat /usr/local/apache/logs/httpd.pid`

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

В access.conf содержатся директивы, описывающие права доступа к каталогам и файлам Web-сервера. Прежде всего решите, в каком каталоге будут храниться документы. По умолчанию это /usr/local/apache/share/htdocs, однако многие администраторы предпочитают размещать документы начиная с каталога /www/<имя_сервера>/, поскольку при такой организации проще ориентироваться в структуре файлов. Пусть, например, мы создали каталоги:

/www/rmt.ru/;
/www/radio-msu.net/;
/www/people.radio-msu.net/.

Они будут корневыми для соответствующих виртуальных серверов.

Файл access.conf может содержать секции Directory, Location и Files, которые ограничены одноименными директивами. В параметрах этих директив могут использоваться символы "?" и "*" , а также регулярные выражения, предваряемые тильдой, например <Directory ~"^/www.+/a?server">. В секции Directory помещаются инструкции, относящиеся к определенному каталогу на диске, в секции Location - относящиеся к виртуальному пути, в секции Files - относящиеся к файлу или группе файлов.

<Directory /www/rmt.ru> - директивы, относящиеся ко всем документам, хранящимся в каталоге /www/rmt.ru и вложенных в него </Directory>.

<Location /cgi-bin> - директивы, относящиеся ко всем документам, доступным по адресу http://<имя_сервера>/cgi-bin/ <путь_к_файлу></Location>.

<Files /www/rmt.ru/form.html> - директивы, относящиеся к файлу form.html из каталога /www/rmt.ru </Files>.

Различие между секциями Directory и Location состоит в том, что первая относится к каталогам на диске, вторая - к виртуальному пути (URL), который браузер запрашивает у Web-сервера. И в той, и в другой могут присутствовать директивы order, allow и deny, которые позволяют ограничить доступ к каталогу или URL с различных машин.

Indexes - разрешить выдачу листинга каталога, если в нем нет файла index.html (или файла индекса, заданного директивой DirectoryIndex);

MultiViews - разрешить поддержку многих языков; по умолчанию она отключена, и включать ее, как правило, не нужно; поддержка перекодирования "на лету" для русского языка устанавливается с помощью других директив, которые мы рассмотрим позже;

All - установить сразу все перечисленные режимы кроме MultiViews.

При отсутствии специальных требований к безопасности вполне допустимо указать "OptionsAll" в секции <Directory /www>; в противном случае нужно описать параметры каждого каталога отдельно.

Большинство директив могут задаваться не только в конфигурационных файлах сервера, но и в файлах .htaccess в каталогах сервера. Директива AllowOverride определяет набор директив, допустимых в файлах .htaccess. Параметры могут быть указаны следующие:

authconfig - разрешить установку авторизации по имени пользователя и паролю;
fileInfo - разрешить директивы, отвечающие за типы документов;
indexes - разрешить директивы, связанные с листингом каталогов;
limit - разрешить команды allow и deny;
options - разрешить описанную выше директиву Options.

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

Файл srm.conf содержит директивы, связанные с общими настройками структуры каталогов сервера. Как правило, в нем достаточно изменить лишь несколько строк.

DocumentRoot<первый каталог сервера>. Путь к каталогу по умолчанию, индексный файл которого пользователь получит при обращении к серверу (http://<имя_сервера>/). Эту директиву следует задать и для каждого из виртуальных серверов (в секции <VirtualHost> файла httpd.conf).

UserDir<имя пользовательского каталога>. Каталог, в котором пользователи должны размещать свои файлы, чтобы они были доступны по адресу http://<имя_сервера>/ ~<имя_пользователя>/. Стандартно public_html. Иногда, чтобы облегчить жизнь пользователям, администраторы дают директиву "UserDirwww".

DirectoryIndex<список файлов индекса>. Файл индекса - это тот файл, который будет передан клиенту при обращении к каталогу. Если указать несколько имен, сервер будет искать подходящий файл "слева направо". По умолчанию список содержит всего одно имя - index.html, но принято добавлять в него и другие распространенные имена индексных файлов. Например, директива может иметь вид: DirectoryIndex .index.html index.html index.htm index.cgi index.shtml home.html home.htm defaulthtmdefaulthtml

Чтобы включить на сервере поддержку CGI-сценариев, следует убрать знак комментария перед директивами ScriptAlias и AddHandlercgi-script .cgi. Первая задает каталог на диске, в котором будут храниться исполняемые программы, а вторая определяет, что все файлы с расширением .cgi должны обрабатываться как сценарии.

Директива ErrorDocument позволяет заменять стандартные сообщения сервера об ошибках на свои. Например, в случае самой распространенной ошибки - 404 (файл не найден) - считается хорошим тоном выдавать пользователю страницу с предложением продолжить свой путь по серверу или форму для поиска по узлу. Реализуется это достаточно просто: в настройках сервера мы убираем знак комментария со строки ErrorDocument 404 /missing.html.

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

Файл httpd.conf. Конфигурационный файл httpd.conf является основным и содержит настройки, связанные с работой Web-сервера, виртуальных серверов, а также всех его программных модулей. Кроме того, именно в нем настраивается перекодирование русских букв при передаче от сервера к клиенту и обратно.

Директива Port, помещенная в самом начале файла, определяет номер порта для http-сервера; по умолчанию это 80. При необходимости можно приписать серверу другой порт или несколько портов, для чего служит директива Listen.

Директива HostnameLookups с параметром on или off включает или, соответственно, отключает преобразование численных IP-адресов клиентов, получивших документы с сервера, в доменные имена. Такое преобразование несколько замедляет работу сервера, но при числе посещений менее 10 000 в сутки это, как правило, практически не заметно.

Директивы User и Group задают пользователя, который будет администрировать сервер. С точки зрения безопасности нежелательно указывать здесь существующего пользователя, имеющего доступ к каким-либо другим ресурсам или файлам. Лучше создать отдельного пользователя и группу специально для http-сервера, например:

userwww;
groupwww.

Директивы ServerRoot, ErrorLog, CustomLog определяют соответственно корневой каталог http-сервера, путь к журналу регистрации ошибок (error_log) и путь к общему журналу обращений к серверу (access_log).

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

В большинстве случаев один http-сервер способен обрабатывать запросы, поступающие на различные, так называемые виртуальные, Web-серверы. Виртуальные серверы могут иметь как один и тот же IP-адрес, но разные доменные имена, так и разные IP-адреса. С точки зрения пользователя второй вариант чуть более предпочтителен, поскольку запрос к серверу, отличающемуся от основного только доменным именем, должен содержать его имя, а некоторые старые браузеры, не поддерживающие протокол HTTP/1.1 (например, MicrosoftInternetExplorer 2.0), не включают в запрос эту информацию. Однако такие браузеры выходят из употребления (сейчас их уже менее 0,5% общего числа); с другой стороны, выделение собственного IP-адреса каждому виртуальному серверу может быть неоправданной растратой адресного пространства компании.

Для описания адресов и доменных имен виртуальных серверов служат директивы ServerName, ServerAlias, NameVirtualHost и VirtualHost. Они необходимы, только если вам нужно установить более одного виртуального сервера.

Директива ServerName, находящаяся вне секций VirtualHost, определяет имя основного сервера, т. е. сервера, корневой каталог которого задан директивой DocumentRoot в файле srm.conf. Виртуальные серверы наследуют настройки основного; при необходимости специальной настройки соответствующие директивы помещаются в секции VirtualHost, относящейся к данному серверу. Допустимы любые директивы, которые могут встретиться в файлах httpd.conf и srm.conf, например DocumentRoot, ErrorLog, CustomLog, Location, ServerAdmin.

Модуль поддержки русских кодировок был разработан в 1996 г. Дмитрием Крюковым (dvk@stack.net), а с февраля 1997 г. поддерживается рабочей группой Apache-RUS Team во главе с Алексеем Тутубалиным (lexa@lexa.ru). За время своего развития модуль претерпел множество изменений и теперь обладает практически неограниченными возможностями настройки для любой конкретной конфигурации.

Инструкции, отвечающие за перекодирование, разделяются естественным образом на три группы. К первой относятся две директивы, указывающие, в какой кодировке хранятся файлы на диске: CharsetSourceEnc<кодировка> и CharsetByExtension<кодировка><расширение1><расширение2>...

Например, файл httpd.conf может содержать строки:

CharsetSourceEnc koi8-r;
CharsetByExtension windows-1251.txt.

Такая запись означает, что все файлы хранятся на диске в кодировке koi8-r; исключение составляют текстовые файлы с расширением txt, для которых используется Windows-1251.

Если кодировок более одной и документы в каждой кодировке хранятся в своем каталоге, директивы CharsetSourceEnc помещаются в соответствующие секции <Location> либо в файлы .htaccsess внутри каталогов.

Вторую группу составляют директивы CharsetDecl, CharsetAliasCharsetRecodeTable и CharsetWideRecodeTable, которые определяют названия кодировок, их синонимы и таблицы перекодирования. Все они размещаются в секции <IfModulemod_charset.c> - </IfModule> и в большинстве случаев не нуждаются в изменении.

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

Принято, чтобы при попадании на русскоязычный сервер пользователь получал страницу в "своей" кодировке, определяемой автоматически на основе той информации об операционной системе, которую передает серверу браузер: например, установив, что пользователь работает в Windows, сервер выдает ему страницу в кодировке Windows-1251, а установив, что он работает в Unix, выдает страницу в koi8. Если выбранная таким образом страница не подходит, клиент может сменить кодировку вручную. Основных схем выбора три: по префиксу каталога, по имени виртуального сервера и по номеру порта.

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

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

Чтобы применить выбор по номеру порта, необходимо в файле httpd.conf удалить директиву Port и снять комментарии со строк:

Listen 80;
Listen 8100;
Listen 8101;
Listen 8102;
Listen 8103;
CharsetByPort koi8-r 8100;
CharsetByPort windows-1251 8101;
CharsetByPortibm866 8102;
CharsetByPort iso-8859-5 8103.

Номера портов не очень важны. В стандартной настройке Apache-RUS нумерация, как видим, начинается с 8100, но чаще ее начинают с 8000 или 8080.

Данная схема не требует внесения дополнительных записей в DNS и позволяет работать с виртуальными серверами даже клиентам, которые не поддерживают протокол HTTP/1.1, - ведь кодировка выбирается исходя из числа, указывающего на номер порта Web-сервера (по умолчанию это 80). Однако сетевые брандмауэры иногда запрещают работу с определенными портами, и если таким брандмауэром защищена сеть клиента, он не сможет установить соединение с вашим сервером. К сожалению, подобная ситуация возникает чаще, чем хотелось бы.

Чтобы документы, кодировка которых была выбрана автоматически, не оседали в кэшах прокси-серверов, Apache-RUS дает им специальный HTTP-заголовок, запрещающий кэширование. В результате при возврате на страницу (например, по кнопке Back) она считывается с сервера заново, что, во-первых, замедляет работу, а во-вторых (и это более серьезная проблема) очищает все текстовые формы, которые были на странице (то же происходит при использовании JavaScript). Разрешить кэширование позволяет директива CharsetDisableForcedExpiresOn, которая задается в секции <Location> для данного виртуального пути или в соответствующем файле .htaccess, но тогда возникает риск, что пользователи иногда будут получать страницы в "чужой" кодировке. Существуют и промежуточные варианты: например, можно установить CharsetDisableForcedExpiresOn (в секции <Files>) только для тех документов, которые содержат формы, окна или JavaScript-сценарии.

Для полного отключения перекодирования в каталоге или на виртуальном сервере служит директива CharsetDisableOn.

При выборе кодировки по имени сервера или по префиксу каталога хорошим тоном является использование для графических файлов абсолютных ссылок с указанием имени сервера (например, <imgsrc="images/image-http://images.rmt.ru/ picture.jpg">). Тогда при переходе клиента от основного сервера к выбранной кодировке изображения будут браться из локального кэша браузера, а не перечитываться заново. Это особенно актуально при большом объеме графической информации на сервере.

По окончании процедуры настройки следует запустить httpd-сервер. Для этого нужно войти в систему с привилегиями пользователя root и дать команду /usr/local/apache/sbin/apachectlstart.

Если в конфигурационных файлах есть серьезные ошибки, сервер не запустится, а на экран будет выведено соответствующее сообщение. В любом случае после запуска сервера имеет смысл просмотреть файлы error_log и access_log, которые находятся в каталоге logs. Для проверки работоспособности сервера достаточно создать в его корневом каталоге файл index.html и обратиться из браузера по адресу сервера. Правильную установку режимов перекодирования следует проверять с помощью браузеров для различных операционных систем.

Разработанное веб-приложение используется для решения следующих задач:

Размещение товара;
добавление рекламного баннера;
размещение данных о компании.

Разработанное веб-приложение функционирует в любом современном веб-браузере, т.е. является кроссбраузерным.

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

Рисунок 2.4 Главная страница сайта

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

Рисунок 2.5 Каталог товаров.

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

Рисунок 2.6 Как заказать товар.

Кликнув по следующей ссылке можно просмотреть контактную информацию (рисунок 2.7).

Рисунок 2.7 Контактная информация.

При переходе по следующей ссылке можно просмотреть отзывы и комментарии (рисунок 2.8).

Рисунок 2.8 –Отзывы и комментарии

3 Расчет экономической эффективности

.1 Обоснование актуальности разработки

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

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

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

Факторами, обуславливающими повышение эффективности процесса оформления заказа, являются:

- сокращение времени ввода клиента в БД;

- сокращение времени на формирование заказов;

- сокращение времени на обработку информации.

2.3.1 Исходные данные для расчета

Расчет экономической эффективности ЭИС осуществлен в соответствии с ГОСТ 24.702-85.

Исходные данные для расчета экономической эффективности проекта собраны во время преддипломной практики с 9 декабря 2013 года по 16 марта 2014 года и представлены в таблицах 3.1 -3.5. Источниками получения исходной информации являются нормативные документы, документы бухгалтерской отчетности, и другие данные, предоставленные персоналом магазина «Техномир».

Таблица 3.1 – Нормативные показатели интернет магазина «Техномир»

Наименование показателя	Усл-е обозначение	Единица измерения	Значение показателя
1	2
Годовой фонд рабочего времени	Фр.в	час	1944
Коэффициент дополнительной заработной платы	Кдоп	%	10
Уральский коэффициент	Кур		15
Процент накладных расходов	Нр	%	10
Отчисления во внебюджетные фонды, в том числе:		%	30,2
Пенсионный фонд	Кпф		22
Фонд медицинского страхования	Кмс		5,1
Фонд социального страхования	Ксс		2,9
Страхование от несчастных случаев	Кнс		0,2
Нормативный срок окупаемости капитальных вложений	Тн	лет	5
Нормативный коэффициент эффективности капитальных вложений	Ен		0,35
Оклад программиста	Опр	руб.	15 000
Оклад специалиста	Осп	руб.	20 000
Стоимость 1 машиночаса	Смаш.час.	руб.	10

Таблица 3.2 –Затраты времени на создание ИС

Этапы создания	Условное обозначение	Единицы измерения	Время, затраченное программистом (час.)
всего	в т.ч. машинного времени
1
Разработка
Изучение области автоматизации	Тиз	час	50
Анализ задач ИС	Тан	час	1
Разработка ТЗ	Ттз	час	60

Продолжение таблицы 3.2

Проектирование ИС	Тпр	час	50	50
Программная реализация	Тпрр	час	40	40
Тестирование и отладка	Ттест	час	34	34
Внедрение
Установка	Туст	Час	12	12
Отладка	Тотл	Час	12	12
Обучение персонала: программист специалист	Тобуч Тобуч2	Час Час

3.2 Расчет затрат на создание ЭИС

Таблица 3.3 – Исходные данные для расчета экономической эффективности

Наименование показателя	Условное обозначение	Единица измерения	Значение показателя
Базовый вариант	Внедряемый вариант
1
Количество клиентов в месяц		Чел.	0	40
Ввод одного клиента в БД		Час.	,35	0,1
Среднее количество заказов на одного клиента		Шт.		2
Затраты времени на формирование одного заказа		Час.	,2	0,1
Количество формируемых отчетов в месяц		Шт.	15
Время на формирование одного отчета		Час.	0.3	.1

Затраты на создание ЭИС определяются по формуле:

где Зсозд –капитальные затраты на создание ЭИС, руб.;

Зразр –затраты на разработку ЭИС, руб.;

Звнедр –затраты на внедрение ЭИС, руб.

3.2.2.1 Расчет затрат на создание ЭИС

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