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

/>Введение
 
Мировой и российский опыт говорит о том,что применение современных информационных решений позволяет значительноповысить эффективность работы государственных структур, обеспечить прозрачностьпроцессов управления.
Наиболее ответственным разделом государственногоуправления является управление финансами, в котором, в свою очередь, первоеместо занимает комплекс проблем, связанных с бюджетом – его формированием иутверждением, исполнением, анализом и контролем финансовых потоков. Весь этоткомплекс действий, регламентированный законодательством РФ и упорядоченный вовремени, принято называть бюджетным процессом. Одной из особенностей бюджетногопроцесса является то, что он регулируется по одним составляющим федеральнымзаконодательством, нормативными и инструктивными документами Министерствафинансов РФ, по другим – законодательством субъектов РФ и нормативными актамимуниципалитетов, под которые, как правило, инструктивных материалов создаетсякрайне мало.
Возможно, как раз поэтому автоматизациябюджетного процесса силами специализированных ИТ-компаний охватывала долгоевремя именно процессы исполнения бюджета в регионах.
Однако специалисты финансовых органовнуждаются в комплексной автоматизации бюджетного процесса. И, несмотря на точто на рынке систем бюджетирования для предприятий имеется целый ряд неплохозарекомендовавших себя продуктов, бюджетный процесс в региональных финансовыхорганах в принципе другой, и требует специальных методов и инструментов.
Финансовое управление администрацииНовоегорлыкского сельского поселения поставило перед информационным отделомзадачу автоматизации процесса планирования бюджета, определив ее как создание механизма,обеспечивающего многовариантность расчетов проекта бюджета, а такжеоперативность и точность расчетов параметров бюджета с формированиемдокументов.
Таким образом, задача была поставленасразу достаточно широко – речь идет о создании централизованной системыуправления бюджетным процессом, предоставляющей сотрудникам финансовогоуправления оперативный распределенный доступ к бюджетным данным, возможностьсопоставления этих данных за различные временные периоды и по разным объектам. Приэтом, система должна позволять оперативно вносить изменения и обеспечиватьодновременную работу большого количества пользователей.
 
 
/>/>1.  Разработка требований к программномуобеспечению
/>/>/> 1.1     Анализ предметной области
Целью программного комплекса, разработанного в рамках дипломногопроекта, является автоматизация деятельности Финансового управленияАдминистрации Новоегорлыкского сельского поселения в части организации бюджетного процесса иконтроля над его исполнением на территории Новоегорлыкскогосельского поселения.
Для того чтобы внести ясность в понятие бюджетный процесс,воспользуемся определением, данным этому термину в Бюджетном кодексе РоссийскойФедерации.
Бюджетный процесс – регламентируемая нормами права деятельностьорганов государственной власти, органов местного самоуправления и участниковбюджетного процесса по составлению и рассмотрению проектов бюджетов, проектовбюджетов государственных внебюджетных фондов, утверждению и исполнению бюджетови бюджетов государственных внебюджетных фондов, а также по контролю за ихисполнением /5/.
В структуре законодательства Российской Федерации регулирующегобюджетный процесс можно выделиться следующие правовые акты:
-         Бюджетный кодекс Российской Федерации ифедеральные законны о федеральном бюджете на соответствующий год принятые всоответствии с ним;
-         законы субъектов Российской Федерации обюджетах субъектов Российской Федерации на соответствующий год;
-         нормативные правовые актыпредставительных органов местного самоуправления о местных бюджетах насоответствующий год;
-         иные федеральные законы, законысубъектов Российской Федерации и нормативные правовые акты представительныхорганов местного самоуправления, регулирующие правоотношения, возникающие в бюджетномпроцессе.
Основными принципами бюджетной системы Российской Федерацииявляются:
-         единство бюджетной системы РоссийскойФедерации;
-         разграничение доходов и расходов междууровнями бюджетной системы Российской Федерации;
-         самостоятельность бюджетов;
-         равенство бюджетных прав субъектовРоссийской Федерации и муниципальных образований;
-         полнота отражения доходов и расходовбюджетов;
-         сбалансированность бюджета;
-         эффективность и экономичностьиспользования бюджетных средств;
-         гласность;
-         достоверность бюджета;
-         адресность и целевой характер бюджетныхсредств.
Принцип единства бюджетной системы Российской Федерации означаетединство бюджетного законодательства Российской Федерации, принциповорганизации и функционирования бюджетной системы Российской Федерации, формбюджетной документации и отчетности, бюджетной классификации бюджетной системыРоссийской Федерации, санкций за нарушение бюджетного законодательстваРоссийской Федерации, единый порядок установления и исполнения расходныхобязательств, формирования доходов и осуществления расходов бюджетов бюджетнойсистемы Российской Федерации и бюджетных учреждений.
Принцип разграничения доходов и расходов между бюджетами разныхуровней означает закрепление в соответствии с законодательством РоссийскойФедерации доходов и расходов за бюджетами бюджетной системы РоссийскойФедерации, а также определение полномочий органов местного самоуправления поформированию доходов, установлению и исполнению расходных обязательств.
Принцип равенства бюджетных прав субъектов Российской Федерации,муниципальных образований означает определение бюджетных полномочий органовгосударственной власти субъектов Российской Федерации и органов местногосамоуправления, установление и исполнение расходных обязательств. Формированиеналоговых и неналоговых доходов бюджетов субъектов Российской Федерации иместных бюджетов, определение объема, форм и порядка предоставлениямежбюджетных трансфертов в соответствии с едиными принципами и требованиями,установленными Бюджетным кодексом Российской Федерации.
Принцип сбалансированности бюджета означает, что объемпредусмотренных бюджетом расходов должен соответствовать суммарному объемудоходов бюджета и поступлений из источников финансирования его дефицита.
Принцип эффективности и экономности использования бюджетныхсредств означает, что при составлении и исполнении бюджетов уполномоченныеорганы и получатели бюджетных средств должны исходить из необходимостидостижения заданных результатов с использованием наименьшего объема средств илидостижения наилучшего результата с использованием определенного бюджетом объемасредств.
Принцип гласности означает обязательное опубликование в открытойпечати утвержденных бюджетов и отчетов об их исполнении, а также обязательнуюоткрытость для общества и средств массовой информации процедур рассмотрения ипринятия решения по проектам бюджетов.
Принцип достоверности бюджета означает надежность показателейпрогноза социально-экономического развития соответствующей территории иреалистичность расчета доходов и расходов бюджета.
Принцип адресности и целевого характера бюджетных средствозначает, что бюджетные средства выделяются в распоряжение конкретныхполучателей бюджетных средств с обозначением направления их на финансированиеконкретных целей.
В Российской Федерации устанавливается казначейское исполнениебюджетов. На органы исполнительной власти возлагается организация исполнения иисполнение бюджетов, управление счетами бюджетов и бюджетными средствами.Указанные органы являются кассирами всех распорядителей и получателей бюджетныхсредств и осуществляют платежи за счет бюджетных средств от имени и попоручению бюджетных учреждений.
В структуре бюджетного процесса можно выделить следующие комплексызадач:
-         формирование и утверждение проектабюджета;
-         формирование и утверждение бюджетнойросписи;
-         ежемесячное формирование кассовогоплана по подведомственной сети распорядителей и получателей бюджетных средств;
-         финансирование расходовподведомственных распорядителей и получателей бюджетных средств;
-         контроль над поступлением доходов насчета бюджета;
-         контроль над целевым расходованиембюджетных средств;
-         формирование и предоставление отчетныхданных в вышестоящие контролирующие органы.
К сожалению, эти комплексы задач столь объемны, что не представляетсявозможным описать и реализовать их все в рамках одного дипломного проекта.Представленный проект полностью охватывает реализацию первого комплекса задачиз приведенного выше списка, а также от части седьмого комплекса. Следуетотметить, что архитектура информационной системы, спроектированной в рамкахдипломного проекта, позволяет легко расширять функциональные возможностипрограммы, что позволяет при дальней проработке предметной области реализоватьв системе недостающие комплексы подзадач бюджетного процесса.
При проектировании системы выбран объектно-ориентированный подход,который позволяет описать систему в виде взаимосвязанных сущностейпредставляющих собой объекты реального мира. Это позволяет значительноупростить процесс проектирования и снизить риски.
При описание системы активно используется Unified ModelingLanguage 2.0, который позволяет в наглядной графической форме отобразить всеаспекты проектируемой системы и CASE‑средство Enterprise Architect фирмыSparx Systems./>1.2     Анализ существующих решений поавтоматизации предметной области
Среди существующих программных решений по автоматизациидеятельности администраций следует отметить автоматизированную информационнуюсистему АС «Бюджет» НПО «Криста», которая предназначена для комплексной автоматизации деятельностифинансовых органов субъектов РФ и муниципальных образований на всех этапахисполнения бюджета. Данная ИС позволяет организовать исполнение бюджета всоответствии с действующим бюджетным законодательством, обеспечивает созданиесистемы управленческого бюджетного учета и отчетности финансового органа,поддерживает различные варианты кассового обслуживания исполнения бюджета ворганах Федерального казначейства. Информационная система АС «Бюджет» обеспечивает выполнениеследующих функций:
-         автоматический бюджетный контроль;
-         множественное визирование документов сприменением ЭЦП;
-         многобюджетный режим работы;
-         расширенный аудит действийпользователей;
-         сбора информации;
-         учет государственных контрактов идоговоров;
-         учет бюджетных обязательств;
-         электронный обмен с банком);
-         сканер двухмерного штрих-кода платежныхпоручений.
Функция автоматического бюджетного контроля предназначена дляавтоматизации бюджетного контроля первичных документов в соответствии спринятым порядком организации исполнения бюджета.
Функциямножественного визирования документов с применением ЭЦП позволяет внедрить вовнутренний документооборот средства ЭЦП и шифрования.
Функциямногобюджетный режим позволяет вести учет исполнения нескольких бюджетов водной базе данных, используя стандартные функциональные возможности.
Функциярасширенный аудит действий пользователей предназначена для мониторинга действийпользователей по изменению данных, выявления некорректных действий ивосстановления данных.
Функция сбораинформации позволяет организовать сбор и консолидацию произвольной оперативнойи отчетной информации от нижестоящих отделов. Посредством Системы вышестоящийорганы формирует запросы – задания на подготовку информации, а нижестоящиеотделы предоставляют информацию в соответствии с заданиями.
Функция учетгосударственных контрактов и договоров предназначена для учета и контролягосударственных контрактов и договоров, заключенных по результатам проведенияконкурсов, а также договоров, заключаемых без проведения конкурсных процедур,расшифровки стоимости договора по этапам, по кодам бюджетной классификации исрокам оплаты, по видам продукции и ОКПД; документов исполнения.
Функция учетбюджетных обязательств предназначена для учета финансовыми органами бюджетныхобязательств, вытекающих из договоров на поставку продукции, выполнение работ,оказание услуг, заключенных бюджетными учреждениями, и подлежащих оплате засчет средств соответствующего бюджета.
Функцияэлектронный обмен с банком предназначена для осуществления полнофункциональногодвухстороннего обмена электронными платежными документами между ФО и органамиФК, а также между ФО и учреждениями банков.
Функциясканирования двухмерного штрих-кода платежных поручений предназначена дляавтоматизации ввода платежных поручений в АС «Бюджет», которая заключается вполучении информации, закодированной в двухмерном штрих-коде на бумажной копииплатежного поручения, и занесении этой информации в базу данных.
/>Комплексная система АЦК-Финансы, разработаннаякомпанией «Бюджетные Финансовые Технологии» предназначена для обеспеченияавтоматизации всего процесса исполнения бюджета и управления бюджетнымпроцессом /6/.
АЦК-Финансы обеспечивает комплексную оптимизацию и автоматизациювсех участков и всех участников бюджетного процесса, в том числе автоматизациювсех структурных подразделений внутри финансового органа, подчиненныхтерриториальных подразделений ФО, распорядителей и получателей бюджетныхсредств. Кроме того, система АЦК-Финансы решает задачи связи ФО с МНС и УФК, апри необходимости и с обслуживающим банком или РКЦ.
Система АЦК-Финансы позволяет создать единый электронныйдокументооборот, обеспечивающий полную автоматизацию процесса исполнениябюджета, охватывающий всех участников бюджетного процесса в диапазоне отконечных получателей бюджетных средств до главного распорядителя, включая всеотделы, входящие в структуру финансового органа, а именно:
-         бухгалтерия ФО;
-         бюджетный и отраслевые отделы ФО;
-         отдел ценных бумаг и неденежных форм расчетов ФО;
-         отдел доходов ФО;
-         казначейский отдел ФО;
-         отдел управления и обслуживания государственного долга ФО;
-         отдел учета бюджетных обязательств ФО;
-         отдел автоматизации систем финансовых расчетов ФО;
-         РБС;
-         ПБС и прочие.
Система АЦК-Финансы обеспечивает автоматизацию рабочего местакаждого специалиста, участвующего в бюджетном процессе, его функционирование врамках должностных инструкций, а также связь всех автоматизированных рабочихмест с единой системой электронного документооборота с использованием припередаче электронных документов средств криптографической защиты иэлектронно-цифровой подписи. Используемые в системе АЦК-Финансы средствакриптографической защиты информации и электронно-цифровой подписи имеют всенеобходимые сертификаты.
Организация единого удаленного документооборота обеспечиваетсоздание единой информационной системы ФО, позволяющей осуществлять мониторингисполнения регионального бюджета в режиме реального времени, вплоть до конечныхПБС вне зависимости от их территориальной удаленности.
Система АЦК-Финансы, являясь комплексным решением автоматизацииФО, помимо осуществления казначейского расхода, автоматизирует все функции ФО,такие, как:
-         формирование проекта бюджета;
-         проведение взаимных расчетов междууровнями бюджета;
-         расчет / принятие лимитовбюджетных обязательств;
-         учет бюджетных обязательств;
-         исполнение бюджета по расходам;
-         исполнение бюджета по доходам;
-         операции с привлеченными средствами и средствами, размещенными на возвратной основе;
-         бухгалтерский учет;
-         учет средств, полученных от предпринимательской и иной приносящей доход деятельности;
-         учет гарантий и поручительств;
-         исполнение бюджета по источникампокрытия дефицита бюджета;
-         исполнение доходов и расходовцелевых бюджетных фондов;
-         проведение операций с ценнымибумагами;
-         анализ исполнения бюджета, получение и свод отчетности об исполнении бюджета;
-         капитальное строительство и другие.
Рассмотренные автоматизированнаяинформационная система АС «Бюджет» и комплексная система АЦК-Финансы обеспечивает построение эффективнойсистемы управления бюджетным процессом региона за счет централизации всейинформации о ходе бюджетного процесса и автоматизации всех участков и всехучастников бюджетного процесса. Однако бюджетный процесс в региональныхфинансовых органах имеет ряд специфических особенностей и требует специальныхметодов и инструментов. В результате этого финансовое управление администрацииНовоегорлыкского сельского поселения поставило перед информационным отделомзадачу разработки информационной системы автоматизации процесса планированиябюджета, которая должна учитывать особенности в части многовариантностирасчетов проекта бюджета, а также оперативности и точности расчетов параметровбюджета.
 
