Разработка информационного Интернет-портала

метки: Портал, Разработка, Информационный, Модель, Пользователь, Папка, Клиент, Необходимо

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

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

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

Целью дипломного проекта является доработка и развитие Интернет-ресурса Карандаш для ИП Рахманов [1].

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

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

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

1. Описание предметной области информационного портала

1.1 Анализ существующих решений

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

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

Разработка образовательного портала ‘Информационные системы ...

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

Примерами сайтов торговых компаний, позиционирующих себя как порталы, являются сайты «Торговый портал — Путлет» [3] и интернет-портал «BallMarket.ru Продажи & консалтинг» [4].

Главное окно портала Путлет представлено на рис. 1.1. Порталами, которые предлагает портал Путлет, являются безопасная сделка и заключение договоров.

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

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

Рис. 1.1 — Главное окно Торговый портал — Путлет

Точка входа в интернет-портал «BallMarket.ru Продажи & консалтинг» показана на рис. 1.2. Данный сайт позиционирует себя как ресурс, предоставляющий услуги только зарегистрированным клиентам. Пользуясь порталами портала, зарегистрированные пользователи могут:

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

Рис. 1.2 — Точка входа в интернет-портал «BallMarket.ru Продажи &консалтинг»

Одним из примеров сайтов торговых компаний, работающих как интернет-портал, является сайт издательства Фёдорова [5] (см. рис. 1.3).

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

Рис. 1.3 — Сайт издательства Фёдорова

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

Интернет-магазины, их виды и характеристика

... сравнение традиционного магазина и Интернет - магазина. Таблица 1 – Сравнительная характеристика традиционной и электронной торговли Традиционный магазин Виртуальный магазин Торговый зал Виртуальный магазин Ходьба покупателя по торговому залу и осмотр товаров на полках Магазина Просмотр ...

Интернет поиск выдает огромное количество книжных интернет-магазинов, рассмотрим самые популярные: Магистр и OZON.

Интернет-магазин «Магистр» является одним из крупнейших книжных Интернет-магазиновв Южном регионе[6] (см. рис. 1.4).

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

Рис. 1.4 — Главное окно интернет-магазина «Магистр»

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

Рис 1.5- Главное окно интернет-магазина «OZON»

1.2 Анализ предметной области

Торговое предприятие ИП Рахмонов занимается реализацией учебной литературы и канцтоваров на рынке Ростова-на-Дону более 5 лет. Предприятие имеет сайт Карандаш [1].

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

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

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

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

Рис 1.6 — Диаграмма вариантов использования пользователей интернет магазина

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

Основными требованиями к актору Администратор являются:

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

• ведение данных по учету товаров, отображаемых в интернет-магазине.

Диаграмма вариантов использования для актора Администратор представлена на рисунке 1.7.

Разработка ИС-ведения учета товаров в магазинах оптово-розничной торговли

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

Рис 1.7- Диаграмма вариантов использования для актора Администратор

Диаграмма вариантов использования для актора Менеджер представлена на рисунке 1.8.

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

Рис 1.8 — Диаграмма вариантов использования для актора Менеджер

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

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

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

Рис 1.9 — Диаграмма вариантов использования по поддержанию функционирования форума

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

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

Однако реализация форума ведет к ряду проблем, требующих контроля и вложений:

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

Исходя из проведенного анализа можно сказать, что основными категориями пользователей Интернет-портала электронного магазина являются акторы представленные на рисунке 1.10: Гость, Зарег. пользователь, Менеджер, Администратор, и при условии реализации Форума — Модератор и Администратор форума.

Современные технологии разработки Web-сайтов

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

Подсистемы, реализуемые в рамках Интернет-портала, показаны на рисунке 1.11.

Рис 1.10 — Диаграмма ролей Интернет-портала

Рис 1.11 — Подсистемы Интернет-портала

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

1.3 Сбор и моделирование требований

Сбор требований — один из основных этапов анализа системы, обеспечивающий успешную реализацию проекта [8, 9]. Результатом проведения сбора требований служит техническое задание (ТЗ) на проект.

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

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

