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

При создании физической модели сервера баз данных, посредством SQL Server Enterprise Manager, для всех суррогатных ключей было установлено свойство Identy, необходимое для вызова хранимой процедуры аутоинкремента. Для увеличения реактивности системы, индексам, закрепленными за суррогатными ключами присвоено значение Clustered.

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

В качестве СУБД обосновано применение Microsoft SQL Server 2000 Enterprise Edition.

На основании концептуальной модели данных для Microsoft SQL Server 2000 разработана физическая модель данных.

3.1      Разработка архитектуры программного комплекса

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

Описывая систему в терминах архитектурных слоев, удобно воспринимать составляющие ее подсистемы в виде «слоеного пирога». Слой более высокого уровня пользуется службами, предоставляемыми нижележащим слоем, но тот не «осведомлен» о наличии соседнего верхнего слоя. Более того, обычно каждый промежуточный слой «скрывает» нижний слой от верхнего.

Расчленение системы на слои предоставляет целый ряд преимуществ:

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

-          можно выбирать альтернативную реализацию базовых слоев;

-          зависимость между слоями можно свести к минимуму;

-          созданный слой может служить основой для несколько слоев более высокого уровня.

Архитектура проектируемого приложения основывается на трех основных слоях:

-          слой представления

-          слой домена

-          слой источника данных

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

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

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

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

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

NET Framework – это управляемая среда для разработки и исполнения приложений, обеспечивающая контроль типов. Эта среда управляет выполнением программы: она выделяет память под данные и команды, назначает разрешения программе или отказывает в их предоставлении, начинает исполнение приложения и управляет его ходом, а также отвечает за освобождение и повторное использование памяти, занятой ресурсами, более ненужными программе..NET Framework состоит из двух основных компонентов: общеязыковой исполняющей среды и библиотеки классов.NET Framework.

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

Библиотека классов .NET Framework содержит набор полезных типов, разработанных специально для СLR и доступных для многократного использования. Типы, поддерживаемые.NET Framework, являются объектно-ориентированными, полностью расширяемыми и обеспечивают бесшовную интеграцию приложений с .NET Framework.

Конструкция.NET Framework обеспечивает межъязыковую совместимость. Проще говоря, компоненты, реализованные с применением .NET Framework, способны взаимодействовать друг с другом независимо от языка, на котором они написаны. Так, приложение на Visual Basic.NET может обращаться к DLL, написанной на С#, а та, в свою очередь, способна вызвать ресурсы, созданные на управляемом C++ или любом другом NET-совместимом языке. Межъязыковая совместимость поддерживается и для наследования в ООП, например, на основе С#-класса можно объявлять классы в программах на Visual Basic.NET и наоборот.

В качестве языка программирования, при помощи которого, будет реализовываться проектируемая система, выбран язык C#. Этот выбор обусловлен, прежде всего, тем, что данный язык разрабатывался специально для платформы. Net Framework. Он сочетает в себе мощь C++ и простоту Visual Basic.

Для доступа к данным используется набор библиотек ADO. Net.

ADO. Net – это набор библиотек, поставляемых с Microsoft. Net Framework и предназначенный для взаимодействия с различными хранилищами данных из. Net-приложений. Библиотека ADO. Net включают классы для подсоединения к источнику данных, выполнения запросов и обработки их результатов. Кроме того, ADO. Net можно использовать в качестве надежного, иерархически организованного, отсоединенного кэша данных для автономной работы с данными. Главный отсоединенный объект, DataSet, позволяет сортировать, осуществлять поиск, фильтровать, сохранять отложенные изменения и перемещаться по иерархическим данным. Кроме того, объект DataSet включает ряд функций, сокращающих разрыв между традиционным доступом к данным и программированием с использованием XML.

Для взаимодействия между удаленными узлами, на которых расположены компоненты проектируемого приложения, используется технология. Net Remoting /17, 22/.

NET Remoting – это объектно-ориентированная архитектура для поддержки распределенных приложений в Microsoft .NET. Подобно тому как .NET Framework заменяет СОМ в качестве средства разработки компонентов .NET Remoting заменяет DCOM в качестве средства создания распределенных приложений на основе.NET Framework. Более того .NET Remoting является основой для .NET Web-сервисов. Таким образом, понимание основ .NET Remoting совершенно необходимо для разработки на основе .NЕТ Framework распределенных приложений, в том числе для Интернета.

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

