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

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

АМС "Агент+ Инвент"

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

ST-Мобильная торговля

Программный комплекс для автоматизации локальных дистрибьюторов и небольших сетей с учетной системой на базе "1С: Предприятие". Решение объединяет инструменты для торговых агентов, мерчендайзеров, супервайзеров и руководителей компаний.

Офисная часть

Служит для управления агентами из вкладки "Мобильная торговля" программы "1С: Предприятие":

· позволяет обрабатывать и хранить информацию,

· обеспечивает обмен данными с КПК,

· отвечает за удаленное лицензирование и синхронизацию данных.

Мобильная часть

· Устанавливается на КПК полевых сотрудников, максимально упрощает работу на маршруте:

· обеспечивает доступ к необходимой информации,

· автоматизирует вычисления и расчеты,

· обменивается данными с учетной системой в онлайн режиме.

Сравнительный анализ методом анализа иерархий

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

1. Наличие локального и мобильного АРМ;

2. Хранение мультимедийной информации;

3. Осуществление постоянного информационного обмена с локальным АРМ

4. Автономная работа в случае отсутствия сигнала связи;

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

Затем для каждого критерия определяем коэффициент значимости. Коэффициенты распределяются на отрезке от 0 до 1.

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

,

где

Oзn - интегральная оценка заявленной методологии;

n - количество критериев сравнения заявленных методологий согласно таблице критериев;

Zi - значение оценки степени выполнения критерия.

Ki - коэффициент значимости критерия сравнения (от 0 до 1).

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

Таблица 3.1 - Оценка рассматриваемых аналогов

Оценка Критерий	Ki	Наполеон	Агент Плюс	ST-Мобильная торговля
		Zi	Zi·Ki	Zi	Zi·Ki	Zi	Zi·Ki
Наличие локального и мобильного АРМ;	0,3	4	1,2	4	1,2	3	0,9
Хранение мультимедийной информации;	0,2	4	0,8	5	1	3	0,6
Осуществление постоянного информационного обмена с локальным АРМ	0,3	3	0,9	2	0,6	2	0,6
Автономная работа в случае отсутствия сигнала связи	0,2	3	0,6	4	0,8	5	1
Интегральная оценка, Q		3,5	3,6	3,2

Метод экспертных оценок позволяет выбрать наилучшую альтернативу с учетом важности критериев. В моей решаемой задаче такой альтернативой является Агент Плюс. Данная система получила максимальную оценку в 3,6 балла. Однако если учесть, что оценка производилась по пятибалльной шкале, то ни одна из систем не удовлетворяет даже на уровне "хорошо" заявленным требованиям. Поэтому использование готовой системы не является приемлемым. Требуется спроектировать собственную ИС супервайзера, которая удовлетворит требования выделенных критериев более чем на 4,0 балла.

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

Обобщив сказанное выше, можно перечислить основные требования к ИС:

1. Формирование электронных бланков заказа;

2. Ввод и хранение данных о совершенных операциях;

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

3.2 Архитектура информационной системы

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

Таблица 3.2 - Типовые компоненты информационной системы

Обозна-чение	Наименование	Характеристика
PS	Presentation Services (средства представления)	Обеспечиваются устройствами, принимающими ввод от пользователя и отображающими результаты обработки.
PL	Presentation Logic(логика представления)	Управляет взаимодействием между пользователем и ЭВМ. Обрабатывает действия пользователя при выборе команды в меню, нажатии кнопки или выборе элемента из списка.
BL	Business or Application Logic (прикладная логика)	Набор правил для принятия решений, вычислений и операций, которые должно выполнить приложение.
DL	Data Logic (логика управления данными)	Операции с базой данных (SQL-операторы), которые нужно выполнить для реализации прикладной логики управления данными.
DS	Data Services (операции с базой данных)	Действия СУБД, вызываемые для выполнения логикиу правления данными, такие как: манипулирование данными, определение данных, фиксация или откат транзакций и т. п. СУБД обычно компилирует SQL-предложения.
FS	File Services (файловые операции)	Дисковые операции чтения и записи данных для СУБД (файловые операции) и других компонентов. Обычно являются функциями операционной системы (ОС)

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

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

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

