Размещено на http://www.Allbest.ru/

Содержание

• Список сокращений
• Введение
• 1. Описание предметной области Web-сервиса
• 1.1 Анализ существующих решений
• 1.2 Анализ предметной области
• 1.3 Сбор и моделирование требований
• 1.4 Спецификация требований
• 2. Проектирование и разработка сервиса учебного процесса кафедры физкультуры
• 2.1 Архитектура сервиса
• 2.2 Проектирование интерфейса
• 2.3 Проектирование и разработка БД сервиса
• 2.4 Структура проекта
• 2.5 Клиентская часть
• 2.6 Организация взаимодействия с БД
• 2.7 Развертывание сервиса
• 3. Эффективность Web-сервиса
• 3.1 Оценка стоимости проекта
• 3.2 Создание пооперационного перечня работ
• 3.3 Эффективность проекта
• Заключение
• Библиографический список
• Приложение А. Техническое задание
• Приложение Б. Структура таблиц подсистемы администрирования
• Приложение В. DDL сценарий создания объектов базы данных
• Приложение Г. Структура концептуальной модели на основе DSL
• Приложение Д. Обоснование модели выбора жизненного цикла

СПИСОК СОКРАЩЕНИЙ

EDM - Entity Data Model, модель «сущность-связь»;

DSL - доменный языка;

CSDL - язык DSL на основе XML;

БД - база данных;

ВКР - выпускная квалификационная работа;

ЖЦ - жизненный цикл;

ПП - программный продукт;

ТЗ - техническое задание;

Введение

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

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

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

Целью ВКР является разработка Web-сервиса оказания консультационных услуг. Реализация данного проекта позволит предприятию расширить клиентскую базу, повысить прибыль как за счет интернет продаж, так и за счет привлеченных сервисом клиентов.

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

– провести обследование предметной области;

– построить модель предметной области «как есть» и выявить существующие недостатки;

– построить модель «как будет» и предложить рекомендации по устранению выявленных недостатков предприятия;

– разработать базу данных (БД) Web-сервиса для обеспечения функциональности работы сервиса;

– провести отладку;

– провести оценку эффективности принятых решений, и реализованного сервиса.

1. Описание предметной области Web-сервиса

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

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

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

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

Одним из примеров оригинальных дизайнерских решений является сайт компании «Эскулап ИТ-Сервис» [1], главная страница которого представлена на рисунке 1. Сервис для связи с компанией представлен на рисунке 2. На Web-странице показаны контактные телефоны компании и диалоговое окно, обеспечивающее возможность общения с представителями компании через электронную почту.

Компания обеспечивает выполнение следующего перечня услуг:

– ИТ аутсорсинг;

– ремонт компьютеров;

– создание Web-сайтов;

– продвижение или SEOоптимизация сайта;

– маркетинг;

– контекстная реклама.

Рисунок 1.1 - Главная страница компании «Эскулап ИТ-Сервис»

Рисунок 1.2 - Контактная страница компании «Эскулап ИТ-Сервис»

Более традиционным дизайнерским решением является сайт группы компаний «ГУDLINE» [2]. Страница, связанная с абонентским обслуживанием компьютерной техники, представлена на рисунке 1.3. На данной странице присутствует окно, обеспечивающее of-line связь с представителем компании.



Рисунок 1.3 - Контактная страницагруппы компаний «ГУDLINE»

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

Предприятие ИП Беридзе предоставляет следующими виды услуг:

– ремонт персональных компьютеров и ноутбуков;

– установкой и настройкой ОС;

– установкой и настройкой программ:

– подключение и настройка сети;

– антивирусная профилактика.

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

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



Рисунок 1.4 - Диаграмма вариантов основных категорий работников компании по оказанию ИТ услуг

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

Рассмотрим более подробно деятельность менеджера компании (см. рисунок 1.6). Офис менеджер обеспечивает:

– прием заказов индивидуальных клиентов на ремонт и обслуживание техники;

– прием заявок на аутсорсинг, сопровождение подписания договоров, сопровождение договоров аутсорсинга;

– назначение ответственных работников за выполнение индивидуальных заказов и договоров аутсорсинга;

– контроль деятельности исполнителей.

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

Рисунок 1.5 Диаграмма вариантов использования компании по оказанию ИТ услуг

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

Рисунок 1.6 Диаграмма вариантов использования инженерной службы

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

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

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

– приема и обработки заказов;

– обслуживания компьютерной техники;

– администрирования ИТ парка заказчиков.

