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

Федеральное государственное автономное образовательное учреждение
высшего профессионального образования
НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ
ВЫСШАЯ ШКОЛА ЭКОНОМИКИ
МОСКОВСКИЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ
НАЦИОНАЛЬНОГО ИССЛЕДОВАТЕЛЬСКОГО УНИВЕРСИТЕТА
«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к дипломному проекту
На тему “Автоматизированная информационная система содействия реализации
Государственной программы энергосбережения города Москвы”
Студент Гребенюк Александр Владимирович
Руководитель проекта Иванова Елена Михайловна
Допущен к защите ____________2013г.
КОНСУЛЬТАНТЫ ПРОЕКТА:
Специальная часть
А.В. Вишнеков
Рецензент
Л.П. Шумская
Зав. кафедрой__________________
МОСКВА
2013
Аннотация
В данной дипломной работе была спроектирована и разработана система
для организации работы предприятий города Москвы энергетического комплекса. Приведен обзор существующих систем и обосновано решение о написании собственного программного продукта. Был проведён анализ существующего системного и инструментального программного обеспечения, необходимого для разработки системы.
В разделе «Разработка» проводится анализ и моделирование предметной
области, описывается разработка структуры базы данных и создание программного обеспечения. Выполнен анализ архитектуры API Яндекс.Карт 2.0 и создан
детальный прототип пользовательского интерфейса на основе ранее построенной концептуальной модели. Приводятся результаты тестирования прототипа
интерфейса и расчеты надежности системы, а также описываются мероприятия
по улучшению показателей эффективности созданного ПО.
В разделе "Экономическая часть" произведен расчет всех затрат на создание АИС в течение трех месяцев и ожидаемой прибыли.
В разделе "Охрана труда" приведен обзор источников искусственного
освещения с выявлением наиболее перспективных и рекомендации по защите
здоровья от вредных и опасных факторов, возникающих при излучении ламп.
Приложение к пояснительной записке содержит графический материал.
2
Оглавление
Аннотация .................................................................................................................... 2
Оглавление ................................................................................................................... 3
1. Специальная часть .................................................................................................. 4
Введение ................................................................................................................... 4
1.1 Постановка задачи ......................................................................................... 4
1.2 Обзор существующих решений ................................................................... 5
1.3 Выбор инструментов разработки ............................................................... 28
1.4 Разработка .................................................................................................... 46
1.4.1 Разработка прототипа системы ......................................................... 46
1.4.2 Разработка архитектуры системы..................................................... 55
1.4.3 Реализация системы ........................................................................... 63
1.5 Оптимизация и расчет надежности системы ............................................ 78
2. Экономическая часть ............................................................................................ 84
3. Охрана труда .......................................................................................................... 88
Заключение................................................................................................................. 91
Приложение 1. Графический материал ................................................................... 92
Список используемых источников ........................................................................ 100
3
1. Специальная часть
Введение
Данная
квалификационная
обеспечивающей
сотрудниками
взаимодействие
внутри
работа
между
организации,
а
посвящена
созданию
начальником
также
между
отдела
системы,
и
организацией
его
и
субподрядчиками.
1.1 Постанов ка задачи
Целью данной работы является разработка системы, позволяющей
организовать и автоматизировать работу разъездных бригад, обслуживающих
осветительные установки города Москвы.
Актуальность. Традиционные средства, которые обычно используются в
государственных организациях энергетического комплекса для формирования
межведомственного взаимодействия, а также кооперации между сотрудниками
отдела внутри организации, не предоставляют достаточных функций, гибкости
и удобства для эффективной работы. Актуальность поставленной задачи
обусловлена необходимостью автоматизации работы сотрудников таких
организаций для повышения скорости и корректности принятия решений в
рамках реализации государственной программы.
Задачи, решенные в данной работе:
1. анализ существующих на рынке технологических решений;
2. выявление требований к программному обеспечению и средствам
разработки;
3. проектирование системы;
4. реализация системы.
Практическая значимость данной работы подтверждена успешной
эксплуатацией разработанного программного продукта в ГУП «Моссвет».
4
1.2 Обзор существующих решений
АИС РФС АПК
АИС РФС АПК – информационная система, использующая в качестве базы
данных «Реестр федеральной собственности агропромышленного комплекса»
[15]. Файловое хранилище объединяет данные нескольких генеральных
заказчиков и субподрядчиков. Доступ реализуется с помощью браузера через
сеть Интернет. Схема доступа к базе данных показана на следующем рисунке:
Браузер на
компьютере
клиента
Сеть
Интернет
Сервер
приложений
Сервер баз
данных
Рис 1. Схема доступа клиента к базе данных
Контроль доступа к информации из базы данных происходит с помощью
механизма идентификации. Система определяет пользователя с помощью
формы авторизации. Экранная форма авторизации показана на следующем
рисунке:
Рис 2. Авторизация в АИС РФС АПК
5
После успешной авторизации и загрузки системы пользователь может
работать с определенными сущностями из реестра объектов. Экранная форма
программы на данном этапе работы выглядит на следующем рисунке:
Рис 3. Показ формы для выбранного объекта
Над списком объектов находится строка с возможностью поиска по
названию объекта. Поиск возможен как по полному названию, так и по его
части. Для этого необходимо ввести запрос в строку поиска и нажать кнопку
«Выполнить поиск» (или “Enter” на клавиатуре):
Рис 4. Поиск объектов по названию
6
Также стоит отметить наличие возможности загрузки множественного
списка объектов.
Рис 5. Загрузка файла с данными
Технологии, используемые в рассматриваемой системе, позволяют ввести
детальный учет объектов (в данном случае земель, различных тендеров,
относящихся к агропромышленному комплексу). ГИС-модуль делает удобной
навигацию по данным объектам. Существует возможность отображения
(скрытия) по категориям. Учетно-аналитический блок системы объединен с
геоинформационным модулем. Создание системы соответствует тенденции
«электронного правительства», главным направлением которой является
использование «безбумажной» кооперации между подрядчиками.
Таким образом, перспективой АИС РФС АПК является ее развитие в
вертикально - интегрированную систему управления земельно-имущественным
комплексом Министерства сельского хозяйства России в соответствии с
технологиями «электронного правительства».
АИС «ОГД»
АИС
«ОГД»
ориентирована
на
учет
объектов
градостроительной
деятельности [16]. Для доступа к информацию к данным объектам в системе
7
имеется веб-интерфейс, что позволяет просматривать информацию вне
зависимости от используемого пользователем программного обеспечения .
Программный комплекс рассматриваемой автоматизированной системы
реализован на базе продуктов следующих фирм: Geocad System и Geocad
Enterprise Edition [16].
АИС ОГД для визуализации данных об объектах на карте использует ГИСмодуль. Также в системе предусмотрена возможность создания графических
отчетов с помощью Logic Report. Стоит также отметить широкий выбор
инструментов для учета оконечного оборудования.
Рис 6. Графическая информация в ГИС-модуле
8
Рис 7. Главная форма Geocad Systems
В качестве недостатков системы стоит отметить отсутствие возможности
получение массива объектов из файла (и последующей визуализации). Также
стоит отметить относительно медленную работу системы (ввиду использования
большого количества внешних продуктов) и излишнюю функциональную
сложность.
9
Рис 8. Заполнение данных о принятом документе.
Рис 9. Редактор отчетов АИС «ОГД»
10
Портал «Электронный атлас»
Электронный Атлас – картографический сервис города Москвы. С
помощью данного сервиса у пользователя есть возможность записаться в
отмеченную на карте музыкальную школу или подать жалобу с указанием
объекта жалобы [17].
На данный момент портал работает в тестовом режиме, но после
официального
релиза
все
официальные
сервисы
Москвы
в
качестве
геоинформационной основы будут использовать данный Атлас. На данный
момент сервис уже используется для контроля качества сотовой связи, где
пользователь имеет возможность отметить на карте место, где у него возникли
проблемы связи.
Рис 10. Редактирование отображаемых категорий в Электронном атласе
Кроме открытых данных, к которым есть доступ у любого желающего,
Атлас содержит конфиденциальные данные, которые могут просматривать лишь
представители тех или иных органов государственной власти.
На карту нанесено более 140 категорий объектов с возможностью
отображения (скрытия) необходимых для пользователя [17]. Также стоит
отметить удобную навигацию с возможностью поиска по следующим
атрибутам:
11
 по адресу;
 по координатам;
 по названию объекта.
Рис 11. Атрибутивный поиск и предоставление информации в
Электронном атласе
У Атласа есть разные возможности геопоиска с фильтрацией по
категориям:
 в радиусе от точки;
 на расстоянии от линии;
 в замкнутой области.
Стоит отметить, что Электронный Атлас носит скорее исключительно
информационный
характер
и
обладает
относительно
малым
набором
возможностей для автоматизированной реализации поставленных перед
12
разрабатываемой системой задач, поэтому не будет включен в таблицу
сравнения аналогов.
ЕИАИС ЭЭ
Реализация мероприятий государственной программы энергосбережения
невозможна
без
межведомственного
координация
действий
различных
взаимодействия,
организаций
т.е.
необходима
энергокомплекса.
Стоит
отметить, что у каждой организации сложились свои порядки работы, которые
имеют существенные различия.
Это стало предпосылкой для создания «Единой интегрированной
автоматизированной информационной системы мониторинга и управления
эффективностью энергосбережения на объектах города Москвы» (ЕИАИС ЭЭ)
[12].
Перед созданием системы были изучены международные аналоги, в
частности были рассмотрены системы класса EMS (Energy Management
System), представляющие собой автоматизированные системы объектов
энергосбережения. Но их применение для решения поставленных задач
оказалось невозможным, т.к. они
не имеют возможности интегрировать
российскую нормативную базу, вследствие чего их внедрение, во-первых, не
выдерживает сроки реализации госпрограммы, и, во-вторых, нерентабельно.
13
Рис 12. Фрагмент модели предметной области ЕИАИС ЭЭ
На первом этапе разработки системы – моделирования, т.е. создания
прототипа – были обозначены следующие функции [12]:
 контроль выполнения проектов госпрограммы, а именно обеспечение
взаимодействия сотрудников различных организаций и автоматизация
документооборота;
 учет данных о номинальных характеристиках оконечного оборудования,
установленного на объектах энергосбережения;
 автоматизированный учет данных о статусе использования объектов
энергосбережения;
 интеграция с Государственной информационной системой, созданной в
рамках госпрограммы энергосбережения;
14
 обеспечение доступа к системе сотрудников всех компетентных организаций, выполняющих и контролирующих мероприятия по выполнению