Описание существующей системы

На основании данных от разработчиков сайта Карандаш на момент начала доработки была разработана и внедрена подсистема Магазин в части организации структуры данных предметной области.

На диаграмме классов этапа анализа представлены сущности, описание которых реализовано в модели данных сайта (см. рис. 1.12):

• sh_Tree — дерево объектов предметной области;
• sh_ItemProperty — сущность, определяющая признак категории объектов, отображаемых на сайте;
• Рис 1.12 — Сущности предметной области сайта Карандаш
• sh_Enterprise — производители товаров, в частности издательства книжной продукции;
• sh_goods — общая категория товаров;
• sh_books — книжная продукция.

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

Сайт Карандаш реализован на основе технологии MVC.Net 4.0. Размещение сайта осуществлено на виртуальном сервере (VPS) компании InfoBox. WindowsVPS сервера данной компании располагаются в Амстердаме и Санкт-Петербурге, имеют архитектуру на быстрых SSD (сверхпроизводительных твердотельных накопителях), имеют минимальный ping до городов России и СНГ. На серверах устанавливается лицензионная ОС WindowsServer. НаVPS, размещающем сайт Карандаш, установлена ОС WindowsServer 2012 r2. База данных реализована под управлением СУБД MSSQLServer 2008 r2.

Базы данных, основные модели их организации

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

Диаграммы вариантов использования существующей системы представлены на рисунках 1.13 для ролей Гость.

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

Рисунок 1.13 — Диаграмма вариантов использования актора Гость

Основной проблемой существующей реализации является наполнение магазина конкретными данными по номенклатуре товаров.

Парсинг номенклатуры товаров

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

Оптовые поставки товаров в магазин Карандаши осуществляются несколькими предприятиями дистрибьютерами: Рельеф-Центр[11] и Самсон [12].

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

Для наполнения сайта Карандаш необходимо использовать прайс-листы данных дистрибьютеров. На рисунке 1.14 представлен образец прайса внутреннего использования от компании Рельеф центр. Представленный документ является файлом Excelи структура атрибутов прайса не соответствует структуре таблиц базы данных сайта.

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

Рисунок 1.14 — Прайс компании Рельеф центр

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

Во-первых для удобства работы необходимо осуществить перенос прайса из формата Excel в таблицу вспомогательной БД MSSQLServer.

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

Следующим шагом является перенос номенклатуры товаров из раздела прайса в соответствующий раздел БД сайта.

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

На рисунке 1.15 представлена диаграмма деятельности, показывающая реализацию описанного алгоритма.

Рисунок 1.15 — Диаграмма деятельности по наполнению сайта номенклатурой товаров на основе прайса компании дистрибьютера

1.1.1. Отображение бизнес-правил.

Рассмотрим реализацию

1.1.2. Отображение рабочего процесса между пользователями и системой

1.1.3. Отображение взаимодействий между пользователями и системой

1.2. Спецификация требований

В приложении А представлено техническое задание (ТЗ) на доработку информационного портала магазина Карандаш.

Данное ТЗ разработано на основе предположения, что реализация портала будет происходить в несколько этапов. На первом этапе разрабатывается:

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

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

Выводы

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

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

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

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

2.1 Архитектура портала

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

• Представление администратора;
• Представление гостя;
• Представление зарегистрированного пользователя;
• представление менеджера.

Рисунок 2.1 — Концептуальная архитектура интернет портала

Современное Web-приложение основывается на технологии «клиент-сервер». Таким образом, его архитектура расширяется до трехуровневой. При такой архитектуре клиентский уровень занимает обозреватель, на уровне сервера находится сервер БД, а на промежуточном уровне размещаются Web-сервер и модули расширения сервера. Модуль расширения сервера выступает преобразователем протоколов между клиент-серверным приложением БД и Web-сервером. Структура приложения представлена на рисунке 2.2.

Рисунок 2.2 — Базовая архитектура трехуровневогоWeb-приложения

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

