Geum.ru

Отчет о нир листов

Вид материалаОтчет

Содержание


3Содержание Мероприятий
3.2Доработка информационных систем
3.3Внедрение посреднического ПО
Подобный материал:
1   ...   39   40   41   42   43   44   45   46   47

.3Содержание Мероприятий

.3.1Мероприятия по миграции


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

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

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

Рефакторинг может осуществляться:
  • Путем переноса системы на другую прикладную (интеграционную) платформу, реализующую стандартизованные Сводом механизмы взаимодействия, в т.ч. с перекомпиляцией (пересборкой) системы из исходного кода (при его наличии).
  • Путем воспроизведения прикладного кода на базе другой технологии (языка программирования и т.п.), в т.ч. с использованием автоматизированных систем преобразования кода и извлечения знаний о системе.
  • Путем создания «компонентных оболочек», полностью инкапсулирующих существующие компоненты системы и обеспечивающих предусмотренные Сводом способы взаимодействия.

Как правило, миграция систем предполагает также миграцию накопленных в системах массивов данных. Миграция массивов данных может выполняться следующими способами:
  • Однократным переносом агрегированных данных, в т.ч. с использованием специально разработанных программ и сценариев извлечения агрегированных данных. Применяется в случаях, когда данные в унаследованной системе используются только для построения ограниченного комплекса сводных отчетов.
  • Однократным переносом полного массива данных в новую систему с применением программ преобразования данных (в т.ч. специально разработанных), автоматизированных сценариев и т.п.
  • Путем реализации постоянного программного компонента-адаптера обеспечивающего извлечение необходимых данных из массива по запросам через стандартизованный интерфейс.
  • Ручным переносом данных с использованием пользовательских интерфейсов унаследованной и заменяющей ее систем или путем файлового обмена, в т.ч. с применением программ ручной обработки данных (текстовых редакторов, преобразователей формата и т.п.)

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

.3.2Доработка информационных систем


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

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

.3.3Внедрение посреднического ПО


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

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

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

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