Разработка программного комплекса расчета компенсаций по капитальному ремонту

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

Введение

1. Анализ существующих систем по расчету компенсаций по капитальному ремонту

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

1.2 Факторы, влияющие на выбор

1.3 Решение задачи в разных субъектах РФ

1.3.1 Республика Калмыкия

1.3.2 Республика Мордовия

1.3.3 Вологодская область

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

2.1 Требования к характеристикам взаимодействия с внешними системами

2.1.1 Требования к функционированию

2.1.2 Требования к информационному обеспечению

2.1.3 Требования к программному обеспечению

2.1.4 Требования к эргономике и технической эстетике

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

3 Структура программного комплекса

4 Описание базы данных

4.1 Табличные пространства

4.2 Блоки данных

4.3 Экстенты

4.4 Сегменты

4.5 Описание структуры базы данных

5. Разработка алгоритмов

6 Реализация программных модулей системы

7. Отладка и экспериментальное тестирование

8. Разработка технической документации. Руководство пользователя

Заключение

Список использованных источников

ВВЕДЕНИЕ

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

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

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

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

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

С развитием информационных систем возникает ряд проблем:

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

2) значительные затраты на начальном этапе разработки, тестирования и внедрения;

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

С октября 2014 года в Вологодской области, согласно поправок в Жилищный кодекс и нормативные документы областного значения, у собственников помещений появилась обязанность уплачивать взносы на капитальный ремонт. Согласно постановлениям Правительства Вологодской области № 401 от 16.04.2010г и № 402 от 16.04.2010г, выделяются отдельные категории граждан, которым назначаются льготы на уплату взносов на капитальный ремонт. Разработан следующий механизм начисления льгот: собственник помещения уплачивает взнос на капитальный ремонт в размере 100%, затем районные центры социальных выплат высчитывают объем льготы и отправляют эти данные в некоммерческую организацию Вологодской области «Фонд капитального ремонта многоквартирных домов Вологодской области» (далее Фонд). Фонд производит начисление и отправляет эти данные обратно в центры социальных выплат для выплаты собственнику[2][3].

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

1. АНАЛИЗ СУЩЕСТВУЮЩИХ СИСТЕМ ПО РАСЧЕТУ КОМПЕНСАЦИЙ ПО КАПИТАЛЬНОМУ РЕМОНТУ

В настоящее время в России все собственники помещений обязаны уплачивать взносы на капитальный ремонт. В каждом субъекте на местном уровне разработан механизм уплаты взносов, а также их размер, например, в Москве размер взноса единый и составляет 15 рублей за квадратный метр, в Санкт-Петербурге размер взноса дифференцированный, зависит от ряда показателей и составляет от 2,5 рублей до 4 рублей за квадратный метр. В Вологодской же области размер взноса составляет 6,6 рублей за квадратный метр. (постановление Правительства Вологодской области от 31 октября 2013 года № 1119 "Об установлении минимального размера взноса на капитальный ремонт общего имущества в многоквартирном доме")[1].

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

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

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

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

3) осуществление функций технического заказчика работ по капитальному ремонту общего имущества в многоквартирных домах, собственники помещений в которых формируют фонды капитального ремонта на счете, счетах Регионального оператора;

4) финансирование расходов на капитальный ремонт общего имущества в многоквартирных домах, собственники помещений в которых формируют фонды капитального ремонта на счете, счетах Регионального оператора, в пределах средств этих фондов капитального ремонта с привлечением при необходимости средств, полученных из иных источников, в том числе из федерального бюджета, бюджета субъекта Российской Федерации и (или) местного бюджета;

5) взаимодействие с органами государственной власти субъекта Российской Федерации и органами местного самоуправления в целях обеспечения своевременного проведения капитального ремонта общего имущества в многоквартирных домах, собственники помещений в которых формируют фонды капитального ремонта на счете, счетах Регионального оператора;

6) иные предусмотренные настоящим Кодексом, законом субъекта Российской Федерации и учредительными документами регионального оператора функции.

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