Архитектура клиент-сервер предназначена для разрешения проблем файл-серверной архитектуры путем разделения компонентов приложения и размещения их там, где они будут функционировать наиболее эффективно. Особенностью архитектуры клиент-сервер является использование выделенных серверов баз данных, понимающих запросы на языке структурированных запросов SQL (Structured Query Language) и выполняющих поиск, сортировку и агрегирование информации.

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

Большинство конфигураций клиент-сервер использует двухуровневую модель, в которой клиент обращается к услугам сервера. Предполагается, что диалоговые компоненты PS и PL размещаются на клиенте, что позволяет обеспечить графический интерфейс. Компоненты управления данными DS и FS размещаются на сервере, а диалог (PS, PL), логики BL и DL - на клиенте. Двухуровневая архитектура клиент-сервер использует именно этот вариант: приложение работает на клиенте, СУБД - на сервере.

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

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

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

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

Многоуровневая архитектура стала развитием архитектуры клиент-сервер и в классической форме состоит из трех уровней:

· нижний уровень представляет собой приложения клиентов, выделенные для выполнения функций и логики представлений PS и PL и имеющие программный интерфейс для вызова приложения на среднем уровне;

· средний уровень представляет собой сервер приложений, на котором выполняется прикладная логика BL и с которого логика обработки данных DL вызывает операции с базой данных DS;

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

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

Централизация логики приложения упрощает администрирование и сопровождение. Четко разделяются платформы и инструменты для реализации интерфейса и прикладной логики, что позволяет с наибольшей отдачей реализовывать их специалистами узкого профиля. Наконец, изменения прикладной логики не затрагивают интерфейс, и наоборот. Но поскольку границы между компонентами PL, BL и DL размыты, прикладная логика может появиться на всех трех уровнях. Сервер приложений с помощью монитора транзакций обеспечивает интерфейс с клиентами и другими серверами, может управлять транзакциями и гарантировать целостность распределенной базы данных. Средства удаленного вызова процедур наиболее соответствуют идее распределенных вычислений: они обеспечивают из любого узла сети вызов прикладной процедуры, расположенной на другом узле, передачу параметров, удаленную обработку и возврат результатов. С ростом систем клиент-сервер необходимость трех уровней становится все более очевидной.

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

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

Критериями оценивания описанных выше трех альтернатив будут:

а) Простота реализации;

б) Простота обновления ПО;

в) Затраты на эксплуатацию и установку.

Присвоим наиболее важному критерию оценку 100 баллов. Исходя из попарного отношения критериев по важности, дадим в баллах оценку каждому из критериев (таблица 3.3):

Таблица 3.3 - Оценка критериев

Критерии	Баллы
Простота реализации	100
Простота обновления ПО	85
Затраты на эксплуатацию и установку	75

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

где Ai - баллы критерия,

n - количество критериев.

Результаты нормировки приведены в таблице 3.4



Таблица 3.4 - Нормированные оценки критериев

Критерии	Баллы	Нормировка весов
Простота реализации	100	0,384615385
Простота обновления ПО	85	0,326923077
Затраты на эксплуатацию и установку	75	0,288461538
сумма баллов	260	1

Измерим значение каждой альтернативы по каждому из критериев по шкале от 0 до 100 баллов.

Таблица 3.5 - Оценка альтернатив

Альтернативы	Критерии
	Простота реализации	Простота обновления ПО	Затраты на эксплуатацию и установку
Файл-сервер	90	70	95
Клиент-сервер	85	85	90
Многоуровневая	75	80	75

Определим общую оценку каждой альтернативы, используя формулу взвешенной суммы баллов общая оценка альтернативы - , где Вi оценка альтернативы по каждому критерию (таблица 3.6)

Таблица 3.6 - Общая оценка альтернатив