• Apache HTTP-сервер — кроссплатформенное ПО, поддерживаемое операционными системами Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS — 57,93% серверов;
• NginxHTTP-сервер -сервер, работающий на Unix-подобных операционных системах, с версии 0.7.52 появилась бинарная сборка под Microsoft Windows — 12,18%серверов;
• IIS (Internet Information Services) — набор серверов для нескольких служб Интернета от компании Майкрософт. IIS распространяется с операционными системами семейства Windows NT — 12,14%.

Для реализации портала учебного процесса кафедры физкультуры выбран сервер IIS 7.0с операционной системой WindowsServer 2008 R2.IIS 7.0 поставляется вместе с библиотекой .NET Framework.

Шаблоном архитектуры программного обеспечения выбрана технология MVC .Net. Данный паттерн обеспечивает разделение данных, логики и интерфейса (см. рис. 2.3):

• Model — часть приложения, содержащая в себе бизнес-логику, описывающую предметную область. Модель знает, как устроены данные и как с ними работать;

• Controller. — контролирует части программы, реагирует на какие-то события и, исходя из этого, влияет на модель или представление.
• View — часть приложения, визуализирующая модель данных. Обычно представление имеет прямой доступ к модели, но разрешено только чтение этих данных;
• Рис. 2.3- Структура шаблона MVC

2.2 Проектирование интерфейса

Уровень представления Web-приложения критически важен при разработке системы и оказывает значительное влияние на степень принятия приложения пользователями. Он обеспечивает выполнение бизнес-функций, представляемых приложением пользователям, а также визуальное представление информации, которой управляет приложение. Эффективность пользовательского интерфейса значительно влияет на успех приложения в целом [20].

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

1. Производительность — главное требованием к Web-приложению. Максимальное время выполнения операций не должно превышать 3-10 с.

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

3. Интерактивность и широкие возможности. Пользовательский интерфейс должен быть интерактивным и отзывчивым. Кроме того, уровень представления должен быть обогащенный в визуальном смысле, включая диаграммы, drag-and-drop компоненты, ползунки для изменения данных, интерфейс в виде панелей и т.п.

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

Для структуры макета порталаУчебная работа кафедры ФВ,СиТ была принята концепция «резинового» макета, который подразумевает информация будет занимать пространство, подстраиваясь под разрешение. Используется решение с адаптивнымweb-дизайном, когда определены основные разрешения (размеры экрана), под которые адаптируется контент

Структура макета главной страницы портала для мониторов с большим разрешением,представлена на рисунке 2.4. Макет включает области заголовка (heder), навигации (sidebar), контента страницы (content) и нижнего колонтитула (footer).

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

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

Рисунок 2.4 — Структура макета главной страницы

Рисунок2.5 — Структура макета главной страницы для мобильных устройств

Реализация структуры сайта приведена в листинге 2.1. При вёрстке портала использован блочный подход. Таблицы используются только для своей прямой роли — представление информации в виде таблицы.

Код HTML создаёт скелет страницы, её абстрактную модель при помощи тэгов (языка разметки HTML).

При написании разметки прописываются классы и идентификаторы.

Листинг 2.1 — Реализация структуры проекта

2.3 Проектирование и разработка БД портала

При проектировании базы (БД) данных создаются два уровня модели — логический и физический. Логический уровень — это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире[19].

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

Категории пользователей системы задаются сущностями Студент и Преподаватель, которые связаны с сущностью Лицо отношением один к одному. Сущность Студент связана с сущностями Специальность и Тип обучения отношением один ко многим. Отношение между сущностями Студент и Группа — многие ко многим. Это связано с тем, что одним из определяющих атрибутов сущности Группаявляется атрибут Курс, который для студента изменяется по времени обучения.

Представленные на рисунке 2.9 сущности UserProfile, webpages_Roles и webpages_Membership определяют роль пользователя системы, справочник ролей (Гость, Студент, Преподаватель или Администратор) и параметры входа пользователя в систему. Данные сущности создаются автоматически при использовании шаблона приложения MVC в среде VisualStudio.