3.2      Разработка прототипов пользовательского интерфейса

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

На рисунке 3.1 представлена среда автоматизированной системы бюджетного процесса.

Рисунок 3.1 Среда автоматизированной системы бюджетного процесса

Пользовательская среда автоматизированной системы бюджетного процесса состоит из нескольких основных частей:

-          главное меню приложения;

-          строка навигации по доступным проектам бюджета;

-          панель навигации;

-          основная часть.

Главное меню приложения служит для доступа ко всем функциям системы.

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

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

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

Структура главного меню приложения представлена в таблице 19.

Таблица 19 Структура главного меню

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

3.3      Проектирование структуры программного

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

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

Пользователь вводит логин и пароль своей учетной записи и нажимает на кнопку «Войти» формы AuthForm. Эта форма в свою очередь отправляет сообщение Connect управляющему объекту ClientImpl, который представляет собой клиентское приложение. Объект ClientImpl вызывает метод Connect объекта-сервера ServerImpl и передает себя в качестве параметра этого сообщения. ServerImpl проверяет наличие в системе зарегистрированной учетной записи, с введенными пользователем логином и паролем, при помощи управляющего объекта SecurityManager. Если учетная запись с введенными пользователем данными зарегистрирована в системе, то сервер регистрирует сессию для клиентского приложения и возвращает управление клиентскому приложению.

Рисунок 3.2 Аутентификация пользователя в системе

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

Администратор вводит на форме RegisterUserForm необходимые для регистрации нового пользователя данные, а затем запускает процедуру регистрации нового пользователя в системе. Форма RegisterUserForm передает сообщение Register управляющему объекту UserManager вместе с введенными администратором данными.

UserManager проверяет корректность введенных данных и добавляет нового пользователя в систему.

Рисунок 3.3 – Регистрация нового пользователя в системе

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

Пользователь вводит свой старый пароль и новый, и запускает процедуру смены пароля. Форма ChangePasswordForm передает сообщение ChangePass управляющему объекту UserManager, который в свою очередь при помощи SecureManager проверяет наличие у пользователя права на смену пароля на текущей учетной записи. Если у пользователя это право имеется, то SecureManager посылает сообщений объекту Users, который меняет пароль на учетной записи.

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

Рисунок 3.4 Смена пароля на учетной записи пользователя

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

Дадим некоторые пояснения по структуре приложения.

Центральными классами являются ServerImpl и ClientImpl, которые соответственно представляют серверную и клиентскую часть приложения. Первый объект реализует интерфейс IServer, а второй IClient. Клиентская часть приложения имеет доступ к серверу только через интерфейс IServer. Такая реализация продиктована требованиями безопасности.

При проектировании класса ServerImpl использовался паттерн Singleton, что гарантирует существование единственного экземпляра этого класса в течение всего времени работы программы.

Класс ServerImpl управляет загрузкой подключаемых модулей и предоставляет доступ клиентскому коду к управляющим объектам.

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

Все управляющие объекты реализуют интерфейс IManager и доступ к ним осуществляется по названию менеджера через класс ServerImpl.

Рассмотрим назначение основных менеджеров.

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

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

UserManager служит для управления пользователями. Он позволяет регистрировать новые учетные записи пользователей, удалять их и изменять регистрационные данные.

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

DatabaseManager управляет подключениями к базе данных, а также транзакциями.

DALManager управляет компонентами доступа к данным. При помощи этого менеджера в системе регистрируются DAL‑компоненты, которые осуществляют сохранение объектов в базе данных, их модификацию и удаление, а также построение объектов из данных сохраненных в базе.

BudgetManager управляет проектами бюджета. Позволяет создавать, модифицировать и утверждать проекты бюджета.

BCAdminManager управляет администраторами бюджетных средств. Позволяет назначать и удалять администраторов бюджетных средств.

BCStewardManager управляет распорядителями бюджетных средств. Позволяет назначать и удалять распорядителей бюджетных средств.

SFDAdminManager управляет администраторами источников финансирования дефицита. Позволяет назначать и удалять администраторов источников финансирования дефицита.

RevenueEstimateManager управляет сметами доходов администраторов бюджетных средств.

OutlayEstimateManager управляет сметами расходов распорядителей бюджетных средств.

SFDEstimateManager управляет сметами источников финансирования дефицита бюджета.

