Главная

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

• к системе в целом;
• по безопасности системы;
• к аппаратной части и системному программному обеспечению: серверные платформы, платформы клиентов, сети и телекоммуникации;
• к интерфейсу с пользователем;
• к системам хранения данных, СУБД и хранилищам данных;
• к совместимости с другими ИС;
• к администрированию системы и т.д.

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

Для налоговой инспекции это такие требования:

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

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

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

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

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

Наиболее адекватным представляется принцип разработки АИС налоговой инспекции на основе концепции открытых систем.

Открытой системой, по определению IEEE - Institute of Electrical & Electronics Engineers (Институт инженеров по электротехнике и радиоэлектронике - основная инстанция по утверждению международных стандартов в этой области), называется всесторонний и согласованный набор международных стандартов, который определяет интерфейсы, обслуживание и форматы, направленные на достижение совместимости и переносимости приложений, данных и трудовых ресурсов.

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

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

Стандарты портируемости приложений (их платформной независимости) были определены IEEE. Согласно этим определениям существует несколько градаций портируемости, например стандарт IEEE 1003.1. Portable Operating System Interface for Computing Environments (POSIX) - интерфейс переносных операционных систем для вычислительных сред, который обеспечивает платформонезависимость исходных кодов приложений. Это означает, что исходные коды приложений, разработанных в соответствии с этим стандартом, можно использовать на разных платформах. Для этого требуется предварительно откомпилировать исходные коды приложений на требуемой платформе. Такую степень платформонезависимости обеспечивает применение в разработке стандартных языков программирования, поддерживаемых ANSI и ISO. При этом недопустимо применять при кодировании и компиляции приложений специальные, нестандартные утилиты или средства разработки;

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

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

Требования к безопасности системы

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

Требования к безопасности системы направлены в первую очередь на обеспечение:

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

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

• на уровне операционной системы;
• от несанкционированного доступа на уровне программного обеспечения промежуточного слоя и прикладных компонентов АИС;
• на уровне СУБД;
• при обмене в распределенных системах, включая криптографические функции;
• на уровне специальных программных средств (например, средств защиты от программных вирусов);
• на уровне администрирования средств безопасности.

Требования к функциональным компонентам

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

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

Требования к корпоративной системе хранения данных

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

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

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

• Эффективность. В данном контексте эффективность средств хранения данных характеризуется тремя показателями: емкостью (Гбайт), скоростью обмена (Мбайт/с), количеством операций ввода/вывода в секунду.
• Масштабируемость. Имеется в виду возможность экономичного повышения эффективности по мере возрастания корпоративных требований.
• Высокая доступность. Требуется обеспечить как бесперебойную работу накопителей, так и их сопряжение со средствами резервного копирования, гарантирующими долговременную сохранность данных.
• Способность к экономически оправданному эволюционированию вместе с другими компонентами информационной системы.
• Открытость, следование принятым стандартам, возможность обеспечения поддержки перспективных стандартов.
• Прозрачность доступа. Приложения должны единообразно работать с данными независимо от платформы хранения и платформы исполнения.
• Управляемость. Под управляемостью здесь понимаются простота установки, экономичность и простота эксплуатации. Последнее требование может быть выполнено только при наличии средств централизованного управления системой хранения данных, позволяющих производить мониторинг производительности системы, переконфигурирование и другие административные процедуры.

Требования к интерфейсу пользователя

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

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

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

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

1. Данные набиваются только в те строки, в которых что-то проставлено (пустые строки нулями не заполняются).

2. Для каждой строки, в которой стоит какое-то значение, оператор вводит идентификатор этой строки и само стоящее в ней значение.

3. Правила арифметической проверки задаются также с помощью идентификаторов строк (например, содержимое 11-й строки должно равняться сумме значений, стоящих в 7-й и 10-й строках).

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

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

Качество прикладных компонентов

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

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

Неудовлетворительное качество программного обеспечения обусловливается следующими причинами:

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

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

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

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

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

• средств измерений (тестирование, испытание, расчет объемно-структурных характеристик, сбор и обработка мнений экспертов и т.д.);
• средств оценки значений показателей качества программного обеспечения;
• автоматизированных средств принятия решений о качестве программного обеспечения;
• средств информационного обеспечения (сбор и переработка информации, базы знаний и данных, абстракторы информации и т.п.).

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

Параметризация

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