Рис. 2.9 — Концептуальная модель БД подсистемы администрирования

Разработка модели БД проводилась средствами MSVisualStudio2013 с использованием на модели ADO.NetEDM[22].

Данная модель — это модель «сущность-связь» — Entity Data Model (EDM), описанная Питером Ченом в 1976 году. Данная модель представляет собой набор основных понятий, которые описывают структуру данных независимо от формы хранения.

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

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

1. Конструктор моделей EDM ADO.NET (конструктор сущностей) позволяет с помощью визуальных средств создавать и изменять сущности, ассоциации, сопоставления и связи наследования. Конструктор сущностей также формирует код уровня объекта на языке C# или Visual Basic.

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

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

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

На основе концептуальной модели создана БД проекта, реализованная в MSSQLServer 2008 R2. Структура и связи таблиц представлены рис. 2.10.

Рисунок 2.10 — Структура таблиц подсистемы администрирования

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

2.4 Структура проекта

Web-сервис разрабатывается в VisualStudio 2013, как проектSportEducation.Разработка проекта осуществлялась на основе мастера Веб-приложение ASP.NetMVC 4. На рисунке 2.11 представлена страница выбора данной категории проекта. На рисунке 2.12 представлен выбор шаблона проекта: Интернет-приложение на базе обработчика представлений Razorс созданием проекта разработки модульных тестов — SportEducation.Tests.

Полученная структура проекта представлена на рисунке 2.13.

Рис. 2.11. — Открытие шаблона создания проекта SportEducation

Рис. 2.12. — Открытие шаблона создания проекта SportEducation

Рис. 2.13. Структура проекта SportEducation

Данный проект, как и все проекты MVC содержит следующие папки: App_Data, Content, Controllers, Models, Scripts и Views. В дополнение к данным папкам сгенерированное веб-приложение MVC использует код в файле Global.asax для установки глобальных параметров маршрутизации URL-адресов по умолчанию, а также использует файл Web.config для настройки приложения.

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

Content — папка для рекомендуемого расположения файлов содержимого (например, файлов каскадных таблиц стилей, изображений и пр.).

В общем случае папка Content предназначена для статических файлов.

Controllers — папка для рекомендуемого расположения контроллеров. Имена контроллеров в платформе MVC должны оканчиваться на «Controller», например Home Controller, Login Controller или Product Controller.

Models — предназначена для классов, которые представляют модель приложения для веб-приложения MVC. Эта папка обычно содержит код, который определяет объекты и логику взаимодействия с хранилищем данных. Сами объекты модели обычно располагаются в отдельных библиотеках классов. Тем не менее, при создании нового приложения классы можно расположить в этой папке, чтобы переместить их в отдельные библиотеки на более поздней стадии разработки.

Scripts — рекомендуемое расположение для файлов скриптов, поддерживающих приложение. Эта папка по умолчанию содержит файлы платформы ASP.NET Ajax и библиотеку jQuery.

Views — рекомендуемое расположение для представлений. Представления используют файлы ViewPage (ASPX), ViewUserControl (ASCX) и ViewMasterPage (MASTER) в дополнение к остальным файлам, которые связаны с отображением представлений. Папка Views содержит папки для всех контроллеров. Название папки состоит из префикса имени контроллера. Например, если существует контроллер с именем HomeController, то в папке Views будет вложенная папка с именем Home. При загрузке представления платформой ASP.NET MVC в папке «Views\имя_контроллера» по умолчанию выполняется поиск файла ViewPage (ASPX), который имеет имя требуемого представления. По умолчанию в папке Views находится папка Shared, которая не соответствует ни одному контроллеру. Папка Shared используется для представлений, которые используются на нескольких контроллерах. Например, главную страницу веб-приложения можно поместить в папку Shared.

2.5 Клиентская часть

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

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

2.6 Организация взаимодействия с БД

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

• тип сущности;
• тип ассоциации;
• свойство.

Структура концептуальной модели передаётся при помощи доменного языка (DSL).Платформа ADO.NET Entity Framework использует язык DSL на основе XML, называемый языком CSDL, для определения концептуальных моделей. Файл метаданных концептуальной модели представлен в Приложении В.