RevenueEnquiryManager управляет справками-уведомлениями по доходам.

OutlayEnquiryManger управляет справками-уведомлениями по расходам.

SFDEnquiryManager управляет справками-уведомлениями по источникам финансирования дефицита бюджета.

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

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

Разработанные классы объединены в компоненты, представленные в таблице 20.

Таблица 20 Компоненты автоматизированной системы бюджетного процесса

3.4      Тестирование программной системы

Процесс тестирования представляет собой эксплуатацию приложения в контролируемых условиях и изучение полученных результатов /31/. При этом проверяется работа приложения с нормальными и ошибочными данными и событиями. Следует изучить и реакцию на неожиданные ситуации.

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

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

Первое испытание направлено на тестировании работы автоматизированной системы бюджетного процесса по сохранению вводимых данных при вводе справок-уведомлений по доходам.

Рисунок 5.1 Состояние таблицы RevenueEnquirys до внесения справки в систему

Рисунок 5.2 Состояние таблицы RevenueEnquiryRows до внесения справки в систему

На рисунках 5.3 и 5.4 представлено состояние этих же таблиц после внесения справки-уведомления.

Рисунок 5.3 Состояние таблицы RevenueEnquirys после внесения справки в систему

Рисунок 5.4 Состояние таблицы RevenueEnquiryRows после внесения справки в систему

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

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

Вторым типом тестов, которые проводились с системой, являются тесты на корректность бизнес-логики приложения.

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

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

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

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

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

В качестве языка программирования, при помощи которого, реализована проектируемая система, выбран язык C#.

Для доступа к данным используется технология ADO. Net, которая представляет собой набор библиотек, поставляемых с Microsoft. Net Framework, и предназначена для взаимодействия с различными хранилищами данных из. Net-приложений.

Для взаимодействия между удаленными узлами, на которых расположены компоненты проектируемого приложения, используется технология. Net Remoting, которая является объектно-ориентированной архитектурой для поддержки распределенных приложений в Microsoft.NET.

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

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

Программное обеспечение информационной системы разработано на языке C#, проведено тестирование системы.

4.1      Выбор жизненного цикла разработки информационной системы

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2      Определение цели и области действия программного проекта

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

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

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

Относительно данного проекта можно сказать, что он будет:

-          внутренним;

-          предназначен для автоматизации процесса планирования бюджета;

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

Проект не будет:

-          предназначаться для использования всеми отделами администрации Новоегорлыкского сельского поселения;

-          предназначенным для обеспечения доступа к информации не из администрации.

4.3      Создание структуры пооперационного перечня работ

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

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

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

-          выполняется разработка программного обеспечения;

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

-          обеспечивается поддержка для всех действий, выполняемых в ходе осуществления проекта;

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

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

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

Рисунок 4.1 – Схема декомпозиции работ

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

4.4      Идентификация задач и действий

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

В качестве программы управления проектами была выбрана Microsoft Office Project 2007. В MS Project предусмотрен обширный набор возможностей по гибкому конфигурированию вида ленточных диаграмм.

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

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

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

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

Проект представлен в виде графика Ганта на рисунке 4.2.

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

Визуально диаграмма Ганта представляет собой последовательность действий, выполняемых в рамках данного проекта.

Рисунок 4.2 Диаграмма Ганта. Лист 1

4.5      Распределение ресурсов проекта

Для управления ресурсами проекта в MS Project имеется коллекция представлений проекта, которые специально ориентированы на решение задач данного типа.

Процесс назначения ресурсов задачам проекта называют ресурсным планированием проекта.

Ресурсное планирование позволяет:

-          оценить потребность в ресурсах конкретного типа;

-          спланировать рациональное распределение потребности в ресурсах во времени;

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

-          оценить суммарную стоимость проекта;

-          контролировать расходование ресурсов при реализации проекта.

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

Ресурсы проекта представлены в сводной таблице загрузки ресурсов.

Рисунок 4.4 – Сводная таблица загрузки ресурсов

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

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

Рисунок 4.5 – Детальная таблица загрузки ресурсов

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

Уровень интеграции периодов реализации проекта может определятся пользователем.

Статистика проекта показывает дату начала и окончания проекта, его длительность, количество рабочих часов, стоимость работ.

Рисунок 4.6 – График использования ресурсов специалиста по вариантам использования

Рисунок 4.7 – Статистика проекта

