close

Вход

Забыли?

вход по аккаунту

Забелин Сергей Алексеевич. Методика взаимодействия жителей города при решении проблем городского хозяйства

код для вставки
Powered by TCPDF (www.tcpdf.org)
АННОТАЦИЯ
ВКР 85 с., 35 рис., 3 табл., 22 источников, 1 прил.
ГОРОДСКОЕ
ХОЗЯЙСТВО,
ЖКХ,
ПРОБЛЕМЫ
ГОРОДСКОГО
ХОЗЯЙСТВА, ИНФОРМАЦИОННАЯ СИСТЕМА, СБОР ИНФОРМАЦИИ, ВЕБСЕРВИС,
ГЕОИНФОРМАЦИЯ,
ГЕОЛОКАЦИОННЫЙ
СЕРВИС,
ГЕОСОЦИАЛЬНАЯ СЕТЬ, ОБРАТНОЕ ГЕОКОДИРОВАНИЕ.
Выпускная квалификационная работа посвящена разработке методики
взаимодействия жителей города при решении проблем городского хозяйства,
которая
позволит
документооборотом,
избежать
решить
узких
мест,
проблемы
с
связанных
открытостью
с
неэффективным
и
актуальностью
информации по проблеме, повысить качество жизни людей в городе.
В первой главе был произведен анализ и исследование существующих
подходов взаимодействия жителей города при решении проблем городского
хозяйства, разработка требований к информационной системе.
Во второй главе проанализировали существующие методы взаимодействия
жителей города при решении проблем городского хозяйства. Разработана
методика взаимодействия жителей города при решении проблем городского
хозяйства.
В третьей главе была разработана логическая схема построения системы,
описана архитектура системы, спроектирована структура данных в виде
логической и физической модели.
В четвертой главе описаны алгоритмы работы основных модулей
подсистемы, реализующей разработанную методику, разработана логика диалога с
пользователем,
спроектированы
и
описаны
пользовательские
интерфейсы
системы.
В заключении сделаны основные выводы по выпускной квалификационной
работе.
Разработанная методика позволит повысить качество жизни людей, решив
проблемы открытости и актуальности информации по проблемам города.
4
СОДЕРЖАНИЕ
ВВЕДЕНИЕ
6
1 АНАЛИЗ И ИССЛЕДОВАНИЕ СУЩЕСТВУЮЩИХ ПОДХОДОВ
ВЗАИМОДЕЙСТВИЯ ЖИТЕЛЕЙ ГОРОДА ПРИ РЕШЕНИИ ПРОБЛЕМ
ГОРОДСКОГО ХОЗЯЙСТВА
10
1.1 Обзор существующих систем обеспечивающих взаимодействие жителей
города при решении проблем городского хозяйства
10
1.2 Анализ подходов к построению систем обеспечивающих
взаимодействие жителей города при решении проблем городского
хозяйства
15
1.3 Формализация требований к системе взаимодействия жителей города
при решении проблем городского хозяйства
23
1.4 Постановка задачи исследования
30
2 СУЩЕСТВУЮЩИЕ МЕТОДЫ ВЗАИМОДЕЙСТВИЯ ЖИТЕЛЕЙ
ГОРОДА ПРИ РЕШЕНИИ ПРОБЛЕМ ГОРОДСКОГО ХОЗЯЙСТВА
32
2.1 Исследование и анализ подходов к выстраиванию взаимодействия
жителей города при решении проблем городского хозяйства
32
2.2 Выявление преимуществ и недостатков подходов к выстраиванию
взаимодействия жителей города при решении проблем городского
хозяйства
35
2.3 Методика взаимодействия жителей города при решении проблем
городского хозяйства
37
3 ПРОЕКТИРОВАНИЕ ПРОТОТИПА ИНФОРМАЦИОННОЙ СИСТЕМЫ,
РЕАЛИЗУЮЩЕГО РАЗРАБОТАННУЮ МЕТОДИКУ
44
3.1 Архитектура прототипа информационной системы, реализующего
разработанную методику
44
3.2 Проектирование структуры данных
48
3.3 Разработка алгоритмов работы отдельных подсистем
62
5
4 РЕАЛИЗАЦИЯ ПРОТОТИПА ИНФОРМАЦИОННОЙ СИСТЕМЫ
РЕАЛИЗУЮЩЕЙ МЕТОДИКУ ВЗАИМОДЕЙСТВИЯ ЖИТЕЛЕЙ
ГОРОДА ПРИ РЕШЕНИИ ПРОБЛЕМ ГОРОДСКОГО ХОЗЯЙСТВА
67
4.1 Построение логики диалога с пользователем
67
4.2 Экранные формы прототипа информационной системы, реализующего
разработанную методику
70
ЗАКЛЮЧЕНИЕ
77
СПИСОК ЛИТЕРАТУРЫ
79
ПРИЛОЖЕНИЕ А Копия свидетельства о регистрации программы для
ЭВМ
82
УДОСТОВЕРЯЮЩИЙ ЛИСТ № 165143/п
83
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА ДОКУМЕНТА
НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
84
6
ВВЕДЕНИЕ
Существованию
городов
на
протяжении
истории
человеческой
цивилизации всегда сопутствовали различные проблемы, связанные с их
благоустройством,
вопросами
снабжения
продовольствием,
обеспечения
безопасности, духовных потребностей населения и др. Со временем некоторые
вопросы ушли на государственный уровень, другие стали неактуальны, но
полностью проблемы никогда не заканчивались, более того, их число
увеличивалось.
Развитию
продолжительности
и
общества
качества
жизни
сопутствовало
населения,
увеличение
научно-техническое
и
культурное развитие, отток основной массы населения в города, что в свою
очередь позволило интегрировать жилые дома в общую систему коммуникаций
города. Это способствовало внедрению в быт населения новых технологий,
увеличения спроса на новые услуги. Начало формироваться понятие городского
хозяйства[1].
На
сегодняшний
день
городское
хозяйство
-
это
сложно-
структурированная, постоянно изменяющаяся система взаимодействующих между
собой различных сфер человеческой деятельности, направленных на обеспечение
и удовлетворение основных потребностей жителей, организаций и предприятий
города.
Сложность
многообразии
и
управления
системой
разнородности
городского
потребностей
хозяйства
жителей
состоит
города,
в
состава
организаций и предприятий, характера оказываемых ими услуг, организационных
форм, их структуры и специфики деятельности.
Наиболее
употребим
термин
городского
хозяйства
в
отношении
совокупности сфер деятельности, обеспечивающих функционирование города,
предоставляющих следующие виды услуг:
 производственные услуги, направленные на удовлетворение запросов
производства, но не являющиеся частью его технологического процесса. Это
услуги, связанные в основном с водоснабжением производства, обеспечением
7
тепло- и электроэнергией, доставкой сырья, конечной продукции потребителю и
т.д.;
 личные услуги, направленные на удовлетворение как материальных, так
и духовных запросов населения. Как правило, это услуги организации торговли,
общественного питания, функционирования большинства отраслей жилищнокоммунального хозяйства (ЖКХ), бытового обслуживания, здравоохранения и т.д.;
 общественные услуги, направленные на развитие самого города и его