/>/>1.3    Моделирование бизнес-процессов предметной области
Для того чтобы более четко разобраться с предметной областью /30/и понять, что требуется от проектируемой информационной системы далееприводится описание существующих в Финансовом управлении бизнес-процессов,которые подлежат автоматизации.
На рисунке 1.1 представлена схема бизнес-процесса по формированиюсметы расходов распорядителя бюджетных средств.
/>
Рисунок 1.1 – Бизнес-процесс«Формирование сметы расходов распорядителя»
Целью данного бизнес-процесса является получение сводной сметырасходов распорядителя бюджетных средств на год. Выходной документ, которыйформируется в результате этого бизнес-процесса, отражает предполагаемые суммырасходов распорядителя бюджетных средств на год, для которого составляетсяпроект бюджета.
Этот документ формируется распорядителями бюджетных средств,которые по большей части, представляют собой внешние по отношению к Финансовомууправлению организации. В данной ситуации может возникнуть вопрос, если этиорганизации являются внешними по отношению к автоматизируемому предприятия, тозачем здесь приводится описание этого бизнес-процесса. Для того чтобы прояснитьэту ситуацию отметим, что само Финансовое управление является распорядителембюджетных средств для некоторых получателей. Решением этой задачи в рамкахФинансового управления администрации Новоегорлыкского сельского поселения занимаются специалисты бюджетного отдела.
Входной информацией для бизнес-процесса служат сметы расходовподведомственных получателей. В рамках бизнес-процесса для получения выходногодокумента, производится суммирование объемов денежных средств необходимыхподведомственным получателям в разрезе статей расходов. Полученные суммызаносятся в выходной документ, который направляется в Финансовое управление нарассмотрение и утверждение.
Архитектура проектируемой информационной системы предполагает размещениепрограммных модулей по составлению сметы расходов в организацияхраспорядителях, что позволит автоматизировать процесс передачи данных отраспорядителей в Финансовое управление.
На рисунке 1.2 представлена схема бизнес-процесса по формированиюсметы доходов администраторов бюджетных средств.
Целью данного бизнес-процесса является получения сметы доходовадминистратора бюджетных средств. Выходной документ данного бизнес-процессаотражает предполагаемые объемы поступления доходов в году, для которого составляетсяпроект бюджета. Выходной документ данного бизнес-процесса служит входнойинформацией при составлении доходной части проекта бюджета.
Как и в случае со сметой расходов распорядителя бюджетных средств,смета доходов администратора бюджетных средств по большей части составляетсясторонними организациями.
Финансовое управление также является администратором некоторыхвидов доходов. В рамках Финансового управления этой задачей занимаютсяспециалисты отдела прогнозирования доходов и налоговой политики.

