Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Средства разработки клиентских программ (ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ КЛИЕНТСКИХ ПРОГРАММ)

Содержание:

ВВЕДЕНИЕ

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

Безусловно, одной из глобальных общемировых тенденций является стремление к обширной информатизации и автоматизации различных процессов во всех сферах общественной жизни, включая её социальную сферу. Другой, частной тенденцией, характерной лишь для российской действительности, является подогреваемый СМИ рост подозрений о недобросовестности большого числа участников рынка ЖКХ: организаций, осуществляющих обслуживание многоквартирных домов – управляющих компаний и ТСЖ. Важной особенностью второго тренда является сохранение низкого уровня правовой грамотности населения по вопросам ЖКХ, а также традиционно признаваемая неопределённость законодательства в совокупности со сложным и запутанным механизмом бюрократической государственной машины, созданной для поддержания порядка в сфере жилищно-коммунального хозяйства.

В России на сегодняшний день существует разнообразный ряд публикаций, посвящённых различным аспектам проблем, связанных с качеством предоставления жилищно-коммунальных услуг. Уделяется внимание и общим вопросам информатизации в сфере ЖКХ [1], и некоторым частным проблемам качества предоставления услуг потребителям [2].

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

Однако все указанные исследования характеризуются двумя общими чертами:

  1. Они носят весьма общий характер. До сих споры ведутся споры относительно многих основополагающих механизмов интеграции принципов «информационного общества» в сферу жилищно-коммунального хозяйства. Исследовательская мысль ещё не дошла до решения многих узких проблем, ключевой из которых является проблема информационной поддержки граждан по вопросам нормативов качества жилищно-коммунальных услуг и прав потребителей в случае нарушений таких нормативов [4].
  2. Как отмечают некоторые исследователи [5], предлагаемые сегодня новые технологические пути решения по наведению порядка в сфере ЖКХ в своём подавляющем большинстве неразрывно связаны с государственными проектами, уже успевшими, если не доказать свою несостоятельнось, то, как минимум, осуществить всплеск негативных отзывов в отношении так и не начавших полноценную работу государственных информационных систем [6, 7].

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

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

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

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

  1. Анализ имеющихся у потребителей жилищно-коммунальных услуг возможностей на подачу жалоб о проблемах в сфере ЖКХ и борьбы с выявленными нарушениями по инициативе потребителей таких услуг – выявление сильных и слабых сторон имеющихся у потребителей вариантов решения своих жилищно-коммунальных проблем.
  2. Анализ существующих в России информационных систем, созданных для поддержки решения проблем потребителей жилищно-коммунальных услуг.
  3. Проектирование информационной системы, обеспечивающей взаимодействие между потребителями жилищно-коммунальных услуг и профессиональными юристами, оказывающими правовую помощь по вопросам ЖКХ.

Структура работы соответствует поставленным задачам. Первая глава посвящена анализу состояния дел в вопросах выявления нарушений и борьбы с нарушениями в сфере ЖКХ по инициативе потребителей жилищно-коммунальных услуг. Указанная глава разделена на три параграфа. Первый параграф описывает представленные в нашей стране подходы к разрешению жилищно-коммунальных проблем, второй – информационные системы, использующие эти возможности и функционирующие в настоящее время. В третьем параграфе приведены выводы по результатам исследования, в частности, описаны функциональные возможности, которые должны быть обеспечены для пользователей, но не предоставляются в существующих информационных системах.

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

ГЛАВА 1 ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ КЛИЕНТСКИХ ПРОГРАММ

1.1 Анализ представленных в России возможностей подачи жалоб на проблемы в сфере ЖКХ

Проблема жилищно-коммунального хозяйства в России традиционно привлекает внимание, как широких слоёв населения, так и профильных исследователей [8], а также лиц, чьи решения и действия определяют направление развития района, города и страны в целом [9]. Вопросы ЖКХ не сходят с первых страниц СМИ местного, регионального и федерального уровней. Жители российских многоквартирных домов зачастую небезосновательно подозревают организации, осуществляющие управление домами (управляющие компании и ТСЖ) в недобросовестном исполнении своих обязанностей. Часть проблем связана с ненадлежащим техническим обслуживанием жилищного фонда: отсутствие ремонта в подъезде, затопление осадками, аварии на трубопроводах и электрических сетях. Другие проблемы проистекают из вопросов административного характера: захвата придомовой территории, необоснованного начисления в квитанциях на оплату услуг и т.п.

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

