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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Разработка информационного обеспечения

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

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

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

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

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

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

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

Класс	Атрибут	Описание
1	2	3
Бюджетная Классификация	Бюджетная классификация РФ
Год	Год для которого действительна бюджетная классификация
Группа Доходов	Группа доходов
Код	Код группы доходов
Наименование	Наименование группы доходов
Подгруппа Доходов	Подгруппа доходов
Код	Код подгруппы доходов
Наименование	Наименование подгруппы доходов
Статья Доходов	Статья бюджетной классификации доходов
Код	Код статьи доходов
Наименование	Наименование статьи доходов
Прог Доход	Программа бюджетной классификации доходов
Код	Код программы доходов
Наименование	Наименование программы доходов

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

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

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

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

Класс	Атрибут	Описание
1	2	3
Раздел Расходов	Раздел бюджетной классификации расходов
Код	Код раздела расходов
Наименование	Наименование раздела расходов
Подразд Расходов	Подраздел бюджетной классификации расходов
Код	Код подраздела расходов
Наименование	Наименование подраздела расходов
ЦСР	Целевая статья расходов
Код	Код целевой статьи расходов включающий программный срез
Наименование	Наименование целевой статьи расходов
Вид Расходов	Вид расходов
Код	Код вида расходов
Наименование	Наименование вида расходов
Эконом Класс Расходов	Экономический класс расходов
Код	Код экономического класса расходов
Наименование	Наименование экономического класса расходов
Расход	Расход
Код	Код расхода

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