/>
Рисунок 1.2 – Бизнес-процесс«Формирование сметы доходов администратора бюджетных средств»
На рисунке 1.3 представлена схема бизнес-процесса по формированиюсметы администратора источников финансирования дефицита.
/>
Рисунок 1.3 – Бизнес-процесс«Формирование сметы администратора источников финансирования дефицита бюджета»
Целью данного бизнес процесса является получение сметыадминистратора источников финансирования дефицита бюджета. Выходной документотражает объемы средств направляемых на погашение дефицита бюджета, в случаеесли такой имеется.
Как и в случае вышеописанных бизнес-процессов, сметаадминистратора источников финансирования дефицита бюджета составляетсясторонними организациями, являющимися администраторами источниковфинансирования дефицита бюджета. Финансовое управление также являетсяадминистратором некоторых источников финансирования дефицита. В рамкахФинансового управления этот бизнес-процесс протекает в бюджетном отделе.
На рисунке 1.4 представлена схема бизнес-процесса по формированиюдоходной части проекта бюджета.
/>
Рисунок 1.4 – Бизнес-процесс«Формирование доходной части проекта бюджета»
Целью данного бизнес-процесса является получение ведомости доходов– документа, в котором отражаются предполагаемые объемы доходов территории, длякоторой составляется проект бюджета.
В рамках данного бизнес процесса производится суммирование объемовдоходов администраторов бюджетных средств, представленных во входных документов– сметах доходов администраторов бюджетных средств – в соответствии с бюджетнойклассификацией Российской Федерации.
Выходной документ данного бизнес-процесса является составнойчастью проекта бюджета.
На рисунке 1.5 представлена схема бизнес-процесса по формированиюрасходной части проекта бюджета.

/>
Рисунок 1.5 – Бизнес-процесс«Формирование расходной части проекта бюджета»
Целью данного бизнес-процесса является получение ведомостирасходов – документа, в котором отражаются предполагаемые объемы расходовтерритории, для которой составляется проект бюджета.
В рамках данного бизнес-процесса производится суммирование объемоврасходов распорядителей бюджетных средств, представленных во входных документах– сводных сметах расходов распорядителей бюджетных средств – в соответствии сбюджетной классификацией Российской Федерации.
Выходной документ данного бизнес-процесса является составнойчастью проекта бюджета территории.
На рисунке 1.6 представлена схема бизнес-процесса по формированиюисточников финансирования дефицита бюджета.
Целью данного бизнес-процесса является получение ведомостиисточников финансирования дефицита бюджета – документа, в котором отражаютсяисточники и объемы средств, направляемых на погашение дефицита бюджета.
Этот бизнес-процесс возникает только тогда, когда проект бюджетаявляется дефицитным, т.е. объем расходов превышает объем доходов. Выходнойдокумент данного бизнес-процесса является составной часть проекта бюджета.

/>
Рисунок 1.6 – Бизнес-процесс«Формирование источников финансирования дефицита бюджета»
На рисунке 1.7 представлена схема бизнес-процесса направленного наподдержание проекта бюджета в актуальном состоянии в течение всего года.
/>
Рисунок 1.7 – Бизнес-процесс«Корректировка проекта бюджета»
Так как при исполнении бюджета начальные показатели меняются, топроект бюджета необходимо поддерживать в актуальном состоянии. Это достигаетсяза счет справок-уведомлений. Корректировка бюджета осуществляется попоказателям доходов, расходов и источников финансирования дефицита бюджета.
Справки-уведомления на уменьшение объема ассигнований служат дляуменьшения изначально запланированных объемов средств.
Справки-уведомления на увеличение объема ассигнований служат дляувеличения изначально запланированных объемов средств.
На рисунке 1.8 представлена схема бизнес-процесса по формированиюконсолидированного бюджета.

/>
Рисунок 1.8 – Бизнес-процесс«Формирование консолидированного бюджета территории»
Целью данного бизнес-процесса является получение проектаконсолидированного бюджета территории.
Так как Новоегорлыкское сельское поселения представляет нескольких сельскихпоселений, то для предоставления данных в Министерство финансов Ростовскойобласти составляется проект консолидированного бюджета территории. В этомдокументе отражаются общие показатели объемов доходов и расходов, а такжеобъемов средств выделенных на покрытие дефицита бюджета Новоегорлыкскогосельского поселения./>1.4     Анализ и моделирование требований/>/> 1.4.1   Формирования функциональных требований
Для того чтобы определить функциональные требования, предъявляемыек системе, необходимо, прежде всего, выявить лиц заинтересованных в этойсистеме, а затем определить тот функционал, который им требуется дляосуществления своей профессиональной деятельности.
Заинтересованные в системе пользователи, которые были выявлены впроцессе исследования бизнес-процессов и предпроектного обследованияФинансового управления, представлены на рисунке 1.9.

/>
Рисунок 1.9 –Пользователи системы
Дадим краткую характеристику каждому классу пользователей системы.Администраторы автоматизированной информационной системы бюджетного процессазанимается настройкой системы, управлением пользователями и пользовательскимигруппами, управлением правами доступа.
Специалисты бюджетного отдела – сотрудники отделов Финансовогоуправления, которые занимаются составлением расходной части проекта бюджета ибюджетной росписи.
Специалисты отдела прогнозирования доходов и налоговой политики –сотрудники отдела Финансового управления, в задачи которых входит составление доходнойчасти проекта бюджета и бюджетной росписи.
Распорядители бюджетных средств – это организации, управляющиераспределением бюджетных средств по подведомственным получателям иосуществляющих их финансирование.
Администраторы бюджетных средств – это организации, управляющихпоступлениями доходов в бюджет.
Администраторы источников финансирования дефицита – этоорганизации, управляющие поступлениями средств, направленных на покрытиедефицита бюджета.
После того, как мы выявили основных пользователей системы,проведем анализ вариантов использования ими системы. Прецеденты фактически иявляются функциональными требованиями к системе.
На рисунке 1.10 представлены варианты использования системыраспорядителем бюджетных средств.
В процессе выполнения прецедента «Формирование сметы расходов»пользователь выполняет поэтапное формирование сметы расходов, последовательновводя предполагаемые суммы расходов на год по соответствующим целевым статьямбюджетной классификации Российской Федерации.
В процессе выполнения прецедента «Утверждение сметы расходов» всистеме фиксируется состояние сметы расходов, и дальнейшая ее модификации втечение года возможна только при помощи справок-уведомлений.
В процессе выполнения прецедента «Передача сметы расходовФинансовому управлению» происходит передача сметы расходов распорядителябюджетных средств в Финансовое управление для проверки и окончательного утверждения.В дальнейшем сметы расходов распорядителей служат основой для формированиярасходной части проекта бюджета.
В процессе выполнения прецедента «Внесение изменений в сметурасходов» пользователь проводит корректировку сумм расходов предполагаемых в планируемомгоду. Выполнение этого прецедента возможно, только если смета расходов еще неутверждена, т.е. если не выполнялся прецедент «Утверждение сметы расходов нагод».
В процессе выполнения прецедента «Ввод справок-уведомлений»пользователь проводит корректировку показателей сметы расходов в течение годаисполнения бюджета. Этот прецедент служит для подержания сметы расходов вактуальном состоянии в течение всего года.
/>
Рисунок 1.10 –Варианты использования системы распорядителем бюджетных средств
На рисунке 1.11 представлены варианты использования системыадминистратором бюджетных средств.
В процессе выполнения прецедента «Формирование сметы доходов»пользователь производит поэтапное формирование сметы доходов, последовательновводя предполагаемые суммы доходов на год по соответствующим видам доходовбюджетной классификации Российской Федерации.

/>
Рисунок 1.11 –Варианты использования системы администратором бюджетных средств
В процессе выполнения прецедента «Утверждение сметы доходов» всистеме фиксируется состояние сметы доходов, и дальнейшая ее модификация втечение года возможна только при помощи справок уведомлений.
В процессе выполнения прецедента «Внесение изменений в сметудоходов» пользователь проводит корректировку сумм доходов предполагаемых впланируемом году. Выполнение этого прецедента возможно, только если сметадоходов еще не утверждена, т.е. если не выполнялся прецедент «Утверждение сметыдоходов».
В процессе выполнения прецедента «Передача сметы доходов вФинансовое управление» происходит передача сметы доходов администраторабюджетных средств в Финансовое управление для проверки и окончательногоутверждения.
В дальнейшем сметы доходов администраторов служат основой дляформирования доходной части проекта бюджета.
В процессе выполнения прецедента «Ввод справок-уведомлений»пользователь проводить корректировку показателей сметы доходов в течение годаисполнения бюджета. Этот прецедент служит для поддержания сметы доходов вактуальном состоянии в течение всего года.
На рисунке 1.12 представлены варианты использования системуадминистраторами источников финансирования дефицита бюджета.
В процессе выполнения прецедента «Формирование сметы источниковфинансирования дефицита бюджета» пользователь производит поэтапное формированиесметы источников финансирования дефицита, последовательно вводя предполагаемыесуммы средств направляемых на покрытие дефицита бюджета в соответствии сбюджетной классификацией Российской Федерации.
В процессе выполнения прецедента «Утверждение сметы источниковфинансирования дефицита бюджета» в системе фиксируется состояние сметы источниковфинансирования дефицита бюджета, и дальнейшая ее модификация в течение годавозможна только при помощи справок уведомлений.
В процессе выполнения прецедента «Внесение изменений в сметуисточников финансирования дефицита» пользователь проводит корректировку объемовсредств направляемых на покрытие дефицита бюджета. Выполнение этого прецедентавозможно, только если смета источников финансирования дефицита бюджета еще неутверждена, т.е. если не выполнялся прецедент «Утверждение сметы источниковфинансирования дефицита бюджета».