Альтернативы	Критерии
	Простота реализации	Простота обновления ПО	Затраты на эксплуатацию и установку	Общая оценка
Файл-сервер	34,6153846	22,8846153	27,4038461	84,9038461
Клиент-сервер	32,6923076	27,7884615	25,9615384	86,4423076
Многоуровневая	28,8461538	23,0769230	21,6346153	73,5576923

Выберем как лучшую альтернативу, имеющую наибольшую общую оценку - это архитектура Клиент-Сервер.

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

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

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

Через мобильный АРМ просматриваются задания и сообщения от супервайзеров. В обратном направлении отсылаются результаты проделанной работы и заказы на поставку товаров.

3.3 Варианты использования информационной системы

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

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

Рисунок 3.1. - Диаграмма вариантов использования информационной системы супервайзера

3.4 Разработка модели данных информационной системы супервайзера

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

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

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

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

Модель данных нашей системы содержит 8 сущностей с их атрибутами:

§ Ассортимент (хранение данных об ассортименте продукции);

§ Остаток на дату (остатки товаров на складе);

§ Клиент (клиентов, совершивших заказ);

§ Скидка (справочник скидок).

§ Заказ (заказ, совершенный клиентом)

§ Элемент заказа (товарная позиция, принадлежащая заказу)

§ Задание (задание, выданное супервайзером)

§ Результат (результат, достигнутый мерчендайзером при выполнении задания)

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

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

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

Рисунок 3.2 - Физическая модель базы данных информационной системы супервайзера

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



Глава 4. Разработка информационной системы автоматизированной проверки отчетной документации торговых представителей

4.1 Выбор и обоснование устройства для установки информационной системы

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

Будем рассматривать устройства, которые в первую очередь обладают оптимальным соотношением таких качеств, как цена, производительность и простота разработки приложений под это устройство. Сейчас наиболее распространенной является мобильная ОС Android. Она практически вытеснила Windows Mobile. Apple iOS работает лишь на дорогостоящих устройствах и я ее рассматривать не буду. Под составленное описание попадают следующие устройства (2 смартфона и 2 планшета):

1. Планшетный компьютер ViewSonic VPAD10S

2. Планшетный компьютер Qumo Flame 8Gb 3G

3. Смартфон Acer Liquid MT S120 Br

4. Смартфон Samsung Galaxy Ace GT-S5830 Black

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

1. Стоимость

2. Процессор

3. Объем оперативной памяти

4. Время автономной работы

5. Поддержка Wi-Fi

6. Поддержка карт памяти

7. Размер экрана

Воспользуемся методом анализа иерархий.

Выполним попарное сравнение критериев и определим наиболее важные (см. таблицу 4.1)

Таблица 4.1 - Сравнение критериев

Критерии	Стоимость	Процессор	Объем оперативной памяти	Время автономной работы	Поддержка Wi-Fi	Поддержка карт памяти	Размер экрана	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
Стоимость	1	1/2	1/3	4	2	3	1/4	1	0,0959715
Процессор	2	1	1/2	6	4	5	1/3	1,693813	0,1625579
Объем оперативной памяти	3	2	1	8	6	7	1/2	2,685748	0,2577555
Время автономной работы	1/4	1/6	1/8	1	1/3	1/2	1/8	0,271417	0,0260483
Поддержка Wi-Fi	1/2	1/4	1/6	3	1	2	1/7	0,562676	0,0540009
Поддержка карт памяти	1/3	1/5	1/7	2	1/2	1	1/9	0,375784	0,0360646
Размер экрана	4	3	2	8	7	9	1	3,830310	0,3676009

Далее попарно сравним альтернативы по критериям.

Таблица 4.2 - Данные по критерию "Стоимость"

ViewSonic	8000 рублей
Qumo Flame	1000 рублей
Acer Liquid MT	9900 рублей
Samsung Galaxy	9600 рублей

Таблица 4.3 - Сравнительный анализ альтернатив по критерию "Стоимость"

	ViewSonic	Qumo Flame	Acer Liquid MT	Samsung Galaxy	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