Однако потребители, как правило, не знают самостоятельные пути решения этих проблем. Слишком велико число государственных и муниципальных органов и учреждений, куда вероятно нужно обратиться – также и работают эти органы с различной эффективностью и удобством для потребителей. Неизвестны потребителям и требования жилищного законодательства, и границы ответственности работающих в сфере ЖКХ лиц. В итоге сформирована ситуация, когда массовый потребитель жилищно-коммунальных услуг не знает, ни при каких нарушениях он может обратиться за защитой своих прав, ни порядок и формы таких обращений, ни лицо, на которое необходимо жаловаться. И даже если ответы на эти вопросы у потребителя находятся, у него зачастую не имеется свободного времени, чтобы решать имеющиеся жилищно-коммунальные проблемы до тех пор, пока они не начинают носить срочный аварийный характер.

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

  1. Переговорный процесс с лицом, осуществляющим управление домом.
  2. Обращение с жалобами в надзорные и контрольные государственные и муниципальные органы (см. табл. 1.1.).
  3. Подача в суд искового заявления об обязании устранить допущенные нарушения законодательства.

Таблица 1.1. Обращение потребителей с жалобами в надзорные и контрольные органы

Органы власти

Возможные результаты обращения

Инспекция государственного жилищного надзора

  • отсутствие ответа;
  • ответ об отсутствии нарушений или компетенции;
  • передача заявления в другой орган власти;
  • штраф лицу, осуществляющему управление домом, в размере до 250 т.р.;
  • выдача предписания об устранении нарушений

Органы власти

Возможные результаты обращения

Роспотребнадзор

  • отсутствие ответа;
  • ответ об отсутствии нарушений или компетенции;
  • передача заявления в другой орган власти;
  • штраф лицу, осуществляющему управление домом, в размере до 40 т.р.

Роспожнадзор

  • отсутствие ответа;
  • ответ об отсутствии нарушений или компетенции;
  • передача заявления в другой орган власти;
  • штраф лицу, осуществляющему управление домом, в размере до 150 т.р.

Прокуратура

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

Администрация города или района

  • отсутствие ответа;
  • ответ об отсутствии нарушений или компетенции;
  • передача заявления в другой орган власти;
  • представление о нарушении законодательства;
  • штраф лицу, осуществляющему управление домом, в размере, как правило, до 40 т.р.

Любые другие окологосударственные организации («письма в «Спортлото»).

  • отсутствие ответа;
  • ответ об отсутствии компетенции.

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

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

К недостаткам этого способа относятся:

Ограниченность диапазона решаемых проблем, зависящая только от степени свободы, предлагаемого каждым «управдомом» индивидуально, исходя из его субъективных оценок ситуации.

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

Совпадение лиц: допустившего нарушение и принимающего решение о необходимости его устранения.

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

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

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

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

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

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

Риск понести существенные денежные затраты в случае поражения в суде.

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

Временные затраты на подготовку документов.

Длительность судебной процедуры – от 3-х месяцев и выше.

1.2 Информационные системы, используемые при подаче заявок на проблемы в сфере ЖКХ

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

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

Информационные системы, претендующие на статус «глобальных» и пытающиеся охватить максимальное число вопросов, связанных с ЖКХ (ГИС ЖКХ – dom.gosuslugi.ru);

Информационные системы, специализирующиеся на обработке жалоб граждан во всех сферах жизнедеятельности, в т.ч., ЖКХ (Сердитый гражданин – Angrycitizen.ru);

Информационные системы, специализирующиеся на обработке жалоб пользователей жилищно-коммунальных услуг (РосЖКХ – roszkh.ru);

Информационные системы, действующие в отдельных государственных органах, позволяющие обратиться к ним с помощью заполнения формы на сайте такого органа (например, на сайте Прокуратуры Пермского края – prokuror.perm.ru/faq1)

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