/>
Рисунок 1.12 –Варианты использования системы администратором источников финансированиядефицита бюджета
В процесса выполнения прецедента «Передача сметы источниковфинансирования дефицита бюджета в Финансовое управление» происходит передачасметы источников финансирования дефицита бюджета в Финансовое управление дляпроверки и окончательного утверждения. В дальнейшем сметы источниковфинансирования дефицита бюджета служат основой для формирования источниковфинансирования дефицита в проекте бюджета.
В процессе выполнения прецедента «Ввод справок-уведомлений»пользователь проводить корректировку показателей сметы источниковфинансирования дефицита в течение года исполнения бюджета. Этот прецедентслужит для поддержания сметы источников финансирования дефицита в актуальномсостоянии в течение всего года.
На рисунке 1.13 представлены варианты использования системыадминистратором автоматизированной системы бюджетного процесса при управлениипользователями.
/>
Рисунок 1.13 –Прецеденты управлении пользователями ИС
В процессе выполнения прецедента «Регистрация пользователя»администратор регистрирует в системе новую учетную запись.
В процессе выполнения прецедента «Блокирование пользователя»администратор временно блокирует учетную запись пользователя. Если пользовательв это время подключен к системе, то он уведомляется о том, что его учетнаязапись заблокирована, после чего происходит его отключение от системы.
В процессе выполнения прецедента «Удаление пользователя»администратор удаляет учетную запись пользователя и списка зарегистрированных всистеме.
В процессе выполнения прецедента «Назначение прав доступапользователю» администратор назначает пользователю права доступа к системе,которые необходимы ему для осуществления своей профессиональной деятельности.
На рисунке 1.14 представлены варианты использования системыадминистратором автоматизированной информационной системы при управлениипользовательскими группами.
В процессе выполнения прецедента «Регистрация пользовательскойгруппы» администратор регистрирует в системе новую пользовательскую группу.Пользовательские группы служат для облегчения процесса администрированиясистемы.
В процессе выполнения прецедента «Удаление пользовательскойгруппы» администратор удаляет выбранную пользовательскую группу из списказарегистрированных в системе групп.
В процессе выполнения прецедента «Управление членствомпользователей в пользовательских группах» администратор управляет составомпользовательских групп. Он может добавить нового члена, выбрав его из списказарегистрированных в системе, либо наоборот исключить пользователя из группы.
В процессе выполнения прецедента «Назначение прав доступапользовательской группе» администратор назначает пользовательской группе правадоступа к системе, общие для всех членов этой группы.
На рисунке 1.15 представлены прочие варианты использования системыадминистратором автоматизированной системы бюджетного процесса.

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

/>
Рисунок 1.15 –Прочие варианты использования системы администратором
На рисунке 1.16 представлены варианты использования системыспециалистом бюджетного отдела финансового управления при формировании проектабюджета.
В процессе выполнения прецедента «Формирование сети распорядителейбюджетных средств» пользователей формирует список организаций являющихсяраспорядителями бюджетных средств. Каждому распорядителю присваивается код всоответствии с бюджетной классификацией Российской Федерации.
В процессе выполнения прецедента «Формирование сетиадминистраторов источников финансирования дефицита бюджета» пользовательформирует список организаций являющихся администраторами источниковфинансирования дефицита бюджета. Каждому администратору присваивается код всоответствии с бюджетной классификацией Российской Федерации.
В процессе выполнения прецедента «Формирование проекта бюджета»пользователь регистрирует в системе новый проект бюджета, указывая при этомпоселение и год на который составляется проект бюджета.

/>
Рисунок 1.16 –Варианты использования формирования проекта бюджета
В процессе выполнения прецедента «Проверка и утверждение сметырасходов распорядителя» пользователь проверяет сметы, поступившие отраспорядителей бюджетных средств. Если смета корректна, то пользовательутверждает ее и в дальнейшем эта смета участвует в формировании проектабюджета. При утверждении сметы распорядителю при следующем его подключении ксистеме выдается сообщение о том, что его смета утверждена. Если же в сметесодержатся ошибки, то специалист бюджетного отдела формирует список замечаний иотправляет смету распорядителю на доработку, о чем система также оповещаетраспорядителя при первом же его подключении к системе.
В процессе выполнения прецедента «Проверка и утверждение сметыадминистратора источников финансирования дефицита бюджета» пользовательпроверяет сметы, поступившие от администраторов источников финансированиядефицита бюджета. В случае корректности сметы, пользователь ее утверждает, и вдальнейшем она участвует в формирования проекта бюджета. При утверждении сметыадминистратору при следующем его подключении к системе выдается уведомление отом, что его смета утверждена. Если же в смете содержатся ошибки, то специалистбюджетного отдела формирует список замечаний и отправляет смету администраторуна доработку, о чем система также оповещает администратора при первом же егоподключении к системе.
В процессе выполнения прецедента «Утверждение проекта бюджета» всистеме фиксируется состояние проекта бюджета и дальнейшие его изменениявозможны только при помощи справок уведомлений. Выполнения этого прецедентавозможно только после того как утверждены сметы от всех распорядителейбюджетных средств, администраторов бюджетных средств и администраторовисточников финансирования дефицита.
В процессе выполнения прецедента «Ввод справок-уведомлений»проводит корректировку показателей проекта бюджета в течение года исполнениябюджета. Этот прецедент служит для поддержания проекта бюджета в актуальномсостоянии в течение всего года.
В процессе выполнения прецедента «Сравнительны анализ проектовбюджета» пользователь выбирает проекты бюджета, которые он хочет сравнить, асистеме выдает ему отчет, который содержит показатели проектов бюджета идинамику роста.
На рисунке 1.17 представлены варианты использования системыспециалистом бюджетного отдела при формировании проекта консолидированногобюджета территории.
/>
Рисунок 1.17 –Варианты использование формирования проекта консолидированного бюджетатерритории
В процессе выполнения прецедента «Формирование проектаконсолидированного бюджета» пользователь регистрирует в системе новый проектконсолидированного бюджета, указывая при этом наименовании территории и год накоторый составляется проект бюджета, а также проекты бюджетов, которыеучаствуют в формировании консолидированного бюджета.
На рисунке 1.18 представлены варианты использования системыспециалистом отдела прогнозирования доходов и налоговой политики.
В процессе выполнения прецедента «Формирование сетиадминистраторов бюджетных средств» пользователь формирует список организацийявляющихся администраторами бюджетных средств. Каждому администратору бюджетныхсредств присваивается код в соответствии с бюджетной классификацией РоссийскойФедерации.

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

/>
Рисунок 2.6 –Объекты, участвующие в процессе составления смет источников финансированиядефицита бюджета
В таблице 9 представлено описание классов объектов, участвующих впроцессе составления смет источников финансирования дефицита бюджета.
Таблица 9 –Описание классов объектов, участвующих в процессе составления смет источниковфинансирования дефицита бюджетаКласс Атрибут Описание 1 2 3 Администратор ИФД Администратор источников финансирования дефицита Код Код администратора источников финансирования дефицита Смета ИФД Смета источников финансирования дефицита Номер Номер документа Статус Текущее состояние сметы источников финансирования дефицита Строка Сметы ИФД Строка табличной части сметы источников финансирования дефицита Сумма Предполагаемый объем средств направляемых на покрытие дефицита Примечание Комментарии Справка Уведомление ИФД Справка-уведомление по источникам финансирования дефицита Номер Номер документа Дата Дата внесения Примечание Комментарии Статус Текущее состояние справки-уведомления
На рисунке 2.7 представлена часть концептуальной модели, котораяотображает объекты, участвующие в процессе составления консолидированногопроекта бюджета территории.
/>
Рисунок 2.7 –Объекты, участвующие в процессе составления консолидированного проекта бюджетатерритории
В таблице 10 представлено описание классов объектов, участвующих впроцессе составления консолидированного проекта бюджета территории.
Таблица 10 –Описание классов объектов, участвующих в процессе составленияконсолидированного проекта бюджета территории
Класс
Атрибут
Описание 1 2 3 Территория Территория для которого составляется проект бюджета Код Код территории Наименование Название территории Проект Консолид Бюджета Проект консолидированного бюджета территории Год Год на который составляется проект бюджета Наименование Название консолидированного проекта бюджета территории
На рисунке 2.8 представлена часть концептуальной модели, котораяотображает объекты, участвующие в процессе управления пользователямипроектируемой системы и их правами доступа.