ViewSonic	1	4	3	2	2,213363839	0,466848564
Qumo Flame	1/4	1	1/2	1/3	0,451801002	0,095295064
Acer Liquid MT	1/3	2	1	1/2	0,759835686	0,160266555
Samsung Galaxy	1/2	3	2	1	1,316074013	0,277589817



Таблица 4.4 - Данные по критерию "Процессор"

ViewSonic	NVIDIA Tegra 250,1 ГГц
Qumo Flame	ARM Ltd. , Cortex A8, 800 МГц
Acer Liquid MT	Qualcomm, MSM 7230-1, 800 МГц
Samsung Galaxy	Qualcomm, MSM7227, 800 МГц

Таблица 4.5 - Сравнение альтернатив по критерию "Процессор"

	ViewSonic	Qumo Flame	Acer Liquid MT	Samsung Galaxy	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
ViewSonic	1	2	3	3	2,059767144	0,453084941
Qumo Flame	1/2	1	2	2	1,189207115	0,261588713
Acer Liquid MT	1/3	1/2	1	2	0,759835686	0,167140304
Samsung Galaxy	1/3	1/2	1/2	1	0,537284966	0,118186042

Таблица 4.6 - Данные по критерию "Объем оперативной памяти"

ViewSonic	512 МБ, DDR2 SDRAM, 667 МГц
Qumo Flame	512 МБ, DDR2 SDRAM, 667 МГц
Acer Liquid MT	512 МБ, Mobile
Samsung Galaxy	512 МБ, Mobile

Таблица 4.7 - Сравнение альтернатив по критерию "Объем оперативной памяти"

	ViewSonic	Qumo Flame	Acer Liquid MT	Samsung Galaxy	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
ViewSonic	1	1	2	2	1,414213562	0,333333333
Qumo Flame	1	1	2	2	1,414213562	0,333333333
Acer Liquid MT	1/2	1/2	1	1	0,707106781	0,166666667
Samsung Galaxy	1/2	1/2	1	1	0,707106781	0,166666667

Таблица 4.8 -

Данные по критерию "Время автономной работы"

ViewSonic	7,5 часов
Qumo Flame	10 часов
Acer Liquid MT	11 часов
Samsung Galaxy	6 часов

Таблица 4.9 - Сравнение альтернатив по критерию "Время автономной работы"

	ViewSonic	Qumo Flame	Acer Liquid MT	Samsung Galaxy	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
ViewSonic	1	1/4	1/6	2	0,537285	0,091873
Qumo Flame	4	1	1/2	6	1,86121	0,318257
Acer Liquid MT	6	2	1	8	3,130169	0,535242
Samsung Galaxy	1/2	1/6	1/8	1	0,319472	0,054628

Таблица 4.10

- Данные по критерию "Поддержка Wi-Fi"

ViewSonic	Wi-Fi IEEE 802.11b/g
Qumo Flame	Wi-Fi IEEE 802.11b/g/n
Acer Liquid MT	Wi-Fi IEEE 802.11b/g/n
Samsung Galaxy	Wi-Fi IEEE 802.11b/g/n

Таблица 4.11 - Сравнение аналогов по критерию "Автономная работа"

	ViewSonic	Qumo Flame	Acer Liquid MT	Samsung Galaxy	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
ViewSonic	1	1/2	1/2	1/2	0,594603558	0,142857143
Qumo Flame	2	1	1	1	1,189207115	0,285714286
Acer Liquid MT	2	1	1	1	1,189207115	0,285714286
Samsung Galaxy	2	1	1	1	1,189207115	0,285714286

Таблица 4.12

- Данные по критерию "Поддержка карт памяти"

ViewSonic	microSD, microSDHC до 32 Гб
Qumo Flame	microSD, microSDHC до 32 Гб
Acer Liquid MT	microSD, microSDHC до 32 Гб, в комплекте 2Гб
Samsung Galaxy	microSD, microSDHC до 32 Гб, в комплекте 2Гб



