Аналіз методів інтернет-маркетингу і теорії прийняття рішень на прикладі Web-технології

 

Окончание табл.2.7

1	2	3	4	5
LR-01	Программа распространяется бесплатно, при условии, что заказчик не выдвигает требований к лицензированию	Рекомендуется	Средняя	Интернет-маркетолог
10. Предостережение относительно  вопросов, связанных с авторскими  правами
СR-01	Авторские права принадлежат разработчику программы	Обязательно	Средняя	Интернет-маркетолог
11. Подержанные стандарты
SU-01	Стандарт качества программного продукта	Рекомендуется	Средняя	Интернет-маркетолог
SU-02	Качестве кода, как дизайна так и логики написания функций.	Обязательно	Средняя	Интернет-маркетолог
SU-03	Доступность для устройств	Рекомендуется	Низкая	Интернет-маркетолог

 

Выводы

 

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

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

 

 

РАЗДЕЛ 3

ПРОЕКТНЫЕ И ТЕХНИЧЕСКИЕ РЕШЕНИЯ

 

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

 

3.1. Математическая  постановка задачи

 

Среди методов Интернет-маркетинга можно выделить два основных направления. Это методы исследования рынка и методы продвижения и продажи.

Для целей исследования рынка применяются такие методы и технологии: прямая регистрация посетителей сервера;

анализ и учет интересов посетителей по активности взаимодействия со встроенными поисковыми системами;

электронные опросы посетителей;

интерактивное взаимодействие.

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

помещение рекламы на собственном сервере;

рассылка электронных писем потенциальным клиентам;

участие в сетевых телеконференциях.

Непрямая реклама в Интернете использует регистрацию сервера в известных поисковых машинах, включение бесплатных ссылок на свой сервер во все известные Web-каталоги, «желтые страницы», тематические серверы (Jump Stations), размещение взаимных ссылок и рекламы на дружественных серверах, размещение платных рекламных объявлений на хорошо посещаемых серверах, подготовку и публикацию на других серверах интересных тематических материалов со ссылками на свой сервер, включение имени (адреса) сервера в несетевую рекламу (на традиционных носителях).

 

3.1.1. Концептуальное инфологичное проектирование.

Инфологическую уровень представляет собой информационно - логическую модель (ИЛМ) предметной области, в которой исключена избыточность данных и отображены информационные особенности объекта управления, без учета особенностей и специфики конкретной СУБД [25].

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

корректность схемы БД;

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

ИЛМ описана на языке, понятном проектировщикам БД, программистам, администратору и будущим пользователям;

Основной составляющей инфологической модели является атрибуты, которые нужно проанализировать и некоторым образом сгруппировать для дальнейшего хранения в БД. Сущность инфологического моделирования заключается в выделении информационных объектов, которые подлежат хранению в БД, а также определении характеристик объектов и связей между ними. Характеристиками или свойствами объектов имеются атрибуты [8].

Словарь данных, содержащихся в таблицах базы данных, приведен в табл. 3.1. 

Таблица 3.1

Словарь данных

№ п/п	Наименование элемента	Тип и длина	Назначение элемента
1	2	3	4
1	Код сотрудника	Int 32	Хранит  код сотрудника
2	ФИО	Varchar(20)	Хранит ФИО сотрудника
4	Фото	Varchar(20)	Хранит фото сотрудника
5	Электронный адресс	Varchar(20)	Хранит электронный адресс сотрудника
6	Код задачи	Int 32	Хранит  код задачи
7	Тема	Varchar(20)	Хранит тему задачи
9	Дата начала	Datetime	Хранит дату начала задачи

 

Окончание табл. 3.1

1	2	3	4
10	Дата окончания	Datetime	Хранит дату окончания задачи
11	Статус	Varchar(20)	Хранит статус задачи
13	Код клиента	Int 32	Хранит код клиента
14	ФИО	Varchar(20)	Хранит ФИО клиента
15	Компания	Varchar(20)	Хранит компанию клиента
16	Электронный адреса клиента	Varchar(20)	Хранит эдектронный адреса клиента
17	Код отзыва	Int 32	Хранит код отзыва
18	Дата создания	Datetime	Хранит дату создания отзыва
19	Тег	Varchar(20)	Хранит тег отзыва
20	Описание	Varchar(20)	Хранит описание отзыва

 

3.1.2. Проектирование глобальной логической модели данных

Структура логической модели данных (рис.3.2) отражает структуру элементов, находящихся в базе данных.

Она описывает семантику предметной области и не учитывает особенности конкретной СУБД. По данной логической схеме построена физическая модель (рис. 3.3), в которой учтены такие особенности СУБД, как допустимые типы и наименования полей.

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

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

Эффективность обеспечена выбором комплекса технических средств, выбором СУБД, проектированием оптимальной логической и физической модели данных в процессе физического проектирования БД [12].

Таблица 3.4

Ограничение уникальности

№ п/п	Атрибут или группа атрибутов	Среди каких экземпляров, которой сущности или связи имеет место уникальность
1	Задачи. Код_ Задачи	Для всех экземпляров сущности «Задачи»
2	Сотрудники.Код_ Сотрудника	Для всех экземпляров сущности «Сотрудники»
3	Клиенты.Код_ Клиента	Для всех экземпляров сущности «Клиенты»
5	Отзывы.Код_ Отзыва	Для всех экземпляров сущности «Роль»

 

Таблица 3.5

Динамические ограничения

№ п/п	Группа атрибутов	Ограничения
1	Задачи. Код_ Задачи	Код_ Задачи = Код_ Задачи +1 - значение атрибута курс может только увеличиваться на единицу.
2	Сотрудники.Код_ Сотрудника	Код_ Сотрудника = Код_ Сотрудника +1 - значение атрибута курс может только увеличиваться на единицу.
3	Клиенты.Код_ Клиента	Код_ Клиента = Код_ Клиента +1 - значение атрибута курс может только увеличиваться на единицу.
4	Отзывы.Код_ Отзыва	Код_ Отзыва = Код_ Отзыва +1 - значение атрибута курс может только увеличиваться на единицу.

 

3.1.3. Проектирование физической модели данных

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

 

3.2. Разработка архитектуры программной системы

 

3.2.1. Диаграмма классов.

Диаграмма классов отражает основные классы системы.

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

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

 

 

Рис.3.4. Диаграмма основных классов

 

60

Рис 3.2. Логическая структура модели данных

 

 

Рис. 3.3. Структура физической модели данных

 

 

3. Тестирование приложения

 

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

Целью тестирования приложения является проверка корректной работы и функционирования.

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

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

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

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

 

Функциональное тестирование представлено в приложении Б. (табл. Б.4)

 

3.3.1. Тестирование графического интерфейса пользователя

При тестировании графического интерфейса используется следующий подход:

1) все действия по тестированию выполняются в ручном режиме;

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

Целью тестирования графического интерфейса является нахождение недоработок в графическом интерфейсе в ходе проведения различных оценок после завершения написания проекта [12].

Базовое тестирование, тестирование валидации и тестирования «usability» приведено в прил. Б.