/>
Рисунок 2.8 –Объекты, участвующие в процессе управления пользователями системы и их правамидоступа
В таблице 11 представлено описание классов объектов, участвующих впроцессе управления пользователями системы и их правами доступа.
Таблица 11 –Описание классов объектов, участвующих в процессе управления пользователямисистемы и их правами доступа
Класс
Атрибут
Описание 1 2 3 Пользователь Пользователь системы Логин Имя учетной записи пользователя Пароль Хэш пароля учетной записи пользователя Ф.И.О. Имя пользователя Пользовательская Группа Группа пользователей Код Код пользовательской группы Наименование Название пользовательской группы Право Доступа Право доступа к функциональности системы Наименование Название права доступа Группа Прав Доступа Группа объединяющая несколько прав доступа Код Код группы прав доступа Наименование Название группы прав доступа />/> 
2.2     Обоснование выбора СУБД
Одним из требований заказчика является реализация информационногообеспечения на основе Microsoft SQL Server 2000 Enterprise Edition /24/, всвязи с тем, что у них уже имеется лицензионная копия данного продукта. Этопозволит в некоторой степени сократить первоначальные затраты на разработку ивнедрение системы.
Microsoft SQL Server 2000 – этозаконченное решение для управления и анализа данных, позволяющее оперативноразвертывать масштабируемые приложения нового поколения. SQL Server 2000 – ключевойкомпонент поддержки электронной коммерции, интерактивных деловых приложений ихранилищ данных, обеспечивающий масштабируемость, необходимую для поддержкирастущих, динамических сред. В SQL Server 2000 предусмотрена широчайшаяподдержка функций производительности и доступности, гарантирующих своевременноерешение поставленных задач, а также развитой функциональности управления инастройки, позволяющей автоматизировать выполнение рутинных задач и снизитьсовокупную стоимость владения.
SQL Server 2000 обладает рядомвозможностей, обеспечивающих легкость установки, развертывания и эксплуатации,а также поддерживающих масштабируемость, создание хранилищ данных и системнуюинтеграцию с другим серверным программным обеспечением.
Механизм баз данных SQL Server 2000представляет собой надежный сервер, способный управлять базами данныхтерабайтного объема, к которым одновременно обращаются тысячи пользователей. Вто же время при работе с параметрами по умолчанию SQL Server 2000 поддерживаеттакие функции, как динамическая самонастройка, что позволяет не обременятьпользователей решением административных задач.
Некоторые функции SQL Server 2000увеличивают масштабируемость системы. Например, SQL Server 2000 динамическирегулирует степень дробления блокировок для каждой таблицы, на которуюссылается запрос, в него также входит оптимизированная поддержкавысокоскоростных операций в средах VLDB. Кроме того, SQL Server 2000 способенпланировать параллельное исполнение, при котором обработка оператора SQLразделяется на несколько частей. Каждая часть может быть выполнена на отдельномпроцессоре, в этом случае формирование полного результирующего набораосуществляется быстрее, чем в том случае, когда отдельные части оператороввыполняются последовательно.
SQL Server 2000 состоит из рядакомпонентов, таких, как механизм реляционных баз данных, Analysis Services иEnglish Query. Все эти компоненты, каждый из которых играет определенную роль,работая совместно, формируют полнофункциональную реляционную СУБД.
Механизм реляционных баз данных SQL Server2000 – это современное ядро с высокой степенью масштабируемости,предназначенное для хранения данных. Механизм баз данных сохраняет данные втаблицах. Каждая таблица представляет определенный класс объектов, взависимости от интересов конкретной организации. Таблица состоит из столбцов,каждый из которых представляет атрибут объекта, который она моделирует, истрок. Каждая строка представляет один экземпляр объекта, моделируемоготаблицей. Приложение передает механизму баз данных оператор SQL, механизмвозвращает результат в виде набора данных в табличной форме.Интернет-приложение передает механизму баз данных оператор SQL или запросXPath, а тот возвращает результат в виде документа XML. Механизм реляционныхбаз данных обеспечивает поддержку стандартных интерфейсов доступа к данным,таких, как ADO, OLE DB и ODBC.
Механизм реляционных баз данных обладаетвысокой масштабируемостью. SQL Server 2000 Enterprise Edition поддерживаетгруппы серверов баз данных, формирующих базы данных терабайтного объема, ккоторым могут обращаться тысячи пользователей одновременно. Механизм баз данныхтакже способен динамически настраиваться путем выделения дополнительныхресурсов по мере роста числа пользователей, подключенных к базе данных, иосвобождения ресурсов после отключения пользователей. Другими словами,отдельные пользователи или небольшие рабочие группы, у которых нетадминистраторов баз данных, могут использовать более простые редакции SQLServer. С помощью административных утилит с графическим интерфейсом изкомплекта поставки продукта легко администрировать даже крупные серверы базданных под управлением Enterprise Edition, работающие в эксплуатационномрежиме.
Механизм реляционных баз данных такжеобладает высокой степенью зашиты. Аутентификацию при регистрации допустимоинтегрировать с проверкой подлинности Windows, поэтому SQL Server не хранитникаких паролей и не пересылает их по сети. На узлах разрешается задавать аудитвсех пользователей, обращающихся к базе данных, соответствующий требованиямбезопасности уровня С2, и применять протокол SSL для шифрования всех данных,передаваемых между приложением и базой данных.
Репликация SQL Server 2000 позволяетподдерживать несколько копий данных на различных компьютерах с целью повышенияобщей производительности системы, а также обеспечивает поддержку синхронизациивсех копий. Репликация – важная и мощная технология распределения данных инекоторых типов объектов баз данных по всему предприятию. В репликации SQLServer используется принцип «публикации и подписки». Издатель данных,подлежащих репликации, определяет статьи, которые надо сделать доступными дляподписчиков.
Многим организациям для более эффективногопринятия решений требуется централизация данных. Однако данные можно хранить всамых разнообразных форматах и в нескольких различных местах. DTS в SQL Serverпозволяет создавать хранилища и киоски данных путем интерактивного илиавтоматического импорта и передачи данных из нескольких гетерогенных источниковпо расписанию.
DTS SQL Server 2000 существенно повышаетэффективность процесса создания хранилищ данных для оперативной аналитическойобработки. Кроме того, он предоставляет средства для тонкой настройки обширныхбаз данных для оперативной обработки транзакций, в результате чего можноувеличить число одновременно работающих пользователей, активно добавляющих имодифицирующих данные. Структура баз данных OLTP такова, что они регистрируютподробности каждой транзакции. Попытка выполнить сложный анализ для определениятрендов продаж за несколько месяцев или лет потребует просмотра огромного числазаписей, а большая загруженность обработкой информации при этом снижаетпроизводительность баз данных OLTP.
Хранилища и киоски данных создаются всистеме OLTP на основе данных, извлеченных и преобразованных в форму, котораялучше подходит для OLAP-обработки. Периодически осуществляется сбор строк сподробными данными OLTP в промежуточную базу данных, где они обобщаются, аитоговые данные помещаются в хранилище или киоск. DTS поддерживает извлечениеданных из одного источника и выполнение сложных преобразований с последующимсохранением итоговых преобразованных данных в другом источнике данных. Этоткомпонент в значительной степени упрощает процесс извлечения данных изнескольких систем OLTP и создания на основе извлеченных данных хранилища иликиоска данных для OLAP.
Analysis Services предоставляетинструменты для анализа данных, которые находятся в хранилищах и киоскахданных, где итоговая информация содержится в таблицах фактов. Таблица фактов – центральнаятаблица в схеме хранилища данных, в ней хранятся численные меры и ключи,связывающие факты с таблицами измерений. Как правило, базовая таблица фактовсодержит сведения, описывающие некоторые события в бизнесе, например банковскиетранзакции или факты продажи продукции. Приложения работают с данными AnalysisServices с помощью многомерных расширений ADO и OLE DB. Обработка запросов OLAPпосредством многомерных кубов Analysis Services выполняется существеннобыстрее, чем с использованием подробной информации из баз данных OLTP.
В систему Analysis Services входит сервер,управляющий многомерными кубами, предназначенными для анализа. Он обеспечиваетклиенту быстрый доступ к данным куба. Чтобы быстро выдавать ответы на сложныеаналитические запросы. Analysis Services организует данные из хранилища вкубические массивы с помощью предварительно вычисленных агрегированных данных.Analysis Services также облегчает создание моделей извлечения информации дляданных как из многомерных, так и из реляционных источников. Можно применятьмодели извлечения информации к обоим типам данных. Посредством службыPivotTable – компонента доступа, совместимого с OLE DB, Microsoft Excel иприложения других производителей могут получать данные с сервера и представлятьих пользователю или создавать локальные кубические массивы для автономногоанализа./>/>2.3     Разработка физической модели данных
На основании концептуальной модели данных,описанной в первой части этой главы, была разработана физическая модельпредставленная ниже.
На рисунке 2.9 представлены таблицы,относящиеся к бюджетной классификации доходов. В таблице 12 представлено описаниетаблиц, относящихся к бюджетной классификации доходов. Во всех таблицах поле tsс типом данных timestamp используются для оптимистического управленияблокировками при многопользовательской работе с проектируемой системой. Этополе в описания таблиц, в связи с ограничением на объем дипломного проекта, неприводится.