Рисунок 1.7 - Диаграмма вариантов использования службы аутсорсинга



Рисунок 1.8 - Подсистемы Web-сервиса

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

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

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

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

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

Рассмотрим возможности системы для пользователей различных категорий.

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

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

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



Рисунок 1.10 - Диаграмма вариантов использования актора Зарегистрированный пользователь

У актора Клиент в добавление к личному кабинету появляется подсистема управления конфигурацией ИТ-оборудования и программного обеспечения. Диаграмма вариантов использования актора Зарегистрированный пользователь для подсистемы Управление конфигурацией представлена на рисунке 1.11.

Рисунок 1.11 - Диаграмма вариантов использования актора Клиент

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

– Гость;

– Зарег. пользователь;

– Администратор;

– Менеджер.

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

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

Рисунок 1.12 - Диаграмма классов акторов предметной области

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

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

Техническое задание (ТЗ) на реализацию Web-сервиса консультационных услуг представлено в приложении А.

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

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

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

– карта сервиса,

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

Выводы

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

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

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

2.1 Архитектура сервиса

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

– Представление клиентов;

– Представление менеджера;

– Представление администратора.

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

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



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

Реализация такой трехуровневой структуры определяется выборомWeb-сервера. Основными типамиWeb-серверов представленных сегодня на рынке являются HTTP_сервера Apache, Nginxи IIS (Internet Information Services).

HTTP-сервер Apache является кроссплатформенным программным обеспечением, поддерживаемым операционными системами Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. Доля этих серверов на рынке превышает 50%. NginxHTTP-сервер и IISделят рынок примерно поровну, находясь на уровне 12%.

Для реализации Web-сервиса консультационных услуг выбран сервер IIS 7.0с операционной системой Windows Server 2008 R2.IIS 7.0 поставляется вместе с библиотекой. NET Framework.

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

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

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

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

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

Рисунок 2.3 - Структура шаблона MVC

В инфраструктуре MVC .Net контроллеры - это классы C#, производные от класса System.Web.Mvc.Controller. Каждый открытый метод в классе, производном от Controller, является методом действия, который посредством системы маршрутизации ASP.NET ассоциируется с конфигурируемым URL. Когда запрос отправляется по URL, связанному с методом действия, операторы в классе контроллера выполняются, чтобы провести некоторую операцию над моделью предметной области и затем выбрать представление для отображения клиенту.

Взаимодействия между контроллером, моделью и представлением показаны на рисунке 2.4:

Рисунок 2.4 - Взаимодействия в приложении MVC

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

Разработка модели БД проводилась средствами MSVisualStudio2013 с использованием на модели ADO.NetEDM[9]. Данная модель - это модель "сущность-связь" - Entity Data Model (EDM), описанная Питером Ченом в 1976 году. EDM модель представляет собой набор основных понятий, которые описывают структуру данных независимо от формы хранения.

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 2.11 - Открытие шаблона создания проекта Advice



Рисунок 2.12 - Открытие шаблона создания проекта Advice

Рисунок 2.13 Структура проекта Advice

Данный проект, как и все проекты 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.

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

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

Рисунок 2.14 - Модель данных Entity Framework

2.7 Развертывание сервиса

Завершающим и критически важным шагом разработки веб-приложений является развертывание. Рассмотрим развертывание приложения Advice.

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

– на машине Windows Server с Internet Information Services (IIS), что предполагает локальное управление,

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

– в облачной инфраструктуре, обеспечивающей работу и масштабирование приложения.

Тестовая версия разработанного Web-сервиса была размещена на виртуальном сервере (VPS) компании Info Box. Windows VPSсервера данной компании располагаются в Амстердаме и Санкт-Петербурге, имеют архитектуру на быстрых SSD (сверхпроизводительных твердотельных накопителях), имеют минимальный ping до городов России и СНГ. На серверах устанавливается лицензионная ОС Windows Server. На VPS установлена ОС Windows Server 2012 r2, веб-сервер IIS 7.0, СУБД MSSQL Server 2008 r2.

Управление данным сервером осуществляется через удаленный рабочий стол.

Web-сервис публикуется на веб-сервере IIS. Вначале осуществляется конфигурирование веб-сервер. Для этого открывается средство администрирования IIS. Необходимо зайти в Панель управления, затем выбрать Администрирование->Диспетчер служб IIS. Откроется консоль управления IIS, представленная на рисунке 2.15.



Рисунок 2.15 Консоль управления IIS