Совокупность всех представленных в России информационных систем (их типичных представителей), связанных с подачей заявок о проблемах ЖКХ, представлена в таблице 1.2.

Таблица 1.2. Информационные системы, связанные с подачей заявок о проблемах в сфере ЖКХ

Название ИС

Отношение к государству / порядок финансирования

Специализация

Особенности приёма и обработки заявок

ГИС ЖКХ

(dom.gosuslugi.ru)

Государственная

Претендует на глобальный статус – решение всех ЖКХ проблем.

Представлена возможность подать жалобу на сайте и через личный кабинет получить ответ от ИГЖН и администрации населённого пункта.

Мобильное приложение не предусматривает указанной возможности.

ИС Реформа ЖКХ

(reformagkh.ru)

Государственная

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

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

ИС Реформа ЖКХ

(reformagkh.ru)

Государственная

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

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

Сердитый гражданин

(angrycitizen.ru)

Частная / Финансируется за счёт пожертвований и платных косвенных продуктов

Претендует на глобальный статус – решение проблем потребителей во всех сферах жизни.

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

РосЖКХ

(roszkh.ru)

Частная / Финансируется за счёт пожертвований

Специализирована на приём заявок пользователей на проблемы ЖКХ.

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

ИС отдельных государственных органов

Государственные

Специализации нет

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

ИС отдельных управляющих организаций или их объединений

Частные / Финансируются из собственных средств владельцев

Специализированы на всех вопросах ЖКХ, возникающих при управлении домами.

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

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

При использовании государственных информационных систем:

Воспользоваться веб-сайтом для отправки заявки в службу поддержки ИС;

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

Воспользоваться веб-сайтом для отправки заявки в ИГЖН или другой надзорный орган;

Получить по почте ответ на свою заявку от ИГЖН или другого надзорного органа.

При использовании частных информационных систем:

Воспользоваться веб-сайтом для отправки заявки в ИГЖН или другой надзорный орган;

Получить по почте ответ на свою заявку от ИГЖН или другого надзорного органа.

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

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

Получить через веб-сайт ответ на свою заявку от службы поддержки ИС управляющей организации;

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

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

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

1.3 Реализация возможностей, не предусмотренных существующими информационными системами, связанными с подачей заявок на проблемы в сфере ЖКХ

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

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

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

Весь процесс деятельности потенциального пользователя проектируемой информационной системы, позволяющей подать заявку о проблемах ЖКХ в суд, можно разбить на 11 этапов:

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

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

Этап 3. Принятие решения о судебном пути борьбы с проблемой. Потребитель решает осуществить защиту своих прав путём подачи в суд искового заявления об обязании устранить допущенные нарушения законодательства.

Этап 4. Поиск юриста. Потребитель определяет юристов, которые будут заниматься его жилищно-коммунальной проблемой в судебном порядке.

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

Этап 6. Подготовка заявления в суд. На основании предоставленных потребителем сведений юрист анализирует ситуацию и в случае наличия нарушений готовит в интересах потребителя документы для последующей их подачи в суд.

Этап 7. Передача заявления в суд. Участие в суде. Юрист направляет в суд заявление и иные необходимые для рассмотрения дела документы, участвует в судебном разбирательстве в защиту прав потребителя, в том числе в апелляционной и кассационной инстанциях.

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

Этап 9. Передача решения юристу. Юрист как представитель потребителя получает в суде судебный акт, вступивший в законную силу.

Этап 10. Передача решения потребителю. Юрист как представитель потребителя передаёт последнему полученный в суде судебный акт, вступивший в законную силу.

Этап 11. Решение проблемы потребителя. Потребитель имеет на руках наиболее эффективный документ, решающий проблемы жилищно-коммунального хозяйства.

Перспективным видится осуществление проектирования системы таким образом, чтобы максимально упростить все действия потребителя услуг ЖКХ, совершённые им от момента принятия решения о выборе судебного пути и использования системы (этап 3) до момента решения проблемы (этап 11). Достижение такой возможно при автоматизации процессов № 4, 5, 6 и 10, как это изображено на диаграмме в Приложении 1 к настоящей работе.