Таким образом, общая стоимость работ составляет 93900 рублей.

4.6      Расписание проектных работ

Сетевая диаграмма представляет совокупность операций проекта в виде логической схемы типа вершинного графа. Фрагмент сетевой диаграммы представлен на рисунке 4.8.

Рисунок 4.8 Фрагмент сетевой диаграммы

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

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

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

В сетевой диаграмме содержится следующая информация:

-          название действия или идентификатор узла;

-          время наискорейшего начала производственного этапа, которое определяется на основании времени завершения предыдущего действия или какого-либо другого ограничения;

-          время быстрейшего завершения действия;

-          продолжительность этапа;

-          максимально возможный срок, когда действие может быть начато, не затронув стадию следующего действия;

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

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

4.7      Оценка размера и возможности повторного использования ПО

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

При выполнении операции определения размеров используются пять весьма полезных и широко известных технологий:

-          подсчет сток кода в качестве единиц оценки размера;

-          подсчет функциональных точек в качестве единиц оценки размера;

-          подсчет точек свойств в качестве единиц оценки размера;

-          применение блиц-модели;

-          применение модели Wideband Delphi.

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

В разработанной программной системе использовался архитектурный подход изоляции слоев приложения и технология паттернов проектирования, что закладывает предпосылки повторного использования кода. Так серверная и клиентская части приложения взаимодействуют через интерфейсы IServer и IClient. При проектировании класса ServerImpl использовался паттерн Singleton, что поддерживает режим повторного использования кода. Подключаемые модули поставляются в виде динамически подключаемых библиотек, которые могут использоваться в других проектах. В каждой библиотеке определен один или несколько классов реализующих интерфейс взаимодействия. Все управляющие объекты реализуют интерфейс IManager и доступ к ним осуществляется по названию менеджера через класс ServerImpl.

4.8      Оценка экономической эффективности проекта

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

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

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

-          повысить прозрачность процессов управления;

-          упростить и ускорить процесс составления проекта бюджета.

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

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

Центральным показателем является показатель NPV – текущая стоимость денежных потоков за вычетом текущей стоимости денежных оттоков. Это обобщенный конечный результат инвестиционной деятельности в абсолютном измерении.

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

Формула расчета чистого приведенного дохода:

где  – чистый приведенный доход;

n – месяц;

  величина денежного потока в течение n месяцев, рубли;

– ставка дисконтирования;

 – стартовые инвестиции, рубли;

Формула для расчета величины денежного потока:

где  – величина денежного потока, рубли;

 – выгоды от реализации проекта;

 – суммарные ежемесячные затраты на реализацию проекта;

Затраты на реализацию проекта в первом месяце составляют 20000 рублей, во втором – 25000 рублей, в третьем – 30000 рублей, в четвертом т 19000 рублей. Ставка дисконтирования равна 10,5%.

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

Таблица 21 Денежный поток по каждому месяцу

NPV=2170 рублей.

Поскольку величина чистой текущей стоимости 2170 рублей, то есть NPV > 0, то проект можно принять.

Коэффициент возврата инвестиций ROI позволяет оценить прибыльность инвестиций, вложенных в проект.

Формула для расчета коэффициента возврата инвестиций:

где  – чистый приведенный доход;

 – стартовые инвестиции, рубли;

При ROI > 100% – инвестиции прибыльны, при ROI < 100% инвестиции убыточны.

.

Поскольку ROI = 102%, то есть ROI > 100% – инвестиции прибыльны.

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

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

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

Построение диаграмм позволяет наглядно представить график работ, изобразить последовательность действий, выполняемых в рамках данного проекта.

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

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

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

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

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

Список используемых источников

1.    Анализ требований и создание архитектуры решений на основе Microsoft.NET. Учебный курс MSCD/Пер. с англ. М.: Издательско-торговый дом «Русская редакция», 2004. – 416 с.: ил.

2.    Бизнес-правила в среде разработки и моделирования. Проверено 19.01.2008.

3.    Богданов, В. Управление проектами в Microsoft Project 2002 / В. Богданов. − СПб.: Питер, 2003. – 604 с.

4.    Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++./ Г. Буч. – М.: «Бином», СПб: «Невский диалект», 2001. – 560 с.

5.    Бюджетный кодекс Российской Федерации. Постатейный научно-практический комментарий. Второе, дополнительное издание. – М: Агентство «Библиотечка «Российской газеты», 2006 – 288 с.