Вначале происходит настройка пула приложений. Для этого вызывается функция добавления пула приложений, как показано на рисунке 2.16. В окне добавления пула приложений указывается имя Web-приложения и версия среды .Net Frame Work. Для устанавливаемого Web-сервиса это .Net Frame Work версии 4.0.

Рисунок 2.16 Добавление пула приложений

Следующим шагом является добавление сайта Advice, как показано на рисунке 2.17.



Рисунок 2.17 Добавление нового Web-приложения

После введения параметров нового Web-приложения можно переходить к опубликованию приложения в Visual Studio. Для этого необходимо нажать правой кнопкой на название проекта и в появившемся меню выбрать Опубликовать, как показано на рисунке 2.18.

Рисунок 2.18 Выбор меню Опубликовать

Открывается мастер публикации, который предложит пройти несколько этапов. Вначале выбираем профиль, как представлено на рисунке 2.19. Так как профиль новый, то определяем имя профиля. В нашем случае публикация осуществляется в локальной системе и, лишь, потом папка с опубликованными файлами переносится на удаленный сервер. Поэтом далее осуществляем выбор или создание папки для размещения файлов. На диске C:// создаём папку Advice,как показано на рисунке 2.20.

На вкладке Подключение определяем тип подключения как файловую систему и указываем целевое назначение (см. рисунок 2.21). На рисунке 2.23 показан последний шаг - это просмотр полученных файлов в созданной папке.

Рисунок 2.19 Выбор профиля публикации

Рисунок 2.20 Создание папки для размещения публикуемых файлов

Рисунок 2.21 Определение типа размещения файлов

Рисунок 2.22 Просмотр содержимого подключения

Папка с полученными файлами переносится на виртуальный сервер.

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

Выводы

Проведен выбор архитектуры Информационный портала Управление ИТ как трехуровневого Web-приложения. Проведена разработка интерфейса портала. Разработана база данных проекта для подсистемы администрирования портала.

Разработано Web-приложение Adviceна базе шаблона MVC .Net 4.0. Рассмотрены основные аспекты программирования данного приложения. Проведено развертывание портала на Web-сервере.

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

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

Для оценки стоимости проекта необходимо определить модель жизненного цикла (ЖЦ) программного продукта.

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

Модель ЖЦ может быть определена на основе методики предложенной в работе Т. Фатрелла [10]. Таблицы обоснования выбора модели представлены в приложении Д. Сводные данные на основе методики определения модели ЖЦ приведены в таблице 3.1.

Таблица 3.1

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

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

Из приведенных данных можно сделать следующие выводы. Для разрабатываемого Web-сервиса, наиболее подходящей моделью ЖЦ является метод быстрой разработки приложений «RAD».

Характерной чертой «RAD» является короткое время перехода от определения требований до создания полной системы. Метод основывается на последовательности итераций эволюционной системы или прототипов, критический анализ которых обсуждается с заказчиком. В процессе такого анализа формируются требования к продукту. Разработка каждого интегрированного продукта ограничивается четко определенным периодом времени, который, как правило, составляет 60 дней и называется временным блоком. Факторы, позволяющие создать систему за 60 дней, причем без ущерба качеству, включает в себя использование мощных инструментальных средств разработки, высокий уровень фактора повторного использования, а также осмысления и выделенные ресурсы.

При выполнении нашего проекта, для которого модель «RAD» подходит в достаточной мере, появляются следующие преимущества:

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

– существует возможность произвести быстрый изначальный просмотр продукта;

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

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

– модель обеспечивает эффективное использование имеющихся в наличии средств и структур;

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

– в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);

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

– основное внимание переносится с документации на код, причем соблюдая принцип «получите то, что видите»;

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

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

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

Для успешного создания уникального продукта или услугу необходимо, прежде всего, осуществить некоторую последовательность работ. Основная задача планирования проекта заключается в достаточно точной оценке сроков исполнения и стоимости этих работ. Чтобы добиться наивысшего качества плана проекта необходимо дать как можно более точную оценку сроков исполнения и стоимости работ. Точную оценку можно дать только в том случае, если хорошо представлен состав работ по выполнению проекта, то есть те работы, которые необходимо выполнить для получения необходимого результата. Как только мы составили список всех проектных работ, производится оценка длительности каждой из них, а также выделяются необходимые ресурсы для их выполнения. И только после всего этого можно будет оценить стоимость и сроки выполнения проекта. Именно поэтому определение состава работ является первым и наиболее важным шагом при планировании проекта. Модель RAD, представляет собой специальный случай линейной модели. Главной отличительной чертой этой модели является то, что для нее присущ чрезвычайно короткий цикл разработки ПО, при осуществлении которого используется конструкция, основанная на компонентах. Для данного ВКР была выбрана модель RAD и посредством ее показана версия задач и действий, необходимых для построения жизненного цикла Web-сервиса кафедры физкультуры.

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