Требующие автоматизации процессы представлены в виде диаграммы последовательностей AS IS в нотации IDEF0.

Рисунок 1.1. Получение решения суда AS IS в нотации IDEF0

Ниже представлена декомпозиция приведённой диаграммы в первом приближении.

Рисунок 1.2. Декомпозиция диаграммы AS IS в нотации IDEF0

Получение решения суда

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

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

Решение поставленной задачи становится возможным в связи с использованием не применяемого ранее подхода по автоматизации процессов, связанных с судебным путём подачи заявок на проблемы ЖКХ. Эксплуатационная стоимость информационной системы, акцентирующей внимание на взаимодействие с административными органами, ограничена полномочиями последних. Административные органы зажаты в узкие рамки, предоставленные им законом, и вправе применять к нарушителям ограниченное число мер. Однако суды в Российской Федерации принимают решения, исходя из заявленных в иске требований [10, 11]. Таким образом, обратившись в суд, заявитель жалобы имеет возможность весьма гибко сформулировать свои требования, предусмотрев для виновной стороны обязанность по оплате штрафов и стоимости юридических услуг, оказанных с использованием информационной системы.

Последним из требований, предъявляемых к проектируемой системе и не реализованных в существующих решениях, выступает необходимость предусмотреть пути дополнительной стимуляции потребителей жилищно-коммунальных услуг пользоваться услугами проектируемого сервиса, помимо «прямой» нужды решить ту или иную ЖКХ-проблему. Прогрессивным шагом будет внедрение дополнительной финансовой мотивации пользователя системы за каждую реально существующую проблему, о которой он заявит [12]. В качестве нового стимула, не предлагаемого раньше, можно использовать денежное вознаграждение, выплачиваемое пользователю за каждую заявку, поданную им с помощью системы и оцененную юристами как имеющую потенциал для подачи иска в суд. При этом, денежное вознаграждение пользователю должно выплачиваться вне зависимости от результатов и длительности судебных процедур в фиксированном размере непосредственно сразу после верификации заявки со стороны юристов системы.

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

ГЛАВА 2 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1 Функциональные требования к проектируемой системе

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

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

Бизнес-роли лиц, работающих в информационной системе, раскрыты в таблице 2.1.

Таблица 2.1. Роли лиц, использующих информационную систему

Бизнес-роль

Функции

Системный администратор

Имеет доступ ко всем компонентам системы и отвечает за её работоспособность.

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

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

Юрист

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

Пользователь услуг ЖКХ

Создаёт заявки и получает по ним верифицированную администратором информацию от юристов.

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

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

Таблица 2.2. Функциональные требования

№ п/п

Бизнес-роль

Потребность

Цель

1

Пользователь услуг ЖКХ, юрист и администратор

Входить в систему

Пользоваться функционалом системы

2

Пользователь услуг ЖКХ

Регистрироваться в системе

Иметь возможность начать пользоваться системой

3

Пользователь услуг ЖКХ

Создавать заявки

Получить достойный уровень доставки услуг ЖКХ

4

Пользователь услуг ЖКХ

Просматривать свои заявки

Быть в курсе происходящих с ними процессов

5

Пользователь услуг ЖКХ

Вносить изменения в свои заявки при необходимости

Предоставить более развёрнутую и достоверную информацию для обработки заявки

6

Пользователь услуг ЖКХ

Принимать присланное соглашение

Запустить процесс передачи судебного дела юристам сервиса

7

Пользователь услуг ЖКХ

Получать сообщения от администратора

Иметь более точное представление о том, что от меня требуется

8

Пользователь услуг ЖКХ

Получать судебные документы в электронном виде (PDF-файл)

Иметь подтверждение об успешном (или нет) завершении судебного процесса по заявке

9

Пользователь услуг ЖКХ

Иметь возможность восстановить пароль

Возобновить работу с системой в случае его утери

10

Пользователь услуг ЖКХ

Иметь возможность отправить заявку без регистрации

Упростить начало работы с системой

11

Юрист, администратор

Просматривать

Обрабатывать

пользовательские заявки

12

Юрист

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

Уведомлять пользователя о прогрессе по заявке

13

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