Структура модели данных представлена на рисунке 2.14.

Рис. 2.14

В проекте автоматически с генерируется класс enterprise_order Entities 1, который наследуется от класса Object Context, представляет сущности базы данных Knowit All Order, содержит свойства, моделирующие таблицы sh_Three и Title, связи между таблицами.

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

Рис. 2.15

3. Эффективность Web-портала

Оценка надежности Информационный портала

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

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

Так как Информационный портал «БК Ростов» не предусматривает завоевание пользовательской аудитории, а является порталом для обеспечения учебной деятельности, то при анализе надежности сайта следует исходить из первого определения, связанного с безотказной работой.

Критерии надежности сайтов отличаются для статических и динамических сайтов. Для статических сайтов характеристики надежности связаны со временем безотказной работы.

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

Таблица 3.1 — Характеристика надежности

Лет	Характеристика надежности сайта	Примечание
2 и более	Очень высокая надежность сайта.	Владельцу сайта повезло. Очень высокое качество сайта.
1,5-2	Высокая надежность сайта.	Высокое качество сайта.
1-1,5	Надежный сайт.	Сайт создан профессиональным веб-дизайнером. Сайт качественный.
0,5-1	Низкая надежность сайта.	Качество сайта ниже среднего.
менее 0,5	Очень низкая надежность сайта.	Владельцу сайта не повезло. Очень низкое качество сайта.

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

3.1 Оценка стоимости проекта

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

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

Определим модель ЖЦ проектирования на основе методики предложенной в работе Т. Фатрелла [23].

Таблицы обоснования выбора модели представлены в приложении Д.

Таблица 3.1- Определение оптимальной модели жизненного цикла, в баллах

Характеристика	Каскадная	V-образная	Прототипирование	Спиральная	RAD	Инкрементная
Требования	3	3	5	4	6	4
Участники команды разработчиков	3	1	8	7	3	4
Коллектив пользователей	4	3	6	9	2	7
Типы проектов и рисков	4	4	1	4	1	4
Итого	14	11	20	24	12	19

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

Спиральная стратегия (эволюционная или итерационная модель, автор Барри Боэм, 1988 г.) подразумевает разработку в виде последовательности версий, но в начале проекта определены не все требования. Требования уточняются в результате разработки версий.

Схема модели представлена на рисунке 3.1.

Рис. 3.1 — Спиральная модель ЖЦ

Данная модель жизненного цикла характерна при разработке новаторских (нетиповых) систем [21].

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

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

Достоинства модели:

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

• уменьшаются риски заказчика. Заказчик может с минимальными для себя финансовыми потерями завершить развитие неперспективного проекта.

Недостатки модели:

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

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

3.2 Создание пооперационного перечня работ

Использование спиральной модели, как указывалось, ведет к циклической перестановке действий одной из выбранных линейных моделей. В учебнике Фатрелла «Управление программными проектами» базовой линейной моделью считается модель быстрого прототипирования. Выполнение данной модели в цикле приводит ко все более устойчивым результатам поставляемого продукта.

В дипломном проекте рассматривались два первых прохода.

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

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

Рисунок 3.2 — Пооперационный перечень

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

• установку соответствия между действиями и планом;
• распределение ресурсов проекта;
• установку среды проекта;
• планирование управлением проекта.

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

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

Разрабатываемый интернет портал включает в себя:

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

Идентификация задач представлена на рисунке 3.2.

3.3 Эффективность проекта

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

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

Анализ рынка компаний, занимающихся предоставлением услуг аутсорсинга, показывает, что основной процент заказчиков консультационных услуг и услуг на обслуживание компьютерного парка принадлежит малому бизнесу, неспособному обеспечить самостоятельное обслуживание компьютерной техники. В Ростове-на-Дону значительную долю рынка — до 30% в сфере внедрения ИТ-технологий и дальнейшего сопровождения программных продуктов для бизнеса занимает ООО «1С Гэндальф». Поэтому для услуг аутсорсинга малого предприятия остается ниша, связанная с обслуживанием компьютерного парка, администрированием ИТ-систем предприятий.

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