– планирование и активизация проекта;

– фаза планирования требований;

– фаза описания пользователя;

– фаза «расчистки».

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

- процесс разработки проекта;

- процесс внедрения.

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

Диаграмма Ганта проекта представлена на рисунке 3.2.

Для реализации проекта выделены следующие ресурсы:

– Руководитель проекта;

– Аналитик;

– Разработчик;

– Тестировщик

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

Рисунок 3.2 - Диаграмма Ганта

Рисунок 3.3 - Затраты на трудовые ресурсы

Итоговая сумма затрат на трудовые ресурсы составила 58 100руб (см. таблицу 3.2).

Отчисление на социальное страхование вычисляем по формуле (3)

, (3.1)

где - сумма идущая на социальное страхование, руб.;

- заработная плата проекта, руб.;

Амортизация оборудования рассчитывается по формуле (3.2)

, (3.2)

где - амортизация аппаратных средств, руб;

- число часов в году, ч;

- число лет работы оборудования;

- потраченное время, ч

Расчеты по основным затратным статьям представлены в таблице 3.2.

Таблица 3.2

Затраты на проект

	Название ресурса	Макс. единиц	Пиковая загрузка	Стандартная ставка	Ставка сверхурочных	Затраты	Труд. затраты, ч
Трудо-затраты	Руководитель проекта	20%	19%	400,00р./ч	0,00р./ч	10 400,00р.	50,4
	Аналитик	50%	50%	300,00р./ч	0,00р./ч	17 400,00р.	57,6
	Разработчик	50%	50%	300,00р./ч	0,00р./ч	15 900,00р.	55,2
	Тестировщик	50%	50%	300,00р./ч	0,00р./ч	14 400,00р.	21,6
	Итого	58 100,00р.	184,80
			Затраты
	Соц. Страхование	30%				17 430,00р.
Мат. Затр.			Срок окупаемости, лет	Цена		Амортиз.
	Компьютер		5	42 000,00р.		537,51р.
	Программное обеспечение		5	0,00р.		0,00р.
	Итого общее	76 067,51р.

Итоговая стоимость проекта составила 76 067,51 руб.

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

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

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

Самым распространенным показателем эффективности проекта является чистый приведенный доход (Net Present Value, NPV). Это суммарная дисконтированная стоимость всех платежей проекта:

(3.3)

Где - (Cash Flow) денежный поток в k-й период, k = 1, 2, n;

n-горизонт расчета проекта = 2 года;

IC - (Invested Capital) стартовая инвестиция в проект;

I - ставка дисконтирования.

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

Ставка дисконтирования -- переменная величина, зависящая от ряда факторов

,

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

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

Таким образом i = 8,25%.

Денежный поток рассчитывается по формуле 3.4

(3.4)

где - ожидаемый приток средств (результаты) от реализации проектав k-й период;

_ ожидаемый отток средств (затраты) на реализацию проекта в k-й период.

Оценка стоимости разработки информационного портала проведена в разделе 3.2 и составляет примерно 65 000 руб. Данная сумма представляет собой единовременные затраты. Затраты на текущие расходы, связанные с эксплуатацией сервиса (предположительно на 5 лет), приведены в таблице 3.3 и составляют 5800 руб./мес.

Таблица 3.3

Расчет затрат на эксплуатацию сервиса

Расходы	Цена	Кол-во, лет	Итог
Оплата доменного имени, год	600,00р.	5	3 000,00р.
Оплата VPS сервера, год	9 000,00р.	5	45 000,00р.
Обновление номенклатуры, год	5 000,00р.	5	25 000,00р.
Итого за период	73 000,00р.
Итого в месяц	5 800,00р.

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

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

Коэффициент возврата инвестиций ROI (Return of Investment) позволяет оценить прибыльность инвестиций, вложенных в проект (формула 3ю5):

(3.5)

Где NPV - чистый приведенный доход;

IC - стартовая инвестиция в проект.

Таблица 3.4

Расчет денежных потоков

Месяц	DP	Z	CF		Доход /расход	Нарастающий итог
1	87 000,00р.	69 600,00р.	17 400,00р.	1,085	16 036,87р.	-48 850,64р.
2	156 000,00р.	69 600,00р.	86 400,00р.	1,177225	73 392,94р.	24 542,29р.
3	192 000,00р.	69 600,00р.	122 400,00р.	1,277289	95 827,95р.	120 370,24р.