Менять статус заявки, прикреплять судебные документы и писать пользователю сообщения

Уведомлять пользователя о прогрессе по заявке

14

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

Верифицировать изменения юриста по заявке

Не допустить нарушений в бизнес-процессах системы

Ключевым элементом всех процессов, происходящих с использованием проектируемой информационной системы, является заявка пользователя услуг ЖКХ, и в отношении которой может произойти ряд изменений:

Заявка может быть создана;

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

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

У заявки может быть изменён статус в зависимости от стадии её обработки;

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

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

Ниже на рисунке 2.1. представлена диаграмма прецедентов use-case о возможны действиях пользователей системы с заявками.

Рисунок 2.1. Диаграмма прецедентов use-case

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

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

2.2 Архитектура проектируемой системы

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

Архитектура системы включает в себя четырёх основных компонента:

База данных;

Серверная часть

Десктопное клиентское приложение для юристов и администраторов заявок;

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

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

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

Общая архитектура проектируемой системы изображена на рисунке 2.3.

Рисунок 2.3. Общая архитектура проектируемой системы

2.3 База данных системы

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

База данных информационной системы включает в себя 5 таблиц.

Пользователи;

Адреса;

Заявки;

Аудентификационные токены;

Документы к заявкам.

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

Наиболее значимой таблицей является таблица заявок (Requests), поскольку вся система проектируется с целью их приёма и обработки.

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

Аутентификационные токены (AuthTokens) выдаются при входе пользователя в систему и используются для его идентификации.

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

Уникальный индекс есть только в одном поле – email из таблицы пользователи услуг ЖКХ (Users), поскольку электронный адрес используется для входа в систему, а посему должен быть уникален.

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

Описанная схема базы данных изображена ниже на рисунке 2.4.

Рисунок 2.4. Схема базы данных проектируемой системы

ЗАКЛЮЧЕНИЕ

В настоящей работе выполнено проектирование информационной системы для подачи заявок о проблемах в сфере ЖКХ.

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

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

Возможность направить свою заявку по судебному пути решения проблем ЖКХ;

Возможность для пользователя отслеживания юридической «судьбы» поданной заявки.

Решение задачи по извлечению информационной системой прибыли.

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

Спроектированная информационная система включает в себя указанные нереализованные ранее функциональные решения.

СПИСОК ЛИТЕРАТУРЫ

  1. Арбитражный процессуальный кодекс Российской Федерации от 24.07.2002 № 95-ФЗ.
  2. Архипова Т.И. Проблемы тарифного регулирования в жилищно-коммунальной сфере // Экономика и предпринимательство. 2013 № 10 (39), С. 438-440.
  3. Афанасьева А.Н. Правовые проблемы в сфере жилищно-коммунальных услуг // ВЭПС. 2015. № 3. С. 118-120
  4. Бобровская Н.И. Российская государственная политика в области жилищно-коммунального хозяйства: теоретические аспекты проблемы // Государственное и муниципальное управление. Ученые записки СКАГС. 2013. № 3. С. 31-40 
  5. Бублик Н. Д., Шарипова Л. К., Чувилин Д. В. Проблемы и пути развития ЖКХ региона // ПСЭ. 2012. № 4. С. 295-298
  6. Ващишин Д. С. Реформирование жилищно-коммунального хозяйства: современное состояние, проблемы и перспективы // Вестник ОмГУ. Серия: Экономика. 2009. № 3. С. 50-55
  7. ГИС ЖКХ: новый сомнительный мегапроект? // [Электронный ресурс]. URL: http://alfakontakt.ru/gis-zhkh-novyiy-somnitelnyiy-megaproekt/ (дата обращения 29.06.2018).
  8. Гражданский процессуальный кодекс Российской Федерации от 14.11.2002 года № 138-ФЗ.
  9. Информационные технологии ЖКХ: госпроекты или гражданские стартапы? [Электронный ресурс]. URL: http://rln.fm/arhiv/high-tech/462-informacionnye-tehnologii-v-zhkh-gosproekty-ili-gradanskie-startapy.html (дата обращения 01.06.2018).
  10. Постановление Правительства РФ от 15.04.2014 № 313 "Об утверждении государственной программы Российской Федерации "Информационное общество (2011 - 2020 годы)".
  11. Путин: в сфере ЖКХ проблем больше, чем решений // ТАСС [Электронный ресурс]. URL: http://tass.ru/ekonomika/4812438 (дата обращения 29.05.2018).
  12. Системный сбой ЖКХ // Газета.Ру [Электронный ресурс]. URL: https://www.gazeta.ru/business/realty/2016/09/28_a_10219079.shtml#page1. (дата обращения 29.0.2018).
  13. Чистова М.В., Концевич Г.Е., Демина Н.В. Возможности внедрения информационных технологий для реформирования жилищно-коммунального хозяйства РФ // Гуманизация образования. 2014. № 6. С. 95-101.