/>
Рисунок 2.9 –Бюджетная классификация доходов
Таблица 12 –Описание физической модели бюджетной классификации доходов
Таблица
Атрибут
Описание 1 2 3 BudgetClassifications Бюджетные классификации за разные годы id Уникальный идентификатор year Год в течении которого действует бюджетная классификация RevenueGroups Группы доходов id Уникальный идентификатор budgetClassificationId Код бюджетной классификации. Внешний ключ. sid Код группы доходов в соответствии с бюджетной классификацией name Наименование группы доходов RevenueSubgroups Подгруппы доходов id Уникальный идентификатор groupId Код группы доходов. Внешний ключ. sid Код подгруппы доходов в соответствии с бюджетной классификацией name Наименование подгруппы доходов RevenueClauses Статья доходов id Уникальный идентификатор subgroupId Код подгруппы доходов. Внешний ключ sid Код статьи доходов в соответствии с бюджетной классификацией name Наименование статьи доходов RevenueSubclauses Подстатьи доходов id Уникальный идентификатор clauseId Код статьи доходов. Внешний ключ sid Код подстатьи доходов в соответствии с бюджетной классификацией name Наименование подстатьи доходов Elements Элементы бюджетной классификации id Уникальный идентификатор budgetClassificationId Код бюджетной классификации. Внешний ключ sid Код элемента в соответствии с бюджетной классификацией name Наименование элемента RevenuePrograms Программы доходов id Уникальный идентификатор budgetClassificationId Код бюджетной классификации. Внешний ключ sid Код программы в соответствии с бюджетной классификацией доходов name Наименование программы доходов
На рисунке 2.10 представлены таблицы,относящиеся к бюджетной классификации расходов.
В таблице 13 представлено описание таблиц,относящихся к бюджетной классификации расходов.
На рисунке 2.11 представлены таблицы,относящиеся к бюджетной классификации источников финансирования дефицита.
В таблице 14 представлено описание таблиц,относящихся к бюджетной классификации источников финансирования дефицита.
На рисунке 2.12 представлены таблицы,относящие к процессу формированию доходной части проекта бюджета.
В таблице 15 представлено описание таблиц,относящихся к процессу формирования доходной части проекта бюджета.
/>
Рисунок 2.10 –Бюджетная классификация расходов

Таблица 13 –Описание физической модели бюджетной классификации расходов
Таблица
Атрибут
Описание 1 2 3 OutlaySections Разделы бюджетной классификации расходов id Уникальный идентификатор budgetClassificId Код бюджетной классификации. Внешний ключ sid Код раздела бюджетной классификации расходов name Наименование раздела бюджетной классификации расходов
/>
Рисунок 2.11 –Бюджетная классификация источников финансирования дефицита

Таблица 14 –Описание физической модели бюджетной классификации источников финансированиядефицита
Таблица
Атрибут
Описание 1 2 3 SFDGroups Группы бюджетной классификации источников финансирования дефицита id Уникальный идентификатор budgClassifId Код бюджетной классификации. Внешний ключ sid Код группы источников финансирования дефицита в соответствии с бюджетной классификацией name Наименование группы источников финансирования дефицита
/>
Рисунок 2.12 –Формирование доходной части проекта бюджета
Таблица 15 –Описание таблиц физической модели данных, относящихся к процессу формированиидоходной части проекта бюджета
Таблица
Атрибут
Описание 1 2 3 Locations Поселения, для которых формируются проекты бюджета id Код поселения domains Код территории к которой относится поселение name Название поселения BudgetProjects Проекты бюджетов id Уникальный идентификатор locationId Код поселения, которому принадлежит проект бюджета year Год, на который составляется проект бюджета name Название проекта бюджета status Состояние проекта бюджета
На рисунке 2.13 представлены таблицы, относящие к процессуформированию расходной части проекта бюджета.
/>
Рисунок 2.13 –Формирование расходной части проекта бюджета
В таблице 16 представлено описание таблиц, относящихся к процессуформирования расходной части проекта бюджета.
Таблица 16 –Описание таблиц физической модели данных, относящихся к процессу формированиирасходной части проекта бюджета
Таблица
Атрибут
Описание 1 2 3 BCSteward Распорядители бюджетных средств id Уникальный идентификатор budgProjId Код проекта бюджета. Внешний ключ legalId Код юридического лица. Внешний ключ sid Код распорядителя в соответствии с бюджетной классификацией OutlayEstimates Сметы расходов распорядителей бюджетных средств bcStewardId Код распорядителя бюджетных средств id Номер документа status Состояние сметы расходов OutlayEstimateRows Строки табличной части сметы расходов распорядителя бюджетных средств id Уникальный идентификатор estimateId Код сметы расходов. Внешний ключ outlayId Код расхода. Внешний ключ sum Объем денежных средств description Примечание OutlayEnquirys Справки-уведомления по расходам id Номер документа bcStewardId Код распорядителя бюджетных средств. Внешний ключ docId Код документа основания. Внешний ключ date Дата description Примечание status Состояние справки-уведомления OutlayEnquiryRows Строки табличной части справок-уведомлений по расходам id Уникальный идентификатор enquiryId Код справки-уведомления. Внешний ключ outlayId Код расхода. Внешний ключ summ Объем денежных средств description Примечание
На рисунке 2.14 представлены таблицы, относящие к процессуформированию источников финансирования дефицита бюджета.
В таблице 17 представлено описание таблиц, относящихся к процессуформирования источников финансирования дефицита бюджета.

/>
Рисунок 2.14 –    Формированиеисточников финансирования дефицита бюджета
Таблица 17 –Описание таблиц физической модели данных, относящихся к процессу формированииисточников финансирования дефицита бюджета
Таблица
Атрибут
Описание 1 2 3 SFDAdministrators Администраторы источников финансирования дефицита бюджета id Уникальный идентификатор legalId Код юридического лица. Внешний ключ budgProjId Код проекта бюджета. Внешний ключ sid Код администратора источников финансирования дефицита в соответствии с бюджетной классификацией SFDEstimates Сметы источников финансирования дефицита бюджета sfdSdminId Код администратора источников финансирования дефицита бюджета id Номер документа status Состояние сметы
На рисунке 2.15 представлены таблицы, относящие к процессуформированию консолидированного проекта бюджета территории.