Оценка стоимости разработки Web-сервиса проведена в разделе 3.1 и составляет 40 000 руб. Данная сумма представляет собой единовременные затраты

Вычислим чистую текущую стоимость внедрения сервиса (NPV)

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

Для того, чтобы найти NPV нам нужно найти CF (поступления от инвестиций)

CF = Прибыль + Амортизация

Определение коэффициента k осуществляется

Кумулятивный метод оценки ставки дисконтирования определяется исходя из следующей формулы:

d = Emin + I + r,

где d — ставка дисконтирования (номинальная);

• Emin — минимальная реальная ставка дисконтирования;
• I — темп инфляции;
• r — коэффициент, учитывающий уровень инвестиционного риска (премия за риск).

Как правило, за минимальную реальную ставку дисконтирования принимают 30-летние гособлигации США.

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

Примером шкалы рисковых премий является методика, изложенная в «Положении об оценке эффективности инвестиционных проектов при размещении на конкурсной основе централизованных инвестиционных ресурсов бюджета развития Российской Федерации» (утверждено Постановлением Правительства РФ №1470 от 22.11.97).

В этой методике описана рекомендованная процедура определения ставки дисконтирования для анализа проекта и предложена следующая «лестница» рисковых премий:

Таблица 3.2 — Методика определения премии за риск используемая при размещении на конкурсной основе централизованных инвестиционных ресурсов бюджета развития РФ

Тип проекта	Рисковая премия
Вложения при интенсификации производства на базе освоенной техники	3-5%
Увеличение объема продаж существующей продукции	8-10%
Производство и продвижение на рынок нового продукта	13-15%
Вложения в исследования и инновации	18-20%

Для внедрения Web-сервиса необходимо использовать пункт: Увеличение объема продаж существующей продукции, который дает значение рисковой премии в 8-10%

Ставка рефинансирования ЦБ РФ на 2016 г. составляет 11%.

Для рассмотрения эффективности использования Web-сайта в дальнейшем, необходимо провести детальный анализ затрат на его реализацию. Для этого разделим все затраты на единовременные капиталовложения, связанные с предпроектной подготовкой, и текущие затраты, обеспечивающие работу данного проекта. Необходимые, на наш взгляд, единовременные инвестиции приведены в таблице П 8.1. Указанные в таблице П 8,1 показатели сформированы исходя из средней рыночной стоимости всех необходимых программных средств, затрат на их обслуживание, доставку и монтаж, включая оплату консультационных услуг, а также расходов по обучению персонала. В общей сумме указанные единовременные затраты составили 348 100 рублей.

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

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

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

Так как в соответствии с документацией срок эксплуатации приобретаемого оборудования и программного обеспечения составляет 3 года, то месячные амортизационные отчисления оборудования и программного обеспечения рассчитаем по формуле [95, С,29]:

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

На первоначальном этапе оценки эффективности проекта рассчитаем коэффициент дисконтирования (d).

Для этого воспользуемся формулой (1) [56, С.26]. Таким образом, значение коэффициента дисконтирования, для расчета экономической эффективности данного проекта будет равно:

• Полученная величина удовлетворяет указанным требованиям d = 32% или 0,32 < 1 и показывает темп снижения ценности денежных ресурсов с течением времени.

В данном расчете применим размер доходности от вложений средств, равный 9%, определенный как средний банковский депозитный процент — 9 % годовых в долларах США. Под указанной величиной понимается наименьший гарантированный уровень доходности, сложившийся на рынке капиталов — то есть, нижняя граница стоимости капитала.

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

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

По данным агентства РБК, уровень годовой инфляции в 2005 г., составил 11% [23, С.6, 74]. Поэтому для дальнейших расчетов значение уровня инфляции возьмем равное 11 %.

Все необходимые показатели, для определения эффективности инновационного проекта, где отразим все необходимые инвестиционные затраты и предполагаемые объемы сделок.