Приложение А. Техническое задание

ИНФОРМАЦИОННАЯ СИСТЕМА ДЛЯ ПОДАЧИ ЗАЯВОК О ПРОБЛЕМАХ В СФЕРЕ жкх

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

Лист утверждения

А.В.00001-01 ТЗ 01-лу

Руководитель проектирования

___________Л.Н. Лядова

“_____”____________2018

Исполнитель

___________Валиев В.Т.

“_____”____________2018

Пермь, 2018

Содержание

1. ВВЕДЕНИе 37

1.1. Наименование программы 37

1.2. Краткая характеристика области применения программы 37

2. Основание для разработки 37

2.1. Основание для проведения разработки 37

2.2. Наименование и условное обозначение темы разработки 37

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

3.1 Функциональное назначение программы 37

3.2. Эксплуатационное назначение программы 37

4. Требования к программе 38

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

4.1.1. Требования к составу выполняемых функций 38

4.1.2. Требования к организации входных данных 38

4.1.3. Требования к организации выходных данных 39

4.1.4. Требования к временным характеристикам 39

4.2. Требования к надежности 39

4.2.1. Требования к обеспечению надежного (устойчивого) функционирования программы 39

4.2.2. Время восстановления после отказа 40

4.2.3. Отказы из-за некорректных действий оператора 40

4.3. Условия эксплуатации 40

4.3.1. Климатические условия эксплуатации 40

4.3.2. Требования к видам обслуживания 40

4.3.3. Требования к численности и квалификации персонала 41

4.4. Требования к составу и параметрам технических средств 41

4.5. Требования к информационной и программной совместимости 42

4.5.1. Требования к информационным структурам и методам решения 42

4.5.2. Требования к исходным кодам и языкам программирования 42

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

4.5.4. Требования к защите информации и программ 42

4.6. Требования к маркировке и упаковке 42

4.7. Требования к транспортированию и хранению 42

4.8. Специальные требования 42

5. Требования к программной документации 43

5.1. Предварительный состав программной документации 43

5.2. Специальные требования к программной документации 43

6. ЧИСЛЕННЫЕ показатели 43

6.1. Предполагаемая годовая потребность 43

7. Стадии и этапы разработки 43

7.1. Стадии разработки 43

7.2. Этапы разработки 43

8. Порядок контроля и приемки 44

8.1. Виды испытаний 44

8.2. Общие требования к приемке работы 44

ВВЕДЕНИЕ

Наименование программного продукта

Наименование – «Информационная система по приёму заявок о проблемах в сфере ЖКХ».

Краткая характеристика области применения программного продукта

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

Основание для разработки

Основание для проведения разработки

Основанием для проведения разработки является Приказ о выполнении ВКР студентами НИУ ВШЭ – Пермь вечерне-заочно факультета экономики и управления.

Наименование темы проектирования

Наименование темы проектирования – «Проектирование информационной системы для подачи заявок о проблемах в сфере ЖКХ».

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

Функциональное назначение программного продукта

Функциональным назначением программного продукта является приём обработка и учёт заявок о проблемах в сфере ЖКХ.

Эксплуатационное назначение программного продукта

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

Требования к ПРОГРАММНОМУ ПРОДУКТУ

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

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

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

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

Вход в систему;

Регистрация в системе;

Создание заявки зарегистрированным пользователем;

Создание заявки незарегистрированным пользователем;