/>
Рисунок 2.15 –Формирования консолидированного проекта бюджета территории
В таблице 18 представлено описание таблиц, относящихся к процессуформирования консолидированного проекта бюджета территории.
Таблица 18 –Описание таблиц физической модели данных, относящихся к процессу формированииконсолидированного проекта бюджета территорииТаблица Атрибут Описание 1 2 3 Domains Территории id Код территории name Название территории ConsBudgetProjects Консолидированные проекты бюджетов территории id Уникальный идентификатор year Год, на который составляется консолидированный проект бюджета территории domainId Код территории. Внешний ключ name Название проекта бюджета
В процессе физического проектирования базы данных в среде MS SQLServer 2000 была создана база данных fin_budget, состоящая из файлов данныхfin_budget.mdf и файлов журналов транзакций fin_budget_log.ldf. Принципотдельного хранения данных и журналов транзакций, а также разбиение этих двухгрупп информации на различные файлы в SQL Server 2000 необходим для повышениянадежности системы.
При создании физической модели сервера баз данных, посредством SQLServer Enterprise Manager, для всех суррогатных ключей было установленосвойство Identy, необходимое для вызова хранимой процедуры аутоинкремента. Дляувеличения реактивности системы, индексам, закрепленными за суррогатнымиключами присвоено значение Clustered.
На основе модели состояния системы разработана концептуальнаямодель данных проектируемой системы, включающая описание классов и ихатрибутов. В дипломе представлены концептуальные модели бюджетной классификациидоходов и расходов, источников финансирования дефицита, доходов администраторовбюджетных средств и доходной части проекта бюджета, смет расходовраспорядителей бюджетных средств и расходной части проекта бюджета, сметисточников финансирования дефицита бюджета, консолидированного проекта бюджетатерритории.
В качестве СУБД обосновано применение Microsoft SQL Server 2000Enterprise Edition.
На основании концептуальной модели данных для Microsoft SQL Server2000 разработана физическая модель данных.
/>/>3.        Проектированиепрограммного комплекса/>/> 3.1     Разработка архитектуры программногокомплекса
При проектировании системы используется концепция слоев – одна изобщеупотребительных моделей, применяемая разработчиками программногообеспечения для разделения сложных систем на более простые части.
Описывая систему в терминах архитектурных слоев, удобновоспринимать составляющие ее подсистемы в виде «слоеного пирога». Слой болеевысокого уровня пользуется службами, предоставляемыми нижележащим слоем, но тотне «осведомлен» о наличии соседнего верхнего слоя. Более того, обычно каждыйпромежуточный слой «скрывает» нижний слой от верхнего.
Расчленение системы на слои предоставляет целый ряд преимуществ:
-         отдельный слой можно воспринимать какединое самодостаточное целое, не особенно заботясь о наличии других слоев;
-         можно выбирать альтернативнуюреализацию базовых слоев;
-         зависимость между слоями можно свести кминимуму;
-         созданный слой может служить основойдля несколько слоев более высокого уровня.
Архитектура проектируемого приложения основывается на трехосновных слоях:
-         слой представления
-         слой домена
-         слой источника данных
Слой представления охватывает все, что имеет отношение к общениюпользователя с системой. К главным функциям этого слоя относятся отображениеинформации и интерпретация вводимых пользователем команд с преобразованием их всоответствующие операции в контексте домена и источника данных.
Слой источника данных – это подмножество функций, обеспечивающих взаимодействие состоронними системами, которые выполняют задания в интересах приложения. Кодэтой категории несет ответственность за мониторинг транзакций, управлениедругими приложениями, обмен сообщениями. Слой источника данных управляетобращениями к базе данных, обменом сообщениями, транзакциями.
Логика домена описывает основные функции приложения,предназначенные для достижения поставленной перед ним цели. К таким функциямотносятся вычисления на основе вводимых и хранимых данных, проверка всехэлементов данных и обработка команд, поступающих от слоя представления, а такжепередача информации слою источника данных.
Также, при проектировании приложения использовалась концепцияподключаемых модулей. Такой подход предполагает постепенное расширениефункциональных возможностей системы за счет подключение к базовой архитектуреновых модулей.
В качестве базовой платформы для разработки приложения планируетсяиспользовать. Net Framework 2.0.
NET Framework – это управляемая среда дляразработки и исполнения приложений, обеспечивающая контроль типов. Эта средауправляет выполнением программы: она выделяет память под данные и команды,назначает разрешения программе или отказывает в их предоставлении, начинаетисполнение приложения и управляет его ходом, а также отвечает за освобождение иповторное использование памяти, занятой ресурсами, более ненужными программе..NETFramework состоит из двух основных компонентов: общеязыковой исполняющей среды ибиблиотеки классов.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. Более того .NETRemoting является основой для .NET Web-сервисов. Таким образом, понимание основ.NET Remoting совершенно необходимо для разработки на основе .NЕТ Frameworkраспределенных приложений, в том числе для Интернета.
NET Remoting позволяет объектам,исполняющимся внутри разных доменов приложений и контекстов, взаимодействоватьдруг с другом через границы .NET Remoting. Граница .NET Remoting ведет себя,как полупроницаемая мембрана: в некоторых случаях она позволяет экземплярупройти сквозь нее без изменений; в других – заставляет экземпляр объекта запределами домена или контекста взаимодействовать с внутренними объектами построго определенному протоколу./>/>3.2     Разработка прототипов пользовательскогоинтерфейса
Пользовательский интерфейс клиентскойчасти приложения выполнен в виде единого интегрированного Windows-приложения смногодокументным интерфейсом. Клиентская часть поддерживает подключаемыемодули, которые могут расширять ее функциональные возможности. При этом новыекомпоненты интегрируются в среду, обеспечивая единый интерфейс для работы.
На рисунке 3.1 представлена средаавтоматизированной системы бюджетного процесса.
/>
Рисунок 3.1 –Среда автоматизированной системы бюджетного процесса
Пользовательская среда автоматизированнойсистемы бюджетного процесса состоит из нескольких основных частей:
-         главное меню приложения;
-         строка навигации по доступным проектамбюджета;
-         панель навигации;
-         основная часть.
Главное меню приложения служит для доступако всем функциям системы.
Строка навигации по доступным проектамбюджета служит для выбора поселения и проекта бюджета на соответствующий год, скоторым будет вестись работа.
Панель навигации дублирует основныефункции главного меню приложения для облегчения и ускорения доступапользователя.
В основной части среды, выполненной в видепанели с закладками, открываются формы, непосредственно с которыми работаетпользователь.
Структура главного меню приложенияпредставлена в таблице 19.
Таблица 19 –Структура главного меню
№ п/п
Название
Описание 1 2 3 1 Файл 1.1 Войти в системы Позволяет пользователю подключится к системе 1.2 Выйти из системы Позволяет пользователю отключится от системы 1.3 Выход Завершает работу приложения 2 Правка 2.1 Отменить Позволяет отменить последнее произведенной пользователем действие 2.2 Повторить Позволяет повторить отмененное ранее действие 2.3 Скопировать Позволяет скопировать данные в буфер обмена 2.4 Вырезать Позволяет вырезать данные в буфер обмена 2.5 Вставить Позволяет вставить данные из буфера обмена 3 Проект бюджета 3.1 Доходы 3.1.1 Сметы доходов Администраторам бюджетных средств позволяет вводить и передавать в Финансовое управление сметы доходов, а работникам Финансового управления проверять и утверждать сметы 3.1.2 Справки-уведомления
Администраторам бюджетных средств позволяет вводить
справки-уведомления по доходам, а работникам Финансового управления проверять и утверждать их 3.2 Расходы 3.2.1 Сметы расходов Распорядителям бюджетных средств позволяет вводить и передавать в Финансовое управление сметы расходов, а работникам Финансового управления проверять и утверждать сметы 3.2.2 Справки-уведомления Распорядителям бюджетных средств позволяет вводить и передавать в Финансовое управление справки-уведомления по расходам, а работникам Финансового управления проверять и утверждать их
Следует отметить, что пользовательскийинтерфейс автоматически настраивается в соответствии с правами доступа текущегопользователя, то есть пользователю отображаются только доступные ему функции./>/>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 –Компоненты автоматизированной системы бюджетного процесса
Название компонента
Описание 1 2 ASBPServer.exe Серверная часть приложения, выполненная в виде Windows‑процесса ASBPClient.exe Клиентская часть приложения ASBP. Common.dll Динамическая библиотека, объединяющая базовые классы, используемые большинством компонентов автоматизированной системы бюджетного процесса ASBP. BudgetProj. Server.dll Динамическая библиотека, объединяющая классы серверной части приложения, которые используются при формировании проекта бюджета ASBP. BudgetProj. Client.dll Динамическая библиотека, объединяющая классы клиентской части приложения, которые используются при формировании проекта бюджета ASBP. Exchange. Server.dll Динамическая библиотека, объединяющая классы серверной части приложения, которые используются при обмене данными между Финансовым управлением, администраторами и распорядителями бюджетных средств, а также администраторами источников финансирования дефицита бюджета ASBP. Exchange. Client.dll Динамическая библиотека, объединяющая классы клиентской части приложения, которые используются при обмене данными между Финансовым управлением, администраторами и распорядителями бюджетных средств, а также администраторами источников финансирования дефицита бюджета ASBP. ConsBudgProj. Server.dll Динамическая библиотека, объединяющая классы серверной части приложения, которые участвуют в процессах составления консолидированного проекта бюджета территории ASBP. ConsBudgProj. Client.dll Динамическая библиотека, объединяющая классы клиентской части приложения, которые участвуют в процессах составления консолидированного проекта бюджета территории ASBP. Revenue. Server.dll Динамическая библиотека, объединяющая классы серверной части приложения, которые используются при формировании смет доходов администраторов бюджетных средств и справок-уведомлений по доходам ASBP. Revenue. Client.dll Динамическая библиотека, объединяющая классы клиентской части приложения, которые используются при формировании смет доходов администраторов бюджетных средств и справок-уведомлений по доходам ASBP. Outlay. Server.dll Динамическая библиотека, объединяющая классы серверной части приложения, которые используются при формировании смет расходов распорядителей бюджетных средств и справок-уведомлений по расходам ASBP. Outlay. Client.dll Динамическая библиотека, объединяющая классы клиентской части приложения, которые используются при формировании смет расходов распорядителей бюджетных средств и справок уведомлений по расходам ASBP.SFD. Server.dll Динамическая библиотека, объединяющая классы серверной части приложения, которые используются при формировании смет источников финансирования дефицита бюджета и справок-уведомлений по источникам финансирования дефицита бюджета ASBP.SFD. Client.dll Динамическая библиотека, объединяющая классы клиентской части приложения, которые используются при формировании смет источников финансирования дефицита бюджета и справок-уведомлений по источникам финансирования дефицита бюджета
/> 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.        Управлениеинформационным проектом/> 4.1     Выбор жизненного цикла разработки информационной системы
Жизненный цикл информационной системы представляет собой непрерывныйпроцесс, начинающийся с момента принятия решения о создании информационнойсистемы и заканчивающийся в момент полного изъятия ее из эксплуатации.
Модель жизненного цикла информационной системы представляет собойнекоторую структуру, определяющую последовательность осуществления процессов,действий и задач, выполняемых на протяжении её жизненного цикла, а такжевзаимосвязи между этими процессами, действиями и задачами. Наиболее известнымижизненными циклами разработки ИС можно назвать следующие: каскад, V-образноеэволюционное ускоренное прототипирование, быстрая разработка приложений, инкрементнаяи спиральная модели.
В каскадной модели предусмотрена последовательная организацияработ. При этом основной особенностью является разбиение всей разработки наэтапы, причем переход с одного этапа на следующий происходит только после того,как полностью завершены все работы на предыдущем этапе. Каскадная модельприменяется в проектах, когда требования и их реализация максимально четкоопределены и понятны.
V-образная модель является разновидностью каскадной модели. В этоймодели особое значение придается действиям, направленным на верификацию иаттестацию системы. Тестирование системы обсуждается, проектируется ипланируется на ранних этапах жизненного цикла разработки. Область применения V-образноймодели – когда информация о требованиях достаточно полная. Модифицированная V-образнаямодель включает в себя итерационные циклы внесения изменений в требования.
Модель прототипирования жизненного цикла информационной системыпредполагает создание легко поддающихся модификации и расширению рабочихмоделей системы. Этот подход предполагает участие конечного пользователя втечение всего процесса разработки. Процесс уточнения продолжается до тех порпока пользователь не получит требуемую функциональность.
Основной чертой метода RAD является короткое время перехода отопределения требований до создания полной системы. Метод предполагаетпривлечение конечного пользователя на каждой фазе проекта основывается напоследовательности итераций эволюционной системы или прототипов, критическийанализ которых обсуждается с заказчиком. Период итерации, как правило, 60 дней.Обязательным является применение CASE-технологий.
Инкрементная модель представляет собой процесс частичнойреализации всей системы и медленного наращивания функциональных возможностей.Данная модель описывает процесс, при выполнении которого первостепенноевнимание уделяется системным требованиям, а затем их реализации разработчиками.
Спиральная модель предполагает итерационный процесс разработкиинформационной системы. При этом возрастает значение начальных этаповжизненного цикла, таких как анализ и проектирование. На этих этапах проверяетсяи обосновывается реализуемость технических решений путем создания прототипов.Каждая итерация представляет собой законченный цикл разработки, приводящий квыпуску внутренней и внешней версии изделия, которое совершенствуется отитерации к итерации, чтобы стать законченной системой. Таким образом, каждыйвиток спирали соответствует созданию фрагмента или версии программного изделия,на нем уточняются цели и характеристики проекта, определяется его качество,планируются работы на следующем витке спирали. На каждой итерации углубляются ипоследовательно конкретизируются детали проекта, в результате чего выбираетсяобоснованный вариант, который доводится до окончательной реализации.
Использование спиральной модели позволяет осуществлять переход наследующий этап выполнения проекта, не дожидаясь полного завершения текущего –недоделанную работу можно будет выполнить на следующей итерации. Главная задачакаждой итерации – как можно быстрее создать работоспособный продукт, которыйможно показать пользователям системы. Таким образом, существенно упрощаетсяпроцесс внесения уточнений и дополнений в проект.
Приемлемая модель жизненного цикла разработки программного обеспечениядля проекта выбирается на основе анализа отличительных категорий проекта,которые включают в себя анализ требований, команды разработчиков, коллективапользователей, типа проекта и рисков.
В данном случае анализируются требования, коллектив пользователей,тип проекта и риски. Матрицы, предназначенные для осуществления процесса выборамодели жизненного цикла итогам исследования отличительных категорий проектабыли получены результаты, представленные в таблице 4.1.
Таблица 20 –Результаты выбора приемлемой модели жизненного цикла разработки программногообеспеченияХарактеристика Каскадная V-образная Прототипирование Спиральная RAD Инкрементная Требования 2 5 2 5 4 2 Участники команды разработчиков 6 6 4 6 3 6 Коллектив пользователей 1 2 3 1 2 Типы проектов и рисков 3 4 6 8 7 6 Итого 12 17 12 22 15 16