госпрограммы.
Рис 13. Фрагмент логической схемы данных ЕИАИС ЭЭ
15
Таким образом, рассмотренные возможности при проектировании ЕИАИС
ЭЭ подтверждают, что создаваемое автором работы программное обеспечение
имеет актуальные предпосылки к созданию и обладает перспективой,
заключающейся в дальнейшей интеграции с разрабатываемой ЕИАИС ЭЭ.
Учитывая, что рассматриваемая система находится в стадии разработки,
она не будет включена в таблицу сравнения аналогов.
CloudMade
CloudMade
в качестве карты использует данные некоммерческого
геосервиса OpenStreetMap.
Рис 14. Элементы управления на карте
Данная система предоставляет следующие возможности:
 задание собственных стилей отображаемым объектам;
 создание собственного стиля для отображения объекта на карте (после
регистрации);
16
 построение различных маршрутов с лучшей на данный момент скоростью на основании данных свободного геосервиса;
 задание собственного стиля для отображения карты, т.е. у пользователя
есть возможность, например, сделать выразительнее обозначение какойлибо административной границы, и наоборот затемнить другие элементы;
 наличие большого числа собственных стилей, что является важным
фактором для качества визуализации;
Рис 15. Задание различного стиля для отображения карты
17
Рис 16. Задание своего изображения для обозначения объекта на карте
Объекты маршрута можно перед выполнением построения маршрута
добавлять, удалять и перемещать. Построенный маршрут можно загрузить для
его дальнейшего использования, например, в навигаторе.
Рис 17. Построение маршрута
18
Google Maps Engine Lite
Google
Maps
Engine
Lite
—
свободнораспространяемый
геоинформационный сервис для визуализации данных на карте [19]. Система
позволяет пользователю создавать собственный экземпляр карты Google Maps, с
последующей визуализации на нем различных данных. Есть возможность
загрузки
информации,
которую
пользователь
имеет
редактировать. Кроме этого, пользователь может сохранить
возможность
полученный
результат и поделиться с другими.
Каждому объекту в системе можно присвоить свое обозначение. Система
имеет в наличии большое число собственных пиктограмм, что является важным
фактором для качества визуализации.
Рис 18. Задание своего изображения для обозначения объекта на карте
19
Помимо сходства с ранее рассмотренными аналогами, где пользователь
может вручную создавать необходимые ему объекты, данная система имеет
удобный интерфейс для загрузки файлов с большим количеством объектов и их
последующей визуализации на карте.
Для этого при загрузке таблицы
необходимо выбрать одну или более колонок, определяющих координаты
объектов. Например, если существует столбец, который содержит в полном
объеме геолокацию объекта, то выбирается только он. Если есть несколько
столбцов, один из которых содержит город, а другой улицу с номером дома, то
не обходимо выбрать оба столбца.
Кроме этого, в системе предусмотрено возможность редактирования
категорий объектов.
Рис 19. Фрагмент интерфейса Google Maps Engine Lite
20
MapInfo Professional
MapInfo Professional - геоинформационная система, которая на данный
момент по многим параметрам превосходит другие системы . Помимо учета
оборудования, MapInfo позволяет не только отображать соответствующую
информацию, но и редактировать свойства визуализации [13].
Рис 20. Панель инструментов в MapInfo Professional
В качестве источника данных для данной системы могут быть как файлы
AutoCAD, так и растровые карты в различных форматах (BMP, GIF, JPEG и
т.д.). Отличительной особенностью MapInfo служит возможность отображать
данные, полученные с помощью спутниковой системы. Система поддерживает
возможность загрузки данных из текстовых файлов и файлов Excel, которые
могут содержать как номинальные характеристики объектов, так и их
21
координаты. Данная ГИС автоматически преобразует их для удобного
просмотра на карте. Кроме этого, система располагает удобным механизмом
взаимодействия с наиболее распространенными СУБД (например, Oracle). В
течение одного сеанса возможно использование данных различного формата.
Пользователь также имеет возможность выборки по определенным
параметрам (поиск в определенной удаленности от заданного объекта, поиск в
пределах определенной площади и т.д.) благодаря встроенному языку SQL.
Кроме этого, стоит отметить следующие возможности системы:
 выборки по определенным параметрам можно сохранить в качестве
шаблона;
 поиск по локальной базе объектов;
 поиск возможен по разному критерию, а именно по адресу, по координатам или по системе атрибутов;
 импорт и экспорт файлов в формате KML (создан на основе формата
XML), которые используют, к примеру, популярные геоинформационные
сервисы Google;
 наносить объект на карту и определять его атрибуты;
 редактировать категории;
 использовать встроенный или собственный стиль для отображения объекта;
 трехмерное отображение объекта;
 отчет формата PDF, полностью соответствующий внешнему виду отчета
в системе.
22
Рис 21. Управление категориями объектов в MapInfo Professional
InstantMaps
InstantMaps — это геоинформационная система управлениями данными, в
качестве которых выступают объекты с определенным набором характеристик
[20]. Сервис поддерживает как Яндекс.Карты и Google Maps, так и
OpenStreetMap.
Также
у
пользователя
есть
возможность
подключить
собственную растровую карту.
Объекты можно объединить в категорию с определенным набором
характеристик, а также отображать (скрывать) определенную категорию.
23
Рис 22. Управление категориями объектов в InstantMaps
Существует
возможность
комментирования
и
отображения
с
использованием встроенного набора пиктограмм или собственного шаблона.
Реализован поиск объектов только по адресу.
Система имеет удобную панель управления для различных действий над
объектами и их группами. Осуществлен контроль доступа пользователя с
помощью механизма идентификации.
Рис 23. Панель управления в InstantMaps
24
Кроме этого, пользователи системы имеют возможность добавлять
собственные объекты. Администратор имеет полномочия ограничить список
категорий, в которые может добавлять объекты тот или иной пользователь.
Рис 24. Управление характеристиками объектов в InstantMaps
Есть возможность для загрузки большого количества объектов путем
импорта из файла. Массив объектов отображается на карте в виде меток
определенных стилей, заданных пользователем. Нажатие на метку открывает
подсказку, включающую в себя характеристики данного объекта.
Результаты анализа аналогичных существующих решений по наиболее
важным критериям сведены в таблицу.
Условные
обозначения:
«+»
обозначает
корректную
реализацию
программным продуктом данного критерия, «–» - обозначает отсутствие такой
возможности, «±» - реализация требует усовершенствования.
25
Google
Instant
АИС
АИС РФС
MapInfo
Cloud
Maps
Разрабатывае
Maps
«ОГД»
АПК
Pro
Made
Engine
мая система
Lite
Веб-интерфейс
+
±
-
+
+
+
+
±
±
±
+
±
-
+
+
-
-
±
+
+
+
+
+
+
+
+
+
+
+
-
+
+
-
+
+
Документооборот
-
+
+
+
-
-
+
Удобство эксплуатации
+
+
+
±
-
+
±
Стоимость
±
-
-
-
+
+
+
Поиск объектов в локальной базе
данных в рамках маршрута
Визуализация данных об
объектах на карте
Возможность редактирования
слоев (категорий объектов)
Получение координат
;по массиву адресов
Таблица 1. Сравнительный анализ аналогов
Выводы
Среди объектов анализа присутствовали системы, ориентированные как
на работу органов государственной власти, так и на задачи юридических и
физических лиц. Необходимость разработки обусловлена тем, что при
исследовании рынка у подобных программных продуктов были выявлены
следующие недостатки (и их следствия):
 излишняя функциональная сложность (необходимо специальное
обучение персонала);
 сложность
развертывания
(установка
и
наладка
производится
представителями разработчика);
 недостаточное качество картографического представления данных (не
удовлетворяет требованиям);
 отсутствие удобного интерфейса для построения маршрута;
 работа с графическими картами специализированного формата
(необходимость приобретения у разработчика, не всегда в наличии);
 основной недостаток – высокая стоимость.
27
1.3 Выбор инструментов разработки
Обзор картографических сервисов
Google Maps
В текущем году был анонсирован запуск обновленных карт [19]. Был
значительно изменен интерфейс – теперь Google Maps заполняют все окно,
убраны лишние блоки.
Рис 25. Новый интерфейс Google Maps
Из элементов навигации осталась только поисковая строка, сделав запрос
в которой пользователь получает не только расположение заданного объекта
на карте, но и информацию о нем (телефон, отзывы посетителей и т.д.).
28
Рис 26. Информация об объекте из поисковой строки в Google Maps
Отзывы можно оставить и самому благодаря сервису Google+. Также
предусмотрен просмотр панорам. Кроме этого, пользователи сами участвуют
в наполнении сервиса информацией, загружая собственные фотогографии.
Рис 27. Система отзывов в Google Maps
29
Появилась
возможность
построения
маршрута:
автомобильного,
велосипедного, общественного транспорта или пешком. Есть возможность
просмотра дорожной ситуации.
Рис 28. Построение маршрута в Google Maps
Из недостатков стоит отметить возможность построения маршрута
только между двумя точками в новой версии. Кроме этого, детализация карты
по городу Москва, точность построения маршрута и актуальность пробок не
достаточно высоки. На данный момент актуальной является API версии 3.0,
акцент в которой был сделан на быстродействие, а также добавлены новые
возможности по сравнению с предыдущими версиями, такие как работа с
форматом JSON, использование пространства имен, поддержка мобильных
устройств, усовершенствован сервис геокодирования.
Яндекс.Карты
На данный момент актуальным является API версии 2.0 [22], которая
имеет следующие новые возможности:
 возможность отображения большого объема информации (с помощью
кластеров – путем использования технологий html5и css3);
 поддержка мобильных устройств;
 усовершенствован сервис геокодирования;
30
 оптимизация под большое количество пользователей
 усовершенствован алгоритм построения маршрутов;
 усовершенствован сервис пробок.
Рис 29. Кластеризация в Яндекс.Картах
Рис 30. Построение автомобильного маршрута в Яндекс.Картах
31
Рис 31. Применение пользовательского стиля для элемента управления в
Яндекс.Картах
Рис 32. Дорожная ситуация на Яндекс.Картах
32
Также стоит отметить большие возможности API для реализации
собственных
идей
и
действующий
клуб
разработчиков.
И
главное
преимущество данной системы перед другими – предоставление самой
детализированной карты среди аналогов по г. Москве и Московской области.
2ГИС
Данный сервис имеет собственный API со следующими основными
возможностями [21]:
 добавление и редактирование меток;
 элемент управления изменения масштаба;
 слои;
 поиск.
Рис 33. Предоставление сервисов в 2ГИС
33
На данный момент многие интерфейсы непроработаны, документация
содержит мало примеров, нет возможности работы с данными 2ГИС. Но
проект активно развивается, в связи добавились следующие возможности:
 усовершенствованы алгоритмы поиска;
 добавлено отображение маршрутов, проходящих через выбранную
пользователем остановку;
 возможность перевода карты в полноэкранный режим одним щелчком
мыши;
 изменен макет подсказки при выборе объекта;
 усовершенствован алгоритм изменения масштаба карты.
