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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 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. Аттестация требований

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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