CC BY
161
Палькин Е.А. Группы задач сопровождения в информационной системе
коммерческого банке Дата: 31/01/2011 Номер: (25) УЭкС, 1/2011
Аннотация: В статье рассматривается важность процесса сопровождения программного обеспечения и предлагается классификация задач сопровождения информационных систем с учётом специфики работы коммерческого банка
Abstract: The article discusses the importance of software maintenance and support problems. Also the article proposes the classification of the supporting information system tasks with the specifics of the commercial bank
Ключевые слова: группы задач сопровождения, сопровождение информационных систем, классификация задач сопровождения, сопровождение в коммерческом банке
Keywords: grouping of supporting tasks, information system supporting, classification of the supporting tasks, supporting in the commercial bank
Палькин Егор Александрович аспирант
Саратовский государственный социально-экономический университет
pea.@bankfininvest.ru
Выходные данные статьи: Палькин Е.А. Группы задач сопровождения в
информационной системе коммерческого банке // Управление экономическими системами: электронный научный журнал, 2011. - № 1 (25). - № гос. рег. статьи 0421100034/. - Режим доступа к журн.: http://uecs.mcnip.ru.
В настоящее время, по мере усложнения и роста стоимости используемых программных систем, все более актуальной становится проблема их сопровождения. С одной стороны наблюдается ускоренное развитие информационных технологий, требующее постоянных изменений в используемом программном обеспечении, с другой стороны жизненный цикл сложных программных систем должен быть достаточно длительным, чтобы успеть окупить затраты на их создание. По некоторым оценкам (например, Браудэ[1]) стоимость сопровождения современной информационной системы (ИС) может достигать 80% всех затрат жизненного цикла ИС. В то же время задачи этапа сопровождения ИС до настоящего времени остаются мало исследованными по сравнению с задачами этапов анализа требований, планирования и оценки проекта, проектирования, реализации и тестирования.
Сопровождение, по ГОСТ Р ИСО/МЭК 12207-99, - это внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям. Являясь неотъемлемой частью функционирования программных систем любого масштаба, особое значение процесс сопровождения приобретает в корпоративных системах. Яркий пример подобных программ -
банковские ИС. Их разветвлённая модульная структура со сложными механизмами сопряжения и высокими требованиями к надёжности данных не может оставаться работоспособной без систематического сопровождения, как внутреннего, так и внешнего.
Несмотря на то, что по данным известного информационного агентства CNews Analytics в 2008 году на российском рынке АБС совокупная доля основных разработчиков сократилась, доля собственных разработок банков из топ-50 (по версии РБК) не превышает 11%. Поэтому почти 9 из 10 банков нуждаются в полноценном сопровождении приобретённых универсальных систем. Поставляемые готовые решения для малых и средних банков находятся в постоянной доработке, учитывающей специфику предоставляемых на рынках продуктов и внутренних правил ведения бухгалтерского учёта.
Как уже было упомянуто, задачи сопровождения изучены слабо, отсутствует методика их классификации. В большинстве источников сопровождение предстаёт как второстепенный этап жизненного цикла ИС, в то время как на практике его значимость трудно переоценить. Как правило, эта задача рассматривается с точки зрения разработчика, в то время, как наибольший интерес для коммерческой структуры представляет видение процесса глазами потребителя. В стандарте ГОСТ Р ИСО/МЭК 14764-2002 описана структура модификаций, производимых в ходе сопровождения ИС, однако эта структура не учитывает специфики задач сопровождения корпоративных информационных систем. Заимствованный принцип разделения производимых в системе изменений на исправление ошибок и изменение функционала был учтён при разработке собственной классификации.
Потребность в классификации задач сопровождения ИС возникла при попытке оценки масштаба той или иной задачи. Среди множества однотипных задач встречались как конечные, так и промежуточные, что затрудняло их идентификацию и заставляло каждый раз искать способы их решения сначала. В то же время, определённые подходы к сопровождению ИС могут быть с успехом применены к разнородным задачам. Таким образом, классификация задач сопровождения является актуальной.
Информационная инфраструктура включает в себя аппаратное и программное обеспечение. В данной работе особенности построения и использования аппаратной части не изучаются, поэтому задачи сопровождения рассматриваются с точки зрения потребителя применительно к программной среде, которая включает в себя данные и механизмы их обработки. На рис. 1 показана иерархия задач сопровождения, учитывающая специфику банковских информационных систем. Все задачи сопровождения разбиты на три класса: развитие ИС, корректирующее сопровождение и сопровождение данных.
Рисунок 1. Классификации задач сопровождения ИС.
Развитие ИС предполагает частичную или полную модернизацию. В связи с этим, развитие ИС можно разделить на доработку ИС, разработку дополнительного ПО и замену ИС на более современную и функциональную. Адаптивное сопровождение это доработка программного продукта после поставки, позволяющее адаптировать его к новым условиям эксплуатации [2].
Полная модернизация является наиболее дорогостоящим этапом в развитии ИС. Активное развитие рынка и все возрастающие потребности банковского бизнеса предъявляют новые требования к системам автоматизации. Сегодня по некоторым данным свыше 13% коммерческих банков абсолютно не удовлетворены функционирующим ИТ-решением и в связи с этим планируют сменить АБС. Понимая, что переход на новую систему требует больших финансовых сложений, затрагивает весь персонал и заставляет на протяжении нескольких месяцев работать параллельно в двух АБС, можно утверждать, что переход на новую АБС в разы труднее, чем ее первоначальное внедрение при открытии банка.
Основным фактором, объясняющим стремление банка сменить функционирующую АБС, по опросу CNews Analytics, является моральное устаревание системы. Для
половины опрошенных ИТ-специалистов это вполне объективная причина модернизации информационного обеспечения банка. Полученные данные свидетельствуют о том, что банки все больше осознают необходимость выбора нового, перспективного решения, построенного на современной промышленной платформе, имеющего настраиваемый документооборот и GUI-интерфейс. Кроме того, банки нуждаются в надежном партнере, способном не только разработать, но и обеспечить качественное сопровождение и развитие решения, которое способно опережать рост бизнеса банка.
В случае разработки дополнительного ПО очевидны немалые преимущества: функционал дорабатывается под нужды персонала, необходимые требования будут квалифицированно оценены и выполнены, интерфейс и принципы работы останутся неизменными, доработка будет производиться с использованием существующих средств и методов. Данный вид модернизации может быть осуществлён в случае, если необходимый функционал требуется лишь на относительно короткий срок, или стандартное решение от разработчика отсутствует[3].
Корректирующее сопровождение направлено на выявление и устранение несоответствий и ошибок после поставки программного продукта.
Информационная система, как и любое ПО, не всегда даёт желаемый результат работы. Применительно к сопровождению ИС ошибка, это искажение кода программы или искажение данных, которые в ходе функционирования этой программы могут вызвать отказ или снижение эффективности функционирования. Под отказом ИС в общем случае понимают событие, заключающееся в нарушении работоспособности объекта. При этом критерии отказов, как признак или совокупность признаков нарушения работоспособного состояния программного обеспечения, определяются в зависимости от функционального назначения той или иной системы или модуля.
В качестве показателя степени тяжести ошибки, позволяющего дать количественную оценку тяжести проявления последствий ошибки, можно использовать условную вероятность отказа программного обеспечения при проявлении ошибки. Оценку степени тяжести ошибки как условной вероятности возникновения отказа, можно производить согласно ГОСТ 28195 - 89, используя метрики и оценочные элементы, характеризующие устойчивость программного обеспечения. При этом оценку необходимо производить для каждой ошибки в отдельности, а не для всей ИС.
Среди основных критериев работы банковской ИС можно обозначить надёжность и предсказуемость, которые трактуются как отсутствие недостатков, сбоев и явных ошибок. Недостатки зависят от субъективной оценки качества ИС банковскими служащими - основными пользователями системы, клиентами, получающими документы, подготовленные с использованием ИС, Центральным Банком и другими надзорными органами, в которые предоставляются отчётные данные.
При этом даже при наличии спецификации ошибок, выявленные на конечном этапе недостатки, говорят о низком качестве всей системы в целом. При таком подходе преодоление недостатков ИС, особенно на заключительном этапе проектирования, может приводить к снижению надёжности. Очевидно, что для разработки ответственного и безопасного ПО такой подход не годится, однако проблемы наличия ошибок в спецификациях, субъективного оценивания пользователем качества программы существуют и не могут быть проигнорированы[4]. В банке должна быть разработана система некоторых ограничений, которая бы учитывала эти факторы при разработке и сопровождении ИС. Для обычных программ все проблемы, связанные с субъективным оцениванием их качества и наличием ошибок, скорее всего, неизбежны.
Возникающие ошибки ИС предлагается разделить на ошибки функциональности, надёжности, удобства использования, эффективности, мобильности. При этом сопровождение каждой из них может быть как реактивным - в виде реакция на выявленные ошибки, так и профилактическим, которое применяется в особо ответственных модулях и системах во избежание возможных (ещё не возникших) проблем.
В настоящее время банковские ИТ-структуры осознали преимущества централизованной системы отслеживания и решения проблем и ошибок. Система отслеживания ошибок -это прикладная программа, разработанная с целью помочь разработчикам программного обеспечения учитывать и контролировать ошибки, найденные в программах, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий. Главный элемент такой системы - это заявка, содержащая основные параметры ошибки и этапы её устранения. База данных заявок является одновременно и классификатором найденных ошибок и базой знаний по исправлениям и доработкам. Система позволяет организовать эффективный процесс сопровождения с сильной обратной связью.
Сопровождение данных. Важной спецификой корпоративных ИС является значительно превышение продолжительности жизненного цикла (ЖЦ) данных над продолжительностью ЖЦ программной среды, технологий обработки, бизнес логики и т.д.[5] Поэтому целесообразно вынести поддержку данных в отдельный класс задач, состоящий из контроля целостности данных, поддержки актуальности данных и резервного копирования и восстановления, а также переноса данных из одной системы в другую.
Информационная инфраструктура коммерческого банка изобилует разнородными базами данных, справочниками, классификаторами, каталогами, файловыми хранилищами. Объёмы информации исчисляются десятками и сотнями гигабайт, поэтому задача сопровождения данных сводится к поддержанию их целостности, актуальности и высокому уровню защиты от воздействий извне.
Понятие целостности используется в контексте терминологии информационной безопасности, при этом объектами, по отношению к которым он применяется, могут быть информация, специализированные данные, ресурсы автоматизированной системы и пр. Целостность информации определяется как состояние информации, при котором её изменение осуществляется только преднамеренно субъектами, имеющими на него право, либо таковое отсутствует.
Актуальность - это свойство данных в указанный момент времени адекватно отображать состояние объектов предметной области.
Если целостность данных поддерживается с помощью СУБД, то наиболее популярным средством поддержания актуальности является механизм создания резервных копий. Теоретически должна существовать возможность восстановления (получения актуализированной версии системы) на любой день, минуту и секунду. Практика же диктует свои требования, в частности в силу высокой ресурсоёмкости процесса создания резервной копии, он должен проводиться в период отсутствия нагрузки на сервер ИС. Как правило, таким периодом выбирают время с окончания операционного дня (обычно 21:00 текущего календарного дня) по начало следующего (8:00 следующего календарного дня). Нескольких часов оказывается достаточно для создания архива и записи его в хранилище. В редких случаях, когда БД настолько велика, что оценочное время процесса архивации превышает допустимое, вместо упаковки данных применяют резервное копирование всего программного комплекса на аналогичный компьютер или
виртуальную машину, откуда уже производят запись в архив. Таким образом, в случае программно-аппаратного сбоя актуальность данных АБС может быть восстановлена в пределах одного операционного дня.
Существуют программные комплексы, для которых необходимо поддерживать актуальность в течение дня. Например, программный комплекс, взаимодействующий с Расчётным Центром Информатизации Банка России, с использованием которого производится отправка и получение платёжных документов. Транспортной единицей в данном ПК является рейс - защищённый ключами шифрования и аутентификации блок данных с информационными полями. В крупных банках за день может быть отправлено до нескольких сотен рейсов. В случае непредвиденной ситуации (сбой, удаление пакета), восстановить состояние системы, используя сведения на конец прошлого дня, практически невозможно. Во избежание подобных происшествий, каждый пакет перед отправкой и при поступлении добавляется в архив. Правила именования и нумерации файлов позволяют однозначно определить дату и время пакета, его направление (входящий/исходящий) и однозначно позиционировать в очереди сообщений.
Иначе обстоит дело с системами денежных переводов. Принципы обработки данных тесно связаны с ведением бухгалтерского учёта в банках, который строго регламентируется нормативной документацией Центрального Банка РФ, поэтому в части создания, подтверждения, выплаты, отправки системы практически не различаются. Чего нельзя сказать о принципах хранения и доступа к данным. Здесь сопровождение напрямую связано с местом хранения и способам работы с информацией.
На сегодняшний день существует коммерческое и открытое ПО, позволяющее контролировать точность и неизменность версий файлов. Большинство инструментов мониторинга за актуальностью системы основаны на сравнении текущего состояния системы и состоянию, которому можно доверять. Это состояние часто называют базовой целостностью, получаемой с заведомо исправной системы [6].
Сетевые инструменты мониторинга привлекают особое внимание, потому что они обеспечивают наблюдение за несколькими системами на уровне пересылаемых пакетов. Но способность видеть пакеты, исходящие от атакующего к уязвимой системе, всего лишь предупреждает об опасности и часто слишком поздно. Для того чтобы узнать, как система ответила и была ли атака успешной, необходимо исследовать вредоносный объект. Инструменты целостного мониторинга позволяют детально изучить атаки на систему, на которой они установлены.
Существует много способов установить наблюдение за отдельно взятой системой. Но стоит помнить, что ни одна программа или приложение не может сама по себе гарантировать полный контроль над целостностью всей системы. Лучше всего иметь несколько инструментов обнаружения подозрительного поведения и несанкционированных изменений.
Инструменты мониторинга за целостностью системы могут существенно улучшить политику безопасности банка. Наряду со встроенными средствами контроля целостности, защиты и правильным ведением логов, такие инструменты служат хорошим препятствием для злоумышленника и являются хорошим средством обеспечения безопасности банковской ИС.
В отдельную группу задач сопровождения данных вынесен перенос данных в другую систему. Проблема связана с сохранением существующих связей и семантики. Процесс переноса данных не должен порождать дублирование записей, равно как и их потерю.
Предложенная классификация задач сопровождения и указанные выше особенности отдельных групп задач позволяют системно подойти к проблеме поддержки информационной инфраструктуры банка и повысить эффективность процесса сопровождения банковской информационной системы.
Библиографический список:
1. Браудэ Э. Технология разработки программного обеспечения. СПб.: Питер, 2004, 655с.
2. Братищенко В.В. Проектирование информационных систем. Иркутск: Изд-во БГУЭП, 2004. - 84 с.
3. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. М.: Финансы и статистика, 2000.
4. Гусятников В.Н., Безруков А.И. Стандартизация и разработка программных систем: учеб. пособие. М.: Финансы и статистика; ИНФРА-М, 2010. - 288 с.: ил.
5. Мишенин А.И. Теория экономических информационных систем. М.: Финансы и статистика, 2000. - 240 с.
6. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. М.: Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
№ гос. рег. статьи 0421100034/
Это статья Журнал ВАК :: Управление экономическими системами: электронный научный
журнал http ://uecs.mcnip.ru
URL этой статьи: http://uecs.mcnip.ru/modules.php?name=News&file=article&sid=317