С началом обязанности уплаты взносов на капитальный ремонт появилась задача начисления льгот по уплате взносов. Необходимо учитывать более 65 категорий льготников, таких как ветеран труда, инвалиды различных групп, участники боевых действий и т.д. У каждой категории граждан свой процент льготы, причем может быть собственник с несколькими группами льгот. Например, самой многочисленной льготной категорией граждан - ветеранам труда и ветеранам труда Вологодской области, меры социальной поддержки на оплату взносов на капитальный ремонт предоставляются в размере 50 % на оплату доли занимаемой общей площади жилого помещения в пределах социальной нормы Также существуют федеральные, областные и муниципальные виды льготников. На местном (областном) уровне принят ряд нормативных документов, регламентирующий процесс начисления, уплаты льгот, а также весь порядок и механизм расчета.

delphi загрузка данные модуль

1.2 Факторы, влияющие на выбор

Данную задачу Фонды капитального ремонта многоквартирных домов различных субъектов РФ решают по-разному. Множество факторов влияет на выбор, существуют три основные пути решения:

1) изначально приобретается полнофункциональное специализированное программное обеспечение, которое затрагивает весь спектр оказываемых услуг, таких как: проведение капитального ремонта, биллинг, работа с собственниками, начисление и ведение льгот и т.д.;

2) разработка и программное интегрирование модуля расчета льгот к уже существующей автоматизированной информационной системе;

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

1.3 Решение задачи в разных субъектах РФ

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

1.3.1 Республика Калмыкия

В республике Калмыкия в 2014 году появилась обязанность уплачивать взносы на капитальный ремонт. В 2013 году с появлением регионального фонда капитального ремонта многоквартирных домов республики Калмыкия, появилась необходимость информационной системы для ведения деятельности фонда, в том числе и начисления льгот по взносам. Фондом у компании ООО «БСТ» было приобретено комплексное решение, состоящее из отдельных модулей, таких как программа капитального ремонта, биллинг, электронный паспорт дома и т.д. Так же в состав решения входит и модуль начисления льгот[13].

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

В качестве аппаратного обеспечения используются арендованные у подрядчика серверные мощности. Такой способ решения аппаратных задач позволил развернуть систему на самых современных многопроцессорных серверах последнего поколения. Так как программа является многопользовательской и существует потребность множества одновременных подключений, произведено подключение к серверам высокоскоростной оптической линии передачи данных, как внутри локально-вычислительной сети организации, так и во внешнюю сеть по средствам сети Интернет. На сервере установлено программное обеспечение Windows Web Server 2012 r2.

В качестве базы данных был выбран отдельный специализированный сервер, со множеством слотов под жесткие диски, объединенные в RAID массив, с задачами зеркалирования и высокой надежности, а также быстродействия. На сервере используется программное обеспечения для баз данных Microsoft SQL Server 2012.

Технологически процесс предоставления льгот реализован следующим образом: в Фонд, имеющий полную базу данных собственников с именами, фамилиями, отчествами, адресами и т.д., местными службами социальной защиты предоставляется информация о льготниках, содержащая ФИО, адрес и код льготы, в виде файла в формате XML. Автоматизированная информационная система обрабатывает данный файл, проставляет соответствующие категории льгот суммы для каждого льготника. На выходе получается файл с начисленными суммами льгот собственников. Данный файл передается в единый расчетный центр для выплаты.

Можно выделить основные причины выбора:

1) хорошее финансирование;

2) наличие местного подрядчика с должной квалификацией;

3) поддержка решения Правительством субъекта РФ;

4) отсутствие в штате специалистов по обслуживание серверов и программистов.

Преимущества выбора данного пути:

1) работа с единственным поставщиком услуг;

2) гарантия бесперебойной работы оборудования 24 часа в сутки, 365 (366) дней в году;

3) оперативная реакция на появившиеся ошибки в работе программы;

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

Недостатки выбора данного пути:

1) существенные финансовые затраты на разработку и внедрение;

2) затраты на аренду серверов;

3) затраты на ежемесячное техническое обслуживание автоматизированной информационной системы, а также обновление;

4) огромная техническая зависимость от единственного поставщика услуг;

5) отсутствие гибкости исполнения, так как создавалось за ранее.

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

1.3.2 Республика Мордовия

В республике Мордовия в 2014 году также появилась обязанность уплачивать взносы на капитальный ремонт. Фондом было приобретено морально устаревшее, но вполне работоспособное, решение, созданная в 2006 году, автоматизированная информационная система ЖКХ. Данная система включала в себя лишь несколько крупных модулей, таких как программа капитального ремонта и электронный паспорт дома. С учетом времени, появлялись потребности в новых модулях автоматизированной информационной системы, в том числе и модуль расчета льгот отдельных категорий собственников[15].

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

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