Рис 34. Построение маршрута общественного транспорта в 2ГИС
34
Мобильная версия 2ГИС имеет возможность построения автомобильного
маршрута, что позволяет использовать данную систему как бесплатный
навигатор, который в случае передвижения будет изменять положение карты.
Кроме того, разработчики проекта обещают выпустить версию для iPad уже
летом 2013 года.
Рис 35. Подсказки на построенном автомобильном маршруте в
мобильной версии 2ГИС
Главным недостатком сервиса является отсутствие слоя пробок в г.
Москве и недостаточную гибкость API для реализации поставленных задач.
Leaflet
Данная система представляет собой открытую JavaScript-библиотеку для
отображения карты, которая работает как на стационарном компьютере, так и
на мобильных устройствах. Основные достоинства:
 высокая производительность – легковесная библиотека с понятным
ООП-кодом;
35
 удовлетворяет основным требованиям пользователя (отсутствие лишней функциональности делает интерфейс ориентированным на удобство работы пользователя);
 использует новые технологии (html5, css3) и быстро развивается;
 код API схож с синтаксисом jQuery;
 управление картой с помощью клавиатуры;
 корректно работающий элемент изменения масштаба;
 поддержка touch-устройств;
 эффект анимации при перемещении;
 удобный интерфейс для редактирования различных объектов на карте;
 наличие собственных элементов управления.
Рис 36. Подсказка при выборе метки в Leaflet
Рис 37. Элемент управления слоями в Leaflet
36
Рис 38. Применение пользовательского стиля для элемента управления в
Leaflet
Для построения маршрутов есть возможность простой интеграции
сервиса от CloudMade. Данная система получила признание у крупнейшего
некоммерческого геопроекта (OpenStreetMap), который перешел на Leaflet
вместо OpenLayers (также открытая JavaScript-библиотека, с большей
функциональностью, но с крайне медленной работой).
Детализация
OpenStreetMap
в
Москве
постоянно
улучшается
пользователями, но на данный момент уступает конкурентам. Также
совершенствуется
дорожный
граф
(необходимый
для
построения
маршрутов).
37
Выбор программных компонентов
Необходимо определиться с теми программными компонентами,
которые можно задействовать при разработке системы.
Для обеспечения поддержки протокола HTTP был выбран Web-сервер
Apache, способный предоставить все необходимые возможности для
реализации веб-интерфейса системы. Другим важнейшим критерием выбора
данного
компонента
является
перспектива
дальнейшей
интеграции
создаваемой системы в организации, которая, в свою очередь, может
предоставить именно этот сервер.
Также
важным
элементом
анализа
системного
программного
обеспечения является выбор СУБД. Сравнительный анализ СУБД приведен в
таблице.
Критерий
Oracle 11g
MS Access 2007
MySQL 5.1
Поддержка SQL
+
±
+
>4 Тб
2 Гб
263 байт (8 млн. Тб)
Максимальный
размер таблицы
Теоретически 263
байт (8 млн. Тб),
Максимальный
> 4 Тб
размер БД
(теоретически)
2 Гб
но практически
зависит от
ограничений ОС
на размер файла
Delphi, C, C++,
Эйфель, Java,
Поддерживаемые
языки
C, C++, Java
VBA
программирования
Лисп, Perl, PHP,
Python, Ruby,
Smalltalk и Tcl,
библиотеки .NET
Локализация
+
+
±
38
Восстановление
+ (таблицы типа
+
-
+
-
-
Удобство работы
-
+
-
Стоимость
-
-
бесплатно
после сбоев
Резервное
копирование
Maria)
Таблица 2. Сравнительный анализ СУБД
Из таблицы сравнения СУБД видно, что, по сути, возможно использовать для создания данной БД или СУБД Oracle, или СУБД MySQL. Поскольку MySQL бесплатна, а существенными недостатками в сравнении с Oracle
(для данной задачи) не обладает, то выбираем ее.
Кроме того, СУБД MySQL наиболее распространена среди хостингпровайдеров (в частности, среди государственных организаций, куда планируется дальнейшая интеграция системы), что позволит при отсутствии возможности обеспечить установку сервера в одном из отделений (например, изза отсутствия провайдеров, предоставляющих симметричный канал), воспользоваться услугами хостинга.
В качестве основного языка программирования для написания серверной
части системы был выбран PHP как наиболее подходящее средство быстрой и
эффективной разработки необходимых функций создаваемой системы.
Использование других языков, в частности python, нецелесообразно, т.к. нет
необходимости в написании долгоживущих «фоновых» процессов и т.п.
HTML 5 – язык для структурирования содержимого веб-страниц,
является пятой версией стандарта HTML. Он расширяет и рационализирует
разметку
и
позволяет
использовать
различные
графические
и
мультимедийные объекты.
CSS 3 – новый стандарт управления внешним видом веб-страниц.
Поддерживает огромное количество новых функций, среди которых элементы
со скругленными углами, градиенты, тени, анимация и т.д.
39
Для моделирования предметной области разрабатываемой системы
необходим редактор. Во-первых, для эффективного взаимодействия с
будущими пользователями важным критерием выбора является доступность
инструмента в сети. Во-вторых, важно наличие необходимых блоков для
построения UML диаграмм. Также обязательно наличие возможности
экспортирования созданной диаграммы (в графическом формате). Все
перечисленные критерии доступны в бесплатной версии сервиса Lucidchart,
который также имеет множество других возможностей, которые могут
потребоваться на дальнейших этапах.
Рис 39. Фрагмент работы сервиса Lucidchart
40
Учитывая
выбранную
ранее
СУБД
MySQL,
выбор
среды
проектирования базы данных был обусловлен, главным образом, удобным
интерфейсом и возможностью кодогенерации конкретно для данной СУБД.
Этим целям полностью отвечает кроссплатформенный продукт MySQL
Workbench.
Рис 40. Рабочая область инструмента MySQL Workbench
Для проектирования пользовательского интерфейса было выбрано
средство прототипирования BalsamiqMockups, демонстрационная версия
которого полностью удовлетворяет задачам разработки интерфейса. Стоит
отметить,
такие
преимущества
данного
инструмента,
как
большую
41
библиотеку
элементов для создания интерфейса, так и большой набор
операций для их редактирования. Также необходимо выделить доступность
инструмента в сети и форму использующихся элементов интерфейса (как
будто, нарисованных «от руки»), позволяющих сосредоточить внимание
разработчика именно на структуре страницы и компоновке форм. Конкретно
к данному проекту оказалась очень важной возможность добавления и
редактирования таблицы.
Рис 41. Пример прототипа, созданного в BalsamiqMockups
Для разработки пользовательского интерфейса предназначены скриптовый
язык
JavaScript
и
удобная
библиотека
jQuery,
а
для
повышения
эффективности работы с ними в качестве «движка шаблонов» на клиентской
42
стороне был выбран jQuery Templates, автоматически создающий html-код и
обновляющий его при изменении исходных данных [4].
Google Chart API – сервис для построения графиков из сформированной
ссылки. Поддерживаются все необходимые функции, такие как легенда,
выносные ссылки для диаграмм, заголовок, различные цвета заливки и т.д. В
данном проекте для визуализации важным является возможность построения
секторной диаграммы.
Рис 42. Круговые диаграммы в Google Chart API
Фреймворк
Twitter
Bootstrap
–
один
из
самых
удобных
и
многофункциональных CSS фреймворков с широким набором jQuery
плагинов [3]. Поддерживает HTML5 и CSS3. Содержит наборы стилей для
любых браузеров, а также классы для форм, таблиц, меню, навигации и т.д.
43
Рис 43. Множество готовых компонентов в Twitter Bootstrap
Рис 44. Пример оформления страницы с помощью Twitter Bootstrap
Для формирования шаблона из Excel файла была выбрана библиотека
Php-excel-reader, главным достоинством которой является быстрота и
корректная обработка латиницы. Также достоинством библиотеки является
чтение любых Excel-файлов и их обработка на стороне сервера, результатом
которой является html-код с полным сохранением исходного форматирования.
44
Выводы
В
результате
анализа
инструментов
разработки
были
выбраны
следующие программные компоненты и средства разработки:
 Apache, MySQL и PHP.
 API Яндекс.Карт 2.0.
 HTML 5 и CSS 3.
 Lucidchart – моделирование предметной области системы.
 MySQL Workbench – моделирование базы данных и кодогенерация.
 BalsamiqMockups – проектирование пользовательского интерфейса.
 JavaScript, jQuery и jQuery Templates.
 Google Chart API.
 Фреймворк Twitter Bootstrap.
 Php-excel-reader – формирование шаблона из Excel файла.
45
1.4 Разработка
1.4.1 Разработка прототипа системы
Прототипирование является важнейшей частью цикла разработки вебприложения, которая предоставляет возможность избежать многих ошибок
уже на этапе проектирования системы.
Прототипирование состоит из следующих этапов [6]:
1.
Определение требований к системе.
2.
Выбор инструментов и технологий.
3.
Создание диаграммы вариантов использования.
4.
Создание макета сайта.
Первые два пункта уже выполнены, поэтому перейдем к созданию
диаграммы вариантов использования, основное назначение которой –
описание функциональности системы, позволяющее разработчику совместно
с представителями организации – будущими пользователями обсуждать и
вносить изменения в систему уже на этапе разработки прототипа.
Во-первых, проведем анализ предметной области. Система создается для
обслуживания организаций и предприятий города Москвы энергетического
комплекса. Таким образом, предметная область характеризуется следующими
особенностями:
 работа большую часть времени имеет разъездной характер;
 работа распределена между несколькими организациями;
 взаимодействие организаций происходит путем регулярных телефонных сессий, факсимильной связи и электронного документооборота путем
пересылки писем по электронной почте, включающих файлы Excel.
Необходимо отдельно рассмотреть принцип работы отдела предприятия,
являющимся контролирующим органом ряда организаций-подрядчиков в
сфере энергосбережения:
46
 отдел состоит из начальника отдела, нескольких заместителей начальника отдела и специалистов (инженеров, инспекторов, старших техников и
т.д.);
 учитывая ранее отмеченный разъездной характер работы, специалисты
большую часть времени работают на служебном автотранспорте с сотрудниками транспортного отдела;
 заместители начальника отдела имеют одинаковые полномочия, таким
образом, распределяя работу между собой;
 специалисты имеют одинаковые полномочия и по поручению руководства должны выполнить поставленную задачу вне зависимости от занимаемой должности;
 начальник отдела формирует график работы отдела;
 начальник отдела анализирует документы от подрядных организаций и
регулирует на их основе работу отдела;
 начальник отдела определяет категории энергосберегающих объектов и
соответствующую им документацию (например, паспорта на объекты);
 заместитель начальника отдела формирует маршруты объездов из объектов, состоящих на балансе организации;
 заместитель начальника отдела формирует набор фотографий для объектов, состоящих на балансе организации;
 заместитель начальника отдела формирует шаблон ежедневного отчета
