Основные подходы и принципы проектирования АИС налоговых органов

Тема 3. Методология создания автоматизированной информационной системы налоговых органов

Основные подходы и принципы проектирования АИС налоговых органов

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

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

• разработка, создание, информационное наполнение и последую­щая поддержка системы баз данных;

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

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

Модель жизненного цикла ПС представляет собой логически свя­занную последовательность основных этапов разработки программно­го обеспечения — от появления необходимости его создания до отказа от использования и коренной модернизации в соответствии с новыми возможностями технических и программных средств и существенным изменением основных требований. Общая модель жизненного цикла со­стоит из четырех этапов (рис. 3.1).

Рис. 3.1. Жизненный цикл программной системы

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

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

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

•широкая обратная связь пользователя с системой, когда она необ-
ходима;

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

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

•интерфейс ядра проекта проходит тестирование неоднократно;

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

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

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

Для успешной разработки совершенствования АИС налоговых ор­ганов необходимы общие принципы по: выбору архитектуры АИС; выбору методологии разработки АИС; применению CASE-средств.

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

Опыт показывает, что только изменение архитектуры АИС при про­чих равных условиях может изменять в сотни раз суммарные затраты на разработку. Поэтому правильный выбор архитектуры АИС — наи­более эффективный способ снижения стоимости разработки и эксплуа­тации всей системы.

С целью эффективного управления информационно-вычислитель­ными ресурсами в распределенной системе за основу архитектуры АИС . налоговых органов берется трехуровневая модель «клиент — сервер», известная как модель сервера приложений (Application Server — AS) (рис. 3.2.).

Рис. 3.2. Модель «клиент — сервер»

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

Следует отметить, что отдельные компоненты могут располагаться как на одном компьютере, так и на разных компьютерах, обеспечивая тем самым распределенную обработку информации. Компонент пред­ставления часто располагается на персональном компьютере или тер­минале, прикладной компонент выполняется сервером среднего уров­ня под управлением операционной системы Unix или Windows NT, a компонент доступа к данным и сами данные располагаются либо на мощных Unix-серверах, либо на больших или мини-ЭВМ.

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

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

Методологии можно разделить на два класса по заложенному в них принципу декомпозиции — деления сложной системы на менее слож­ные подсистемы:

1) структурные методологии, реализующие принцип алгоритмичес­кой декомпозиции: АИС делится на модули, каждый из которых реали­зует некоторую часть общего технологического процесса. Наиболее известны и распространены:

 • методология структурного анализа и проектирования Росса — SADT (Structured Analysis and design Technique, Ross);

• методологии, использующие в качестве центрального метода моделирование потоков данных: Гейн/Сарсон (Gane/Sarson), ДеМарко (DeMarco), Йордон (Yourdon);

• методологии моделирования данных: Варнье/Орр (Warmer/Orr),

ER-моделирование Чена (Chen);

2) объектно-ориентированные методологии, реализующие принци­пы объектной декомпозиции: АИС представляет собой совокупность взаимодействующих объектов, соответствующих словарю предметной области. Наиболее известны и распространены объектные методоло­гии следующих авторов:

• Буч (Booch);

• Рамбо (Rumbaugh, OMT);

• Шлеер/Меллор (Shlaer/Mellor);

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

Применение CASE -средств. Для автоматизированной поддержки всех этапов разработки АИС используются CASE-средства (Computer Aided System/Software Engineering).

 К преимуществам CASE-средств при разработке информационных систем (ИС) относятся:

• сокращение сроков и затрат за счет автоматизации операций
проектирования и кодирования, сведения к минимуму перепроектирования;

• улучшение качества проекта в результате применения современ­ных методов проектирования, формализации проекта, его автоматизи­рованной верификации;

• обеспечение согласованности и полноты документации проекта;

•     возможность повторного использования проекта для новых ИС.  CASE-средства делятся на два класса:

 отдельные инструментальные средства, предназначенные для автоматизации разработки АИС на отдельных этапах: CASE верхнего

 уровня поддерживают этапы анализа и проектирования, CASE нижнего уровня — этапы кодирования и тестирования;

 • интегрированные системы поддерживают разработку АИС на всех

этапах.

        3. 2. Технология разработки АИС налоговых органов

Определив методологию проектирования АИС налоговых органов и средства разработки и поддержания проекта, рассмотрим технологический процесс проектирования системы. Разработка автоматизированной системы для Управления ФНС России осуществляется на нескольких стадиях: разработки и постановки задачи (комплекса задач); исследования предметной области; разработки эскизного проекта на основании технического задания; рабочего проектирования; разработ­ки методики проведения испытания автоматизированной системы; экс­плуатации программного и информационного обеспечения; дальнейшего развития и модернизации системы.

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

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

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

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

Значительное место в проекте занимают пользовательские информационно-справочные системы:

• базы данных законодательных и нормативных актов по налогообложению;

• БД по общеправовым вопросам;

• БД инструктивных и методических материалов;

• разнообразные справочники и т.д.

Особенностью этих баз данных является то, что они активно используются практически во всех подразделениях налоговой инспекции. Существует ряд систем, ведущих и поддерживающих такие БД: Консуль­тант Плюс, Гарант, Дело и право, Юсис, 1C,. АРБТ, Банковские техно­логии и пр.

 Рабочее проектирование может выполняться соисполнителями из сторонних организаций (контрагентами) совместно с сотрудниками налоговой инспекции информатизации. Привлечение к разработке про­екта сторонних организаций обосновывается необходимостью прове­дения значительных объемов оригинального проектирования для от­дельных управлений, комплексации различных систем в единую авто­матизированную систему, созданием системы электронного информа­ционного хранилища (ЭИХ) и возможностью сетевого доступа к ло­кальным базам данных управлений и налоговых инспекций.

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

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

Эксплуатация программного и информационного обеспечения начинается с обучения специалистов управления и передачи технической документации, разработанной на стадии рабочего проектирования. Обучение производится специалистами Управления информатизации с привлечением организаций-разработчиков.

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