Жизненный цикл аис

Вы хотите

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

— Расширить спектр предоставляемых банковских услуг для всех целевых категорий клиентов: физические лица, средний и малый бизнес, компании и холдинги, банки-корреспонденты.

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

— Забыть о рутинной работе своего бэк-офиса путем внедрения сквозных бизнес-процессов и автоматизации узких мест.

— Реализовать современную инфраструктуру обработки банковских документов с удобным интерфейсом поиска данных.

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

— Оперативно выводить на рынок новый конкурентоспособный банковский продукт или услугу.

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

— Получить систему, которая будет развиваться в соответствии с изменениями Вашего бизнеса.

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

— Повысить прозрачность и управляемость, сократить управленческие издержки и риски.

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

— Приобрести в нашем лице стратегического партнера с опытом работы на банковском рынке с 1990 года.

Мы имеем честь предложить Вам

Централизованную автоматизированную банковскую систему «БАНК 21 ВЕК», предназначенную для развития бизнеса многофилиального банка любого масштаба и увеличения его конкурентных преимуществ за счет уникальной архитектуры, использования СУБД Oracle и собственных ноу-хау в реализации бизнес-логики системы.

Ключевые особенности системы

— Широта покрытия предметной области.

— Поддержка всех глав плана счетов кредитных организаций, налоговый и управленческий учет. Отчетность по МСФО.

— Единое информационное пространство – единый каталог клиентов и контрагентов, возможность обслуживания в любом филиале, отделении, операционной кассе. Встроенная CRM.

— Возможность получения всей необходимой аналитической информации непосредственно из ЦАБС. Отсутствие необходимости использования всевозможных конверторов для связи с «Хранилищем». И, как следствие — возможность получения как консолидированной, так и раздельной пофилиальной финансовой и управленческой отчетности в онлайн режиме.

— Обеспечение единых интегрированных каналов продаж (филиалы, отделения, операционные кассы, пункты самообслуживания, Интернет, мобильные телефоны и т.д.).

— Прозрачность межфилиальных расчетов, возможность организации различных схем расчетов («звезда», «централизованная» и др.)

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

— Эффективные средства управления правами доступа, разные варианты доступа пользователей к данным в ЦАБС исходя из многофилиальной структуры:

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

— Единое администрирование системы. Возможность делегирования определенных прав на места для локальной настройки и ведения своих пользователей в филиале.

— Удобный интерфейс для комфортной работы пользователей, сопряжение с офисными пакетами (MS Office, OpenOffice).

— Масштабируемость системы: «БАНК 21 ВЕК» может работать на любых современных серверах под управлением любой современной операционной системы. В настоящий момент есть успешные внедрения как на серверах класса офисного решения (10-15 пользователей), так и полномасштабные кластерные решения.

— Защищенность от несанкционированного доступа и мониторинг действий каждого пользователя. Разделение функций администратора Системы и администратора безопасности. Возможность использование ЭЦП в технологических процессах.

— Уникальная реализация – возможность одновременной работы пользователей в двухзвенной или трехзвенной архитектуре с web-интерфейсом, используя преимущества той или иной технологии в зависимости от обстоятельств.

— Высочайшая производительность при разумных требованиях к аппаратному обеспечению и каналам связи.

— Сочетание достоинств тиражируемой системы с преимуществами заказного проекта.

— Открытость системы: «БАНК 21 ВЕК» передается с исходными текстами, API и полностью документированной базой данных.

Опыт

В настоящее время ЦАБС «БАНК 21 ВЕК» эксплуатируется в более чем 130 российских банках и дочерних структурах иностранных банков. Компания имеет большой опыт по поставке отдельных решений и их интеграции с используемыми банком АБС, бизнес приложениями и системами электронной коммерции. По данным авторитетных рейтингов, Компания ИНВЕРСИЯ на протяжении последних 5-ти лет входит в число лидеров среди российских разработчиков и поставщиков программного обеспечения для финансово-кредитных организаций и опирается в своей деятельности на стабильно растущую клиентскую базу.

Клиенты

Контактная информация

СОЗДАНИЕ И ЭКСПЛУАТАЦИЯ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ

Жизненный цикл (ЖЦ) — период создания и использования автоматизированной информационной системы АИС, охватывающий ее различные состояния, начиная с момента возникновения необходи­мости в данной автоматизированной системе и заканчивая моментом ее полного выхода из употребления у пользователей.

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

Основными работами, выполняемыми на стадиях и этапах проектирования, можно считать следующие:

/ стадия — предпроектное обследование:

1-й этап — сбор материалов для проектирования — формирование требований, изучение объекта проектирования, разработка и выбор варианта концепции системы;

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

// стадия — проектирование:

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

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

/// стадия — ввод системы в действие:

1-й этап — подготовка к внедрению — установка и ввод в эксплуатацию технических средств, загрузка баз данных и опытная эксплуатация программ, обучение персонала;

2-й этап — проведение опытных испытаний всех компонентов системы перед передачей в промышленную эксплуатацию, обучение персонала;

3-й этап (завершающая стадия создания АИС) — сдача в промышленную эксплуатацию; оформляется актами приема-сдачи работ.

IV стадия — промышленная эксплуатация — кроме повседневного функционирования включает в себя сопровождение программных средств и всего проекта, оперативное обслуживание и администри­рование баз данных.

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

Существующие варианты ЖЦ определяют порядок исполнения этапов в ходе разработки АИС, а также критерии перехода от этапа к этапу. Наибольшее распространение получили три следующие модели ЖЦ

1. Каскадная модель предполагает переход на следующий этап после полного окончания работ по предыдущему этапу.

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

3. Спиральная модель делает акцент на начальные этапы ЖЦ: анализ требований, проектирование спецификаций, предварительное и детальное проектирование. На этих этапах проверяется и обосновывается реализуемость технических решений путем создания прототипов. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии АИС. На нем уточняются цели и характеристики проекта, определяется его качество, панируются работы следующего витка спирали. Таким образом углубляются и последо­вательно конкретизируются детали проекта в результате выбирается обоснованный вариант, который доводится до реализации.

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

— накопление и повторное использование проектных решений, средств проектирования, моделей и прототипов АИС;

— ориентация на развитие и модификацию системы и технологии, а в процессе их проектирования;

— анализ риска и издержек в процессе проектирования систем. Главная особенность разработки АИС состоит в концентрации

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

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

Условными фазами или стадиями жизненного цикла ИС являются анализ, проектирование, реализация проекта, внедрение (ввод в эксплуатацию), сопровождение (эксплуатация, наращивание возможностей — модернизация), вывод из эксплуатации (замена):

анализ — определение того, что должна делать система;

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

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

внедрение — установка и ввод системы в действие;

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

    1. Стандарты жизненного цикла ис:

ГОСТ 34.601-90 (не вполне подходит для проведения разработок в настоящее время: многие процессы отражены недостаточно, а некоторые положения устарели).

ISO/IEC 12207:1995. «Information Technology — Software Life Cycle Processes» (российский аналог — ГОСТ Р ИСО/МЭК 12207-99, введен 1 июля 2000 г.) является основным нормативным документом, регламентирующим состав процессов жизненного цикла ИС. Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ИС.

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

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

Модель жизненного цикла информационной системы включает в себя:

  • последовательность выполняемых стадий;

  • результаты выполнения работ на каждой стадии;

  • ключевые события — точки завершения работ и принятия решений.

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

Стандарт ГОСТ Р ИСО/МЭК 12207-99 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.

Специфические (отраслевые) подходы к разработке программного обеспечения реализованы в концепциях жизненного цикла, в основе которых лежат требования ИСО 12207:

Rapid Application Development (RAD) – стадии анализ и планирование требований, проектирование, реализация, внедрение.

Custom Development Method (методика Oracle).

Rational Unified Process (RUP) – рациональный унифицированный процесс (IBM).

Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования (Microsoft).

Подход «кодирование и исправление» (code and fix) упрощенно может быть описан следующим образом. Разработчик начинает кодирование (написание программы) системы с самого первого дня ее разработки, не занимаясь серьезным проектированием. Все ошибки и недоработки обнаруживаются, как правило, к концу кодирования и требую исправления через повторное кодирование.

Экстремальное программирование (англ. Extreme Programming, XP). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведется с использованием последовательно дорабатываемых прототипов.

Основные требования к автоматизированной информационной системы налоговой инспекции

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

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

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

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

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

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

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

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

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

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

Открытой системой, по определению 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. Этим методом можно вводить любые формы, при этом оператор указывает номер строки и само значение только для тех строк, в которых что-то указано. Метод простой, обеспечивает скорость и позволяет использовать номера строк при задании правил вычисления.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Записи созданы 8837

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Похожие записи

Начните вводить, то что вы ищите выше и нажмите кнопку Enter для поиска. Нажмите кнопку ESC для отмены.

Вернуться наверх