Таким образом, коэффициент возврата инвестиций равен:

Индекс рентабельности PI (Profitability Index) показывает, сколько инвестор заработает денег с каждого вложенного в проект рубля (формула 3.6):

(3.6)

Где - (Cash Flow) денежный поток в k-й период, k = 1, 2, n;

n - горизонт расчета проекта = 30 месяцев;

IC - (Invested Capital) стартовая инвестиция в проект;

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

Следовательно, индекс прибыльности показывает, что с каждого вложенного в проект рубля инвестор заработает 13 копеек.

Для анализа инвестиций применяют и такой показатель, как срок окупаемости PBP (payback period method) - продолжительность времени, в течение которого дисконтированные на момент завершения инвестиций прогнозируемые денежные поступления равны сумме инвестиций. Иными словами - это период, необходимый для возмещения стартовых инвестиций.

Исходя из данных таблицы 3.4 построим график, на котором точка пересечения осей X и Y является сроком окупаемости проекта (рисунок 3.6).

Рисунок 3.6 - График срока окупаемости

В результате проведенного нами расчета окупаемость Web-сервиса составила 1 год и 3 месяца, после внедрения в деятельность компании.

Выводы

В третьей главе произведено обоснование выбора жизненного цикла информационной системы и выделено, что наиболее оптимальным вариантом модели является модель RAD. Создана структура пооперационного перечня работ (проект создания информационной системы реализован в Microsoft Project). Определены используемые в проекте ресурсы и на последнем этапе проведена оценка эффективности прототипа ИС, которая показала, что внедрение проекта целесообразно.

web сервис база данный кафедра физкультура

Заключение

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

В ходе выполнения ВКР был спроектирован и разработанWeb-сервис предоставления консультационных услуг компьютерной фирмы. Для этого:

1) был проведен анализ бизнес-процессов по предоставлению консультационных услуг;

2) был выбран объектно-ориентированный подход к реализации приложения;

3) были выбраны следующие программные продукты для разработки приложения:

– Microsoft Visual Studio 2013;

– Microsoft SQL Server 2008;

– MS Project 2010;

– MS Word 2010;

– MS Power Point 2010.

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

Во втором были проведены:

1) выбор технология реализации сервиса - шаблон MVC 4.0 .Net, обеспечивающий единую среду реализации проекта;

2) разработан интерфейс сервиса;

3) проведено моделирование структуры данных средствами MSVisualStudio2013 с использованием на модели ADO.NetEDM.

4) разработано приложение;

5) определена методология развертывания сервиса.

Произведено тестирование приложения по методу «белого ящика», которое показало, что приложение работает корректно.

В третьем разделе ВКР была определена модель жизненного цикла приложения. Проанализировав основные отличительные категории проекта, был выбран метод быстрой разработки приложений «RAD».

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

Расчет эффективности проекта осуществлен методом расчета чистого приведенного дохода.

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

Библиографический список

1. «Эскулап ИТ-Сервис» [Электронный ресурс]

2. ГУDLINE[Электронный ресурс]

3. Методические основы управления ИТ-проектами: учебник / В.И. Грекул, Н.Л. Коровкина, Ю.В. Куприянов. -- М.: Интернет Университет Информационных Технологий: БИНОМ. Лаборатория знаний, 2010. -- 391 с.

4. Вигерс, К. Разработка требований к программному обеспечению./ Пер. с англ. М.: Издательско-торговый дом «Русская редакция», 2004.

5. Infobox. [Электронный ресурс]

6. Создание Web-страниц и Web-сайтов. Самоучитель: [учеб. пособие] / под ред. В.Н. Печникова. - М.: Изд-во Триумф, 2006.-- 464 с.

7. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных. Учебник для вузов // Издание: Корона-принт, 2004 г.

8. Средства модели ADO.NETEDM. Microsoft Developer Network.

9. Фатрелл, Т. Управление программными проектами: достижение оптимального качества при минимуме затрат: Пер. с англ. / Р.Т. Фатрелл, Д.Ф. Шафер, Л.И. Шафер. - М.: Издательский дом «Вильямс», 2003

10. Касатов А.Д. Развитие экономических методов управления интегрированными корпоративными структурами в промышленности: инвестиционный аспект. М.: Изд. Дом «Экономическая газета», 2010. 324 с.