по итогам работы для специалиста;
 заместитель начальника отдела координирует деятельность специалистов по письмам от жителей города и других организаций вне плановых объездов по графику;
 специалист имеет список объектов в виде файла Excel (.xls) с возможностью выбора маршрута c помощью встроенного фильтра;
 специалист для того, чтобы определить местоположение объектов
47
маршрута и загруженность дорог в городе, пользуется сервисами в сети Интернет (причем местоположение каждого из объектов определяется отдельно);
 информация от подрядчиков и другие сведения, необходимые для взаимодействия руководства и специалистов, размещаются в локальной сети;
 ежедневный отчет по результатам работы формируется специалистом в
файле Excel, все характеристики каждого из объектов отчета ищутся отдельно в другом файле (файлах);
 ежемесячный отчет формируется специалистом вручную на основе документов от подрядных организаций.
Перед созданием диаграммы прецедентов важно отметить следующие
моменты:
1.
Учитывая рассмотренные особенности работы в организации, заме-
стителей начальника отдела и специалистов следует объединить в две группы
пользователей с определенным набором прав. Таким образом, полномочия
заместителя начальника отдела имеет пользователь «Заместитель начальника
отдела», а полномочия специалиста – пользователь «Инспектор». Также целесообразно выделение пользователей «Администратор» и «Начальник отдела» с соответствующими правами в разрабатываемой системе.
2.
Координация заместителем начальника отдела деятельности специ-
алистов по письмам от жителей города и других организаций вне плановых
объездов по графику имеет некоторые особенности. Во-первых, постоянно
наблюдается различие адреса (названия) объекта, указанного в письме, от соответствующих характеристик объекта, определенных в паспортах или его
отсутствие на балансе данной организации. Во-вторых, письма требуют
быстрого ответа, поэтому формирование маршрутов из данных объектов является малоэффективным. В-третьих, форма ответа на письма различна, что
делает формирование шаблонов также малоэффективным в данном случае.
Таким образом, приведены доказательства отсутствия модуля, реализующего
48
данную особенность предметной области, в разрабатываемой системе.
3.
В ходе разработки архитектуры системы, в частности создании схе-
мы базы данных, следует отталкиваться от структуры Excel файлов, используемых для хранения информации как внутри организации, так и в организациях-подрядчиках. Второй причиной следования имеющейся на предприятии
структуре файлов служит большой объем данных, а следовательно необходимость предусмотреть возможность заполнения базы данных из файла. В то
же время, в некоторых случаях следует отметить неправильность данной
структуры и необходимость ее изменения, например в случае вынесения некоторых объектов, которые должны быть в нескольких маршрутах, в отдельный файл в каждом из таких случаев.
4.
Учитывая отсутствие строгих норм межведомственного взаимодей-
ствия, в качестве источника данных следует использовать текстовый файл
(формата .txt), в который следует скопировать информацию из Excel файла из
необходимых ячеек (например, путем скрытия/отображения столбцов).
5.
Как правило, специалисты и руководство отдела находятся в разных
зданиях. Взаимодействие внутри отдела происходит путем обмена файлами
через локальную сеть организации, которая иногда выходит из строя. Таким
образом, предпочтительна реализация данного взаимодействия в глобальной
сети, т.е. путем размещения системы в сети Интернет.
6.
Создание отчета по результатам работы специалистом требует ав-
томатизации по нескольким причинам. Во-первых, он делается по шаблону,
который редко подвергается изменениям со стороны руководства, во-вторых,
содержит информацию об объектах, введение которой вручную неэффективно.
7.
Автоматическая обработка сформированного заместителем началь-
ника отдела каталога фотографий для объектов, состоящих на балансе организации, невозможна по причине наличия множества ошибок в названиях
файлов с фотографиями.
49
8.
Для работы специалиста необходима реализация возможности по-
строения автомобильного маршрута между объектами. Объекты в созданных
заместителем начальника отдела рейсах распределены в городе таким образом, что во многих случаях находятся рядом и автоматическое построение
маршрута между всеми объектами рейса является неэффективным. Таким
образом, важно реализовать возможность построения автомобильного маршрута с учетом дорожной ситуации на дорогах и построения маршрутного листа. Выполняемые системой данные операции позволяют эффективнее использовать рабочее время и помогают инспекторам выполнять принятые в
организации обязательства (например, по заполнению путевого листа).
9.
Для работы специалиста необходима реализация возможности поис-
ка объектов на карте по построенному маршруту. Во-первых, путем выбора
объекта из автоматически
сгенерированного маршрутного списка. Во-
вторых, необходима реализация поисковой строки с автоматической подсказкой при наборе (аналогично принципам работы известных поисковых систем). В качестве отличия второй альтернативы от первой будет выступать
изменение масштаба карты и автоматическое перемещение в область
найденного объекта.
10. Рассмотреть дополнительную (необязательную к реализации) возможность системы, заключающуюся в поиске ближайших объектов, находящихся в определенном радиусе от указанной точки.
В итоге, диаграмма вариантов использования выглядит следующим
образом:
50
Рис. 45 Диаграмма вариантов использования
Приступим к созданию прототипа пользовательского интерфейса. Пользовательский интерфейс обеспечивает взаимодействие, а именно обмен действиями и реакциями на эти действия, между пользователем и компьютером.
Исследования в области человеко-машинного взаимодействия показывают,
что любой пользовательский интерфейс должен обеспечивать выполнение
51
следующих четырех функций [7]:
1.
управление компьютером путем действий пользователя: инициация,
прерывание, отмена компьютерных процессов и т.д.;
2.
ввод данных, осуществляемых пользователем, и отклик системы;
3.
отображение данных, вводимых пользователем;
4.
поддержка пользователя в процессе деятельности, что включает в
себя обратную связь и сбор информации об ошибочных или случайных действиях пользователя.
Хорошо спроектированный пользовательский интерфейс должен соответствовать представленным ниже принципам:
1.
иметь низкий порог вхождения, то есть способствовать быстрому
освоению пользовательского интерфейса, формированию у пользователя
устойчивых навыков;
2.
обеспечивать ввод информации естественным образом, не демон-
стрируя пользователю ход вычислительного процесса;
3.
удовлетворять рабочие потребности пользователя, а не заострять его
внимание на процессе обработки данных.
Для получения эффективного результата разработки пользовательского
интерфейса используют различные подходы к проектированию. Вот
основные из них [7]:
1. Подход, ориентированный на пользователя (User-Centered Design).
2. Подход, ориентированный на деятельность (Activity-Centered Design).
3. Целеориентированный подход (Goal Centered Design).
4. Подход, ориентированный на данные (Data Centered Design).
5. Итеративный подход (Agile) - метод последовательных приближений.
При выборе подхода для разработки интерфейса целесообразно
учитывать назначение системы и ее целевую аудиторию. В нашем случае,
стоит выделить подход, ориентированный на пользователя (User-Centered
52
Design), который характеризуется следующими признаками (стандарт ISO
13407) [7]:
 активным вовлечением пользователей в процесс проектирования и тестирования программного продукта;
 четким пониманием пользовательских требований и задач;
 оптимальным распределением функций между пользователями и технологиями;
 интерактивностью и мультидисциплинарностью подхода.
Доказано,
что
применение
данного
подхода
при
разработке
пользовательского интерфейса для достижения высоких показателей в
области юзабилити (согласно ISO 9241-11, это степень эффективности,
продуктивности
и
удовлетворенности,
использоваться
определенными
с
которой
пользователями
продукт
для
может
достижения
определенных целей в определенном контексте) приводит к сокращению
расходов на разработку и повышению эффективности продукта как в
отношении бизнеса (дополнительная прибыль), так и в удовлетворенности
пользователей (повышение лояльности к продукту и разработчику).
Для выбранного подхода к проектированию характерен следующий вид
прототипирования пользовательского интерфейса – бумажное прототипирование [6]. Бумажный прототип – набор экранов и элементов управления, достаточный для иллюстрации поведения системы и проведения пользователя
по сценариям решения типовых задач. Во-первых, это самый быстрый способ
создания прототипов. Рука на бумаге рисует гораздо быстрее, чем на экране.
Созданный прототип легко изменить или нарисовать новый. Учитывая неглубокое знание компьютерных технологий многих будущих пользователей
системы, важно иметь возможность тестировать и обсуждать суть интерфейса, не отягощённую конкретной реализацией. На бумаге рисуют абстрактную
модель интерфейса, которая позволяет быстро зафиксировать пришедшие в
голову идеи.
53
При разработке прототипа интерфейса наряду с приемом бумажного
прототипирования использовался ранее выбранный онлайн-инструмент создания пользовательских интерфейсов. В конечном итоге, результат прототипирования интерфейса главной страницы веб-приложения выглядит следующим образом:
Рис. 46 Концептуальная модель интерфейса главной страницы АИС
54
Таким образом, перечислим основные причины, объясняющие, почему
перед созданием системы был разработать ее прототип:
 получена четкая картина того, какая именно информация будет необходима на каждой странице сайта до этапа разработки;
 рационально распределено время и акцентировано внимание именно
на том, для чего предназначена каждая страница;
 система, должным образом спланированная на этапе создания прототипа, некоторым образом ограждает от неосведомленных пользователей, которые склонны менять свое мнение на стадиях разработки архитектуры и ее
дальнейшей реализации, т.к. функциональность отдельных страниц не должна сильно модифицироваться;
 учитывается экономическая составляющая работы, т.к. осведомленность будущего пользователя также играет здесь важную роль, и он должен
знать, что изменение уже урегулированного прототипа может с большой вероятностью увеличить бюджет;
 получено четкое представление о том, как будут реагировать пользователи на сайт без элементов дизайна и цветовой схемы;
 удалены лишние элементы;
 прототип довольно легко создать, позволяя плавно и эффективно
осуществлять процесс планирования;
 снижена вероятность увеличения объема работы по разработке дизайна;
 интенсивное вовлечение клиента в процесс планирования на раннем
этапе разработки системы позволяет активно согласовывать весь процесс
планирования между обеими сторонами.
1.4.2 Разработка архитектуры системы
При проектировании автоматизированной информационной системы
было выявлено четыре типа пользователей:
 администратор;
55
 начальник отдела;
 заместитель начальника отдела;
 инспектор.
В результате проектирования системы и тестирования прототипа
пользовательского интерфейса были приняты следующие решения:
 отсутствие разграничений прав доступа между начальником отдела и
его заместителями;
 разделение прав доступа между инспекторами и руководством решено выполнить путем разнесения соответствующих модулей по разным страницам сайта системы, т.е. сгруппировав модули редактирования маршрута,
формирования графика работы отдела и т.д. отдельно от модулей, необходимых для работы инспекторов;
 контроль доступа к модулям системы осуществляется программно;
 отсутствие отдельных отношений для учета отделов организации и
многих атрибутов, характеризующих сотрудников, что объясняется непредусмотренной в задании необходимостью в поддержке сотрудников отдела кадров;
 отсутствие многих атрибутов, присущих рассмотренной предметной