6.    Бюджетные финансовые технологии. Проверено 25.04.2008.

7.    Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. / А.М. Вендров. Проверено 05.02.2008.

8.    Вигерс, К. Разработка требований к программному обеспечению. / К. Вигерс. – М.: Изд.-торг. Дом «Русская Редакция», 2004. – 576 с.

9.    Гамма, Э. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. – СПб: «Питер», 2001. – 368 с.

10. Грехэм, И. Объектно-ориентированные методы. Принципы и практика / И. Грехэм – М.: «Вильямс», 2004. – 1024 с.

11. Коберн, А. Быстрая разработка программного обеспечения.: Пер. с англ. / А. Коберн. – М.: ЛОРИ, 2002. – 462 с.

12. Коберн, А. Современные методы описания функциональных требований к системам.: Пер. с англ. / А. Коберн. М.: ЛОРИ, 2002. – 364 с.

13. Конноли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика./ Т. Конноли, К., Бегг, А. Страчан. – М.: «Вильямс», 2001. – 632 с.

14. Концептуальное проектирование реляционный баз данных с использованием языка UML. . Проверено 05.02.2008.

15. Ларман, К. Применение UML и шаблонов проектирования. 2-е издание / К. Ларман – М.: «Вильямс»,  2002. – 496 с.

16. Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. / Д. Леффингуэлл, Д. Уидриг. – М.: «Вильямс», 2002. – 462 с.

17. Маклин, С. Microsoft.NET Remoting.: Пер. с англ. / С. Маклин, Дж. Нафтел, К. Ульямс. – М.: Издательско-торговый дом «Русская редакция», 2003. – 384 с.

18. Мацяшек Л.А. Анализ требований к проектированию систем. Разработка информационных систем с использованием UML / Л.А. Мацяшек. М.: Изд. Дом «Вильямс», 2002. – 432 с.

19. Мюллер Р.Дж. Базы данных и UML / Р. Дж. Мюллер. М: «ЛОРИ», 2002. – 420 с.

20. Нейбург, Э. Дж. Проектирование баз данных с помощью UML. / Э.Дж. Нейбург, Р.А. Максимчук. – М.: «Вильямс», 2002. – 420 с.

21. Олифер, В.Г. Основы сетей передачи данных./ В.Г. Олифер, Н.А. Олифер. Проверено 19.01.2008.

22. Описание предметной области с использованием UML при разработке программных систем. . Проверено 19.01.2008.

23. Проектирование и реализация баз данных Microsoft SQL Server 2000. Учебный курс MCAD, MCSE, MCDBA/Пер. с англ. – 2-е изд., испр. – М.: Издательско-торговый дом «Русская редакция», 2003. – 512 стр.: ил.

24. Полякова, Л.Н. Основы SQL БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий. / Л.Н. Полякова. ИНТУИТ.ру, – 2007. – 462 с.

25. Рамбо, Дж. UML: специальный справочник. / Дж. Рамбо, А. Якобсон, Г. Буч. – СПб: «Питер», 2001. – 632 с.

26. Разработка Windows-приложений на Microsoft Visual Basic. Net и Microsoft Visual C#.Net. Учебный курс MCAD, MCSD/Пер. с англ. – М.: Издательско-торговый дом «Русская редакция», 2003. – 512 стр.: ил.

27. Розенберг, Д. Применение объектного моделирования с использованием UML и анализ прецедентов. / Д. Розенберг, К. Скотт. М.: «ДМК Пресс», 2002. – 436 с.

28. Скрипкин, К.Г. Экономическая эффективность информационных систем. К.Г. Скрипкин. – М.: ДМК Пресс, 2002. – 420 с.

29. Смирнова, Г.Н. Проектирование экономических информационных систем: Учебник Г.Н. Смирнова, А.А. Сорокин Под ред. Ю.Ф. Тельнова. − М.: Финансы и статистика, 2003. – 512 с.

30. Тамре, Л. Введение в тестирование программного обеспечения: Пер. с англ. / Л. Тамре. – М.: Издательский дом «Вильямс», 2003. – 314 с.

31. Уилсон С. Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD/Пер. с англ. – 2-е изд., испр. С. Уилсон, Б. Мейплс, Т. Лэндгрейв. – М.: Издательско-торговый дом «Русская редакция», 2002. 736 стр.: ил.