Методология создания автоматизированной информационной системы налоговых органов (стр. 1 из 5)
Тема 3. Методология создания автоматизированной информационной системы налоговых органов
3.1. Основные подходы и принципы проектирования АИС налоговых органов
Единая информационная система налоговых органов относится к классу больших и сложных информационных систем. Создание программно-технического комплекса, обслуживающего такую систему, предполагает решение следующих проблем:
• информационное объединение налоговых органов федерального,
регионального и местного уровней через телекоммуникационные сети
и обеспечение возможности доступа к информационным ресурсам каждой из них;
• разработка, создание, информационное наполнение и последующая поддержка системы баз данных;
• оснащение налоговых органов вычислительными программно-техническими комплексами с развитой функционально ориентированной
периферией;
• разработка прикладных программных средств, полностью охватывающих функциональные задачи налоговых органов всех уровней.
Модель жизненного цикла ПС представляет собой логически связанную последовательность основных этапов разработки программного обеспечения — от появления необходимости его создания до отказа от использования и коренной модернизации в соответствии с новыми возможностями технических и программных средств и существенным изменением основных требований. Общая модель жизненного цикла состоит из четырех этапов (рис. 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-средств при разработке информационных систем (ИС) относятся:
• сокращение сроков и затрат за счет автоматизации операций
проектирования и кодирования, сведения к минимуму перепроектирования;