подсистем. Это органы управления, охраны общественного порядка, науки и
научного обслуживания внутригородского значения, услуги по благоустройству и
озеленению территории и т.д. [2]
При
решении
проблем
городского
хозяйства,
часто
обращения
определенных слоев населения попросту не доходили до управляющих
организаций, решение проблем города осуществлялось без участия его граждан и
занимало
длительное
разрастающимся
время.
Увеличение
бюрократическим
сроков
аппаратом,
из-за
было
сопряжено
масштабов
с
которого
обращения населения нередко терялись среди множества подведомственных
подразделений. В настоящее время ситуация обстоит несколько лучше. Аппарат
взаимодействия жителей города с управляющими структурами постоянно
подвергался изменениям, сейчас каждый человек может принять участие в
решении
проблем
городского
хозяйства.
Однако
нельзя
сказать,
что
существующие механизмы взаимодействия работают хорошо, поскольку процесс
по-прежнему занимает длительное время, жителю города требуется собрать
необходимые
документы,
написать
заявление,
посетить
управляющую
организацию. В данном случае решение проблемы не является прозрачным.
Жители не могут должным образом отслеживать текущий этап решения
рассматриваемого вопроса [3].
Классическая схема взаимодействия жителей города представляет собой
собрание
жильцов,
обсуждение
существующих
проблем,
выявление
их
актуальности и выставление им приоритетов, принятие мер по их устранению и
отслеживание процесса решения. В такой схеме есть много узких мест, которые
8
препятствуют прозрачности процесса, сильно увеличивают время между
формулированием проблемы и ее решением, ведут к неправильной расстановке
приоритетов и ряду других проблем. Во-первых, по разным причинам, не все
жильцы могут принять участие в собрании, что в свою очередь ведет к неверной
расстановке приоритетов группой жильцов, поскольку не все мнения будут
учтены. Во-вторых, даже посетив собрание, граждане могут не прийти к
консенсусу за отведенное на собрание время. В-третьих, если проблема
сформулирована, признана актуальной, выбрана приоритетной и доведена до
управляющей организации - ставится вопрос о мониторинге выполнения работ по
поставленной задаче. И здесь возникает проблема с отслеживанием выполнения
промежуточных этапов решения проблемы. Жители могут убедиться в том, что по
их вопросом выполняются работы, лишь лично увидев это [4].
Таким образом, существующие подходы, обеспечивающие взаимодействие
жителей города при решении проблем городского хозяйства, не удовлетворяют
современным требованиям открытости и оперативности информации, что в свою
очередь приводит к временным и финансовым потерям различных коммунальных
и муниципальных служб, неэффективности выполнения задач по решению
проблем и как следствие — к снижению уровня жизни граждан.
Отсюда следует актуальность разработки методики взаимодействия
жителей города при решении проблем городского хозяйства. Она позволит
избежать узких мест, связанных с неэффективным документооборотом, решить
проблемы с открытостью и актуальностью информации по проблеме, повысить
качество жизни людей в городе.
Целью
выпускной квалификационной
работы
является
повышение
эффективности взаимодействия граждан и управляющих организаций по
вопросам городского хозяйства, путем внедрения информационной системы,
реализующей разрабатываемую методику взаимодействия жителей города при
решении проблем городского хозяйства.
9
Основными задачами являются:
− анализ
существующих
систем,
обеспечивающих
взаимодействие
жителей города при решении проблем городского хозяйства;
− изучение подходов к построению существующих систем;
− разработка собственной методики;
− проектирование прототипа информационной системы использующего
разработанную методику;
− разработка и реализация прототипа.
Основные
положения
выпускной
квалификационной
работы
докладывались на следующих конференциях:
1. Международная научно-практическая конференция «Экономическая
безопасность в современной России: стратегия противодействия угрозам и
перспективы устойчивого геополитического развития»
2. I молодёжная научно-практическая конференция с международным
участием, г. Белгород, 2017 г.
3. Студенческая научно-техническая конференция «Неделя науки – 2017»,
г. Орел, 2017 г.
10
1 АНАЛИЗ И ИССЛЕДОВАНИЕ СУЩЕСТВУЮЩИХ ПОДХОДОВ
ВЗАИМОДЕЙСТВИЯ ЖИТЕЛЕЙ ГОРОДА ПРИ РЕШЕНИИ
ПРОБЛЕМ ГОРОДСКОГО ХОЗЯЙСТВА
1.1 Обзор существующих систем обеспечивающих взаимодействие
жителей города при решении проблем городского хозяйства
На сегодняшний день основная доля населения страны сосредоточена в
городах.
Именно
здесь
находятся
научно-технический,
социальный
и
экономический потенциалы России, накапливаются природные, социальные и
финансовые
ресурсы,
требуемые
для
социально-экономического
развития
регионов и государства в целом. Совокупность этих факторов определяет
важность создания, внедрения и использования информационных технологий в
процессе управления городским хозяйством с целью создания необходимых
условий для социально-экономического прогресса городов, повышения качества
жизни людей и эффективного использования созданных и накопленных ресурсов
города.
Так как для управления городским хозяйством требуется располагать
информацией о множестве объектов муниципальной структуры, то употребим
термин «геоинформация» [5].
Геоинфомрация — это координированная информация о геопространстве и
его объектах в цифровой компьютерно-воспринимаемой форме, предназначенная
в качестве исходного материала для моделирования геопространства в интересах
конкретного потребителя [6].
В условиях переходного периода механизм управления советского периода
с
применением
внеэкономического
административно-ведомственный
принуждения
механизм.
был
Приведем
преобразован
в
характеристики
современной системы управления городским хозяйством:
1) преобладание государственной и муниципальной собственности в
городском хозяйстве и торможение формирования частного сектора;
2) развитие ведомственного монополизма и ведомственной централизации;
11
3) повышение тарифов на услуги и продукцию жилищно-коммунального
сектора;
4) ведомственный бюрократизм в управлении;
5) ведомственное наблюдение за результатами деятельности;
6) низкая эффективность и громадные потери используемых ресурсов;
7) дотационное финансирование.
Проанализировав приведенные черты механизма управления городским
хозяйством, можно сделать заключение, что в настоящее время в управлении
городским
хозяйством
приоритет
имеет
административно-ведомственный
механизм, основанный на приказах и распоряжениях, а не на учете интересов
участников и обоснованных продуманных решениях. Следовательно, необходимы
существенные преобразования системы управления городским хозяйством и
переход к индикативному механизму управления, соответствующему рыночным
условиям хозяйствования
и ориентирующемуся на интересы жителей города.
Нужно сформировать новый хозяйственный механизм, ориентированный на учет
интересов потребителей. Для достижения цели потребуется решить ряд
следующих задач [7]:
− первостепенное обеспечение учета интересов населения при решении
вопросов развития городского хозяйства;
− разработка системы взаимоотношений между всеми участниками
хозяйственных интересов на экономической и правовой основах;
− обеспечение устойчивого ресурсосбережения комплекса отраслей
городского хозяйства.
На текущий момент для обеспечения взаимодействия между жителями
города и представителями управляющих компаний (УК) создаются различные
информационные системы (ИС) приема заявок от населения. Ниже рассмотрим
некоторые из них.
Наш город — информационный портал, был создан в 2011 году. ИС
представлена как веб-сфйт в сети Интернет и в виде мобильных приложений для
платформ Android и iOS. Пользуясь этим порталом, жители Москвы могут
12
принимать участие в развитии столицы, своевременно информировать о
проблемах города властей, отслеживать своевременность и качество выполнения
заявок, сообщать о нарушениях и оценивать работу государственных учреждений.
Для пользования ресурсом требуется:
1. Выполнить регистрацию на сайте, указав персональные данные.
2. Принять к сведению правила модерации заявок, без прохождения
заявкой процесса модерации она не поступит в обработку.
3. Войти в систему, используя регистрационные данные.
4. Подать заявку, описав проблему, указав адрес, выбрать раздел проблемы,
прикрепить фотографии.
Для удобства восприятия информации все проблемы представлены на
карте.
Каждая поданная заявка проверяется в течении суток администратором,
если все корректно, она публикуется. Все заявки обязательны к рассмотрению, в
течении восьми дней по заявке должен быть дан ответ о решении проблемы.
Ведется рейтинг самых активных пользователей.
Открытая Казань — ИС для решения проблем городского хозяйства в
Казани. Так же как и предыдущий сервис, основан связке веб-сайт в сети
Интернет и мобильных приложений для популярных платформ.
Возможности:
− позволяет подать заявку о проблеме;
− отслеживать состояние выполнения заявки;
− передавать показания приборов учета;
− оплачивать услуги ЖКХ в режиме онлайн;
− просматривать заявки на интерактивной карте;
− просматривать рейтинг управляющих компаний.
Помимо подачи заявки с помощью ИС, существует единый контакт-цент —
можно подавать информацию с помощью телефона.
13
Для подачи заявки средствами ИС потребуется:
1. Зарегистрироваться
в
системе,
в
процессе
регистрации
указать
персональные данные.
2. Войти в систему с помощью регистрационных данных.
3. Оставить заявку, в заявке описать проблему, указать лицевой счет, ФИО,
контактный телефон, адрес, категорию проблемы, фотографии.
После регистрации проблемы, начинаются процедуры по устранению
проблемы. Контроль осуществляют специалисты Исполкома Казани совместно с
журналистами местных средств массовой информации (СМИ).
По мере выполнения работ, у заявки меняется статус, тем самым позволяя
отслеживать ее текущее состояние. В случае плохого исполнения работ по
устранению проблемы, заявка повторно попадает в обработку.
Добродел — информационный портал, созданный по постановлению
Правительства Московской области в 2015 году для решения проблем в сфере
городского хозяйства Московской области. Представлен веб-сайтом в сети
Интернет и мобильными приложениями для Android и iOS. Возможности данной
ИС:
− сообщить о проблеме;
− просмотреть о ближайших сообщениях других пользователей на
интерактивной карте;
− внести предложение;
− принять участие в опросе;
− оставить благодарность управляющим компаниям за своевременную и
качественно выполненную работу;
− просмотреть рейтинг предприятий ЖКХ.
Обращения жителей разделены на две группы:
1. Проблема — ситуация которая требует проведения конкретных
мероприятий со стороны ответственной организации, которые ограничены 8
днями.
14
2. Предложения — требуют детальной проработки, анализа, на их решение
требует больше времени. После проработки предложения, если оно одобрено,
принимается решение о проведении работ.
Для подачи заявки требуется:
1. Зарегистрироваться в системе.
2. Выбрать категорию проблемы.
3. Описать суть проблемы и приложить фотографии.
После подачи заявки, она будет проверяться модераторами в течении двух
дней на предмет корректности заполнения и соответствия действительному
положению вещей по проблеме. После этого она будет направлена ответственной
организации. Срок обработки предложения составляет две недели.
Для оценки эффективности работы рассмотренных ИС были выбраны
следующие критерии:
1) прием заявок в режиме онлайн;
2) автоматическое назначение ответственного;
3) отображение заявок на карте;
4) выявление важных проблем для населения;
5) категоризация заявок;
6) мобильное приложение;
7) масштабирование решения.
Результаты проведенного анализа рассмотренных информационных систем
по описанным критериям представлен ниже в таблице 1.
Таблица 1 — Обзор существующих систем сбора заявок от населения
Критерий эффективности
Наш город
Открытая Казань
Добродел
1
2
3
4
+
+
+
-
-
-
1. Прием заявок в
режиме онлайн
2. Автоматическое
назначение ответственного
15
Продолжение таблицы 1
1
2
3
4
+
+
+
+
-
+
+
+
+
+
+
+
Москва
Казань
3. Отображение заявок
на карте
4. Выявление важных
проблем для населения
5. Категоризация заявок
6. Мобильное
приложение
7. Масштабирование
решения
Московская
область
1.2 Анализ подходов к построению систем обеспечивающих
взаимодействие жителей города при решении проблем городского
хозяйства
При решении проблем городского хозяйства активно внедряются и
используются информационные технологии. Их использование способствует
повышению качества и скорости управления, улучшению контроля проводимых
мероприятий, и, как следствие, повышению уровня жизни населения.
Все чаще употребляется термин «умный город», который включает в себя
процедуры и технологии, обеспечивающие функционирование умного город [8]:
1. Мобильное приложение быстрого реагирования — программа для
мобильных
устройств,
целью
создания
которой
является
оперативное
уведомление городских служб об обнаруженной проблеме.
2. Умный дом — интеллектуальная система управления домом. Такая
система
оснащена
определенными
протоколами
поведения
по
вопросам
жизнеобеспечения и безопасности, которые выполняются в зависимости от
текущего состояния дома.
3. Приложения на основе открытых данных – инициативы в сфере
разработки приложений, на основе открытых данных, способствуют созданию
16
множества полезных мобильных сервисов для жителей города и позволяют
сэкономить средства из городского бюджета.
4. Интеллектуальная система общественного транспорта — комплекс
взаимосвязанных автоматизированных систем, решающих задачи управления
дорожным движением.
5. Система оповещения о ЧС — подобные системы позволят в
значительной
степени
минимизировать
последствия
стихийных
бедствий,
терактов и других ЧС.
6. Мобильные
платежи
—
операции
с
денежными
средствами,
осуществлённая с помощью устройства мобильной телекоммуникационной сети
при оказании электронных услуг населению.
Рассмотренные информационные системы используют связку технологий
мобильных приложений быстрого реагирования и веб-сервис. Жители сообщают о
проблемах с помощью мобильного приложения или веб-сата. Это позволяет
охватить значительную целевую аудиторию и своевременно реагировать на
проблемы. По данным Российского филиала исследовательского центра GfK
(Gesellschaft fur Konsumforschung) Group, который 16.01.2018 опубликовал отчет
«Проникновение Интернета в России: итоги 2017 года» аудитория интернетпользователей в возрасте от шестнадцати лет и старше составила восемьдесят
семь миллионов человек, что на три миллиона больше чем год назад [9]. Ниже на
рисунке 1 представлена динамика роста интернет-пользователей на основе
данных отчета.
Все заявки по проблемам проверяются на корректность модераторами в
ситуационном центре, после чего публикуются на веб-сайте и передаются
исполнителю.
Рассмотренные системы используют архитектуру «клиент-сервер», в
которой задания или сетевая нагрузка распределены между поставщиками услуг,
называемыми серверами, и заказчиками услуг, называемыми клиентами. Средой
взаимодействия выступает Интернет. Клиент общается с сервером с помощью
запросов согласно стеку протоколов TCP/IP, сервер обрабатывает их —
17
обращается к серверу базы данных, формирует ответ, который возвращается
клиенту.
0,8
0,68
0,7
0,6
0,53
0,5
0,4
0,7
0,7
2015
2016
0,73
0,57
0,44
0,33
0,37
0,3
0,2
0,1
0
2008
2009
2010
2011
2012
2013
2014
2017
Доля интернет-пользователей старше 16 лет
Рисунок 1 – Доля интернет-пользователей старше 16 лет
Функции веб-сервера:
− получение запросов клиентов, формирование ответов и их отправка;
− перенаправление запросов конкретным приложениям;
− предоставление
приложениям
доступа
к
необходимым
модулям
(например, к модулю связи с СУБД);
− авторизация и аутентификация пользователей.
Логическая схема построения сети рассмотренных информационных
систем представлена ниже на рисунке 2.
Рассмотрим
языки
программирования,
с
помощью
которых
разрабатываются современные веб-сервисы: Ruby, PHP, Pyhton, Go, JavaScript.
18
Рисунок 2 – Логическая схема построения сети рассмотренных
информационных систем
Ruby
–
динамический,
рефлективный,
интерпретируемый
высокоуровневый язык программирования. Отличается наличием встроенной
независимой от платформы многопоточности, строгой динамической типизацией,
встроенным сборщиком мусора [10]. Для веб-разработки используется, как
правило, фреймворк Ruby on Rails, который позволяет минимизировать
дублирование кода в приложениях и реализует паттерн MVC.
Преимущества Ruby:
− полностью объектно-ориентированный язык программирования, почти
все данные в Ruby являются объектами;
− автоматический сборщик мусора;
− поддерживает замыкания;
− имеет
многопоточности;
независимую
от
ОС
поддержку
невытесняющей
19
− позволяет переопределить операторы, которые на самом деле являются
методами;
− большое сообщество;
− кроссплатформенность.
Недостатки Ruby:
− имеет большой порог вхождения;
− высокая стоимость сопровождения проектов;
− скромная документация на русском языке;
− сложность «развертки» проектов на сервере;
− плохая поддержка ОС Windows;
− отсутствие реальной многопоточности, реализация Global Interpreter
Lock (GIL) — способа синхронизации потоков, ограничивает параллельность
вычислений.
PHP – скриптовый язык общего назначения. Популярен при разработке
веб-приложений. Имеет широкую поддержку у хостинг-провайдеров. Позволяет
быстро приступить к разработке. Имеет очень большое распространение [11].
Среди распространенных фреймворков на PHP известны такие как: CakePHP,
Symfony, Laravel, Zend Framework и другие.
Преимущества PHP:
− прост в изучении;
− имеет действительно большие количество различных фреймворков и
библиотек;
− в большинстве случаев может быть «развернут» на любом хостинге за
кратчайшие сроки.
Недостатки PHP:
− низкая оптимизация рекурсии;
− большинство модулей PHP не обеспечивает безопасность потоков;
− нет единого стандартного подхода для работы с кодировками.
Python – высокоуровневый язык программирования общего назначения,
ориентированный на повышение производительности разработчика и читаемости
20
кода. Python поддерживает несколько парадигм программирования, в том числе
структурное,
объектно-ориентированное,
функциональное,
императивное
и
аспектно-ориентированное [12]. Одним из популярных фреймворков при
разработке веб-приложений на Python является Django.
Преимущества Python:
− прост в изучении;
− легко писать повторно используемый код;
− имеет отличную документацию;
− в свободном доступе большое количество библиотек и фреймворков;
− наличие автоматического сборщика мусора;
− поддержка различных парадигм программирования.
Недостатки Python:
− медленная
скорость
работы,
объясняется
тем
что
язык
интерпретируемый;
− динамическая типизация усложняет процесс разработки сложных
проектов.
Go
–
компилируемый
многопоточный
язык
программирования,
разработанный внутри компании Google. Язык Go разрабатывался как язык
программирования для создания высокоэффективных программ, работающих на
современных распределённых системах и многоядерных процессорах [13].
Основные достоинства:
− кроссплатформенность;
− открытый исходный код;
− строгая статическая типизация, с поддержкой автоматического вывода
типов для пользовательских типов;
− полноценная поддержка указателей, но без возможности применения к
ним арифметических операций.
Недостатки языка Go:
− малое количество переведенной документации;
− отсутствие поддержки объектно-ориентированной модели;
21
− сравнительно молодое сообщество, которое еще развивается.
JavaScript
–
это
современный
язык
программирования,
является
реализацией языка ECMAScript. Имеет полную интеграцию с HTML и CSS.
Позволяет решать задачи как на стороне front-end, так и back-end [14].
Преимущества JavaScript:
− кроссплатформенность
—
все
современные
браузеры
его
поддерживают;
− постоянно развивающийся язык;
− наличие автоматического сборщика мусора;
− возможность пользоваться самыми новыми возможностями языка, с
последующей трансляцией кода в старый синтаксис, который поддерживается
всеми актуальными браузерами.
Недостатки JavaScript:
− скрипты компилируются в момент выполнения кода;
− отсутствует типизация данных — проблема всех скриптовых языков;
− непривычная для многих программистов объектная модель.
На основании приведенного выше, в качестве средства разработки был
выбран язык программирования Python. Для разработки системы будет
использоваться фреймворк Django. Он основан на паттерне проектирования MVC
(Model-View-Controller,
предполагает
четкое
Модель-Представление-Контроллер),
разделение
данных
приложения,
который
пользовательского
интерфейса и управляющей логики на три отдельных компонента, который могут
быть модифицированы независимо. Дополнительным обоснованием выбора
служит наличие у автора опыта работы с Django. Также при разработке будет
использован JavaScript.
Для разработки информационной системы также потребуется определиться
с системой управления базой данных (СУБД). СУБД управляет доступом в базе
данных,
осуществляет
хранение,
информации, хранимой в базе данных.
извлечение,
поиск
и
редактирование
22
Требования при выборе СУБД:
− реализация реляционной модели хранения данных;
− иметь интеграцию с Django;
− иметь возможность свободного, бесплатного использования;
− поддерживать архитектуру «клиент-сервер».
Рассмотрим
наиболее
популярные
СУБД на рынке программного
обеспечения.
SQLite – компактная встраиваемая СУБД. SQLite не использует парадигму
«клиент-сервер», то есть SQLite не имеет отдельно работающего процесса с
которым взаимодействует программа, а представляет собой библиотеку, с которой
программа компонуется. Вся база данных хранится в одном файле, на том
компьютере, на котором исполняется программа. Также у SQLite отсутствует
система пользователей, в связи с чем ее невозможно использовать в ряде вебпроектов [15].
PostgreSQL
–
это
СУБД,
которая
позиционирует
себя
как
профессиональное решение. Среди прочих максимально полно поддерживает
синтаксис SQL, а также обладает высокой степенью надежности [16].
Преимущества:
− открытость;
− высокопроизводительные
и
надёжные
механизмы
транзакций
и
репликации;
− расширяемая система встроенных языков программирования;
− наследование;
− легкая расширяемость.
Недостатки:
− сравнительно невысокая скорость работы (ниже чем у MySQL);
− малая популярность;
− не каждый хостинг-провайдер поддерживает эту СУБД.
Firebird — кроссплатформенная реляционная система управления базами
данных [17].
23
Преимущества:
− версионная архитектура (каждая транзакция видит свою версию
записи);
− наличие событий, генераторов, триггеров;
− одно
клиентское
приложение
может
выполнять
множество
одновременных транзакций;
− резервное копирование без необходимости остановки сервера.
Недостатки:
− отсутствие кэша результатов запроса;
− ограниченное количество одновременных подключений.
MySQL – свободная реляционная система управления базами данных,
представляет собой решения для малых и средних приложений. Обычно
используется с качестве сервера, к которому обращаются локальные или
удаленные клиенты, но есть вариант и внутреннего локального сервера для
автономных программ. Гибкость MySQL достигается за счет поддержки большого
количества типов таблиц, а благодаря открытой архитектуре и GPL-лицензии
количество типов таблиц постоянно увеличивается [18].
Среди рассмотренных систем управления базами данных выбор в качестве
инструментальных средств пал на MySQL. Автор работы имел опыт работы с
данной СУБД.
1.3 Формализация требований к системе взаимодействия жителей
города при решении проблем городского хозяйства
На текущий момент данные о проблемах города собираются по разным
каналам:
это
прямые
обращения
в
управляющие
компании,
письма
в
коммунальные службы, заявки через специальные сервисы или по телефону.
Жители описывают проблему и ее адрес, после обращения заявка заносится в
журнал регистрации заявок. После этого управляющая компания отправляет
заявку исполнителю. Если требуется коллективное решение по проблеме, то
единственный вариант — собрание жильцов. Это неудобно, многие не могут
24
позволить себе присутствовать на собрании по тем или иным причинам. В связи с
этим их мнение не будет учтено.
Такой подход при сборе информации от населения не позволяет
оперативно на них реагировать. Сроки по устранению проблемы возрастают, как и
финансовые расходы. Также это причиняет серьезные неудобства жителям города.
Именно поэтому требуется автоматизация процесса сбора информации о
проблемах городского хозяйства. Такая система позволит отслеживать проблемы
города, оперативно получать о них информацию, своевременно реагировать и
принимать действия по их устранению.
Заявки будут поступать в ситуационный центр управляющей компании.
При корректном выборе категории проблемы она автоматически попадет нужному
исполнителю. Если же была допущена ошибка — ее скорректирует диспетчер.
При повторном обращении диспетчер уведомит заявителя об этом.
За заявкой могут быть закреплены комментарии пользователей, это может
быть полезно для обсуждения проблемы жителями, могут быть выявлены важные
нюансы которые могут оказать существенное влияние на скорость выполнения
заявки.
По
окончании
проведения
работ
исполняющей
организацией,
управляющая организация осуществляет проверку и прием работ. В случае
недочетов, заявка не закрывается до их устранения. Если результаты проведенных
работ удовлетворительны, заявка закрывается, пользователей уведомляют об этом.
Для регулярных проблем, таких как, например, своевременны вывоз и
утилизация технических и бытовых отходов, можно использовать особый вид
заявки со статусом — пин. Он может иметь три состояния:
1) включен — когда требуется выполнить какие-то мероприятия по
проблеме;
2) выключен — когда заявка не активна, действий не требуется;
3) ошибка — когда требуемые действия не могут быть выполнены по
какой-либо причине.
25
В случае ошибки проблема может быть любой, как внутренней, например,
поломка мусороуборочной машины, так и со стороны третьих лиц, например,
дорога была загорожена неправильно припаркованным автомобилем. Также для
подтверждения подобных проблем, должна быть возможность приложить файлы
(фотографии или документы). Это позволит быстрее найти решение проблемы,
например, вызвать эвакуатор, для освобождения пути мусоровозу.
В системе должна присутствовать система уведомлений. Каждый
пользователь может подписаться на все уведомления конкретной заявки.
Иерархия прав пользователей ИС начинается с обычного пользователя, он
обладает наименьшими правами, далее идет диспетчер и
ответственная
организация. Рассмотрим ниже диаграмму вариантов использования. Начнем с
жителя.
Поскольку метка базовая сущность для работы с картой, заявка
наследуется от метки. Пользователь может:
− создавать заявку;
− комментировать заявку;
− подписываться на обновления заявки;
− давать заявке оценку;
− одобрить выполненную заявку, если пользователь ее создал и по ней
выполнены работы, в случае одобрения заявка закрывается;
− вернуть заявку на доработку, например, если работы выполнены
ненадлежащим образом;
− удалить заявку, например, в случае когда проблема более не актуальна;
− просматривать историю статусов заявки.
Рисунок 3 – Диаграмма вариантов использования для жителя
26
27
Далее на рисунке 4 представлена диаграмма вариантов использования
диспетчера управляющей компании.
Диспетчер управляющей компании является более привилегированным
пользователем чем житель. Диспетчер обладает теми же правами что и житель, но
у него есть и дополнительные. Он может:
− просматривать опубликованные заявки, которые еще не прошли
валидацию диспетчером;
− назначить ответственного;
− отклонить заявку если она заполнена некорректно;
− отклонить заявку из-за некомпетентности в решении проблемы;
− просмотреть историю статусов заявки;
− просматривать организации;
− назначать зоны ответственности.
Диаграмма вариантов использования для ответственной организации
представлена ниже на рисунке 5.
Самыми широкими полномочиями наделена ответственная организация, ей
доступны права диспетчера. Она может:
− рассматривать поступившие заявки;
− помечать заявку как выполненную;
− возвращать
заявку
диспетчеру,
неудовлетворительно;
− назначать сотрудников для исполнения;
− отклонять заявки;
− просмотр истории статусов заявки;
− управлять списком сотрудников.
если
работы
проведены
Рисунок 4 – Диаграмма вариантов использования для диспетчера
28
Рисунок 5 – Диаграмма вариантов использования для ответственной организации
29
30
1.4 Постановка задачи исследования
Разработка методики взаимодействия жителей города при решении
проблем городского хозяйства обусловлена следующим.
На текущий момент сбор и распределение заявок от населения не
автоматизирован, занимает большое количество времени. Жители не могут
отслеживать процесс выполнения заявки, представители управляющих компаний
не имеют возможность продемонстрировать оперативность решения проблемы.
Существующие механизмы сбора информации о проблемах города не отвечают
современным требованиям к оперативности и открытости информации, в связи с
чем убытки несут все, и обычные граждане, и представители управляющих
компаний.
Для
решения
этих
проблем
предлагается
разработать
методику
взаимодействия жителей города при решении проблем городского хозяйства.
Внедрить эту методику с помощью информационной системы. Новая методика
позволит избежать существующих узких мест при обеспечении взаимодействия
жителей города, как между собой, так и с управляющими структурами.
Необходимо:
1) рассмотреть существующие методики взаимодействия жителей города
при решении проблем городского хозяйства;
2) выявить их преимущества и недостатки;
3) сформировать свою методику, с учетом недостатков и недоработок
существующих;
4) спроектировать прототип информационной системы (ИС), реализующий
разработанную методику;
5) разработать прототип ИС.
Функциональные требования к разрабатываемой ИС:
− возможность подать заявку в управляющую компанию, указав адрес,
при необходимости прикрепить изображение;
− иметь возможность просматривать возникающие проблемы в городе;
− возможность просмотра статусов поданных заявок;
31
− возможность создания заявок для регулярных проблем с состоянием;
− возможность объединения заявок с состоянием в маршрут;
− распределение заявок ответственным организациям;
− просмотр действий с заявкой;
− ведение обратной связи с населением.
Нефункциональные требования:
− целостность;
− безопасность;
− простота использования;
− отказоустойчивость.
ИС должна быть разработана как веб-приложение, обладать возможностью
одновременной работы с несколькими пользователями. Система должна быть
масштабируема для дальнейшей модернизации и развития.
32
2 СУЩЕСТВУЮЩИЕ МЕТОДЫ ВЗАИМОДЕЙСТВИЯ ЖИТЕЛЕЙ
ГОРОДА ПРИ РЕШЕНИИ ПРОБЛЕМ ГОРОДСКОГО ХОЗЯЙСТВА
2.1 Исследование и анализ подходов к выстраиванию взаимодействия
жителей города при решении проблем городского хозяйства
Прежде
чем
приступить
к
описанию
собственной
методики
взаимодействия жителей города при решении проблем городского хозяйства
требуется
провести
анализ
существующих
подходов
по
выстраиванию
взаимодействия между жителями и управляющими организациями.
Взаимодействие сейчас в большинстве случаев проходит традиционным
способом — это личное посещение управляющей организации, письменное
обращение или звонок по телефону. Среди жильцов это собрания. Обработка всей
информации ведется вручную.
Ниже рассмотрен общий порядок обращения [19]:
1. Подача заявки жильцом лично или через телефон. Создается письменное
обращение.
2. Регистрация заявки в журнале. Сотрудник обязан подтвердить жителю
факт регистрации обращения в этом документе.
3. Составляется план работ по заявке, план создается на неделю.
4. Утверждение директором предприятия плана работ.
5. Рассылка плана работ по участкам.
6. План работ сопоставляется с временными рамками. Если заявок много и
они не укладываются в план работ на неделю, они переходят на следующую.
7. Начальник участка предприятий ЖКХ, получив план работ по заявкам на
неделю, ежедневно планирует работы с разбиением их по времени с возможными
корректировками и обязательным уведомлением заявителей о сроках выполнения.
8. На участках формируют наряд-задание в котором указаны: вид работ, их
объем и время исполнения.
9. Работник, получив наряд-задание, приступает к его исполнению.
33
Из описанного выше можно сделать вывод, что прием и исполнение заявок
от населения занимает много времени по причине не тривиальности процесса.
Отсутствует оперативность в получении информации.
Информационные системы приема заявок работают по одинаковому
принципу. С помощью мобильного приложения или веб-сайта подают заявление.
Они поступают в ситуационный центр, где обрабатываются операторами. Далее в
течении восьми дней на нее может быть дан ответ о выполнении.
Чтобы привязать к заявке адрес, потребуется использовать географические
информационные системы (ГИС) - аппаратно-программный человеко-машинный
комплекс, обеспечивающий сбор, обработку, отображение и распространение
пространственно-координированных данных, интеграцию данных и знаний о
территории для их эффективного использования при решении научных и
прикладных задач, связанных с инвентаризацией, анализом, моделированием,
прогнозированием
управлением
окружающей
средой
и
территориальной
организацией общества [20].
Рассмотрим наиболее популярные картографические веб-сервисы, на базе
ГИС.
Карты Google – бесплатный картографический сервис. Отличительная
черта сервиса — очень высокая детализацию всей планеты, включая все крупные
и средние города России.
Функции сервиса:
− просмотр карты в режиме схемы, спутника и гибрида;
− просмотр маршрутов общественного транспорта;
− наличие информации о пробках;
− определение местоположения с помощью базовых станций сотового
оператора, точек доступа WiFi или встроенного/внешнего GPS-приемника;
− установка меток на карте;
− наличие голосового поиска.
Плюсы сервиса Google:
− простой и понятный интерфейс;
34
− удобный поиск объектов на карте с их описанием.
Минусы:
− малая детализация небольших городов и сел;
− нет информации о пробках в России;
− отсутствие
возможности
вносить
геоинформацию
простыми
пользователями.
Яндекс Карты — бесплатный кртографический сервис. В сравнении с
сервисом Google имеет куда более высокую детализацию территории России.
Преимущества:
− простой и удобный интерфейс;
− удобный поиск объектов на карте с их описанием;
− наличие информации о пробках включая территорию России;
− высокий уровень детализации территории России.
Из недостатков, как и в Google Maps нельзя вносить геоинформацию
пользователями.
2ГИС — справочный картографический сервис, умеет прокладывать
маршрут с учетом необходимых пересадок для общественного транспорта.
Функции сервиса:
− поиск и фильтрация организаций;
− наличие
дополнительной
информации
об
объектах,
такой
как:
фотографии, время работы, контактные телефонные номера, отзывы, рейтинг
доверия и другие.
− подсказки для маршрутов;
− отображение пробок;
− измерение расстояние между объектами.
Достоинства:
− оффлайн режим работы сервиса без доступа к сети Интернет;
− удобство управления и навигации;
− высокая детализация карт;
− прокладка маршрутов.
35
Яндекс Карты и Google карты работают схожим образом и обладают одним
недостатком, данные об организациях чаще чем в 2ГИС могут быть не
корректными,
поскольку
сбор
информации
автоматизирован.
В
2ГИС
используется ручной сбор данных, сотрудники компании регулярно обзванивают
организации на предмет изменения данных. Карты обновляются ежемесячно.
2.2 Выявление преимуществ и недостатков подходов к выстраиванию
взаимодействия жителей города при решении проблем городского
хозяйства
Рассмотрев основные подходы к выстраиванию взаимодействия жителей
города при решении проблем городского хозяйства, выявлены следующие
преимущества и недостатки.
Наличие диспетчерской службы позволяет содержать информацию о
проблеме всегда в актуальном виде, однако всегда остается возможность
допущения ошибок из-за человеческого фактора, процесс остается трудоемким и
дорогим, страдает скорость получения информации.
Среди положительных сторон автоматического сбора информации:
− скорость сбора больших объемов геоданных;
− процесс сбора информации автоматизирован;
− низкие затраты на обслуживание.
Из
явных
минусов
выделяется
менее
достоверная
и
актуальная
информация. Сравнение преимуществ и недостатков существующих методов
сбора геоинформации представлены ниже в таблице 2.
Из описанного выше следует, что требуется новый подход для сбора
геоинформации
—
комплексный
подход,
который
будет
компенсировать
недостатки каждого по отдельности. Можно сэкономить на штате сотрудников,
которые
актуализируют
информацию
ежемесячно,
пользователям возможности самим вносить информацию.
путем
предоставления
36
Таблица 2 – Преимущества и недостатки существующих методов сбора
геоинформации
Метод сбора
геоинформации
Агрегирование
данных
Преимущества
Недостатки
1) Скорость сбора
1) Более низкий
геоданных;
уровень достоверности и
2) Автоматизированный актуальности
сбор информации;
3) Малые затраты на
обслуживание.
Целенаправленный
информации в сравнении
с целенаправленным
сбором информации.
1) Высокий уровень
сбор информации
актуальности и
контакт-центром
достоверности информации.
1) Дороговизна
способа;
2) Трудоемкость
процесса.
Классическая схема взаимодействия жителей города представляет собой
собрание
жильцов,
обсуждение
существующих
проблем,
выявление
их
актуальности и выставление им приоритетов, принятие мер по их устранению и
отслеживание процесса решения. В такой схеме есть много узких мест, которые
препятствуют прозрачности процесса, сильно увеличивают время между
формулированием проблемы и ее решением, ведут к неправильной расстановке
приоритетов и ряду других проблем. Во-первых, по разным причинам, не все
жильцы могут принять участие в собрании, что в свою очередь ведет к неверной
расстановке приоритетов группой жильцов, поскольку не все мнения будут
учтены. Во-вторых, даже посетив собрание, граждане могут не прийти к
консенсусу за отведенное на собрание время. В-третьих, если проблема
сформулирована, признана актуальной, выбрана приоритетной и доведена до
управляющей организации - ставится вопрос о мониторинге выполнения работ по
поставленной задаче. И здесь возникает проблема с отслеживанием выполнения
промежуточных этапов решения проблемы. Жители могут убедиться в том, что по
их вопросом выполняются работы, лишь лично увидев это.
37
Преимуществ в классической схеме выстраивания взаимодействия не
выявлено.
Отсюда вытекают следующие недостатки:
− сложно добиться присутствия всех жильцов на собрании;
− следует из предыдущего — не всегда общее решение отражает мнение
большинства жителей;
− решение может быть не принято за отведенное время.
По традиционному подходу приема заявок преимущества также не были
выявлены. Недостатки присутствуют, выделены следующие:
− длительность обработки заявок;
− недостаток оперативности получения информации;
− отсутствие контроля за ходом выполнения заявок.
У современных информационных систем обработки заявок от населения
также присутствуют свои плюсы и минусы.
Преимущества:
− автоматизированный сбор информации;
− простота подачи заявки.
Из минусов можно выделить снижение оперативности обработки заявки,
т. к. сначала заявку должен проверить оператор (диспетчер).
2.3 Методика взаимодействия жителей города при решении проблем
городского хозяйства
Существующие методы взаимодействия жителей города при решении
проблем городского хозяйства не соответствуют современным требованиям
удобства, оперативности и открытости информации о принятых заявках. Для
решения этих проблем предлагается разработать новую методику взаимодействия
жителей города при решении проблем городского хозяйства. Внедрить эту
методику с помощью информационной системы. Новая методика позволит
избежать существующих узких мест при обеспечении взаимодействия жителей
города, как между собой, так и с управляющими структурами.
38
Для
решения
автоматизированные
территориальным
задачи
предлагается
информационные
принципам.
использовать
центры,
Предполагается
распределенные
функционирующие
перенаправлять
по
правильно
оформленные заявки автоматически представителям ответственной организации.
Это будет возможно с помощью системы ключевых слов, которые будут
закреплены за заявкой.
В процессе создания заявки, пользователь выбирает необходимую
категорию из заранее сформированного списка. При помощи мобильного
приложения пользователь может указать набор ключевых слов, определив этим
получателя заявки. Мы имеем прямое взаимодействие жителей города с
исполнителем. Наличие зон ответственности по территориальному признаку
позволит
автоматически
конкретизировать
исполняющую
организацию,
ответственную именно за данный участок. Такое решение позволит существенно
снизить стоимость обслуживания электронной услуги. Если по каким-либо
причинам
заявка
не
может
быть
выполнена
выбранной
управляющей
организацией, здесь уже вступит в процесс диспетчер, для принятия решения о
переработке заявки или о переназначении ответственного.
Ситуационный центр — интерактивная карта с отмеченными на ней
заявками от населения, представленная в виде веб-сервиса. Процесс выполнения
заявок представлен в ситуационном центре в виде статусов заявок, позволяя
отслеживать ход выполнения по интересующим проблемам, оценивать качество и
оперативность проведенных работ.
Процесс обработки заявки в ситуационном центре представлен ниже на
рисунке 6.
Когда житель не указывает категорию проблемы, заявку рассматривает
диспетчер.
Он
проверяет
корректность
сформированной
заявки,
при
необходимости вносит исправления. Если заявка с ошибками, некорректна, когда
она требует доработки, диспетчер ее отклоняет. Если с заявкой все хорошо,
диспетчер назначает ответственного.
39
Рисунок 6 – Диаграмма процесса обработки заявок
Ответственный по заявке тоже обязан проверить заявку. Если заявка
корректна, ответственный берет ее к исполнению. Если задача по ошибке
назначена неверному ответственному, она возвращается к диспетчеру, где
диспетчер назначает нового ответственного, либо, если назначить некого,
отклоняет ее. В процессе исполнения заявки может выясниться, что по каким-то
причинам ответственный не может выполнить заявку. В таком случае она
попадает диспетчеру, где он назначает другого ответственного.
В случае ненадлежащего качества работ заявка возвращается на доработку.
Если работы выполнены хорошо, она помечается как одобренная и закрывается.
Методика реализуется на базе информационной системы, включающей в
себя веб-сервис и мобильные приложения. Данная методика представлена
последовательностью определенных действий в виде диаграммы деятельности,
которая включает:
1. Создание заявки. Средствами мобильного приложения, либо средствами
веб-сайта, житель формирует заявку, выбирает категорию проблемы, указывает
место, описание, при необходимость прикладывает фотографии к заявке.
2. Заявка попадает диспетчеру, если пользователь не указал категорию
проблемы, либо представителю исполнительной организации.
40
3. После назначения заявке ответственного и попадания в обработку, заявка
становится общедоступной и видна в ситуационном центре. При необходимости,
житель может выполнять поиск заявки.
4. После выбора заявки из отслеживаемых заявок или из списка выдачи
поисковой подсистемы пользователю будет доступна вся информация по заявке.
Это описание проблемы, журнал статусов заявки, фотогалерея.
5. При просмотре заявки, пользователь может оценить заявку. После
оценки
заявки
уведомление.
пользователем,
Также
автору
пользователю
заявки
доступно
придет
соответствующие
комментирование
заявки.
Комментарий может быть оставлен как непосредственно к заявке, так и быть
ответом на комментарий другого пользователя. В случае ответного комментария,
пользователю поступит об этом уведомление.
6. При желании пользователь может подписаться на уведомление о заявке.
Подписка включает подписку на уведомления об изменении описания заявки,
изменении статуса заявки и о появлении новых комментариев.
7. Пользователь может добавить заявку в отслеживаемые заявки и
получить доступ к ним в любое время через специальный интерфейс.
8. Пользователь может делиться информацией о метке с другими
пользователями и группами системы, публиковать в социальных сетях.
Диаграмма деятельности представлена ниже на рисунке 7.
Заявка в рамках реализации ИС представлена меткой. Помимо заявки
существует еще один тип метки — метка с отчетностью или пин. Это особый тип
метки, который позволяет выполнять действия на регулярной основе. Например,
вывоз технического и бытового мусора. Метка условно может отображать
положение мусорного контейнера на карте и по умолчанию имеет состояние
«выключена», т. е. действий не требуется. Как только возникает ситуация, когда
контейнер заполнен и требуется утилизация отходов, пользователь меняет
состояние на «включена» путем запрашивания актуального отчета по метке. Когда
пин включен, ответственный проводит необходимые мероприятия по устранению
проблемы, переводит состояние метки обратно в «выключена».
Рисунок 7 – Методика взаимодействия жителей города при решении проблем городского хозяйства
41
42
Если по какой-либо причине решить проблему не удалось, ответственный
меняет состояние метки на «ошибка», например доступ к бакам загорожен
неверно
припаркованным
автомобилем. В
обоих
случаях
ответственный
формирует отчет, с описанием, приложением фотографий и сменой состояния
метки. Все пины могут быть доступны для актуализации пользователям. Таким
образом любой житель может своевременно сменить состояние пина с «ошибка»
на «включено», например, ранее неверно припаркованный автомобиль в
настоящее время отсутствует, сторонних проблем для вывоза мусора нет.
Ответственный видит что проблема решена и возвращается к выполнению работ
по пину. Данная методика обработки регулярных заявок на основе пина
представлена ниже на рисунке 8.
Предложенная на основе методики информационная система позволит:
1) создавать заявки;
2) автоматизировать деятельность диспетчерских служб, что позволит
снизить нагрузку на этот узел и сократить расходы на обслуживание, т. к. штат
сотрудников будет меньше;
3) выполнять оперативный сбор информации о проблемах городского
хозяйства;
4) назначать исполнителей;
5) контролировать ход выполнения заявок, тем самым делая работу
управляющих компаний более прозрачной и открытой;
6) комментировать заявки и отвечать на комментарии;
7) отслеживать интересующие проблемы;
8) получать соответствующие уведомления.
Из это следует, что внедрение современных информационных технологий
для решения
проблем
городского хозяйства положительно скажется на
оперативности и открытости информации о проблеме, позволяя решать их более
эффективно, обеспечивая должный уровень взаимодействия жителей города и
управляющих организаций.
Рисунок 8 – Методика обработки регулярных заявок на основе пина
43
44
3 ПРОЕКТИРОВАНИЕ ПРОТОТИПА ИНФОРМАЦИОННОЙ
СИСТЕМЫ, РЕАЛИЗУЮЩЕГО РАЗРАБОТАННУЮ МЕТОДИКУ
3.1 Архитектура прототипа информационной системы, реализующего
разработанную методику
В настоящее время одним из приоритетных направлений развития страны
является создание информационного общества, основополагающий принцип
которого – распространение и доступность электронных услуг для населения.
Большую популярность в решении этого класса задач приобретают веб-сервисы.
Их
основное
преимущество
заключается
в
обеспечении
взаимодействия
программных систем независимо от платформы [21].
Сейчас
существуют
различные
механизмы
взаимодействия
в
информационном пространстве. Одним из наиболее старых из них, но при этом
остающимся актуальным, является веб-форум. Суть работы форума заключается в
создании тематических разделов, где автор раздела поднимает некоторый вопрос и
все желающие могут посетить этот раздел для обсуждения проблемы. Любой
участник веб-форума может оставлять комментарии к разделу, задавать вопросы,
оставлять и получать на них ответы. Рассматривая взаимодействие жителей при
решении проблем городского хозяйства, становится очевидно, что функций,
предоставляемых веб-форумом будет недостаточно. Заявка должна иметь
возможность двигаться между жителями и исполнительной организацией, внутри
организации, возможно, между подразделениями. Также заявка должна уметь
менять свое состояние, т.е. должна существовать некоторая система статусов
заявки, обеспечивающая обратную связь с жителями. Эти функции должны будут
регулироваться либо оператором, либо происходить автоматически. В рамках
форума все его участники видят все разделы, что в масштабах страны будет очень
перегружать информацией страницы с перечнем разделов. Необходимо внедрение
механизмов группировки разделов по территориальному принципу. Чтобы
проблемы одного города не отображались среди актуальных проблем у жителей
другого города. Описанные проблемы свидетельствуют о том, что механизмы
45
форума не способны предоставить желаемый набор функций для качественного
взаимодействия участников процесса.
Помимо веб-форумов широкое распространение получили такие системы
взаимодействия как чат-системы. Взаимодействие в таких системах в изначальном
виде представляет собой мгновенный обмен текстовыми или голосовыми
сообщениями. Взаимодействие может вестись между двумя участниками беседы,
либо между участниками группы. У чат-систем есть существенное ограничение
по количеству участников беседы. Оно связано не столько с техническими
ограничениями,
сколько
с
физической
невозможностью
пользователей
воспринимать информацию, которая будет попадать в общее окно чата от
большого
количества
источников.
Также
нет
возможности
осуществить
персональный ответ участнику чата в рамках группового диалога, который есть в
веб-форуме. В связи с этим чат-системы не подходят для решения задач
обеспечения взаимодействия между жителями города для решения проблем
городского хозяйства.
Если разработать информационную систему в виде веб-сервиса, то
практически любой житель города сможет им воспользоваться. Необходимо будет
зарегистрироваться и вступить в соответствующую группу. Участниками такой
группы будут жители, проживающие на определенной территории, например,
проживающие в некотором районе города. Каждый пользователь сможет быть в
нескольких группах. Каждая такая группа может отвечать за прием заявок из
территорий различного уровня декомпозиции. Так одна группа будет отвечать за
решение глобальных проблем на территории всего города, другая за проблемы в
определенном районе, третья за проблемы микрорайона и т.д. В случае выбора
неверной группы, заявка может быть передана в другую группу [22].
Для решения описанных проблем потребуется использовать карту для
определения их местоположения. Наглядное представление о проблемном месте
всегда будет восприниматься лучше, чем «сухое» текстовое описание. Указав
местоположение с помощью установления метки на карте, хорошим дополнением
46
будет прикрепление за меткой фотографий, чтобы каждый пользователь мог со
всей полнотой понимания подойти к рассматриваемой проблеме.
Для выставления приоритетов и определения актуальности поднимаемых
вопросов необходимо использовать некоторую систему голосования, где каждый
пользователь смог бы отдать свой голос за наиболее важный для него вопрос. Для
решения
поставленной
задачи
можно
позаимствовать
классическую
для
социальных сетей систему «лайков», где каждый житель сможет оценить
насколько та или иная проблема актуальна, какое число жителей она волнует.
Еще одна основополагающая задача – это обеспечить возможность
обсуждения проблемы среди пользователей. Для этой цели подойдет система
комментариев к метке (записи о проблеме с отметкой на карте). Каждый участник
группы сможет поделиться своими мыслями по интересующей его проблеме,
акцентировать внимание на каком-то конкретном аспекте рассматриваемого
вопроса.
Каждая
управляющая
организация
обязуется
принять
полученные
проблемы к рассмотрению, и в случае компетенции в решении поставленных
вопросов, принять их в обработку, в противном случае отказать с указанием
причины или перенаправить в другую группу, если это возможно. Если проблема
ушла на обработку, управляющая организация или ее подразделения должны
менять статус заявки по мере решения связанных с ней вопросов, все
пользователи смогут наблюдать за ходом ее выполнения, что в значительной мере
увеличит прозрачность хода выполнения работ и добавит обратную связь с
жителями.
Разрабатываемая ИС является распределенной и высоконагруженой, в
связи с чем должна быть решена задача масштабируемости и распределения
нагрузки.
Для построения веб-сервиса используется клиент-серверная архитектура.
Взаимодействие происходит через сеть Интернет с помощью стека протоколов
TCP/IP. Клиент с помощью браузера или мобильного приложения формирует
47
запрос к серверу. Сервер, в свою очередь, обрабатывает запрос пользователя и
формирует ответ в виде HTML страницы, либо в формате JSON.
Веб-сервер выполняет следующие функции:
− получение запросов клиентов, формирование ответов и их отправка;
− перенаправление запросов конкретным приложениям;
− предоставление
приложениям
доступа
к
необходимым
модулям
(например, к модулю связи с СУБД);
− авторизация и аутентификация пользователей.
Сервер баз данных отвечает за:
− обслуживание базы данных;
− обеспечение целостности данных;
− предоставление утилит для административного управления СУБД.
Система будет разрабатываться на базе фреймворка Django который
реализует концепцию MVC – модель, представление, контроллер. Как это
устроено.
Диспетчер ссылок анализирует адрес запроса и пытается сопоставить его
регулярному выражению среди зарегистрированных ссылок. Найдя первое
вхождение, диспетчер определяет какой именно контроллер требуется вызвать и
отдает ему управление. Контроллер выполняет все необходимые действия, а
именно, обращается к модели для получения, внесения, изменения или удаления
данных. Модель инкапсулирует логику взаимодействия с СУБД или файлом,
формирует результат и возвращает его контроллеру. Контроллер обрабатывает
данные из модели и передает их в представление, которое после вызывается,
формируя в данном случае HTML-страницу. Общая схема взаимодействия
структурных элементов паттерна MVC представлена на рисунке 9.
Таким
образом,
использование
веб-сервиса
позволит
значительно
упростить взаимодействие жителей города при решении проблем городского
хозяйства.
Он
не
обязательно
должен
ставиться
в
противопоставление
классическим методам обсуждения и принятия решения, он может работать
параллельно.
48
Рисунок 9 - Схема взаимодействия элементов в концепции MVC
Использование веб-сервиса позволит упростить процедуру доведения
проблем до управляющей организации, сэкономить личное время граждан и
сделает решение проблем более открытым.
3.2 Проектирование структуры данных
Процесс
проектирования
базы
данных
включает
проектирование
логической и физической модели базы данных.
Целью создания логической модели является развитие концептуального
проектирования БД с учетом принимаемой модели данных.
Для реализации системы была выбрана реляционная модель базы данных,
поскольку она обладает простотой, наглядностью, строгим математическим
обоснованием. Сущности представляются в виде таблиц, где каждый столбец —
это атрибут сущности, а строка — экземпляр сущности.
Для реализации системы потребуются следующие таблицы:
1) пользователь;
2) профиль пользователя;
3) организация;
4) работник организации;
5) ответственный по заявке;
6) группа;
49
7) пользователь группы;
8) метка;
9) галерея метки;
10) тег метки;
11) местоположение;
12) подписчик метки;
13) метка группы;
14) заявка группы;
15) пин группы;
16) маршрут;
17) маршрут группы;
18) статус;
19) файл статуса;
20) стена
21) публикация;
22) публикация стены;
23) комментарий;
24) галерея комментария.
Перейдем к описанию таблиц, начнем с сущности «пользователь», которая
хранит данные для аутентификации:
− идентификатор пользователя;
− логин;
− пароль;
− идентификатор стены.
«Профиль»
пользователя
служит
информации о пользователе:
− идентификатор пользователя;
− логотип;
− имя;
− фамилия;
для
хранения
дополнительной
50
− пол;
− дата рождения;
− телефон;
− skype;
− email;
− vk;
− facebook.
Данная таблица имеет отношение одни к одному с таблицей пользователь.
Сущность «местоположение», создана для хранения координат метки:
− идентификатор местоположения;
− широта;
− долгота;
− адрес.
Центральная сущность системы призванная хранить информацию с
привязкой к координатам карты — «метка»:
− идентификатор метки;
− название;
− описание;
− дата создания;
− дата изменения;
− удалена;
− логотип;
− идентификатор стены;
− идентификатор местоположения.
Как видно из списка атрибутов, метка имеет два мигрирующих ключа из
таблиц стена и местоположение. За меткой могут быть закреплены фотографии,
для этого создана сущность «галерея метки»:
− идентификатор галереи метки;
− идентификатор метки;
− изображение.
51
Также за меткой могут быть закреплены теги, для которых создана
аналогичная таблица — «теги»:
− идентификатор тега метки;
− идентификатор метки;
− тег.
Для реализации подписки пользователем на метку используется таблица
«подписчик метки», у нее два мигрирующих ключа формируют пару основного
ключа сущности:
− идентификатор пользователя;
− идентификатор метки.
Описанные таблицы представлены на ниже на рисунке 10.
Рисунок 10 – Логическая схема модели базы данных часть первая
«Группа «— сущность для кластеризации заявок. Ее атрибуты:
− идентификатор группы;
52
− название;
− описание;
− кто может просматривать метки;
− кто может публиковать метки;
− использование заявок;
− использование пинов;
− использование маршрутов;
− логотип;
− использование новостей;
− идентификатор стены.
Для описания участников группы создана сущность «пользователь
группы»:
− идентификатор пользователя группы;
− идентификатор группы;
− идентификатор пользователя;
− статус пользователя в группе.
Метки могут быть объединены в «маршрут», что позволяет группировать
их по какому-то принципу с учетом их порядка в маршруте:
− идентификатор маршрута;
− название;
− описание.
Метки маршрута описаны одноименной сущностью — «метки маршрута»:
− идентификатор метки маршрута;
− идентификатор метки;
− порядковый номер метки в маршруте.
Если маршрут закрепляется за группой, он описывается в сущности
«маршрут группы»:
− идентификатор маршрута группы;
− идентификатор группы;
− идентификатор маршрута.
53
Для закрепления метки за группой создана сущность «метка группы»:
− идентификатор метки группы;
− идентификатор группы;
− идентификатор публикатора (пользователя);
− черновая.
Черновая метка рассматривается модератором группы прежде чем попадет
в группу.
Заявки и пины имеют атрибут статус, который представлен одноименной
сущностью — «статус»:
− идентификатор статуса;
− значение;
− дата создания;
− идентификатор сменившего статус пользователя;
− причина.
Каждая
смена
статуса
сопровождается
приложением
одного
или
нескольких файлов, для реализации этой возможности создана сущность «файл
статуса»:
− идентификатор файла статуса;
− идентификатор статуса;
− файл.
«Заявка группы»:
− идентификатор метки группы;
− идентификатор организации;
− идентификатор статуса.
«Пин группы»:
− идентификатор метки группы;
− идентификатор статуса.
Данные сущности представлены на рисунке 11 ниже.
Рисунок 11 – Логическая схема модели базы данных часть вторая
54
55
«Организация»:
− идентификатор организации;
− название.
«Работник организации»:
− идентификатор работника организации;
− идентификатор пользователя;
− идентификатор организации;
− должность;
− подтвержден.
Эта сущность описывает пользователя системы, который состоит в
организации. Атрибут «подтвержден» определяет действующего сотрудника,
который подтвердил свой статус при назначении ему должности в рамках ИС.
«Ответственный по заявке»:
− идентификатор работника организации;
− идентификатор заявки группы.
Рассмотренные сущности представлены на рисунке 12 ниже.
«Стена» — это сущность для связи среды аккумулирования публикаций с
объектами системы: пользователем, меткой, группой и т. д.
«Публикация» — сущность, определяющая пост. Ее описание:
− идентификатор публикации;
− дата.
Для хранения публикаций конкретной стены есть сущность «публикация
стены». Ее вид:
− идентификатор публикации стены;
− идентификатор стены;
− идентификатор публикации.
Одним из видов публикации является «комментарий»:
− идентификатор комментария;
− текст;
− ответ на комментарий.
56
Рисунок 12 – Логическая схема модели базы данных часть третья
Атрибут «ответ на комментарий» является мигрирующим ключом с
возможностью null-значения, ссылающимся на самого себя, т. е. может содержать
идентификатор другого комментария если комментарий является ответным.
К комментарию может быть прикреплены фотографии. Для этих нужд
создана сущность «галерея комментария»:
− идентификатор галереи комментария;
− идентификатор комментария;
− изображение.
Описанные сущности представлены ниже на рисунке 13.
Для учета оценки пользователем метки используется сущность «оцененные
метки пользователем», где идентификаторы метки и пользователя выступают
первичными ключами.
57
Рисунок 13 - Логическая схема модели базы данных часть четвертая
Сущность с оценкой метки пользователем представлена на рисунке 14
ниже.
Каждый пользователь может «лайкнуть» каждую метку лишь один раз,
соответственно разумно будет переложить отслеживание целостности данных на
реализацию
БД.
промежуточную
Для
этого
сущность
с
достаточно
организовать
между
составным
первичным
ключом.
таблицами
Так
как
идентификатор в рамках кортежей одной таблицы не может быть повторен,
пользователь не сможет выполнить многократную оценку метки.
Стоит сказать почему похожие сущности, а именно: метки, заявки и пины
представлены по отдельности, хотя теоретически их можно было бы описать
одной сущностью. Это связано прежде всего для соблюдения механизма SRP –
Single Responsibility Principle – или принцип единой ответственности, который
говорит, что одному классу должна соответствовать одна ответственность.
Соблюдение этого подхода позволяет содержать код в более качественном
состоянии при дальнейшем сопровождении разрабатываемой ИС.
58
Рисунок 14 - Логическая схема модели базы данных часть 5
Перейдем
к
описанию
физической
схемы
модели
базы
данных.
Соответствие первой части логической схемы модели базы данных представлено
на рисунке 15 ниже.
Рисунок 15 – Физическая схема модели базы данных часть первая
59
Таблица 3 — Соответствие имен таблиц логической схемы модели базы данных
физической
Логическая
Физическая
пользователь
user
профиль пользователя
user_profile
метка
marker
подписчик метки
marker_follower
местоположение
location
тег метки
marker_tag
галерея метки
marker_gallary
группа
group
пользователь_группы
group_user
маршрут_группы
group_route
метка_группы
group_marker
пин_группы
group_pin
заявка_группы
group_request
маршрут
route
метка маршрута
route_marker
статус
status
файл статуса
status_file
организация
organization
сотрудник организации
employee
ответственный сотрудник
responsible_employees
стена
wall
пост стены
wall_post
пост
post
комментарий
comment
галерея комментария
comment_gallery
оцененная пользователем метка
like
Ниже, на рисунке 16 представлена вторая часть физической схемы модели
базы данных.
Рисунок 16 – Физическая схема модели базы данных часть вторая
60
61
На рисунке 17 представлена третья часть физической схемы модели БД.
Рисунок 17 – Физическая схема модели базы данных часть третья
На рисунке 18 представлена четвертая часть физической схемы модели БД.
Рисунок 18 – Физическая схема модели базы данных часть четвертая
62
3.3 Разработка алгоритмов работы отдельных подсистем
При разработке системы центральной сущностью была выявлена метка.
Она описывает связь между координатами и информацией. На ее базе строятся
другие не менее важные сущности, такие как заявки и пины.
Поэтому разумно будет рассмотреть алгоритм создания центральной
сущности в системе — создание метки.
В начале пользователю предстоит выбрать место на карте, указав курсором
или кликнув на карте. После этого потребуется заполнить все необходимые поля
формы. После заполнения формы пользователь подтверждает создание метки
нажатием на кнопку «Создать». Далее система выполняет валидацию переданных
из формы данных. В случае если данные не заполнены, или заполнены
некорректно, пользователь увидит соответствующие сообщения по каждому
элементу формы. Если данные введены корректно, выполняется проверка наличия
координат у метки. Если координаты не указаны, пользователя попросят их
указать. Если метка корректна, выполняется проверка прав на создание метки в
группе. Если права есть метка будет создана. Если прав на создание меток в
группе у пользователя нет, проверяется является ли метка черновой и есть ли у
пользователя права на создание черновых меток. Если прав нет, метка не
создается, пользователь видит информацию об ошибке с соответствующим
сообщением причины. Если права на создание черновых меток есть, то метка
будет создана как черновая. Идет сохранение метки в БД, а параллельно
выполняется уведомление пользователя об успешном создании метки и
запускается алгоритм обратного геокодирования, который выполняет вычисление
адреса по координатам метки. Эта операция выделена отдельно для снижения
нагрузки на сервер и уменьшения времени ожидания выполнения операции
создания метки. Рассмотренный алгоритм создания метки представлен ниже на
рисунке 19.
Рисунок 19 – Алгоритм создания метки
63
64
Одним из ключевых механизмов взаимодействия в рамках геосоциальной
сети выступает обмет метками. Процесс может быть выполнен внутри системы —
это обмет метками между пользователями и группами, а также вне системы, это
публикация меток в виде постов в популярные социальные сети (vk, facebook и
др.). Алгоритм обмена информацией о метках представлен на рисунке 20.
Рисунок 20 – Алгоритм обмена данными о метке
Алгоритм обратного геокодирования представлен на рисунке 21.
Рисунок 21 – Алгоритм обратного геокодирования
65
66
Алгоритм обратного геокодирования, как уже было написано ранее,
пытается вычислить адрес по координатам метки. Его наличие призвано
упростить процесс контроля корректностью адреса в метке. В системе
используется три сервиса геокодирования: Яндекс, Google и Nominatim – сервис
OpenStreetMap.
Самое хорошее покрытие территории России у Яндекса. По этой причине
он занимает первое место в приоритете обращения к сервису геокодирования.
Вторым выступает Google и третьим Nominatim.
Проверкой успешного обратного геокодирования выступает наличие в
результате обработанных данных названия страны, так как наличие страны в
результате с высокой вероятностью позволяет ожидать там и более конкретные
данные адреса (область, город, улица, дом). Однако, это не гарантирует
корректного результата с абсолютной вероятностью в сто процентов. Поэтому
пользователю доступно редактирование адреса метки вручную.
67
4 РЕАЛИЗАЦИЯ ПРОТОТИПА ИНФОРМАЦИОННОЙ СИСТЕМЫ
РЕАЛИЗУЮЩЕЙ МЕТОДИКУ ВЗАИМОДЕЙСТВИЯ ЖИТЕЛЕЙ
ГОРОДА ПРИ РЕШЕНИИ ПРОБЛЕМ ГОРОДСКОГО ХОЗЯЙСТВА
4.1 Построение логики диалога с пользователем
Построение логики диалога с пользователем будет осуществляться с
помощью диаграммы состояний UML. Ключевыми элементами этой диаграммы
являются «Начальное/Конечное состояние», «Состояние» и «Переход».
При разработке диалога определяются состояния системы. Данная
диаграмма позволяет проследить поведение объекта в рамках отдельного варианта
использования. Состояние – это устойчивое положение системы, в котором
пользователь может выполнять определенные действия. Предполагается, что
система находится какое-то время в данном состоянии, это ключевое отличие от
диаграммы деятельности, где аналог состояния — деятельность, выполняется
мгновенно.
Распространенным способом построения логики диалога является простая
транзитивная сеть — это направленный граф. Состояния системы – вершины
графа, переходы между состояниями – дуги.
В разрабатываемой информационной системе предполагается наличие трех
пользователей: житель города, диспетчер управляющей компании, работник
обслуживающей организации. Рассмотрим логику диалога для
диспетчера,
транзитивная сеть на рисунке 22.
Диспетчер при работе с системой может находиться в следующих
состояниях:
1) вход в систему;
2) главная страница;
3) текущие заявки;
4) просмотр заявки;
5) распределение заявок;
6) выбор организации;
7) приемка работ;
68
8) обработка повторного обращения.
Стартовым состоянием является состояние «Вход в систему». Далее
пользователь при прохождении авторизации попадает на главную страницу
сервиса, из главной страница пользователю доступны все основные функции.
Рисунок 22 – Логика диалога с пользователем со стороны диспетчера
Рассмотрим
интерфейс
ИС
для
жителя
города,
логика
диалога
представлена ниже на рисунке 23.
Житель при работе с системой может находиться в описанных ниже
состояниях:
1) вход в систему;
2) главная страница;
3) подача заявки;
4) мои заявки;
5) создание комментария;
6) поделиться;
7) просмотр заявки;
8) подтверждение заявки;
9) редактирование заявки.
69
Рисунок 23 – Логика диалога с пользователем со стороны жителя
Рассмотрим интерфейс ИС для работника управляющей организации,
транзитивная сеть которого представлена на рисунке 24.
Работник обслуживающей организации при работе с системой может
находиться в следующих основных состояниях:
1) вход в систему;
2) главная страница;
3) текущие заявки;
4) просмотр заявки;
5) прием/отказ от заявки;
6) выполнение заявки.
Начальным
состоянием
является
состояние
«Вход
в
систему»,
пользователь, выполнив авторизацию, попадает на главную страницу, где ему
доступны все остальные интерфейсы.
70
Рисунок 24 – Логика диалога с пользователем со стороны работника
управляющей организации
4.2 Экранные формы прототипа информационной системы,
реализующего разработанную методику
Для рядового пользователя системы, для жителя города, взаимодействие с
системой начинается с авторизации, далее пользователь в случае ввода
корректных данных профиля попадает на главную страницу сервиса, в которой
показаны последние поступившие заявки. У него есть возможность просмотреть
текущие заявки и сообщить о проблемах городского хозяйства. Экранная форма
главной страницы для жителя города представлена на рисунке 25.
Житель города имеет возможность сформировать заявку обслуживающей
организации с целью устранения выявленной проблем. Для этого ему достаточно
нажать на кнопку «Создать заявку» Экранная форма создания заявки представлена
на рисунке 26.
71
Рисунок 25 – Экранная форма главной страницы
Рисунок 26 – Экранная форма создание заявки
После подачи заявки жителю доступно ее подробное описание. Экранная
форма просмотра поданной заявки представлена на рисунке 27.
72
Рисунок 27 – Экранная форма просмотра поданной заявки
Также жителю доступен просмотр истории работы по заявке, а именно
дату и время изменения всех статусов заявки. Экранная форма просмотра истории
заявки представлена на рисунке 28.
Рисунок 28 – Экранная форма просмотра истории заявки
Диспетчер попадает в экран просмотра поданных заявок. Для всех таких
заявок указывается текущий статус с перечнем допустимых действий диспетчера.
73
Диспетчер наследует права жителя города. Экранная форма просмотра текущих
заявок представлена на рисунке 29.
Рисунок 29 – Экранная форма просмотра диспетчером текущих заявок
При возникновении ситуаций, когда житель неправильно указал категорию
проблемы, диспетчер способен сам назначить ответственную организацию.
Экранная форма распределения заявок диспетчером представлена на рисунке 30.
Рисунок 30 – Экранная форма распределения заявок
74
Представитель обслуживающей организации осуществляет прием или
отклонении перенаправленных
заявок.
Когда
заявка
не
входит
в зону
ответственности организации, представитель рабочей организации может ее
перенаправить диспетчеру для выбора новой организации. Экранная форма
работы по заявке представлена на рисунке 31.
Рисунок 31 – Экранная форма работы по заявке
Жителю
города
доступна
функция
«Поделиться»,
нажав
на
соответствующую иконку при просмотре метки, пользователю открывается
диалог, в котором он выбирает интересующую его опцию:
− порекомендовать пользователю;
− порекомендовать группе;
− поделиться в социальных сетях.
Экранная форма с диалогом «Поделиться» представлена на рисунке 32.
Также
пользователю
доступна
возможность
отметить
метку
как
понравившуюся/важную. При этом пользователь не может поставить отметку
одной метке более одного раза. Данное ограничение создано на уровне БД,
которая была описана ранее.
75
Рисунок 32 – Диалог «Поделиться меткой»
Экранная форма с интерфейсом отметки метки пользователем представлен
на рисунке 33.
Рисунок 33 – Интерфейс пользователя для пометки меток
76
Пользователь может оставить комментарий к метке. Экранная форма с
интерфейсом для комментирования представлена на рисунке 34.
Рисунок 34 – Интерфейс для комментирования
Экранная форма с уведомлениями показана на рисунке 35.
Рисунок 35 – Страница уведомлений пользователя
77
ЗАКЛЮЧЕНИЕ
В ходе выполнения данной работы проанализировали существующие
системы взаимодействия жителей города при решении проблем городского
хозяйства и пришли к выводу, что данные технологии не позволяют оперативно
оповещать службы жилищно-коммунального хозяйства о проблемах и массово
отслеживать их устранение.
Описали существующие процессы взаимодействия жителей города при
решении проблем городского хозяйства, с помощью диаграммы вариантов
использования формализовали требования.
Сформулированы функциональные и нефункциональные требования к
информационной системе. В аналитической части работы проанализировали
существующие подходы к построению взаимодействия жителей города при
решении проблем городского хозяйства. Пришли к выводу, что текущие
механизмы не удовлетворяют современным требованиям оперативности и
открытости информации.
На основе проведенного анализа разработали методику взаимодействия
жителей города при решении проблем городского хозяйства. Реализация данной
методики в виде информационной системы позволит
снизить стоимость
обработки и перенаправления поступивших заявок ответственным организациям,
упростить и сделать открытым процесс взаимодействия населения и предприятий
ЖКХ.
Провели
проектирование
прототипа
информационной
системы,
реализующего разработанную методику, а именно: определили архитектуру и
структуру разрабатываемой информационной системы; спроектировали структуру
данных в виде логической и физической модели, разработали основные
алгоритмы обработки данных. В заключительной части работы спроектировали
диалог с пользователем в виде транзитивной сети. На основе построенной логики
диалога
разработали
информационную
систему,
реализующую
методику
взаимодействия жителей города при решении проблем городского хозяйства. Все
78
поставленные задачи решены, цель достигнута. Разработанная методика повысит
эффективность
управления
городским
хозяйством
за
счет
выпускной
квалификационной
внедрения
информационной системы.
Основные
положения
работы
были
подготовлены к публикации и напечатаны в следующих в научных журналах и
сборниках:
1.
решении
Забелин С.А., Паршина В.А., Взаимодействие жителей города при
проблем
городского
хозяйства
[Электронный
ресурс]
/
Естественнонаучные, инженерные и экономические исследования в технике,
промышленности, медицине и сельском хозяйстве : материалы I молодёжной
научно-практической конференции с международным участием / под общ. ред. С.
Н. Девицыной. - Белгород : ИД "Белгород" , 2017 - 693 с.- Режим доступа:
http://dspace.bsu.edu.ru/handle/123456789/19251.
2.
Забелин С.А., Паршина В.А., Геоинформационные системы и области
их применения [Электронный ресурс]/ Естественнонаучные, инженерные и
экономические исследования в технике, промышленности, медицине и сельском
хозяйстве: материалы I молодёжной научно-практической конференции с
международным участием / под общ. ред. С. Н. Девицыной. - Белгород: ИД
"Белгород"
,
2017
-
693
с.-Режим
доступа:
http://dspace.bsu.edu.ru/handle/123456789/19251.
Так же было получено свидетельство о регистрации программы для
ЭВМ — «Система
уведомлений
представлено в приложении А.
пользователя
геосоциальной
сети».
Оно
79
СПИСОК ЛИТЕРАТУРЫ
1.
Ильичёв В. А. Биосферная совместимость: Технологии внедрения
инноваций. Города, развивающие человека. М.: Книжный дом «ЛИБРОКОМ»,
2011. — 240 с.
2.
Захарова Е.Ю. Бытовые услуги: реформы и реалии. Новосибирск
Новосиб. гос. акад. экономики и управл., 2008.
3.
Лунев, Р. А. Анализ проблем и задач управления городским
хозяйством и технологий «умного города» [Текст] / А.С. Бычкова, А.Б. Нечаева,
О.Н. Лунева, Р.А. Лунев, А.А. Стычук, А.Е. Ястребков // Информационные
системы и технологии. – Орел : ПГУ, 2016. – №2/94. Март – апрель 2016. – 153 с. –
С. 59 – 65.
4.
решении
Забелин С.А., Паршина В.А., Взаимодействие жителей города при
проблем
городского
хозяйства
[Электронный
ресурс]
/
Естественнонаучные, инженерные и экономические исследования в технике,
промышленности, медицине и сельском хозяйстве : материалы I молодёжной
научно-практической конференции с международным участием / под общ. ред. С.
Н. Девицыной. - Белгород : ИД "Белгород" , 2017 - 693 с.- Режим доступа:
http://dspace.bsu.edu.ru/handle/123456789/19251.
5.
Забелин С.А., Паршина В.А., Геоинформационные системы и области
их применения [Электронный ресурс]/ Естественнонаучные, инженерные и
экономические исследования в технике, промышленности, медицине и сельском
хозяйстве: материалы I молодёжной научно-практической конференции с
международным участием / под общ. ред. С. Н. Девицыной. - Белгород: ИД
"Белгород",
2017
-
693
с.-Режим
доступа:
http://dspace.bsu.edu.ru/handle/123456789/19251.
6.
Карпик А.П. Системная связь устойчивого развития территорий с его
геологическим информационным обеспечением// Вестник СГГА. – 2010. – Вып.
1(12). – С. 3-13.
80
7.
Нечаева А. Б. Методика сбора геоинформации в процессе управления
городским хозяйством : выпускная квалификационная работа (ВКР) магистра по
направлению подготовки 09.04.03 «Прикладная информатика», направленность
(профиль) «Корпоративные информационные системы» / А. Б. Нечаева ; рук. Р. А.
Лунев. - Орёл : [б. и.], 2017. – 113 с. [Электронный ресурс]. – Режим доступа:
http://elib.oreluniver.ru/090403-prikladnaya-informatika4/nechaeva-anastasiyaborisovna-metodika-sbora-geoin.html.
8.
12 технологий умного города. [Электронный ресурс] — Режим
доступа: http://www.therunet.com/articles/353-12-tehnologiy-umnogo-goroda.
9.
Исследование
GfK:
Проникновение
Интернета
в
России
[Электронный ресурс] — Режим доступа: https://www.gfk.com/ru/insaity/pressrelease/issledovanie-gfk-proniknovenie-interneta-v-rossii.
10. Язык программирования Ruby [Электронный ресурс] — Режим
доступа: https://www.ruby-lang.org.
11. PHP: Hypertext Preprocessor [Электронный ресурс] — Режим доступа:
http://php.net/manual/ru.
12. Our Documentation | Python.org [Электронный ресурс] — Режим
доступа: https://www.python.org/doc.
13. Documentation – The Go Programming Language [Электронный ресурс]
— Режим доступа: https://golang.org/doc.
14. Современный учебник Javascript [Электронный ресурс] — Режим
доступа: https://learn.javascript.ru.
15. SQLite Documentations [Электронный ресурс] — Режим доступа:
https://www.sqlite.org/docs.html.
16. PostgreSQL : Документация: 9.6: Документация к PostgreSQL 9.6.9 :
Компания Postgres Professional [Электронный ресурс] — Режим доступа:
https://postgrespro.ru/docs/postgresql/9.6.
17. Firebird: Documentation [Электронный ресурс] — Режим доступа:
https://www.firebirdsql.org/en/documentation.
81
18. MySQL :: MySQL Documentation [Электронный ресурс] — Режим
доступа: https://dev.mysql.com/doc.
19. Об утверждении Порядка приема и исполнения заявок населения
предприятиями ЖКХ с целью упорядочения приема заявок от населения и их
исполнения предприятиями ЖКХ. [Электронный ресурс] – Режим доступа: http://
mo.regnews.org/doc/dt/he.htm.
20. Лычак А.И. ГИС в территориальном планировании. Часть 1.
Основные понятия и приемы работы. Учебно-методическое пособие / А.И. Лычак,
Т.В. Бобра. - Симферополь: ТНУ, 2003. - С. 12-17.
21. Лунёв, Р. А. Геосоциальный сервис как электронная услуга населению
[Текст] / Р.А. Лунёв, А.А. Стычук, В.Н. Волков, А.А. Митин // Информационные
системы и технологии. – Орел: Госуниверситет - УНПК, 2015. – №3/89. Май –
июнь 2015. – 127 с. – С. 65 – 70.
22. Лунев, Р.А. Использование информационных технологий для решения
проблем городского хозяйства [Текст] / В.А. Зубарева, Р.А. Лунев, И.И. Пятин,
Д.В. Рыженков, А.А. Стычук, А.Е. // Информационные системы и технологии. –
Орел : ПГУ, 2016. – №4/96. Июль – август 2016. – 120 с. – C. 51 – 57.
82
ПРИЛОЖЕНИЕ А
(Справочное)
Копия свидетельства о регистрации программы для ЭВМ
Рисунок А.1 – Свидетельство о регистрации программы для ЭВМ №2017614880
Powered by TCPDF (www.tcpdf.org)
84
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
Наименование
группы атрибутов
атрибута
1. Описание
Обозначение документа
документа
(идентификатор(ы)
файла(ов))
Наименование документа
Характеристики документа на
электронном носителе
\Презентация.ppt
Демонстрационные плакаты к
выпускной квалификационной
работе
Класс документа
ЕСКД
Вид документа
Оригинал документа на
электронном носителе
Аннотация
Демонстрационный материал,
отображающий основные
этапы выполнения выпускной
квалификационной работы
Использование документа Операционная система
Windows 7, Microsoft
PowerPoint 97-2003
2. Даты и время
Дата и время копирования 27.06.2018 17:54:22
документа
Дата создания документа 27.06.2018
Дата утверждения
27.06.2018
документа
3. Создатели
Автор
Забелин С.А.
Изготовитель
Забелин С.А.
4. Внешние ссылки Ссылки на другие
Удостоверяющий лист
документы
№ 165143/п
5. Защита
Санкционирование
ОГУ имени И.С. Тургенева
Классификация защиты
По законодательству РФ
6. Характеристики Объем информации
1 852 928 Байт
содержания
документа
85
7. Структура
документа(ов)
Наименование плаката
(слайда) №1
Наименование плаката
(слайда) №2
Наименование плаката
(слайда) №3
Наименование плаката
(слайда) №4
Наименование плаката
(слайда) №5
Наименование плаката
(слайда) №6
Наименование плаката
(слайда) №7
Наименование плаката
(слайда) №8
Наименование плаката
(слайда) №9
Наименование плаката
(слайда) №10
Наименование плаката
(слайда) №11
Наименование плаката
(слайда) №12
Титульный лист
Цели и задачи работы
Сравнительная таблица
аналогов и прототипов
Диаграмма вариантов
использования для жителя
Преимущества и недостатки
существующих методов сбора
геоинформации
Методика взаимодействия
жителей города при решении
проблем городского хозяйства
Логическая схема модели базы
данных часть первая
Логическая схема модели базы
данных часть вторая
Логическая схема модели базы
данных часть третья
Диаграмма процесса
обработки заявки
Экранные формы
В результате проделанной
работы
Powered by TCPDF (www.tcpdf.org)
1/--страниц
Пожаловаться на содержимое документа