Анализ показал, что наиболее приемлемым в данном случае являетсявыбор спиральной модели жизненного цикла разработки программного обеспечения.Данная модель обеспечивает потребности организации, а также соответствует типувыполняемых работ./>4.2     Определение цели и области действияпрограммного проекта
При выполнении каждого проекта определяется, как минимум, однацель. Для большинства проектов характерны несколько целей. Иногда эти целиименуются заданиями проекта, либо используется собирательное название «миссияпроекта». В данном случае миссия проекта эквивалентна достижению целей изаданий проекта. Определение ясной и четкой миссии проекта является одним изпростейших и наиболее экономных действий, осуществляемых при разработке всегопрограммного проекта. Менеджмент программных проектов чаще всего связан сменеджментом ожиданий и предсказанием рисков.
Важно определить общую цель проекта, выраженную в легко понимаемыхи воспроизводимых терминах. Благодаря осознанию цели достигается компактноеопределение проекта.
Цель данного проекта: обеспечение финансовых органов муниципальныхобразований эффективным и удобным инструментом, позволяющим упростить процессыуправления бюджетными средствами и повысить прозрачность этих процессовпосредством создания информационной системы.
Относительно данного проекта можно сказать, что он будет:
-         внутренним;
-         предназначендля автоматизации процесса планирования бюджета;
-         использоваться в финансовом управление администрации Новоегорлыкскогосельского поселения.
Проект не будет:
-         предназначаться для использования всемиотделами администрацииНовоегорлыкского сельского поселения;
-         предназначенным для обеспечения доступак информации не из администрации./>4.3     Создание структуры пооперационногоперечня работ
Под операцией понимается деятельность или процесс, выполнение которыхтребует некоторых временных и материальных затрат.
Структура пооперационного перечня работ представляет собой инструмент,применяемый для документирования всех рабочих операций, которые должны бытьвыполнены при разработке и поставке программного обеспечения надлежащимобразом. При использовании такой структуры разработчикам проекта значительнопроще разделить весь рабочий процесс на ряд небольших, хорошо определенныхзадач и действий. В частности, при наличии структуры пооперационного перечняработ облегчается планирование, в том числе календарное, и оценивание. Подобнаяструктура представляет собой основу для осуществления мониторинга проекта, атакже для создания хронологической коллекции данных.
Структура пооперационного перечня работ представляет собой иерархическийперечень рабочих действий, необходимых для завершения проекта. В этот переченьвключаются управленческие, административные, интегральные и программистскиедействия, с помощью которых:
-         выполняется разработка программногообеспечения;
-         происходит управление проектом;
-         обеспечивается поддержка для всехдействий, выполняемых в ходе осуществления проекта;
-         выполняются любые другие действия,требуемы для достижения целей проекта и удовлетворения требованийпользователей.
Структура пооперационного перечня работ создания информационнойсистемы представлена на рисунке 4.1.
Структура пооперационного перечня работ представляет собой описаниевыполняемой работы, разбитой на отдельные ключевые компоненты вплоть до самогонижнего уровня. Таким образом, при разбиении проекта на отдельные управляемыечасти размер каждого компонента может быть изменен, а также возможна оценкатрудозатрат, понесенных на этапе разработки этого компонента.
/>
Рисунок 4.1 – Схема декомпозиции работ
Структура пооперационного перечня работ является ключевым рабочимпродуктом, необходимым при выполнении оценок в рамках программного проекта. Длякаждого различного жизненного цикла существует уникальных пооперационныйперечень работ, который может использоваться в самой организации./>4.4     Идентификация задач и действий
Действие – элемент работы, выполняемой в ходе осуществления проекта.Для действия характерна ожидаемая длительность и затраты, а также прогнозируемыетребования к ресурсам. Диаграммы являются графическим средством отображениясодержащейся в проектном файле информации. Из диаграмм можно получить визуальноепредставление о последовательности задач, их относительной длительности идлительности проекта в целом.
В качестве программы управления проектами была выбрана MicrosoftOffice 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 –Денежный поток по каждому месяцу
Месяц 1 2 3 4 5 6
Rk
-20000
-25000
-30000
-10000 25000 30000 35000
NPV=2170 рублей.
Поскольку величина чистой текущей стоимости 2170 рублей, то есть NPV> 0, то проект можно принять.
Коэффициент возврата инвестиций ROIпозволяет оценитьприбыльность инвестиций, вложенных в проект.
Формула для расчета коэффициента возврата инвестиций:
/>
 
где /> – чистый приведенный доход;
/> – стартовые инвестиции, рубли;
При ROI > 100% – инвестиции прибыльны, при ROI
/>.
Поскольку 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 Server2000. Учебный курс 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 стр.: ил.