Рефераты

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

Рисунок 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 Сущности бюджетной классификации

Наименование

Описание

Budgetclassification Бюджетная классификация
Revenuegroup Группа доходов
Revenuesubgroup Подгруппа хододов
Revenueclause Статья доходов
Revenuesubclause Подстатья доходов
Revenueeconomicclass Класс экономической классификации доходов
Revenueprogram Программа доходов
Element Элемент бюджетной классификации
Revenue Доход
Outlaysection Раздел расходов
Outlaysubsection Подраздел расходов
Outlayclause Целевая статья расходов
Outlayclass Класс экономической классификации расходов
Outlayprogram Программа расходов
Outlaysort Вид расходов
Outlay Расход
Sfdgroup Группа бюджетной классификации источников финансирования дефицита
Sfdsubgroup Подгруппа бюджетной классификации источников финансирования дефицита
Sfdclause Статья бюджетной классификации источников финансирования дефицита
Sfdsubclause Подстатья бюджетной классификации источников финансирования дефицита
Sfdprogram программа источников финансирования дефицита
Sfdeconomicclass Класс экономической классификации источников финансирования дефицита
Sfd Источник финансирования дефицита

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

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


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

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

Наименование

Описание

Legalentity Юридическое лицо
Bcsteward Распорядитель бюджетных средств
Outlayestimate Смета расходов
Outlayestimateitem Строка сметы расходов
Bcadministrator Администратор бюджетных средств
Revenueestimate Смета доходов
Revenueestimateitem Строка сметы доходов
Sfdadministrator Администратор источников финансирования дефицита
Sfdestimate Смета источников финансирования дефицита
Sfdestimateitem Строка сметы источников финансирования дефицита
Enquiry Справка-уведомление на изменение выделенных ассигнований

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


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

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

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

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

Наименование

Описание

User Пользователь автоматизированной системы бюджетного процесса
Faleader Начальник финансового управления
BDManager Специалист бюджетного отдела
DPRManager Специалист отдела прогнозирования доходов и налоговой политики
BudgetProject Проект бюджета
Settlement Поселение для которого составляется проект бюджета

Рисунок 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 представлена часть концептуальной модели, которая отображает бюджетную классификацию источников финансирования дефицита бюджета.

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

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


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

Класс

Атрибут

Описание

1 2 3
ГруппаИФД Группа источников финансирования дефицита
Код Код группы источников финансирования дефицита
Наименование Наименование группы источников финансирования дефицита
ПодгрИстФинДеф Подгруппа источников финансирования дефицита
Код Код подгруппы источников финансирования дефицита
Наименование Наименование подгруппы источников финансирования дефицита
СтатьяИФД Статья источников финансирования дефицита
Код Код статьи источников финансирования дефицита
Наименование Наименование статьи источников финансирования дефицита
ПодстатьяИФД Подстатья источников финансирования дефицита
Код Код подстатьи источников финансирования дефицита
Наименование Наименование подстатьи источников финансирования дефицита
ПрогИФД Программа источников финансирования дефицита
Код Код программы источников финансирования дефицита
Наименование Наименование программы источников финансирования дефицита
ЭкономКлассИФД Экономических класс источников финансирования дефицита
Код Код экономического класса источников финансирования дефицита
Наименование Наименование экономического класса источников финансирования дефицита
ИФД Источник финансирования дефицита
Код Код источника финансирования дефицита

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


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

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

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

Класс

Атрибут

Описание

1 2 3
Проект Бюджета Проект бюджета
Год Год на который составляется проект бюджета
Статус Текущее состояние проекта бюджета
Наименование Название проекта бюджета
Юр Лицо Юридическое лицо
ИНН Индивидуальный номер налогоплательщика
Наименование Название организации
Адрес Адрес организации
Администратор Администратор бюджетных средств
Код Код администратора бюджетных средств
Смета Доходов Смета доходов администратора бюджетных средств
Номер Номер документа
Статус Текущее состояние сметы доходов
Строка Смет Доход Строка табличной части сметы доходов
Сумма Предполагаемых объем доходов
Примечание Примечание служит для любых пояснений

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

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

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


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

Класс

Атрибут

Описание

1 2 3
Распорядитель Распорядитель бюджетных средств
Код Код распорядителя бюджетных средств
Смета Расходов Смета расходов распорядителя бюджетных средств
Номер Номер документа
Статус Текущее состояние сметы расходов
Строка Смет Расх Строка табличной части сметы расходов
Сумма Предполагаемый объем расходов
Примечание Комментарии
Справ Уведомление Расходы Справка-уведомление по расходам
Номер Номер документа
Дата Дата внесения
Примечание Комментарии к справке-уведомлению
Статус Текущее состояние справки-уведомления
Строка Спр Увед Расх Строка табличной части справки-уведомления по расходам
Сумма Объем средств, на который увеличиваются или уменьшаются расходы
Примечание Комментарии
Поселение Городское или сельское поселение
Код Код поселения
Наименование Название поселения
Тип Документа Тип документа основания для справок-уведомлений
Код Код типа документа
Наименование Название типа документа

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

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


© 2010 Собрание рефератов