Таблица 4.13

- Сравнение альтернатив по критерию "Поддержка карт памяти"

	ViewSonic	Qumo Flame	Acer Liquid MT	Samsung Galaxy	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
ViewSonic	1	1	1/2	1/2	0,707106781	0,166666667
Qumo Flame	1	1	1/2	1/2	0,707106781	0,166666667
Acer Liquid MT	2	2	1	1	1,414213562	0,333333333
Samsung Galaxy	2	2	1	1	1,414213562	0,333333333

Таблица 4.14

- Данные по критерию "Размер экрана"

ViewSonic	10.1"(25.7 см), 1024 x 600 Пикс
Qumo Flame	8"(20.3 см), 800 x 480 Пикс
Acer Liquid MT	3.6"(9.1 см), 800 x 480 Пикс
Samsung Galaxy	3.5"(8.9 см), 320 х 480 Пикс

Таблица 4.15

- Сравнение альтернатив по критерию "Размер экрана"

	ViewSonic	Qumo Flame	Acer Liquid MT	Samsung Galaxy	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
ViewSonic	1	2	3	5	2,340347	0,483189
Qumo Flame	1/2	1	2	3	1,316074	0,271717
Acer Liquid MT	1/3	1/2	1	2	0,759836	0,156876
Samsung Galaxy	1/5	1/3	1/2	1	0,427287	0,088218

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



Таблица 4.16 - Окончательное сравнение альтернатив

Альтернатива	Критерии	Глобальные приоритеты
	Стоимость	Процессор	Объем оперативной памяти	Время автономной работы	Поддержка Wi-Fi	Поддержка карт памяти	Размер экрана
	Численное значение вектора приоритета
	0,0959	0,1625	0,2577	0,0260	0,0540	0,03606	0,3676
ViewSonic	0,4668	0,4530	0,3333	0,0918	0,1428	0,16666	0,4831	0,3981
Qumo Flame	0,0952	0,2615	0,3333	0,3182	0,2857	0,16666	0,2717	0,2672
Acer Liquid MT	0,1602	0,1671	0,1666	0,5352	0,2857	0,33333	0,1568	0,1845
Samsung Galaxy	0,2775	0,1181	0,1666	0,0546	0,2857	0,33333	0,0882	0,1501

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

4.2 Выбор среды разработки информационной системы

АРМ СУПЕРВАЙЗЕРА

В качестве программного обеспечения для разработки системы можно выбрать Visual Studio, Delphi, 1С:Предприятии 8.0. Delphi и Visual Studio позволяют создавать любые программы: приложения баз данных, драйверы устройств и т.д. Эти системы являются универсальными, что делает процесс разработки информационной системы более сложным и длительным.

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

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

2. передавать управление различным процессам, в зависимости от состояния системы;

3. создавать оболочки для баз данных, как и сами базы данных;

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

Рассмотрим наиболее распространенные среды программирования от ведущих компаний-производителей, к ним можно отнести Microsoft Visual C++; Borland C++ Builder; Borland Delphi.

1) Microsoft Visual C++ - система программирования Microsoft Visual C++ представляет собой реализацию среды разработки для распространенного языка системного программирования C++. Эта система программирования в настоящее время построена в виде интегрированной среды разработки, включающей в себя все необходимые средства для разработки программ, под управлением ОС типа Microsoft Windows различных версий.

Основу системы программирования Microsoft Visual C++ составляет библиотека классов MFC (Microsoft foundation classes). В этой библиотеке реализованы в виде классов C++ все основные органы управления и интерфейса ОС. Также в ее состав входят классы, обеспечивающие разработку приложений для архитектуры "клиент - сервер" и трехуровневой архитектуры. Система программирования Microsoft Visual C++ позволяет разрабатывать любые приложения, выполняющиеся в среде ОС типа Microsoft Windows, в том числе серверные или клиентские программы. Классы библиотеки MFC ориентированы на использование технологий СОМ/ DCOM, а также построенной на их основе технологии ActiveX для организации взаимодействия между клиентской и серверной частью разрабатываемых приложений.

