От промышленной платформы к промышленной технологии производства, внедрения и сопровождения программных продуктов

В последнее время часто употребляется термин "АБС на промышленной платформе". Что подразумевается под этим понятием? Нередко отождествляют разработку на промышленной платформе и использование профессиональной СУБД. По нашему мнению, пришло время взглянуть на проблему шире.

Система управления базами данных

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

Однако промышленной СУБД сейчас уже никого не удивишь. Если еще относительно недавно нашей фирме приходилось конкурировать с системами, написанными на Btrieve и т. п., и одним из главных козырей было использование промышленной СУБД Progress, то в последнее время, все наши реальные конкуренты по открытым и закрытым тендерам банковской автоматизации также представляют решения на промышленных СУБД. В то же время были прецеденты, когда банки, стремясь модернизировать свою информационную инфраструктуру, приобретали системы на промышленной СУБД, но так и не могли внедрить ее применительно к своим конкретным бизнес-процессам. При этом в лучшем случае система работала, но не приносила желаемого результата, в худшем -- приходилось от нее отказываться и приобретать и внедрять другую систему. Так что же сегодня является дифференцирующим фактором, позволяющим побеждать в тендерах, и, что более важно, доводить внедрение системы до победного конца?

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

Программная архитектура и средства разработки

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

Системный анализ, моделирование и проектирование

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

Тестирование и контроль качества

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

Управление конфигурациями

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

Учет дефектов и требований к системе

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

Заключение

Весь наш реальный опыт последнего времени подтверждает, что сегодняшние потребители АБС при оценке адекватности платформы уже не ограничиваются анализом выбора СУБД, а уделяют особое внимание технологической платформе, на которой построен весь процесс разработки, внедрения и сопровождения программного продукта. Для внедрения АБС в современном крупном банке просто необходимо, чтобы система была спроектирована гибкой, в расчете на возможные доработки, а процесс внедрения был отлажен и поставлен на промышленные рельсы. В процессе необходимых доработок может быть затронута смежная функциональность, что требует налаженного и по возможности хорошо автоматизированного тестирования. Как правило, заказные доработки, выполняемые в процессе крупного внедрения, должны производиться в значительно более быстром темпе, чем идет плановое обновление стандартной версии системы, таким образом возникают варианты исходных текстов, отклонения которых от стандартной версии должны быть четко отслежены и впоследствии как можно быстрее синхронизированы со стандартной версией, что практически невозможно без использования средств автоматизированного управления конфигурациями ПО.

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