Технологически процесс предоставления льгот реализован следующим образом: в Фонд, имеющий полную базу данных собственников с именами, фамилиями, отчествами, адресами и т.д., местными службами социальной защиты предоставляется информация о льготниках, содержащая ФИО, адрес и код льготы, в виде файла в формате DBF (версия 2). Автоматизированная информационная система обрабатывает данный файл, проставляет соответствующие категории льгот суммы для каждого льготника. На выходе получается файл в том же формате DBF (версия 2) с начисленными суммами льгот собственников. Данный файл передается обратно в районные службы социальной защиты населения.

Можно выделить основные причины выбора:

1) хорошее финансирование;

2) наличие местного подрядчика с должной квалификацией;

3) поддержка решения Правительством субъекта РФ;

4) присутствие в штате специалистов по обслуживание серверов и программистов.

Преимущества выбора данного пути:

1) существенная экономия денежных средств на модернизацию и обслуживание;

2) гарантия бесперебойной работы оборудования 24 часа в сутки, 365 (366) дней в году;

3) отсутствие необходимости привлечения сторонних разработчиков;

4) оперативная реакция на появившиеся ошибки в работе программы.

Недостатки выбора данного пути:

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

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

3) отсутствие целостности системы, так идет процесс постоянной модернизации, частое появление ошибок.

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

1.3.3 Вологодская область

В Вологодской области в конце 2014 году также появилась обязанность уплачивать взносы на капитальный ремонт. Фонд имел готовое решение, автоматизированную информационную систему «Реестр объектов, находящихся на территории области». Данная система включает в себя все основные модули, такие как программа капитального ремонта, электронный паспорт дома и т.д., но в автоматизированной информационной системе отсутствует модуль расчета льгот. Так же сложилась ситуация, что разработчики автоматизированной информационной системы прекратили все взаимоотношения с Фондом[14].

Автоматизированная информационная система была создана по технологии от Microsoft-ASP.NET. Все файлы программы были скомпилированы и не имели возможности редактирования без использования исходного кода. Разработчик запатентовал данное решение.

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

В качестве базы данных используется имеющееся решение на базе продукта Oracle. База данных установлена на отдельном специализированном сервере с общим объемом жестких диском более 10 терабайт. Также соответственно реализованы RAID-массивы от компании Adaptec.

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

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

Технологически процесс предоставления льгот реализован следующим образом: в Фонд, имеющий полную базу данных собственников с именами, фамилиями, отчествами, адресами и т.д., местными службами социальной защиты предоставляется информация о льготниках, содержащая фамилию, имя, отчество, код улицы, код дома и код льготы, в виде файла в формате DBF (версия 2). Автоматизированная информационная система обрабатывает данный файл, проставляет соответствующие категории льгот суммы для каждого льготника. На выходе получается файл в том же формате DBF (версия 2) с начисленными суммами льгот собственников. Данный файл передается обратно в районные службы социальной защиты населения.

Можно выделить основные причины выбора:

1) существенная экономия денежных средств на создание, модернизацию и обслуживание;

2) гарантия бесперебойной работы оборудования 24 часа в сутки, 365 (366) дней в году;

3) отсутствие необходимости привлечения сторонних разработчиков;

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

Недостатки выбора данного пути:

1) сложность реализации из-за отсутствия опыта создания автоматизированных информационных систем;

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

3) отсутствие целостности системы, так идет процесс постоянной модернизации, частое появление ошибок.

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

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

Процесс защищенного обмена информацией между Фондами и районными службами социальной защиты происходит следующим образом: каждая организация из этого процесса получает средства криптографической защиты информации. Далее происходит обмен сертификатами открытого ключа между всеми участниками. Затем используется приобретенное всеми участниками программное обеспечение Крипто ПРО CSP версии не ниже 3.9.ХХ. Файл открывается в данной программе, подписывается сертификатом руководителя организации отправителя и шифруется сертификатом руководителя организации получателя. Файл с расширением .sig.enc передается по доступным каналам связи по средствам электронной почты. Организация-получатель принимает файл, снимает электронную подпись и расшифровывает файл.

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

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

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

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

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