В отличие от систем программирования компании Borland, система программирования Microsoft Visual C++ ориентирована на использование стандартных средств хранения и обработки ресурсов интерфейса пользователя в ОС Windows. Microsoft Visual C++ обеспечивает все необходимые средства для создания профессиональных Windows-приложений.

Сама по себе библиотека MFC является удачной реализацией широкого набора классов языка C++, ориентированного на разработку результирующих программ, выполняющихся под управлением ОС типа Microsoft Windows. Библиотека может быть подключена к результирующей программе с помощью обычного компоновщика либо использоваться как динамическая библиотека, подключаемая к программе во время ее выполнения.

2) Borland C++ Builder - система программирования Borland C++ Builder объединила в себе идеи интегрированной среды разработки, реализованные компанией в системах Turbo Pascal и Borland Delphi с возможностями языка программирования C++. Основа для Borland C++ Builder, среда Turbo С представляла собой реализацию идей, заложенных компанией в системе программирования Turbo Pascal, для языка программирования С. Компилятор Turbo С не был однопроходным, и потому время компиляции программы превышало время компиляции аналогичной программы в Turbo Pascal. Преимущество Turbo С заключалось в том, что эта система программирования строилась на базе стандартного языка программирования С. Данный язык широко распространен среди разработчиков в качестве языка системного программирования. Современная реализация Borland C++ Builder ориентирована на разработку программ, выполняющихся под управлением ОС Microsoft Windows всех типов. Сама система программирования Borland C++ Builder, как и Borland Delphi, также функционирует под управлением ОС типа Microsoft Windows. Он полностью поддерживает стандарт языка С, что делает возможным создание с помощью данной системы программирования модулей и библиотек, используемых в других средствах разработки (чего очень сложно достигнуть с помощью Borland Delphi). автоматизация программный архитектура супервайзер

По параметрам система программирования Borland C++ Builder схожа с системой программирования Borland Delphi. В ее основу положены те же основные идеи и технологии. Структура классов языка C++ в системе программирования Borland C++ Builder построена в той же библиотеке VCL (visual control library), в которой строится структура классов Object Pascal в системе программирования Borland Delphi.

3) Borland Delphi - система программирования Borland Delphi явилась продолжением и развитием идей, заложенных еще в системе программирования Turbo Pascal. Можно указать его следующие принципиальные отличия:

новый язык программирования - Object Pascal;

компонентная модель среды разработки, ориентированная на технологию RAD (rapid application development).

В языке Object Pascal Компания Borland попыталась учесть все недостатки существующих языков объектно-ориентированного программирования. Компонентная модель среды разработки предусматривает создание основной части программы в виде набора взаимосвязанных компонентов - классов объектно-ориентированного языка. Во время разработки исходной программы компоненты предстают в виде графических образов и обозначений, связанных между собой. Каждый компонент обладает определенным набором свойств, событий и методов. Каждому из них соответствует свой фрагмент исходного кода программы, отвечающий за обработку метода или реакции на какое-то событие. Основу системы программирования Borland Delphi и ее компонентной модели составляет библиотека VCL (visual component library). В этой библиотеке реализованы в виде компонентов все основные органы управления и интерфейса ОС. В качестве недостатков данной системы программирования можно указать нестандартный формат для хранения ресурсов пользовательского интерфейса и кроме того, сам язык Object Pascal не является признанным стандартом. Тем не менее система программирования Borland Delphi получила широкое распространение среди разработчиков.

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

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

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

Таблица 4.17 - Критерии сравнения среды программирования

Критерии	Borland Delphi	Microsoft Visual C++	Borland C++ Builder
Требования к ресурсам	2	1	2
Наглядность разработки интерфейса	4	2	4
Предоставляемые возможности работы с базами данных	3	1	3
Скорость разработанного ПО	2	2	4
Удобство эксплуатации	2	3	3
Всего:	13	9	16

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

