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

Рисунок 1.18 Варианты использования прогнозирования доходов и налоговой политики

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

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

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

Рисунок 1.19 – Варианты использования общие для всех пользователей

В процессе выполнения прецедента «Аутентификация в системе» пользователь осуществляет вход в систему посредством ввода логина и пароля.

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

1.4.2   Формирование нефункциональных требований

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

К операционной среде, в которой должна работать проектируемая система, предъявляются следующие требования:

-          компьютер, на котором размещается серверная часть приложения, должен работать под управлением операционной системы не ниже Microsoft Windows Server 2000. Также на компьютере должны быть установленные компоненты. Net Framework 2.0;

-          компьютеры, на которых размещается клиентская часть приложения, должны работать под управлением операционной среды не ниже Microsoft Windows XP Professional Edition SP2 с установленными компонентами. Net Framework 2.0;

-          проектируемая система должна допускать доступ пользователей через корпоративную сеть интранет и Интернет.

К интерфейсу пользователя предъявляются следующие требования:

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

-          формы должны быть снабжены контекстной справкой.

К производительности системы предъявляются следующие требования:

-          система должна обслуживать одновременно до 100 пользователей в период пиковой активности с 9:00 до 18:00 по местному времени;

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

-          система должна быть доступна пользователям корпоративной сети интранет и клиентам удаленного доступа по коммутируемой линии 99% времени между 0:00 и 24:00 семь дней в неделю.

К безопасности, проектируемой системы, предъявляются следующие требования:

-          все сетевые транзакции должны быть зашифрованы;

-          функции системы становятся доступными пользователю только после его аутентификации в системе;

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

Система также должна позволять экспорт выходных документов в форматы Microsoft Word и Excel.

1.5    Спецификация состояний системы

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

Рисунок 1.20 – Объекты бюджетной классификации

Таблица 1 Сущности бюджетной классификации

На рисунке 1.21 представлены объекты и сущности участвующие в процессах составления смет доходов, расходов и источников финансирования дефицита.

В таблице 2 представлена расшифровка объектов и сущностей, участвующих в процессах составления смет доходов, расходов и источников финансирования дефицита.

Рисунок 1.21 Объекты и сущности процесса составления смет доходов, расходов и источников финансирования дефицита

Таблица 2 Объекты и сущности участвующие в процессах составления смет доходов, расходов и источников финансирования дефицита

На рисунке 1.22 представлены субъекты и объекты, участвующие в процессе составления проекта бюджета.

Рисунок 1.22 Объекты и субъекты процесса составления проекта бюджета

В таблице 3 представлена расшифровка субъектов и объектов, участвующих в процессе составления проекта бюджета.

На рисунке 1.23 представлены объекты, участвующие в процессе составления консолидированного бюджета территории.

Таблица 3 Субъекты и объекты, участвующие в процессе составления проекта бюджета

Рисунок 1.23 Объекты процесса составления проекта бюджета

Объект ConsolidatedBudgetProject представляется проект консолидированного бюджета территории.

1.6      Аттестация требований

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

Существует набор методов аттестации, которые можно использовать как вместе, так и по отдельности:

-          обзор требований – процесс просмотра системной спецификации на предмет неточных описаний и ошибок;

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

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

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

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

Прототипы пользовательского интерфейса рассматриваются в п. 3.2, а тестовые сценарии – п. 3.4 дипломного проекта.

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

Существует две основных методологии проектирования:

-          методология структурного проектирования;

-          методология объектно-ориентированного проектирования.

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

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

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

SADT – Structured Analysis and Design Techniques – описывает модели и функциональные диаграммы;

DFD – Data Flow Diagrams – диаграммы потоков данных;

ERD – Entity Relationship Diagrams – диаграммы «сущность – связь».

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

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

Для реализации проекта был выбран объектно-ориентированный подход в силу следующих факторов:

-          возможность повторного использования кода;

-          повышение безопасности кода за счет инкапсуляции;

-          гибкость при модификации и расширении системы;

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

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

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

В качестве методологии проектирования обосновано применение объектно-ориентированного подхода.

2.1      Разработка концептуальной модели данных

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

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

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

Рисунок 2.1 Концептуальная модель бюджетной классификации доходов

В таблице 4 представлено описание классов и их атрибутов концептуальной модели бюджетной классификации доходов.

Таблица 4 Описание классов концептуальной модели бюджетной классификации доходов

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

Рисунок 2.2 – Концептуальная модель бюджетной классификации расходов

В таблице 5 представлено описание классов и их атрибутов концептуальной модели бюджетной классификации расходов.

Таблица 5 Описание классов концептуальной модели бюджетной классификации расходов

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

В таблице 6 представлено описание классов и их атрибутов концептуальной модели бюджетной классификации источников финансирования дефицита.

Рисунок 2.3 Концептуальная модель бюджетной классификации источников финансирования дефицита

Таблица 6 Описание классов концептуальной модели бюджетной классификации источников финансирования дефицита

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

Рисунок 2.4 Объекты, участвующие в процессах составления смет доходов администраторов бюджетных средств и доходной части проекта бюджета

В таблице 7 представлено описание классов объектов, участвующих в процессах составления смет доходов администраторов бюджетных средств и доходной части проекта бюджета.

Таблица 7 Описание классов объектов, участвующих в процессах составления смет доходов администраторов бюджетных средств и доходной части проекта бюджета

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

Рисунок 2.5 – Объекты, участвующие в процессах составления смет расходов распорядителей бюджетных средств и расходной части проекта бюджета

В таблице 8 представлено описание классов объектов, участвующих в процессах составления смет расходов распорядителей бюджетных средств и расходной части проекта бюджета.

Таблица 8 Описание классов объектов, участвующих в процессах составления смет расходов распорядителей бюджетных средств и расходной части проекта бюджета

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

Страницы: 1, 2, 3, 4