2. РАЗРАБОТКА ТЕХНИЧЕСКИХ ТРЕБОВАНИЙ И ПОСТАНОВКА ЗАДАЧ ВЫПУСКНОЙ КВАЛИФИКАЦИОННОЙ РАБОТЫ

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

2.1 Требования к характеристикам взаимодействия с внешними системами

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

1) выгрузка данных из автоматизированной информационной системы в файлы с открытыми форматами (XML);

2) выгрузка данных из автоматизированной информационной системы в файлы формата MS Excel (версия 2003 или выше).

2.1.1 Требования к функционированию

Автоматизированная информационная система должна обеспечивать функционирование в штатном режиме круглосуточно, без выходных («режим 24х7») с допустимыми регламентными перерывами на техническое обслуживание и случаями форс-мажора.

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

1) два двухъядерных процессора с тактовой частотой 2 ГГц;

2) объем оперативной памяти 8Гб;

3) объем жёсткого диска 400 Гб.

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

2.1.2 Требования к информационному обеспечению

С целью обеспечения надёжного хранения и быстрой обработки информации в автоматизированной информационной системе должна быть применена система управления базами данных с поддержкой многопроцессорности и кластеров. Должна быть использована система управления базами данных Oracle 10. Требование обусловлено функционированием автоматизированной информационной системы на основе данного вида СУБД и её использованием на сервере.

2.1.3 Требования к программному обеспечению

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

1) операционная система Microsoft Windows 2012 Server;

2) сервер базы данных Oracle 10g;

3) Microsoft.Net Framework 3.5;

4) Internet Information Services 9.0.

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

1) любая операционная система (Microsoft Windows, Unix, Linux, Mac OS и т.п.);

2) веб-браузер, совместимый с соответствующей операционной системой (Internet Explorer версии не ниже 7.0 или Mozilla Firefox версии не ниже 6.0, Google Chrome версии 10 или выше, Opera версия 9 и выше) c поддержкой JavaScript (использование JavaScript должно быть обязательно включено). Рекомендуемым браузером является Mozilla Firefox.

2.1.4 Требования к эргономике и технической эстетике

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

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

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

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

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

«POST.DBF» - сведения о почтовых индексах;

«PUNKT.DBF» - справочник населённых пунктов;

«STREET.DBF» - справочник улиц;

«Gnnuuumm.dbf» - сведения о льготниках.

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

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

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

1) разработка автоматизированной информационной системы в среде разработки Delphi;

2) проведение периода тестирования на наличие ошибок;

3) внедрение в производственные процессы;

4) техническое сопровождение автоматизированной информационной системы.

3. СТРУКТУРА ПРОГРАММОГО КОМПЛЕКСА

