Автор: Пользователь скрыл имя, 28 Февраля 2012 в 13:01, курсовая работа
Основная цель разработки и последующего совершенствования автоматизированной информационной системы (АИС) налоговых органов – построение функционально полной информационной системы, объединяющей все структуры налоговой системы на базе единой вычислительной сети с поэтапной интеграцией в единое информационное пространство административных органов федерального, регионального и территориального уровней, а также других заинтересованных организаций (ГУВД, судов, таможни, банков и др.).
1. Понятие, концепции, проблемы налоговых информационных систем.
2. Роль и место информационных систем в деятельности налоговых органов.
3. Основные требования к АИС налоговых органов.
4. Основные принципы построения и использования ИС в налогообложении.
На стратегию информатизации главным образом оказывают влияние: накопленный парк аппаратных и программных средств, уровень подготовки конечных пользователей, позиция высшего руководства организации.
Решение задачи информатизации подобного класса предполагает наличие критериев оптимизации и ограничений. Критериями оптимизации здесь являются:
- функциональная полнота;
- модифицируемость;
- надежность функционирования;
- быстродействие;
- минимизация затрат на стоимость: аппаратных средств, прикладных систем, сопровождения системы, развития системы, которые составляют Совокупную Стоимость Владения АИС.
В настоящее время задача выбора оптимальной платформы вычислительной системы неформализуема. Обычно на практике критерии и требования выбираются эмпирически с учетом специфики проблемной области и условий, сложившихся к моменту начала разработки проекта.
Для налоговых органов требования к АИС включают следующие группы:
- к системе в целом;
- по соответствию стандартам;
- к аппаратной платформе и системному программному обеспечению;
- к локальным сетям;
- к интерфейсу с пользователем;
- к функциональным компонентам;
- к системам доступа к данным;
- к совместимости с другими информационными системами;
- к унифицируемости структур архитектуры АИС (с целью минимизации Совокупной Стоимости Владения и конструирования узлов необходимой функциональности из конечного набора унифицированных структур);
- к безопасности системы;
- к администрированию системы;
- к пользователям системы и т.д.
Рассмотрим подробнее наиболее ключевые из них.
Требования к системе в целом носят в основном декларативный характер и накладывают ограничения на генеральное направление работ по созданию системы. Для налоговых органов это:
- непротиворечивость АИС общегосударственным нормативным документам, регламентирующим деятельность налоговых органов;
- возможность эволюционирования АИС, модификации и усовершенствования системы, а не эксплуатация одной и той же версии системы при изменении требований и не замена одной системы совершенно другой;
- опора при разработке АИС на международные и промышленные стандарты;
- обеспечение расширяемости системы, т.е. возможность добавления новых компонент в уже существующую систему.
Учет фактических и промышленных стандартов в сфере информатизации позволяет первоначально ориентироваться на наиболее распространенные технические и программные средства. Это в значительной мере позволит снизить затраты на сопровождение и развитие системы обработки данных, кроме того, расширит круг специалистов, которые могут быть привлечены к техническому обслуживанию системы, разработке и развитию прикладных программных средств, а также обеспечит большую свободу наращивания мощности технических и системных программных средств.
Наиболее адекватным представляется принцип разработки АИС налоговой службы на основе концепции открытых систем.
Открытой системой называется всесторонний и согласованный набор международных стандартов, определяющих интерфейсы, обслуживание и форматы, с помощью которых осуществляются совместимость и переносимость приложений.
Такой принцип разработки позволяет достичь:
- мобильности приложений – перенос приложений на различные аппаратные платформы, в операционные системы, сетевые протоколы;
- интероперабельности – определение по стандартам общих форматов и интерфейсов взаимодействия программных систем;
- снижения стоимости системы – интеграция программных систем, поддерживающих общепринятые стандарты, уменьшающей стоимость приложений для конечного пользователя;
- снижения риска выбора программного продукта – использование стандартов, освобождающих разработчика от привязанности к конкретному программному продукту;
- увеличения времени жизни системы – соответствие стандартам, что уменьшает риск быстрого устаревания системы;
- наращивания вычислительной мощности прикладной информационной системы в соответствии с потребностями организации и ее финансовыми возможностями.
К немаловажным требованиям к АИС налоговых органов следует отнести обеспечение информационной безопасности, под которой понимается защищенность информации и АИС в целом от случайных или преднамеренных естественных или искусственных воздействий, чреватых утечкой или потерей данных.
Требования по безопасности системы направлены, прежде всего, на обеспечение:
- доступности данных – возможности за приемлемое время получить необходимый информационный ресурс;
- целостности ресурсов – актуальности и непротиворечивости информации, ее защищенности от разрушения и несанкционированного изменения;
- конфиденциальности – защиты от несанкционированного прочтения данных.
3.4. Основные принципы построения и использования ИС в налогообложении.
Разработка АИС налоговых органов базируется на технологиях открытых систем класса «клиент – сервер» с использованием международных стандартов и протоколов. В основе технологии разработки АИС налоговых органов лежит концепция жизненного цикла программных систем (ПС).
Модель жизненного цикла ПС состоит из четырех этапов: 1) анализ; 2) проектирование; 3) кодирование; 4) модификация и представляет собой логически связанную последовательность основных этапов разработки программного обеспечения – от появления необходимости его создания до отказа от использования и коренной модернизации в соответствии с новыми возможностями технических и программных средств и существенным изменением основных требований.
Анализ. Целью анализа является полное, последовательное, доступное для чтения и обзора описание задач, позволяющее проводить сравнение с реальными условиями. Результаты анализа часто используются затем для описания основных функций системы. Цели анализа и проектирования различны. При анализе делаются попытки смоделировать окружающий мир, идентифицируя классы и объекты, отражающие сущность предметной области. Анализ определяет требуемое поведение системы, которая создается, в то время как при проектировании разрабатываются чертежи этой системы.
Проектирование. Проектирование можно начинать, базируясь на имеющемся понимании требований к системе в данный момент времени. После получения первых результатов необходимо изучить достоинства и недостатки проектных решений и определить соответствие их выработанным на этапе анализа требованиям. Предлагается при проектировании использовать разумно выбранные прототипы, каждый из которых моделирует одну из частей системы, при этом совокупность прототипов наращивает со временем свои функциональные возможности. Признаком окончания проектирования является получение таких представлений о процессе проектирования, которые не требуют дальнейшей декомпозиции, так как оказываются достаточно просты, а соответствующее им программное обеспечение можно разработать на основе типовых модульных компонентов.
Кодирование. Этап кодирования состоит из работ по написанию программ, их тестированию и интеграции в единый программный комплекс. Преимущества данного процесса следующие:
- широкая обратная связь пользователя с системой, когда она необходима;
- пользователю могут быть представлены последовательные версии различных структур системы, внедрение которых позволяет обеспечивать плавный переход от старой организации труда к новым компьютерным технологиям;
- поэтапность внедрения отдельных компонентов системы, уменьшающих вероятность срыва всего проекта при запаздывании его отдельных частей;
- неоднократное тестирование интерфейса ядра проекта;
- более равномерное по времени распределение ресурсов для тестирования;
- специалисты, занимающиеся разработкой системы на ранних стадиях, могут видеть результаты работы системы, не дожидаясь завершения всего проекта.
Модификация. Программа, которая используется для решения практических задач управления, должна подвергаться постоянным изменениям по мере развития самой системы управления, изменения окружающей среды, получения более полного представления о требованиях к программному продукту на основе практики его промышленного использования, появления новых технических и программных возможностей. Вместе с тем модификация программы не должна, приводить к ее необоснованному усложнению.
Выбор архитектуры АИС. АИС налоговых органов можно представить как совокупность программных подсистем, решающих определенный круг задач. Подсистемы состоят из взаимодействующих компонентов. Архитектурой АИС называется распределение функций по ее подсистемам и компонентам, точное определение границ подсистем и их информационные взаимодействия, а также распределение хранения и исполнения этих подсистем и компонентов по различным ЭВМ, объединенным в локальную или глобальную вычислительную сеть. Изменение архитектуры АИС при прочих равных условиях может изменять в сотни раз суммарные затраты на разработку. Поэтому правильный выбор архитектуры АИС – наиболее эффективный способ снижения стоимости разработки и эксплуатации всей системы.
С целью эффективного управления информационно-вычислительными ресурсами в распределенной системе за основу архитектуры АИС налоговых органов берется трехуровневая модель «клиент - сервер», известная как модель сервера приложений.
Здесь компонент представления (клиент третьего уровня) обеспечивает пользовательский интерфейс, функции ввода и отображения данных; прикладной компонент (сервер второго уровня) – функциональную логику, характерную для налоговой инспекции; компонент доступа к ресурсам (сервер первого уровня) – фундаментальные функции хранения и управления данными (базами данных, файловыми системами и т.д.). Отдельные компоненты могут располагаться как на одном компьютере, так и на разных компьютерах, обеспечивая тем самым распределенную обработку информации.
Основная цель выбора такой модели – отделение компонентов, реализующих прикладные функции, которые определяются налоговым законодательством. Это позволяет в случае изменения последнего корректировать только прикладную логику соответствующих компонентов и не затрагивать пользовательский интерфейс. Такой принцип построения архитектуры АИС существенно экономит ресурсы на модификацию и упрощает администрирование и сопровождение.
Методология разработки АИС. На каждом этапе модели жизненного цикла в соответствии с решаемыми задачами применяются определенная методология и инструментальные средства.
Методология составляет основу для проектирования и разработки прикладных программ. Она задает определенную последовательность проектных процедур. Если тщательно соблюдать ее, то с большой вероятностью в итоге получится хорошо работающее приложение. Методологии разработки помогают охватить все важные шаги или элементы, которые необходимо надлежащим образом учитывать.
Главное достоинство использования методологий разработки заключается в том, что они обеспечивают прогнозирование результатов, контроль и позволяют разработчикам координировать свои действия.
Методология представляет собой: тесно связанные, предписанные конкретные последовательности шагов; конкретные данные, подлежащие накоплению на каждой стадии; критерии завершения работ в контрольных точках; решения, которые нужно принять перед выбором между альтернативами проектирования; конкретные поименованные стандарты и другие детали, которые могут появиться при построении приложений.
Методологии можно разделить на два класса по заложенному в них принципу декомпозиции – деления сложной системы на менее сложные подсистемы:
1) структурные методологии, реализующие принцип алгоритмической декомпозиции: АИС делится на модули, каждый из которых реализует некоторую часть общего технологического процесса. Наиболее известны и распространены: методология структурного анализа и проектирования Росса – SADT; методологии, использующие в качестве центрального метода моделирование потоков данных: Гейн/Сарсон, ДеМарко, Йордон; методологии моделирования данных: Варнье/Орр, ЕR-моделирование Чена;
2) объектно-ориентированные методологии, реализующие принципы объектной декомпозиции: АИС представляет собой совокупность взаимодействующих объектов, соответствующих словарю предметной области. Наиболее известны и распространены объектные методологии следующих авторов: Буч, Рамбо, Шлеер/Меллор, Код/Йордон, универсальный язык моделирования
Результатом использования этих методологий на каждом этапе является построение набора моделей – графических спецификаций, которые содержат наглядные описания различных аспектов разрабатываемых прикладных систем.
При разработке таких сложных и уникальных проектов, как АИС налоговых органов, необходимо использовать методологии обоих классов, поскольку алгоритмическая декомпозиция концентрирует внимание на порядке происходящих событий, а объектная декомпозиция придает особое значение факторам, либо вызывающим действия, либо выступающим объектами приложения этих действий.