АРМ ТОРГОВОГО ПРЕДСТАВИТЕЛЯ

Для разработки ПО под ОС Android используются следующие среды [12]:

1. Netbeans + AndroidPlugin;

2. Eclipse+ ADT;

3. Motodev Studio for Android.

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

Сравнение произведем на основе следующих критериев:

- удобство в работе;

- встроенный эмулятор;

- русификация интерфейса;

- помощь при программировании.

Сведем для удобства данные по указанным средам и критериям в одну таблицу (см. табл. 4.18)

Таблица 4.18 - Сводные данные по критериям

Среда Критерий	Google SDK	Eclipse+ ADT	Motodev Studio for Android
удобство в работе	Низкий уровень удобства	Высокий уровень удобства	Средний уровень удобства
встроенный эмулятор	Есть	Есть	Есть
русификация интерфейса	Нет	Есть	Нет
помощь при программировании	Автоподстановка, подстветка элементов кода	Автоподстановка, подстветка элементов кода, проверка в режиме реального времени	Автоподстановка, подстветка элементов кода

Сравним критерии, используя шкалу, представленную в таблице 4.19.

Таблица 4.19 - Сравнение критериев

Критерии	удобство в работе	встроенный эмулятор	русификация интерфейса	помощь при программировании	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
удобство в работе	1	6	4	3	2,91295063	0,557183179
встроенный эмулятор	1/6	1	1/4	1/3	0,343294524	0,065664667
русификация интерфейса	1/4	3	1	1/2	0,78254229	0,149683073
помощь при программировании	1/3	3	2	1	1,189207115	0,22746908

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



Таблица 4.20 Сравнение альтернатив по критерию "удобство в работе".

Критерии	Netbeans + AndroidPlugin;	Eclipse+ ADT;	Motodev Studio for Android	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
Netbeans + AndroidPlugin;	1	1/4	1/2	0,50034669	0,1429986
Eclipse+ ADT;	4	1	2	1,99861418	0,5712022
Motodev Studio for Android	2	1/2	1	1	0,2857991

Таблица 4.21 - Сравнение по критерию "Встроенный эмулятор"

Критерии	Netbeans + AndroidPlugin;	Eclipse+ ADT;	Motodev Studio for Android	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
Netbeans + AndroidPlugin;	1	1	1	1	0,3333333
Eclipse+ ADT;	1	1	1	1	0,3333333
Motodev Studio for Android	1	1	1	1	0,3333333

Таблица 4.22 - Сравнение альтернатив по критерию "Русскоязычный интерфейс"

Критерии	Netbeans + AndroidPlugin;	Eclipse+ ADT;	Motodev Studio for Android	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
Netbeans + AndroidPlugin;	1	1/4	1	0,63025169	0,1668207
Eclipse+ ADT;	4	1	4	2,51751434	0,6663585
Motodev Studio for Android	1	1/4	1	0,63025169	0,1668207

Таблица 4.23 - Сравнение альтернатив по критерию "помощь при программировании"

Критерии	Netbeans + AndroidPlugin;	Eclipse+ ADT;	Motodev Studio for Android	Оценка компонент собственного вектора	Нормализованные оценки вектора приоритета
Netbeans + AndroidPlugin;	1	1/2	1	0,79388393	0,2500866
Eclipse+ ADT;	2	1	2	1,58666768	0,4998267
Motodev Studio for Android	1	1/2	1	0,79388393	0,2500866

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

Таблица 4.24 - Сравнение и окончательный выбор альтернатив

Альтернатива	Критерии	Глобальные приоритеты
	удобство в работе	встроенный эмулятор	русификация интерфейса	помощь при программировании
	Численное значение вектора приоритета
	0,55718317	0,06566466	0,14968307	0,22746908
Netbeans + AndroidPlugin	0,142999	0,3333	0,1668	0,2501	0,183422
Eclipse+ ADT;	0,571202	0,3333	0,6664	0,4998	0,55359
Motodev Studio for Android	0,285799	0,3333	0,1668	0,2501	0,262988

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