Структурно проект, написанный на языке Delphi представляет собой набор файлов с расширениями *.pas, *.dfm, *.dpr/*.dproj и несколько менее важных, служебных типов. Все файлы расположены в одной папке, которая является корневой папкой проекта. Основной отправной точкой всего проекта является файл *.dpr - этот файл содержит код на языке Delphi, описывающий общую структуру проекта - какие файлы он содержит, какие действия выполняются в самый первый момент при запуске приложения и т.п.

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

Модуль состоит из заголовка, в котором после ключевого слова unit указывается имя модуля, и четырех разделов: интерфейса (interface), реализации (implementation), инициализации (initialization) и деинициализации (Finalization),представлено на рисунке 3.1.

1. Unit <Имя модуля>;

2. // Раздел интерфейса Interface

3. Uses <Список модулей>;

4. Const <Список констант>;

5. Туре <Описание типов>;

6. Var <Объявление переменных>;

7. <Заголовки процедур>;

8. <Заголовки функций>;

9. // Раздел реализации

10. Implementation

11. Uses <Список модулей>;

12. Const <Список констант>;

13. Туре <Описание типов>;

14. Var <Объявление переменных>;

15. <Описание процедур>;

16. <Описание функций>;

17. // Раздел инициализации

18. Initialization

19. <Инструкции>

20. // Раздел деинициализации

21. Finalization

22. <Инструкции>

23. end.

Мой проект состоит из следующих основных частей, представлено на рисунке 3.2.

Рисунок 3.2- Основные части программы

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

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

Модуль DataKR содержит компоненты доступа к данным - соединение с СУБД Oracle, компоненты для выполнения запросов и другие компоненты, предназначенные для взаимодействия с СУБД.

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

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

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

Так же в системе присутствуют менее важные не большие модули, перечислим их:

1) DatesDiapKR - Форма ввода диапазона дат (для отчетов, фильтров и т.п);

2) DictEditKR - универсальная форма правки значения простого справочника. Справочники, не требующего своей отдельной формы ввода (например, справочник контрагентов), могут быть изменены через специальный редактор справочников (DictsKR, см.ниже), где им сопоставлена эта форма. Она первоначально не имеет созданных в режиме разработки полей ввода, но, анализирует состав полей и типы данный, генерирует форму правки для каждого справочника индивидуально;

3) DictsKR - Редактор простых справочников;

4) FastSearchKR - Форма быстрого поиска. Во время быстрого поиска в списках документов (и справочников), над заголовком поля появляется строка набора символов. Это на самом деле форма, реализующая как раз быстрый поиск, но «безголовая». Такая форма не имеет стадартного заголовка и представлена только теми элементами, которые есть на ней. На форме FastSearchForm это единственная строка ввода поиска;

5) OpenDBKR - Форма настройки и соединения с базой данных;

6) SearchKR - подробный поиск. Есть во всех картотеках слева от основного списка документов, реализован на панели команд кнопкой «Поиск»;

7) SelectKR - Форма выбора значения из справочника;

8) VislGridKR in 'VislGridKR.pas' - реализует настройку полей каждого списка - какие вывести, какие скрыть, а также определяет цвет столбцов и сортировку. Вызывается щелчком мышь по заголовкам табличной части списка;

9) WaitKR - форма окна ожидания («подождите»);

10) FKR - основные функции, процедуры и типы данных для всего проекта;

11) OptionsKR - форма настройки программы;

12) SotrKR - список сотрудников;

13) UsersKR - списк пользователей системы;

14) UserEditKR - редактирование справочника пользователей;

15) UsrGroupsKR - группы пользователей;

16) CalendarKR - форма календарь;

17) LogKR in 'LogKR.pas -журнал событий системы;

18) MultiSelectKR - форме множественного выбора из списка;

19) LogViewKR - форма просмотра события;

20) LogonKR - форма входа в систему;

21) FilesOSZN - документ загруженных исходных реестров льготников (ОСЗН);

22) FilesOSZNEdit - просмотр/правка строки исходного реестра льготников;

23) RTDList - документ «Реестр льготников». Это основная исходная природная. RTDEdit форма редактирования документа из RTDList;

24) RepPaymentsKR - плательщики;

25) LoadOSZNKR - модуль загрузки и сопоставления льгот;

26) UploadOSZNKR - модуль для выгрузки файлов ОСЗН;

27) RTDRecEdit - форма правки строки по отдельному льготнику;

28) SetStateKR - установка состояния дома при ручном сопоставлении льготников;

29) UpdatesKR - работа с обновлением программы;

30) WordKR - реализованы функции MS Word;

31) OffsetListKR - зачеты (список);

32) OffsetEditKR - Правка зачетов;

33) AboutKR - форма «О программе»;

34) WNewKR - форма «Что нового»;

35) LCList - список лицевых счетов;

36) LCEdit - форма правки лицевого счета.

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

4. ОПИСАНИЕ БАЗЫ ДАННЫХ

У базы данных есть как логические структуры, так и физические структуры, представлено на рисунке 4.1.

Рисунок 4.1- Базы данных, табличные пространства и файлы данных

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

4.1 Табличные пространства

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

4.2 Блоки данных

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

4.3 Экстенты

Следующий уровень логического пространства базы данных - экстент. Экстент - определенное число непрерывных блоков данных Oracle (полученных за одно выделение), которые используются, чтобы хранить определенный тип информации. Блоки данных Oracle в экстенте логически непрерывны, но могут быть физически разбросаны на диске из-за чередования RAID и реализаций файловой системы.

4.4 Сегменты

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

Индексные сегменты: у каждого индекса есть индексный сегмент, который сохраняет все его данные. Для секционированного индекса у каждой секции есть индексный сегмент.

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

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

Есть другие типы сегментов, не упомянутые выше. Есть также объекты схемы, такие как представления, пакеты, триггеры, и т.д., которые не считают сегментами даже при том, что они являются объектами базы данных. Сегменту принадлежит соответствующее выделение дискового пространства. Другие объекты существуют как строки, хранимые в системном сегменте метаданных. Сервер базы данных Oracle динамически выделяет пространство. Когда существующие экстенты сегмента заполняются, добавляются дополнительные экстенты. Поскольку экстенты выделяются по необходимости, экстенты сегмента могут быть, а могут и не быть непрерывными на диске, и они могут принадлежать различным файлам данных одного и того же табличного пространства.

4.5 Описание структуры базы данных

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

Хранение входных данных (копия содержимого DBF-файла) производится в двух таблицах - RT_PEP_OSZNFILE и RT_PEP_OSZNFILEDATA. Эти две таблицы представляют документ «Импорт реестра льготников». Первая - RT_PEP_OSZNFILE - шапка документа, содержит общую информацию - имя файла, дату загрузки, количество записей и другую служебную информацию. Второй - RT_PEP_OSZNFILEDATA - собственно табличная часть документа, представляющая собой копию данных их DBF-файла органов социальной защиты населения[8,10].

Для работы с данными по льготам необходимо их обработать и сопоставить с лицевыми счетами и помещениями в многоквартирных домах. При этом входные загруженные данные необходимо оставить в неизменном виде. Для работы с данными создается другой документ - «Реестр льготников». Он представлен тремя таблицами - RTD_DOC_1002_500_00, RTD_DOC_1002_500_01, RTD_DOC_1002_500_02. Первая из них - шапка документа, вторая содержит все записи реестра льготников и третья - исключенные записи (льготники, которые ранее, в прошлом месяце, имели право на льготу, но в новом реестре они отсутствуют).

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

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

Рисунок 4.2- Схема базы данных Oracle

5. РАЗРАБОТКА АЛГОРИТМОВ

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

Рассмотрим на примере загрузки и сопоставления записей реестра льготников[9].

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

Последние 2 параметра используются в случае, если загрузка была прервана где-то в середине файла и нужно продолжить с прерванного момента, чтобы не обрабатывать все заново. Далее извлекается из архива файл DBF-формата, открывается таблица и создается новый документ «Импорт реестра льготников» (таблица RT_PEP_OSZNFILE), «Реестр льготников» (таблица RTD_DOC_1002_500_00).

Далее описывается цикл по записям в DBF-файле. Сначала создается строка в табличной части документа «Импорт реестра льготников» (RT _PEP _ OSZNFILEDATA), затем происходит сбор строки для табличной части документа «Реестр льготников» (RTD_DOC_1002_500_01)

Сбор происходит по следующим параметрам:

1) поиск соответствия физического лица в соответствующем справочнике по коду СНИЛС;

2) если найдено физическое лицо по СНИЛС, сверяется его адрес по коду КЛАДР (строка могла переехать). Если адрес совпадает - все нормально, иначе привязывается ему новый адрес (какой отделение социальной защиты населения передала);

3) если не найден по СНИЛС, ищется по адресу. Сначала по КЛАДР - если найден, все нормально, берется этот адрес. Если по КЛАДР не найден (или КЛАДР пустой - в муниципальных файлах этого кода нет), ищется по строкам - населенный пункт, улица, дом. Если не найден - ставится признак «Адрес не обслуживается» (не наш дом);

4) если адрес найден (дом наш), но указанной квартиры в доме нет, ставит статус «Не найдено помещение»;

5) если адрес найден и квартира такая есть в базе данных, но сам многоквартирный дом не числится на расчетах в Фонде, ставится статус дома «Адрес не обслуживается»;

6) если адрес совсем не найден, даже с точностью до дома, запись получает статус «Адрес не найден»;

7) для найденных обслуживаемых адресов проверяется категория льгот. Есть вероятность, что появилась новая льгота. При необходимости создается новая запись о наличии льготы (в таблицу rt_pep_person), иначе (при имеющейся льготе), используем ту, что есть сейчас в базе данных. Также возможна ситуация, когда льгота в файле отделения социальной защиты населения не указана, либо указана льгота с кодом, отсутствующая в нашем справочнике. В этом случае запись получает статус «Льгота не определена»;

8) после всех проверок и сопоставлений, если запись не получила статусов в пунктах 5.2.3 - 5.2.7, она получает статус «Успешно», по ней будет рассчитана льгота, согласно проценту категории льготника. Происходит сохранение строки в табличной части документа Реестр льготников» (RTD_DOC_1002_500_01).

Далее цикл заканчивается. Происходит закрытие файла DBF, сохранение оставшихся данных документов «Импорт реестра льготников» и «Реестр льготников» и выход из процедуры.

Далее рассмотрим данный алгоритм на примере блок-схемы, представлена на рисунке 5.1.



Рисунок 5.1- Блок-схема

6. РЕАЛИЗАЦИЯ ПРОГРАММНЫХ МОДУЛЕЙ СИСТЕМЫ

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

1) окно входа в систему. При запуске ярлыка системы выходит меню для ввода логина и пароля. В системе реализована одноуровневая система идентификации. В настоящее время данного уровня защиты вполне достаточно, так как подключение происходит только из локально вычислительной сети организации с белым внешним IP-адресом. Со стороны сервера данный адрес прописан в разрешенных подключениях. В будущем при следующих этапах модернизации будет реализована двухуровневая система идентификации со 128 битным шифрованием, когда программа начнет работать через WEB формы и будет доступна из любой точки по средствам сети Интернет, представлено на рисунке 6.1.

Рисунок 6.1- Окно входа в систему

2) общий вид системы, главное окно, представлено на рисунке 6.2.



Рисунок 6.2- Общий вид

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

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



Рисунок 6.3- Меню действия

Рисунок 6.4- Меню документы

5) меню Справочники. Данное меню создано с заделом на будущее и находится в разработке. Используются только Реестр льготников и Сотрудники. Пункт Реестр льготников позволяет получить всю имеющуюся информацию о любом льготнике в Вологодской области. В пункте Сотрудники реализована функция учета сотрудников, как пользователей системы. Наименование управления, отдела, должности, фамилия, имя, отчество. При входе в программу с правами администратора в данном меню можно посмотреть настройку и разграничение прав пользователей. В будущих обновлениях планируется реализация учета рабочего времени, то есть сколько часов, минут и секунд конкретный пользователь затратил на работу в системе в разрезе по окнам, представлено на рисунке 6.5.



Рисунок 6.5- Меню справочники

6) меню Отчеты находится в разработке.

7) меню Сервис. В пункте Загрузка реестров ОСЗН производится загрузка всех присланных файлов по районо. В пункте Выгрузка рассчитанных льгот для ОСЗН указывается корневая папка для выгрузки готовых файлов обмена для последующей отправки. В последующих обновлениях будут реализованы функции расчетов с банками и другими кредитными учреждениями, ведущими расчеты с абонентами. В пункте Настройка программы указываются общие настройки интерфейса. Во вкладке Обмен данными настраивается путь для выгрузки готовых рассчитанных файлов обмена, представлены на рисунках 6.6, 6.7.

Рисунок 6.6- Меню сервис



Рисунок 6.7- Пункт настройка программы

8) пункт Расчет льгот. При нажатии Действия-Расчет льгот открывается дополнительное окно с параметрами расчета льгот. Указывается период месяц и год, район и вид льготника (федеральные и областные либо муниципальные). При нажатии на кнопку «Выполнить» производится расчет льгот по заданным параметрам, представлены на рисунках 6.8, 6.9, 6.10, 6.11.

Рисунок 6.8- Расчет льгот

Рисунок 6.9- Выбор параметров



Рисунок 6.10

Рисунок 6.11

Ниже представлен характерный фрагмент кода программы. В качестве фрагмента использована процедура выгрузки данных рассчитанных льгот в файл DBF-формата для последующей передачи в органы социальной защиты населения. Так как по требованию органов социальной защиты населения, форматы данных для федеральных/областных и муниципальных льгот различаются, это учтено в процедуре выгрузки. Эталонные пустые таблицы берутся из файлов «OSZN_Header_F.DBF» (федеральный) и OSZN_Header_M.DBF (муниципальный). Файлы расположены в каталоге C:\ProgramData\KR. Интерфейс пользователя, обеспечивающий настройку выгрузки данных, представлен на рисунке 6.12[4-7,11].