области, в целях избегания лишней громоздкости окончательной схемы базы
данных.
Механизм
последовательность
нормализации
преобразования
подразумевает
отношений,
определённую
которая
избыточна.
Учитывая данное свойство в совокупности с особенностями предметной
области, перед созданием окончательной схемы базы данных системы, были
выполнены следующие мероприятия:
1.
Сложные атрибуты «Фамилия, имя, отчество» (сущность «Сотруд-
ники») и «Номинальные характеристики объекта энергосбережения» (сущность «Объекты») разделены на простые.
56
2.
Для отношения «Подрядчики» введен суррогатный первичный ключ,
который не несёт смысловой нагрузки и служит только для идентификации
записей. Это объясняется тем, что потенциальный ключ имеет большой размер (длинная символьная строка) и может меняться. Аналогичная операция
проведена
для
отношений
«Категории»,
«Отчеты
организаций»,
«Сотрудники» и «Обязательные объекты».
3.
Свойство объекта энергосбережения «маршрут» выделено в отдель-
ное отношение с ссылкой из отношения «График» и добавлением атрибута,
носящего справочную информацию.
4.
Отношения
«Отчеты-Информация»,
«Объекты-Информация»,
«График», «Сотрудники-Информация», оставлены без первичного ключа, т.к.
на эти отношения никто не ссылается.
5.
В целях минимизации дублирования данных создано отношение
«Объекты-Информация», т.е. учтено то обстоятельство, что объект маршрута
может иметь несколько фотографий (и любых других нерассмотренных характеристик). Аналогично создано отношение «Сотрудники-Информация» (у
сотрудника может быть несколько телефонов).
В связи с тем, что дальнейшая декомпозиция нецелесообразна,
приступим
к
составлению
реляционных
отношений.
Отношения
и
соответствующие ограничения целостности приведены в таблицах 2-12. Для
каждого отношения указаны атрибуты с их внутренним названием, типом и
длиной. Числовой тип данных обозначим буквой «N», символьный тип
переменной длины – «V», символьный тип фиксированной длины – «С».
Содержание поля
Имя поля
Тип, дли-
Примечания
на
идентификатор объек-
o_id
V(10)
первичный ключ
o_category
N(3)
внешний ключ (к Catego-
та
класс
ries)
57
порядковый номер
o_order
N(6)
обязательное поле
категория
o_rank
V(5)
обязательное поле
адрес
o_address
V(70)
обязательное поле
название
o_name
V(70)
обязательное поле
количество светильни-
o_lamp
N(6)
обязательное поле, > 0
o_projector
N(6)
обязательное поле, > 0
o_otherLight
N(6)
обязательное поле, > 0
o_sum
N(6)
обязательное поле, > 0
o_org
N(6)
обязательное поле
V(50)
по умолчанию - NULL
o_winteroff
V(50)
по умолчанию - NULL
o_route
V(45)
внешний ключ (к Routes)
ков
количество прожекторов
количество осветительных приборов
другого типа
общее количество
осветительных приборов
электроснабжающая
организация
летний режим времени o_summeroff
отключения установок
зимний режим времени отключения установок
маршрут
Таблица 3. Схема отношения «Объекты» (Objects)
Содержание поля
Имя поля
Тип, дли-
Примечания
на
идентификатор класса
c_id
N(3)
первичный ключ
58
название класса
c_name
V(45)
обязательное поле
название файла с паспортом клас- c_passport
V(45)
обязательное по-
са
ле
Таблица 4. Схема отношения «Категории» (Categories)
Содержание поля
Имя поля
Тип, длина
Примечания
идентификатор организации
org_id
N(6)
первичный ключ
название организации
org _name
V(70)
обязательное поле
телефон
org _phone
V(50)
обязательное поле
Таблица 5. Схема отношения «Подрядчики» (Contractors)
Содержание поля
Имя поля Тип, длина
Примечания
название маршрута
u_name
V(45)
первичный ключ
примечание
u _note
V(120)
обязательное поле
Таблица 6. Схема отношения «Маршруты» (Routes)
Содержание поля
название объекта
Имя по-
Тип,
ля
длина
obj_id
V(10)
Примечания
внешний ключ (к Objects)
название файла с фотографией
obj
объекта
_photo
V(70)
обязательное поле
Таблица 7. Схема отношения «Объекты-Информация» (objInfo)
59
Содержание поля
Имя по-
Тип,
Примечания
ля
длина
идентификатор отчета
r_type
N(6)
первичный ключ
название объекта
r_objid
V(10)
внешний ключ (к
Objects)
примечание
r_note
V(120)
обязательное поле
количество негорящих освети-
r_off
N(6)
обязательное поле,
тельных приборов
>0
Таблица 8. Схема отношения «Отчеты организаций» (Reports)
Содержание поля
Имя по-
Тип, дли-
Примечания
ля
на
идентификатор отчета
rt_type
N(6)
внешний ключ (к Reports)
название
rt_name
V(45)
обязательное поле
дата (указанная подрядчи-
rt_date
V(45)
обязательное поле
rt_org
N(6)
внешний ключ (к
ком)
идентификатор организации
Contractors)
Таблица 9. Схема отношения «Отчеты-Информация» (rptInfo)
Содержание поля
Имя поля
Тип, длина
Примечания
идентификатор сотрудника
e_id
N(6)
первичный ключ
фамилия
e_lname
V(45)
обязательное поле
имя, отчество
e_fname
V(45)
обязательное поле
логин
e_login
V(45)
обязательное поле
пароль
e_password
С(50)
обязательное поле
«соль»
e_salt
С(50)
обязательное поле
60
должность
e_post
по умолчанию - NULL
V(45)
Таблица 10. Схема отношения «Сотрудники» (staff)
Содержание поля Имя поля Тип, длина
Примечания
сотрудник
p_id
N(6)
внешний ключ (к Staff)
телефон
p_phone
V(45)
обязательное поле
Таблица 11. Схема отношения «Сотрудники-Информация»
(staffInfo)
Содержание поля
Имя поля
Тип, длина
Примечания
дата
gr_date
V(30)
обязательное поле
N(6)
внешний ключ (к mainType)
обязательный объект gr_mainobj
сотрудник
gr_pers
N(6)
внешний ключ (к Staff)
маршрут
gr_route
V(45)
внешний ключ (к Routes)
Таблица 12. Схема отношения «График» (schedule)
Содержание поля
идентификатор обязательного объ-
Имя по-
Тип, дли-
Примечания
ля
на
m_id
N(6)
первичный ключ
m_name
V(45
обязательное по-
екта
название
ле
примечание
m_dop
V(210)
обязательное поле
Таблица 13. Схема отношения «Обязательные объекты» (mainType)
61
В результате база данных разработанной системы выглядит следующим
образом:
Рис.47 Окончательная схема базы данных АИС
62
1.4.3 Реализация системы
Входными данными системы являются:
 текстовый файл, описывающий маршрут;
 текстовый файл, описывающий отчет организации-подрядчика.
Выходными данными системы являются:
 выводимая на экран информация (результаты работы системы);
 сообщения обо всех возникших в работе модулей критических ошибках;
 файл, описывающий отчет о работе специалиста.
В состав программы входят следующие компоненты:
 модуль формирования маршрута;
 модуль картографического представления маршрута;
 модуль визуализации объектов маршрута в виде круговой диаграммы;
 модуль табличного представления маршрута;
 модуль управления дорожной ситуацией и событиями;
 модуль поиска по маршруту;
 модуль построения пути;
 модуль поиска объектов в радиусе;
 модуль формирования отчета машиночитаемого формата;
 модуль формирования отчетов подрядных организаций (и ежемесячного на их основе);
 модуль идентификации пользователя;
 пользовательский интерфейс.
Модуль формирования маршрута преобразует входные данные, а именно
текстовый
файл,
дальнейшем
представления
была
описывающий
маршрут,
возможность
данного
маршрута.
таким
образом,
картографического
Работа
модуля
и
чтобы
в
табличного
характеризуется
следующими функциями:
63
1.
Возможность загрузить пользователю информацию о маршруте из
текстового файла в базу данных, а также преобразовать выбранный маршрут.
2.
Автоматическое преобразование списка адресов объектов в соответ-
ствующие этим адресам координаты. При преобразовании списка учитывается особенность геокодера, использующего обратный порядок задания географических координат. Получаемый XML-ответ геокодера обрабатывается таким образом, что в результате координаты меняются местами, и значение широты/долготы для каждого объекта заносится в соответствующее поле базы
данных. Пользователь также получает информацию об общем количестве
необработанных объектов маршрута.
3.
Выбор текстового файла осуществлен в виде выпадающего списка с
названиями текстовых файлов, загруженных на сервер. Такое решение обусловлено удобством пользователя и ограничением целостности, т.к. у пользователя нет возможности выбрать несуществующий файл и, следовательно,
нет необходимости делать проверку введенных данных.
4.
Модуль разработан таким образом, что выполняет задачи пользова-
теля без перезагрузки страницы.
Перед рассмотрением следующих модулей в качестве справочной
информации стоит разместить схему, отображающую иерархию компонентов
API Яндекс.Карт [22]:
64
Рис.48 Иерархия компонентов API Яндекс.Карт
Модуль картографического представления маршрута визуализирует
объекты маршрута на карте. После идентификации пользователя происходит
загрузка API Яндекс.Карт и создается экземпляр карты [22]. Затем
пользователь выбирает маршрут из списка, автоматически созданного при
загрузке страницы. Далее модуль выполняет следующие операции:
1.
Выбранный маршрут передается в функцию, которая передает его
php-скрипту, выполняющего обращение к базе данных и формирующего файл
формата JSON с результатами выборки.
65
2.
Из полученного массива формируется массив геообъектов – про-
граммных компонентов, описывающих географические объекты реального
мира. Геообъект характеризуется своей геометрией, которая определяется
геометрическим типом и координатами географического объекта. Свойства
каждого геообъекта формируются исходя из соответствующих значений в базе данных и внешних представлений, согласованных с будущими пользователями. Свойства программных компонентов API Яндекс.Карт будут рассмотрены позднее. Геообъекты объединены в специальный тип коллекции – кластеризатор. Выбор данного типа определен несколькими причинами, среди
которых:
 во многих маршрутах объекты находятся на близком расстоянии – на
некоторых масштабах карты метки накладываются; кроме этого есть объекты
с одинаковым адресом – в этом случае метки полностью перекрывают друг
друга, и у пользователя нет доступа к некоторым из объектов маршрута;
 увеличение производительности;
 используемые в кластерах технологии выбраны при разработке системы (html5 и css3).
3.
Для выполнения требований пользователей системы к визуализации
данных функциональности стандартной коллекции недостаточно, в связи с
этим разработан модуль визуализации объектов маршрута в виде круговой
диаграммы. Модуль делает зависимым внешний вид кластера от типов входящих в него меток (геообъектов). Для этого необходимо:
 определить новый шаблон внешнего вида кластера, основой которого
является диаграмма с использованием Google Charts API – для нее определяются размеры и цвета сегментов;
 функция для изменения прозрачности внешнего вида кластера;
 функция, определяющая из входного массива геообъектов количество
меток разного цвета – для ее работы служит функция, возвращающая необходимый идентификатор в зависимости от цвета метки;
66
 создание некоторых других второстепенных функций.
Рассмотрим необходимость данного модуля. Ранее было доказано, что
использование исключительно меток для отображения объектов маршрута не
подходит для их визуализации. В результате каждому объекту в маршруте
соответствует метка, которая вместе с другими метками, в зависимости от
масштаба или одинакового адреса, объединяется в кластеры. В зависимости
от статуса объекта (например, его наличии в отчете от подрядчиков в
качестве негорящего) целесообразно изменять внешний вид метки. В каждом
маршруте, как правило, бывает несколько таких объектов, которые зачастую
объединены в кластер. Следовательно, необходимо изменить внешний вид
такого кластера, т.е. написать собственный метод, который делает зависимым
внешний вид кластера от типов входящих в него меток. Оптимальным
является разделение кластера на сегменты, цвет которых зависит от цвета
входящих в него меток, т.е. созданием «диаграммы». Например, если в
кластере находится три объекта, среди которых два объекта из отчета
подрядчиков (метки которых решено обозначать черным цветом), то кластер
будет представлять собою диаграмму, две трети которой черного цвета и одна
треть – стандартного синего цвета.
4.
Карта автоматически позиционируется по созданной коллекции.
Модуль табличного представления маршрута работает одновременно с
модулем картографического представления, поэтому рассмотрим его работу,
начиная с этапа формирование массива геообъектов из данных, полученных с
сервера.
Помимо массива геообъектов, создается дополнительно три пустых
массива. Первый представляет собой копию массива геообъектов, он
необходим по той причине, что после добавления массива геообъектов в
коллекцию (кластеризатор), работа с его элементами невозможна. Доступ к
свойствам геообъектов необходим как для возможности просмотра сведений
об объекте на карте путем его выбора из табличного списка, так и для модуля
67
поиска по маршруту. Второй и третий массив необходим для записи
категорий и количества в каждой из них объектов из маршрута
соответственно. Далее модуль группирует объекты маршрута по категориям:
 выполняется преобразование над вторым массивом (используется метод, который дает возможность без написания циклов сделать преобразования
над выбранным массивом) с получением новых массивов, содержащих объекты из разных категорий (для этого используется вложенный метод, который
фильтрует элементы первого массива согласно указанному условию – соответствие свойства объекта «Категория» категории, соответствующей аргументу первого метода;
 каждой полученной группе объектов присваиваются значения, необходимые для ее связывания с DOM-элементом (согласно DOM-модели,
HTML-документ является деревом элементов);
 значение группы может представлять собой функцию, что используется в системе следующим образом: существует возможность отобразить/скрыть группу объектов из определенной категории. Для этого пользователю необходимо поставить/снять галочку, при этом вызывается функция, которая в зависимости от выбора добавляет или удаляет группу объектов из
кластеризатора.
Далее создается шаблон табличного списка. Суть JavaScript-шаблонов
заключается в том, что вы можете взять HTML-фрагмент, в который
вставлены переменные шаблона, и скомпоновать его с объектом JavaScript,
заменяя эти переменные шаблона значениями из объекта. Шаблон
размещается в теге SCRIPT, а в качестве MIME-типа указывается text/xjquery-tmpl [4]. Встретив при разборе документа незнакомый MIME-тип,
браузер не пытается интерпретировать содержимое тега SCRIPT, что и
требуется для нашей задачи.
Методу .tmpl() передаются два массива (массив со всеми объектами
маршрута и массив с результатами работы модуля по группировке объектов
68
маршрута по категориям, рассмотренной ранее). Кроме этого, определяется
поведение системы по клику на описание геообъекта в таблице – в цикле с
помощью стандартного метода forEach перебираются элементы массива со
всеми объектами маршрута. У найденного элемента открывается балун с
информацией об объекте.
Модуль
поиска
по
маршруту
осуществляет
поиск
объектов
энергосбережения по собственной базе данных в рамках маршрута с
автоматической подсказкой при наборе нескольких символов. Для его
реализации выполнены следующие действия:
 создается экземпляр класса стандартного поискового элемента управления;
 изменен стандартный провайдер данных на экземпляр класса собственного провайдера данных, осуществляющего поиск по полю «Название»
в коллекции всех объектов выбранного пользователем маршрута;
 используется собственный макет.
Модуль управления дорожной ситуацией и событиями является
альтернативой стандартному элементу управления «пробки», но его создание
обусловлено следующими факторами:
 стандартный элемент управления перегружает карту в совокупности с
двумя поисковыми инструментами (стандартный и разработанный) и другими элементами управлениями (масштаб, линейка и т.д.), как по мнению разработчика, так и по мнению будущих пользователей;
 возможность просмотра даты и времени в удобном формате.
Мероприятия по реализации данного модуля аналогичны действиям по
созданию модуля поиска по маршруту, за исключением следующих
моментов:
 используется рассмотренная ранее библиотека jQuery.tmpl для работы
с шаблонами;
69
 используются регулярные выражения для выбора необходимого варианта (балл, балла, баллов) в зависимости от количества баллов;
 созданы массивы соответствия дней и месяцев значениям, полученным путем вызова конструктора, возвращающего текущую дату.
Учитывая необходимость в создании собственного макета элемента
управления для двух элементов управления, необходимо рассмотреть общий
принцип взаимодействия логической и визуальной части элементов
управления API Яндекс.Карт [22].
Макет – это визуальное представление элемента управления. По сути,
макет – объект, который умеет на основе передаваемых ему данных
генерировать html.
Макет получает на вход объект с полями:

control — ссылка на элемент управления;

options — менеджер опций элемента управления;

data — менеджер данных элемента управления;

state — менеджер состояния элемента управления.
Менеджер – это хранилище, которое позволяет устанавливать и получать
значения по ключу. Менеджер опций также умеет получать опции от родительских элементов, если они не найдены у ребенка.
Опции – это рекомендации к внешнему виду элемента управления. Важная особенность опций – возможность наследования от родителей. То есть
опции можно задавать как напрямую, так и через любой из родительских
элементов. При задании опций через родительские элементы, как правило,
используется префикс.
Данные – это набор полей, описывающих информационное содержимое
элемента. Например, данными может являться заголовок списка или
содержимое кнопки. Данные не наследуются от родительских элементов и
задаются только напрямую в объект.
70
Состояние – это набор полей, описывающих текущее состояние элемента
управления. Поля состояния могут изменяться в результате действий
пользователя. Они также не наследуются от родительских элементов и могут
самостоятельно изменяться в результате действий над элементом управления
[22].
Таким образом, макет элемента управления строится на основе полей
'state', 'data' или 'options' и следит за их изменениями. При изменении
значений полей макет перестраивается.
Рис.49 Взаимодействие элемента управления и его макета
Модуль построения пути строит путь автотранспорта между любыми
двумя объектами выбранного маршрута. Выбор объекта производится с
помощью списка, автоматически созданного из порядковых номеров
71
объектов. У пользователя есть возможность построить кратчайший путь и
оптимальный путь с учетом дорожной ситуации на текущий момент времени.
Кроме этого, с помощью модуля реализованы следующие возможности:
 автоматическое формирование протяженности;
 автоматическое формирование времени в пути с учетом пробок на
данный момент;
 автоматическое формирование подробного маршрутного листа;
 изменение стилей меток начала и окончания построенного пути;
 автоматическое позиционирование карты по построенному маршруту;
 перечисленные возможности, а также очищение карты от построенного маршрута реализуются без перезагрузки страницы.
Для реализации возможностей модуля присущи следующие черты:
 в зависимости от выбранного пользователем способа построения
маршрута в функцию передается соответствующий параметр, устанавливающий свойство учета пробок в нужное значение;
 проверка и запрет на попытку построения маршрута из объекта в тот
же самый объект;
 конечный маршрут анализируется и разбивается на массив путей, согласно которому строится маршрутный лист;
 удаление маршрута с карты производится как при выборе данного
действия пользователем, так и при выборе нового маршрута путем
сохранения на него ссылки в родительской области видимости программы и последующем программном удалении.
Модуль поиска объектов в радиусе обнаруживает объекты в пределах
окружности указанного пользователем радиуса от какого-либо объекта маршрута. Для реализации этой задачи необходимо использовании формулы
Гаверсинуса [23]:
72
Рис.50 Определение функции гаверсинуса
a = sin²(Δφ/2) + cos(φ1).cos(φ2).sin²(Δλ/2)
c = 2.atan2(√a, √(1−a))
d = R.c
где φ – широта, λ – долгота, R – радиус планеты Земля =
6371 км).
Для формулы необходимы значения долготы и широты объекта, относительно которого ведется поиск, и соответствующие значения всех остальных
объектов.
Таким образом, запрос к базе данных включает в себя следующие строки:
6371 * acos( cos( radians(lat_объекта) ) * cos( radians( lat ) ) * cos( radians( lng ) —
radians(lng_объекта) ) + sin( radians(lat_объекта) ) *
sin( radians(lat) ) )
Модуль формирования отчета машиночитаемого формата выполняет
следующие действия:
73
 предоставляет возможность специалисту ввести результаты своей работы в ранее подготовленный шаблон, представляющий собой готовую html-страницу;
 заполнение шаблона происходит путем присвоения данных, введенных пользователем, php-переменным, которые находятся в определенных местах шаблона;
 для перевода в доступный Excel формат используется функция
«htmlentities» в совокупности со следующими параметрами: 1. входная строка, 2. ENT_COMPAT, 3. "Windows-1251", где ENT_COMPAT
преобразует двойные кавычки (одинарные кавычки не изменяются), а
третий аргумент задает кодировку, используемую при преобразовании;
 в заголовке страницы указана информация, необходимая для выведения заполненного шаблона, представляющего собой html таблицу, под
видом xls-файла.
Модуль формирования отчетов подрядных организаций (и ежемесячного
на их основе) работает аналогично модулю формирования маршрута.
Формирование ежемесячного отчета производится путем соответствующего
запроса к базе данных (аналогично модулю табличного представления
маршрута, а именно его операции по объединению объектов маршрута по
категориям и подсчета количества в каждой из них).
Модуль
идентификации
пользователя
выполняет
работу
по
разграничению прав доступа к модулям системы. Пароль для каждого
пользователя хранится не в чистом виде,
а в виде хэша (хэширование
произведено с помощью функции с помощью функции md5()). Однако зная
алгоритм хеширования, пароль можно подобрать. Поэтому используется так
называемая «соль», т.е. набор символов, который добавляется к каждому
паролю. В случае удачной авторизации идентификатор пользователя
записывается в сессию. Благодаря использованию в системе сессий при
74
каждом случае запроса к какому-либо модулю всегда можно определить его
доступность для обращающегося сотрудника.
Схематическое
представление
взаимодействия
модулей
системы
представлено на рисунке.
Рис.51 Схема взаимодействия модулей системы
Общая компоновка экранных форм, разработанная на уровне концепции, была соблюдена при разработке детальных прототипов проекта с помощью инструмента Twitter Bootstrap.
75
Рис.52 Пользовательский интерфейс главной страницы системы
Модули визуализации объекта маршрута в виде круговой диаграммы,
управления дорожной ситуацией и событиями и поиска по маршруту
соответствуют основным принципам паттерна Model-View-Controller. Вопервых, следует отметить недостатки другого подхода. Его реализация
заключается в следующем – на элемент дизайна (кнопка, текстовое поле и
т.д.) определяется обработчик необходимых действий с помощью методов
API Яндекс.Карт. В этом случае необходимо полностью реализовать его
логику работы, которая включает в себя:
 логика запросов на сервер;
 логика выбора элемента и снятия выделения со старого активного
элемента;
 логика обработки объектов поисковой выдачи;
и многое другое.
76
Во-вторых, разделение бизнес-логики и представления устраняет
проблематичность поддержки модулей в будущем.
Выводы
Технологичность в разработке системы позволила организовать процесс
ее реализации лучшим образом.
Создание прототипа системы позволило устранить ряд недостатков,
исправление которых в ходе реализации функциональности заняло бы
больше как времени, так и ресурсов. Была разработана диаграмма
прецедентов, которая дает понимание структуры приложения и позволяет
перейти к этапу разработки прототипа пользовательского интерфейса.
Построенная концептуальная модель системы позволила организовать
необходимое взаимодействие с представителями из других организаций, в
ходе которого были учтены их пожелания к разрабатываемому вебприложению. До перехода к разработке архитектуры системы прототип
перерабатывался несколько раз.
В ходе разработки архитектуры системы были определены группы
пользователей и их роли в системе, построена схема базы данных. Данный
этап также сопровождался постоянным сбором и анализом требований
будущих пользователей.
Моделирование
системы
и
использование
новейших
технологий
определили перспективы данной работы и возможность ее поддержки в
дальнейшем.
77
1.5 Оптимизация и расчет надежности системы
Тестирование прототипа
Прототип, созданный на бумаге можно тестировать, используя самое
дешёвое юзабилити-тестирование, которое позволит совершенствовать прототип, учитывая мнение о нем как пользователя, так и разработчика [6]. Минута, потраченная на разработку и тестирование бумажного прототипа, экономит много часов на этапе разработки пользовательского интерфейса на основе созданного прототипа.
Для участия в тестировании были привлечены 4 участника. Для
проведения тестирования требовались:
 пользователь;
 компьютер (человек, имитирующий работу компьютера);
 ведущий (задает вопросы персонажу и помогает ориентироваться в
системе);
 наблюдатель (человек, наблюдающий за тестированием).
Задания для тестирования были составлены таким образом, чтобы
охватить основные задачи, решаемые пользователями создаваемой системы.
Рис.53 Тестирование бумажного прототипа интерфейса АИС
78
Респонденту предлагалось выполнить задание с помощью макета спроектированного в данной дипломной работе. Были предложены следующие
задачи:
 выбрать маршрут согласно графику работы отдела;
 посмотреть «пробки» в городе с учетом дорожных событий;
 построить маршрут с учетом пробок;
 найти определенный объект из маршрута двумя способами;
 скрыть на карте объекты из двух произвольных категорий;
 добавить новый маршрут;
 сделать ежедневный отчет и др.
Выполняя задания, пользователь должен был комментировать свои действия, объясняя их причины и высказывая вслух свои мысли и эмоции [6].
Результаты тестирования были учтены на этапах разработки архитектуры системы и ее последующей реализации.
Оптимизация
В ходе тестирования системы были выявлены критические запросы и
ситуации и реализованы следующие способы улучшения характеристик
системы:
 преобразование адресов объектов в координаты производится на сервере (а не на клиентской стороне), т.е. на стороне клиента происходит работа
с результатами, уже записанными в базу данных;
 подсчет объектов, принадлежащих разным категориям, производится
на стороне сервера;
 производится выбор только необходимых пакетов API Яндекс.Карт,
компоненты которых необходимы для работы системы;
 учитывая большое количество объектов в каждом маршруте, использование кластеров и Google Chart API для их сегментации позволило избежать большой потери производительности;
79
 отказ от библиотеки PHPExcel по работе с форматами xls из-за ее
лишней функциональности и нерационального использования памяти;
 отказ от каркаса для разработки веб-приложения (фреймворка) из-за
специфических требований системы и, как следствие, отсутствия стандартных библиотек, за исключением модуля идентификации пользователя (написание которого является оптимальным решением, учитывая большое количество лишнего кода и специфическую настройку при использовании фреймворка, что затрудняет последующую возможность интеграции с другими проектами и снижает производительность системы).
Расчет надежности
Экспоненциальная модель надежности ПО основана на предположении
об экспоненциальном характере изменения числа ошибок во времени. В
период нормальной эксплуатации интенсивность отказов не изменяется [10].
Средняя наработка на отказ рассчитывается следующим образом:
T 
0 
1
,
ПО
где λПО – интенсивность ошибок программного обеспечения.
Интенсивность ошибок разрабатываемого программного обеспечения
рассчитывается по формулам:
ПО  0 * e t
0 
,
N
N
0 K
 0 K
K
K
,
N  t ТП N  t ТПi ЯЗi ПЛi
где t – фактическое время отладки;
α – коэффициент крутизны линии, характеризующий скорость роста
надежности;
N0 – число обнаруженных ошибок за время отладки t;
N – общее число строк;
КТП
–
коэффициент,
учитывающий
влияние
методологии
программирования на надежность ПО;
80
КТПi – коэффициент, учитывающий использование i–ой технологии
программирования;
КЯЗi
–
коэффициент,
учитывающий
использование
i–ого
языка
программирования;
КПЛi – коэффициент, учитывающий использование i–ой платформы
программирования.
В
данном
программном
обеспечении
использована
ориентированная технология программирования ( K
(K
K
 0,1 ), язык Javascript
 3 ) на 32-разрядной платформе (для платформ, не являющихся .NET,
ЯЗi
 2 ).
ПЛi
K
ТПi
объектно-
ТП
 3  0,1  2  0,6
Исходное число строк кода N=4927.
Результаты отладки программного обеспечения представлены в таблице
13.
Число ошибок Время отладки t, часы
Интенсивность ошибок, λ0 1/ час
20
4
0,00006
15
4
0,000047
10
4
0,000029
8
4
0,00002
6
4
0,000015
3
4
0,000008
1
4
0,00000
Таблица 14. Результаты отладки ПО
На основе полученных данных можно построить кривую зависимости
интенсивности ошибок от времени отладки.
81
Рис. 54 Зависимость интенсивности ошибок от времени отладки
Как показано выше, функциональная зависимость интенсивности
ошибок ПО от времени отладки описывается экспоненциальным законом и
зависит от коэффициента крутизны линии, характеризующей скорость роста
надежности α, и от фактического времени отладки ПО. Анализ результатов
тестирования ПО позволил определить α = 0,06.
Таким
образом,
интенсивность
ошибок
разрабатываемого
ПО
составляет:
ПО  0  et  0,00006  e0,064  0,000047 (1/час)
По экспоненциальному закону вероятность безотказной работы:
P  t   e  *t
За 8 часов
P  t   0,999624
82
Наработка на отказ программного обеспечения составляет:
T 
0 
1
ПО

1
 21276(ч)
0,000047
Выводы
По результатам тестирования проекта была произведена оптимизация
системы и выполнены мероприятия по улучшению ее характеристик.
Выполнен расчет надежности системы.
83
2. Экономическая часть
Работа, предусмотренная выполнением производственного заказа, носит
инженерный
характер
и
предусматривает
работу
пользователя
на
персональном компьютере. Полный цикл производства выполняется одним
сотрудником, имеющим квалификацию и опыт по проведению всех стадий
разработки. Весь проект выполняется в течение 3 месяцев. Учитывая
необходимую квалификацию инженера, заработная плата оценивается в
40000 руб/месяц. Суммарные расходы на заработную плату составляют:
ЗП = 400000 x 3 = 120000 руб.
Накладные расходы на производство складываются из стоимости и
прокладки проводки, аренды помещения, оплаты ЖКУ, оплаты телефона и
Internet, оплаты проездного билета. Стоимость проводки и ее монтажа
составляет 5000 рублей. Подключение к Интернету, предоставляемое
провайдером, обслуживающим офисное здание составляет 1250 рублей,
тариф с минимальной стоимостью (100Мбит/с, лимит трафика 3 гигабайта в
месяц) равен 1100 рублей. Оплата телефона (до 1000 минут звонков на
номера любых мобильных операторов и городские) составляет 900 рублей в
месяц. Согласно эргономическим требованиям к организации рабочих мест,
площадь, выделяемая на одно рабочее место, должна составлять не менее 8
м2. Исходя из стоимости аренды 1 м2 площади 1600 руб/месяц (с
коммунальными услугами) получаем, что стоимость аренды помещения для
одного рабочего места за 3 месяца равняется 38400 рублей. Оплата
безлимитного проездного билета на метро составляет 5200 рублей.
НР = 1250 + (1100+900) х 3 + 38400 + 5200= 50850 руб.
Выполнение работы невозможно без оборудования. Для подготовки
проекта требуется персональный компьютер с установленным набором
офисных программ, а также специализированные автоматизированные
84
средства проектирования. Т.к. в качестве инструментов разработки выбрано
свободное программное обеспечение, то их использование бесплатно. Один
компьютер в комплектации, подходящей для выполнения поставленных
задач, стоит 1500 рублей в месяц с учетом установленной лицензионной
операционной системы Microsoft Windows 7 Professional и пакета Microsoft
Office Professional Plus 2007.
ОБ = 1500 х 3 = 4500 руб.
Готовый и черновой документационный материал распечатывается в
ближайшей типографии. Средняя стоимость одного листа черно-белой печати
составляет 3 рубля при печати от 20 страниц, цветной – 18 рублей при печати
от 50 страниц. Черно-белая печать используется для основной части
документа, а также черновых вариантов. Цветная печать используется для
окончательных частей документа, содержащих графический материал.
ПЧБ = 3 х 500 = 1500 руб.
ПЦВ = 18 х 70 = 1260 руб.
ПОБЩ = ПЧБ + ПЦВ = 1500 + 1260 = 2760 руб.
Итоговая себестоимость проекта составляет следующую сумму:
СБ = ЗП + НР + ОБ + ПОБЩ = 120000 + 50850 + 4500 + 2760 = 178110
руб.
Ставка НУСНО = 6% от Ц, отсюда N = 0,06 * Ц.
Обязательный
взнос в ПФР рассчитывается
по
формуле
2
*
минимальный размер оплаты труда * 26% * время разработки. С 1 января
2013 года, минимальный размер оплаты труда составляет 5 205 р./мес. В
контексте рассматриваемой задачи, взнос в ПФР за все время разработки
составляет:
2 * 5 205 руб. * 26% * 3 = 8 119,80 руб.
Обязательный
взнос
в
ФФОМС
рассчитывается
по
формуле
минимальный размер оплаты труда * 5,1% * время разработки. В контексте
85
рассматриваемой задачи, взнос в ФФОМС за все время разработки
составляет:5 205 руб * 5,1% * 3 = 796,37 руб.
Ц = СБ + Н + П, где Н – налоги, П – прибыль.
Ц = СБ + 0.06 * Ц + 0,4 * Ц;
0,54 * Ц = СБ;
Ц = СБ/0,54
Ц = 178110/0,54 = 329 833 руб.
Чистая прибыль П = 0,4 * Ц = 131 933 руб.
Налог УСНО N = 19 790 – 796 – 8 120 = 10 874 руб.
№
Категории расходов
Значение
1
Заработная плата
120 000 руб.
2
Накладные расходы
58 110 руб.
3
Налог УСНО
10 874 руб.
4
Налог ПФР
8 120 руб.
5
Налог ФФОМС
796 руб.
6
Чистая прибыль
131 933 руб.
7
Рентабельность
40 %
Таблица 15. Оценка стоимости работы Итого:
Ниже
представлена
диаграмма,
329 833 руб.
характеризующая
экономические
параметры работы:
86
Заработная плата
Накладные расходы
Налог УСНО
Налог ПФР
Налог ФФОМС
Чистая прибыль
Рис 55. Диаграмма стоимости работы
Выводы
Преобладание свободного программного обеспечения среди выбранных
средств разработки системы определяет выгодную экономическую составляющую проекта и дальнейшие перспективы развития. Также произведен
расчет всех затрат на создание АИС в течение трех месяцев и ожидаемой
прибыли.
87
3. Охрана труда
К энергосберегающим источникам света сегодня относят:
 флуоресцентные лампы;
 газоразрядные лампы высокой интенсивности;
 светодиодные лампы.
Основные эксплуатационные и светотехнические различия энергосберегающих источников света представлены в таблицах:
Долговечность и основные светотехнические характеристики источников света.
88
Таблица 16. Долговечность и основные светотехнические характеристики источников света.
Таблица 17. Зависимость световой отдачи от мощности источников света.
Таблица 18. Эксплуатационные характеристики светодиодов, КЛЛ и
ламп накаливания.
По полученным данным видно, что светодиодные лампы имеют значительное превосходство над конкурентами. Перспектива использования данного источника освещения очевидна и уже поддерживается на государственном уровне (например, применение светодиодных светильников в самой широкой части Садового кольца – Зубовском бульваре). Но стоит отметить и
недостатки:
 стоимость;
89
 холодный цвет спектра с негативным световосприятием для человека
при использовании некачественного люминофора;
 отсутствие в некачественных светильниках рассеивателя (высокая
концентрация светового излучения светодиода, вредная для человеческого глаза);
 высокая пульсация при использовании в светильнике некачественного
драйвера.
Рис 56. Диаграмма спектров излучений светодиодов разного цвета
свечения
Из диаграммы видно, что пик излучателя больше у светодиодов
холодного свечения и меньше у теплого. В связи с этим, производители
применяют светодиоды холодного свечения, учитывая более высокую
мощность излучения пика, что негативно сказывается на человечкском
световосприятии.
Выводы
Таким образом, была показана необходимость использования качественных светодиодных светильников, недостатка в которых на данный момент на
рынке нет. В таком случае, будут использованы все преимущества данного
вида освещения, а именно стабильность светового потока, широкий угол
охвата и высокая яркость.
90
Заключение
В работе решена задача по созданию системы, обеспечивающей
взаимодействие между начальником отдела и его сотрудниками внутри
организации, а также между организацией и субподрядчиками.
В ходе выполнения дипломного проектирования был проведен анализ и
моделирование предметной области, выполнено проектирование базы данных и рассмотрена разработка программного обеспечения. Выполнен анализ
архитектуры API Яндекс.Карт 2.0 и создан детальный прототип пользовательского интерфейса на основе ранее построенной концептуальной модели.
Приводятся результаты тестирования прототипа интерфейса и расчеты
надежности системы, а также описываются мероприятия по улучшению показателей эффективности созданного ПО.
В разделе "Экономическая часть" произведен расчет всех затрат на создание АИС в течение трех месяцев и ожидаемой прибыли.
В разделе "Охрана труда" приведен обзор источников искусственного
освещения с выявлением наиболее перспективных и рекомендации по защите
здоровья от вредных и опасных факторов, возникающих при излучении ламп.
Реализованная в соответствии с техническим заданием система доказала,
что интеграция автоматизированных систем в бизнес-процессы предприятий
топливно-энергетического комплекса позволяет на качественно новом уровне
решать задачи, поставленные Государственной программой.
91
Приложение 1. Графический материал
Постановка задач
 Цель:
Разработать систему, позволяющую организовать и автоматизир
разъездных бригад, поддерживающих осветительные установки г
вы в регламентном состоянии.
 Актуальность:
Необходимость в повышении скорости и корректности принятия
трудников организаций энергетического комплекса в рамках реал
дарственной программы.
 Задачи:
Сформировать требования и проанализировать существующие р
Разработать прототип системы.
Разработать рабочую версию системы.
92
Анализ аналого
Instant
АИС
«ОГД»
АИС РФС АПК
MapInfo Pro
Maps
Clo
Ma
Веб-интерфейс
+
±
-
+
+
Поиск объектов в локальной
базе данных в рамках
маршрута
±
±
±
+
±
Визуализация данных об
объектах на карте
+
-
-
±
+
Возможность редактирования
слоев (категорий объектов)
+
+
+
+
+
Получение координат
+
-
+
+
-
по массиву адресов
Документооборот
-
+
+
+
-
Удобство эксплуатации
+
+
+
±
-
Стоимость
±
-
-
-
+
93
Выбор
инструментального
Выбраны следующие программные компоненты и средства разраб
 Apache, MySQL и PHP.
 API Яндекс.Карт 2.0.
 HTML 5 и CSS 3.
 Lucidchart – моделирование предметной области системы.
 MySQL Workbench – проектирование базы данных.
 BalsamiqMockups – проектирование пользовательского интерфейса.
 JavaScript, jQuery и jQuery Templates.
 Google Chart API.
 Фреймворк Twitter Bootstrap.
 Php-excel-reader – формирование шаблона из Excel файла.
94
Модель
предметной области
95
Концептуальная
модель интерфейса
Представление
выбранного
маршрута
Локальный
поиск
Картографическое
Табличное
96
Схема базы данных
97
Примеры
экранных форм
Форма авторизации
Фрагмент работы систем
Группировка объектов
на карте
98
Примеры
выходных отчетов
Сформированный начальнико
Путь между объектами
маршрута
Отчет специалиста о р
99
Список используемых источников
1.
Л. Константайн, Л. Локвуд. Разработка программного обеспечения. –
СПб.: Питер, 2004. – 592 с.
2.
Гради Буч, Джеймс Рамбо и Ивар Якобсон. Язык UML. Руководство
пользователя. – ДМК Пресс., 2006. – 496 с.
3.
David Cochran. "Twitter Bootstrap Web Development How-To. Packt,
2012. – 592 с.
4.
Маккоу А. Веб-приложения на JavaScript. – СПб.: Питер, 2012. – 288
5.
Мэтт Зандстра. PHP. Объекты, шаблоны и методики программиро-
с.
вания. – Вильямс, 2013. – 560 с.
6.
Джеф Раскин. Интерфейс: новые направления в проектировании
компьютерных систем. – Символ-Плюс, 2005. – 272 с.
7.
Алан Купер, Роберт Рейман, Дэвид Кронин. Алан Купер об интер-
фейсе. Основы проектирования взаимодействия. – Символ-Плюс, 2009. – 688
с.
8.
ISO/IEC 12207 Systems and software engineering — Software life cycle
processes. Geneva, Switzerland: ISO, 2008.
9.
Карпова И.П. Введение в базы данных. Учебное пособие. – М.:
МИЭМ, 2005. – 75 с.
10. Половко, А.М. Основы теории надёжности / А.М. Половко, С.В. Гуров – 2-е изд., прераб. и доп. – Спб.: БХВ-Петербург, 2006. – 704 с.
11. Официальный
портал
Мэра
и
Правительства
Москвы.
Государственная программа города Москвы «Энергосбережение в городе
Москве» на 2012-2016 гг. и на перспективу до 2020 года // http://www.mos.ru/.
12. О создании информационной системы мониторинга и управления
эффективностью энергосбережения на объектах города Москвы // Промышленная Энергетика.-2012.-№6(2-6).
13. Всеволод
Николаев.
Геоинформационная
система
MapInfo
100
Professional // САПР и графика.-2013.-№2.
14. Сергей Яценко. Яндекс.Карты — на все сайты // NBSP.-2013-№4.
15. Официальный сайт федерального государственного бюджетного
учреждения "Российский центр стандартизации и метрологии" (ФГБУ "Росагропромстандарт"):
ВЕДЕНИЕ
РФС
АПК,
2013.
//
http://rosast.ru/
index.php?option=com_content&task=blogcategory&id=76&Itemid=160.
16. ГЕОКАД: Системные решения конечного пользователя на базе
GeoCad Systems, 2013 // http://www.geocad.ru/soft/ogd/.
17. Официальный сайт департамента информационных технологий города Москвы: Сервисы для госорганов, 2013. // http://dit.mos.ru/atlas/.
18. OpenStreetMap Forum, 2013 // http://forum.openstreetmap.org/.
19. Официальный
сайт
сервиса
Карты
Google,
2013
//
https://maps.google.com/
20. Официальный
сайт
системы
InstantMaps,
2013
//
http://www.instantmaps.ru/about/index.html
21. Официальный сайт сервиса 2ГИС, 2013 // www.2gis.ru
22. Руководство разработчика, использующего JavaScript API Яндекс.Карт, 2013 //
http://api.yandex.ru/maps/doc/jsapi/2.x/dg/concepts/general.xml.
23. Википедия. Формула Гаверсинуса. //
http://en.wikipedia.org/wiki/Haversine_formula
24. СНиП 23-05-95 (СП 52.13330.2011). Естественное и искусственное
освещение.
25. СанПиН 2.21/2.1.1.1278-03. Гигиенические требования к естественному, искусственному и совмещенному освещению жилых и общественных
зданий.
101