Просмотр заявок;

Внесение изменение в заявку;

Принятие соглашения о работе;

Отправка соглашения о работе

Получение сообщений от юриста пользователю;

Отправка сообщений от юриста пользователю;

Получение от юристов документов в формате .pdf;

Отправка от юристов документов в формате .pdf;

Восстановление пароля от учётной записи;

Изменение статуса заявки;

Верификация изменений вносимых юристов по заявке.

Требования к организации входных данных

Входными данными являются данные, которые вносятся пользователями системы. Входные данные принимаются:

в текстовом формате в кодировке UTF-8;

в формате изображений JPEG;

в формате документов PDF.

Требования к организации выходных данных

Выходные данные программы должны быть организованы:

в текстовом формате в кодировке UTF-8;

в формате изображений JPEG;

в формате документов PDF.

Требования к временным характеристикам

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

Требования к надежности

Требования к обеспечению надежного (устойчивого) функционирования программы

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

организацией бесперебойного питания технических средств;

регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»

регулярным выполнением требований ГОСТ 51188-98. Защита информации. Испытания программных средств на наличие компьютерных вирусов;

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

программа не должна аварийно завершаться при некорректных действиях пользователя (контроль входных данных);

необходимым уровнем квалификации персонала.

Время восстановления после отказа

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

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

Отказы из-за некорректных действий оператора

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

Условия эксплуатации

Климатические условия эксплуатации

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

Требования к видам обслуживания

См. Требования к обеспечению надежного (устойчивого) функционирования программы.

Требования к численности и квалификации персонала

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

В перечень задач, выполняемых администратором, должны входить:

задача поддержания работоспособности технических средств;

задачи установки (инсталляции) и поддержания работоспособности программных средств;

контроль качества обслуживания;

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

установка и настройка системы;

интеграция системы с основным сервисом.

настройка параметров системы программным путем;

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

Пользователями программного продукта будут являться юристы клиента, администратор-юрист, пользователи услуг ЖКХ.

Требования к составу и параметрам технических средств

В состав технических средств должны входить IBM-совместимые серверные компьютеры (СЭВМ), включающие в себя:

процессор Core i3 с тактовой частотой, 3.70GHz, и выше;

оперативную память объемом, 2 Гб, и выше;

жесткий диск объемом 100 Гб, и выше;

наличие Ethernet порта;

Сервер для базы данных должен иметь следующие характеристики:

процессор Core i7 с тактовой частотой, 3.70GHz, и выше;

оперативную память объемом, 16 Гб, и выше;

жесткий диск объемом 3 Тб, и выше;

наличие Ethernet порта.

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

Требования к информационной и программной совместимости

Требования к информационным структурам и методам решения

База данных должна быть реляционной. Специальные требования к методам решения не предъявляются.

Требования к исходным кодам и языкам программирования

Специальные требования к исходным кодам и языкам программирования не предъявляются.

Требования к программным средствам, используемым программным продуктом

Специальные требования к программным средствам не предъявляются.

Требования к защите информации и программного продукта

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

Требования к маркировке и упаковке

Специальные требования к маркировке и упаковке не предъявляются.

Требования к транспортированию и хранению

Соответствуют требованиям хранения приложений для обмена данными.

Специальные требования

Специальные требования к программному продукту не предъявляются.

Требования к программной документации

Предварительный состав программной документации

Состав программной документации должен включать в себя:

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

текст программы;

пояснительные записки к эскизному, техническому, рабочему проектам;

сценарии тестирования.

Специальные требования к программной документации

Специальные требования к программной документации не предъявляются.

ЧИСЛЕННЫЕ ПОКАЗАТЕЛИ

Предполагаемая годовая потребность

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

Стадии и этапы разработки

Стадии разработки

Разработка должна быть проведена в несколько стадий:

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

проектирование информационной системы;

реализация информационной системы.

Этапы разработки

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

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

Порядок контроля и приемки

Виды испытаний

Приемо-сдаточные испытания программы должны проводиться согласно разработанной и согласованной «Программы и методики испытаний».

Общие требования к приемке работы

Прием работы происходит при защите ВКР в НИУ ВШЭ – Пермь.