Приложение А

Техническое задание

Введение

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

1. Назначение разработки

1.1 Функциональным назначением СЕРВИСА является учёт:

– учет пользователей системы;

– ведение информационной поддержки деятельности кафедры физкультуры;

– ведение учебных и тренировочных материалов;

– мониторинг физического состояния студента;

– расписание обязательных и секционных занятий;

– анализ физического состояния студентов.

1.1. Эксплуатационное назначение СЕРВИСА

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

2. Требования к программе или программному изделию

2.1 Требования к функциональным характеристикам

Категории описания требований приведены в таблице 1.1.

Таблица 1

Категории описания требований

Категория	Описание
F	Функциональные требования, описывающие требуемую функциональность или прецеденты системы
C	Системные требования, такие как используемые платформы
P	Требования к представлению

Подобные документы

• Проектирование и разработка web-сервиса

  Проведение исследования опыта взаимодействия в сети. Методы улучшения согласования с пользователем web-сервиса. Особенность проектирования онлайн-приложения. Изучение разработки контроллеров и моделей. Характеристика создания интерфейса программы.
  
  дипломная работа [1,3 M], добавлен 11.08.2017
  

• Разработка интерфейса в виде веб-сервиса для федеральной службы

  Федеральная служба судебных приставов как федеральный орган исполнительной власти. Основные этапы разработки интерфейса в виде веб-сервиса. Общая характеристика схемы интерфейса "Пристав" для удаленного просмотра соединений таблиц из единой базы данных.
  
  отчет по практике [1,0 M], добавлен 07.08.2013
  

• Разработка сервиса агрегации открытых данных

  Обзор существующих решений на основе открытых данных. Выбор социальных сетей для извлечения данных. Ограничение геолокации сообщений из социальных сетей. Разработка формата хранения. Визуализация собранных данных методом теплой карты. Архитектура системы.
  
  дипломная работа [1,0 M], добавлен 18.11.2017
  

• Разработка информационной системы "Больница"

  Анализ предметной области. Обеспечение качества проектной документации. Построение инфологической (концептуальной) модели предметной области. Проектирование физической структуры базы данных. Разработка интерфейса, организация ввода и поиска данных.
  
  курсовая работа [2,5 M], добавлен 10.01.2016
  

• Разработка сервиса агрегации открытых данных и данных из социальных сетей

  Обзор существующих решений на основе открытых данных. Технологии обработки данных и методы их визуализации. Социальные сети для извлечения данных. Ограничение географической локации. Выбор набора и формат хранения открытых данных, архитектура системы.
  
  курсовая работа [129,5 K], добавлен 09.06.2017
  

• Разработка архитектуры программной системы "Библиотека"

  Обзор существующих объектных архитектур. Архитектура программного обеспечения. Создание веб-сервиса "Библиотека", предоставляющего механизмы работы с данными на стороне клиентского приложения. WEB-сервис и трехуровневая архитектура в основе приложения.
  
  лабораторная работа [1,5 M], добавлен 16.06.2013
  

• Проектирование web-сервиса шиномонтажной мастерской

  Анализ информационных потоков, связанных с деятельностью шиномонтажной мастерской. Разработка информационной модели данных. Описание технического задания на разработку web-сервиса. Составление планов управления конфигурациями и контроля качества.
  
  курсовая работа [3,7 M], добавлен 25.12.2014
  

• Создание веб-интерфейса для построения генеалогических деревьев

  Описание создаваемого сервиса. Разработка и реализация серверной части сервиса и клиентской части сервиса, которая будет предоставлять пользователям возможность создания и редактирования генеалогических деревьев, возможность импорта и экспорта данных.
  
  курсовая работа [116,9 K], добавлен 20.07.2012
  

• Проектирование базы данных "Аэропорт"

  Разработка базы данных для компании, занимающейся авиагрузоперевозками, снабженной средствами идентификации пользователей. Описание ее предметной области и функций. Разработка интерфейса программы. Построение концептуальной и реляционной модели БД.
  
  курсовая работа [2,1 M], добавлен 15.06.2014
  

• Анализ и моделирование бизнес-процессов системы физкультурно-спортивного воспитания населения на примере РГЭУ (РИНХ)

  Анализ российской законодательной базы по проблемам информатизации физкультурно-спортивного воспитания населения. Выбор архитектуры, проектирование пользовательского интерфейса. Разработка структуры модели данных. Надежность и эффективность Web-сервиса.
  
  дипломная работа [2,6 M], добавлен 05.04.2017
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам