Российские банки, сотрудничающие с международными платежными системами типа MasterCard, Visa, American Express вынуждены срочно проходить «обследование» на соответствие процессинговых систем международному стандарту PCI DSS (Payment Card Industry Data Security Standard). Это новый неиссякающий источник доходов для ИТ-компаний, ориентированных на услуги ИБ. Мало того что стандарт содержит 12 детализированных требований, так и подтверждать его выполнение требуется каждый год.

У банка «Зенит» есть собственный процессинговый центр для обработки транзакций по международным платежным картам, поэтому ему необходимо выполнить требования стандарта PCI DSS. Проект осложнился тем, что банк обязан обеспечить непрерывность процессинга в режиме 24х7.

«Проект комплексный, и задача состояла в том, чтобы не только обеспечить соответствие стандарту PCI DSS, но и требованиям федерального закона №152 «О персональных данных», и стандарта СТО БР ИББС, - говорит Евгений Рудацкий, руководитель направления PCI DSS компании «Инфосистемы Джет» (исполнитель работ). - Однако в первую очередь необходимо было выполнить требования стандарта PCI DSS в связи со строгими ограничениями сроков со стороны международных платежных систем (в течение года - CNews)».

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

В 2011 году «Московский банк реконструкции и развития» (МБРР) завершил важный этап внедрения новой централизованной банковской системы. Проект уникален в первую очередь рекордно короткими сроками реализации: «В течение четырех месяцев ИТ-специалистами МБРР и командой ЦФТ были установлены и запущены в промышленную эксплуатацию 12 функциональных приложений, - рассказывает Андрей Фомичев (ЦФТ). - К концу 2011 года на новую централизованную систему были переведены все 16 филиалов банка». Столь малое время на внедрение и тиражирование АБС объясняется тем, что почти все дистрибутивы программных модулей на 80-90% соответствовали потребностям банка, потребовался минимальный, по сравнению со среднестатистическим внедрением АБС, объем доработок. Сейчас готовится внедрение следующих модулей: для работы на фондовом рынке, выполнения ритейловых операций.

Банк ВТБ24 продолжает направлять все силы на привлечение розничных клиентов. Став активным кредитором населения, он пришел к неизбежным последствиям - появлению просроченной задолженности, которой следует управлять. Требовалось изменить бизнес-процессы, ИС. Руководство банка выбирало между ИТ-системами Experian, Fair Isaac, Sputnik Labs и ФИС и остановилось на системе, на внедрение которой потребовалось всего 3 месяца. «ВТБ24 в 2010 году внедрил систему мониторинга и взыскания просроченной задолженности TSC Collection на базе Oracle Siebel CRM компании “Техносерв Консалтинг”», - рассказывает Евгений Закрепин, первый заместитель управляющего директора компании «Техносерв». Сейчас все коллекторские подразделения банка (86 центров по числу регионов присутствия) работают в единой системе, которая автоматизирует все стадии работы с просроченной задолженностью по всем продуктам. При этом возможно использовать различные методы управления: работу с коллекторскими агентствами, реструктуризацию долга, продажу прав по договору. Система интегрирована с АБС, процессингом, клиент-банком.

Конечно, такие скорости внедрения возможны только на базе уже созданных корпоративных хранилищ данных. И МБРР, и ВТБ24 завершили эти проекты несколько лет назад. Примечательно, что и создание хранилища, и внедрение АБС для МБРР выполняла одна и та же ИТ-компания, но в 2010 году руководство банка решило заменить АБС, поскольку первая система за 5 лет успела безнадежно устареть.

В России работают около 1 тыс. коммерческих банков. По данным интеграторов, почти половина игроков отрасли в 2010-2011 годах задумывалась о модернизации ИТ-системы. Каковы их требования и претензии к АБС?

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

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

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

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

Второй вариант развития событий - смена приоритетов развития, изменение стратегии. Например, выход на новые рынки. Банк Home Credit & Finance bank трансформировался из монолайнера, специализировавшегося на потребительских кредитах, в полноценный розничный банк. Изменение стратегии повлекло новые требования к инфраструктуре. В результате за последние пару лет в банке прошло несколько масштабных проектов. Во-первых, была внедрена розничная банковская система Tranzware (разработчик - компания "Компас Плюс"), во-вторых, с помощью решения BSC-Praha появился интернет-банкинг.

Поскольку наш ИТ-ландшафт стал включать в себя значительное количество систем, их интеграцию мы сделали с профессиональным подходом - на платформе интеграционной шины (Enterprise Service Bus), используя решение Oracle Service Bus. Некоторые действующие системы были серьезно модернизированы. Например, в системе поддержки розничного кредитования Homer (внутренняя разработка банка) сделано более 200 доработок, касающихся продуктов банка и услуг, предоставляемых клиентам. ERP-система SAP была растиражирована на более чем 100 офисов, внедрено новое хранилище данных на платформе Oracle Business Intelligence. Кроме того, появилось несколько малых приложений. "Любой владелец iPhone может установить утилиту, которая подскажет ему, где находится ближайший офис или банкомат нашего банка, и поможет найти дорогу", - приводит пример Кирилл Кибалко. Внедрена система Unified Front Office, с помощью которой сотрудники офисов банка через одно окно оформляют любые продукты и услуги банка, сейчас решение активно развивается.

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

Со своей стороны, руководство банка "Открытие" решило перевести не только центральный офис, но все 15 филиалов на единую новую АБС. Причиной стало присоединение одноименного инвестиционного банка и банка "Петровский" (Санкт-Петербург), в результате чего банк стал крупным федеральным игроком. Работы начались во второй половине 2010 года, и в феврале 2011 года система стартовала в первых двух филиалах в городах Йошкар-Ола и Челябинск. Интересно, что тиражирование системы на московскую штаб-квартиру и остальные 13 филиалов выполнили собственные ИТ-специалисты банка в течение двух месяцев. В ближайшее время система будет установлена в последнем подразделении - питерском. "Одно из важнейших преимуществ, которое получил банк в ходе модернизации - работа филиалов на единой базе данных в режиме онлайн. На практике это означает, что банк сможет обеспечить сквозную систему обслуживания, когда клиент, обращаясь в любой офис, имеет возможность получить одинаковый набор услуг.

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

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

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

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

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

Ясно просматривается бизнес-модель банка будущего. В основе ценообразования услуги - не столько себестоимость, сколько интерес клиента. Поэтому на первое место выходит целевой маркетинг, основанный на клиентской аналитике.

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

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

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

"Сбербанк" приступил к внедрению системы клиентской аналитики около года назад и планирует завершить его в середине 2012 года. Сейчас идет первый этап, его задача - строить аналитические отчеты по основным учетным продуктовым системам: по счетам, кредитам, карточному процессингу. Цель системы - консолидация, обработка и анализ клиентских данных, полученных из различных учетных систем. Банк хочет получить единое видение клиента, на агрегированных данных строить аналитические модели, к примеру, о потенциальной доходности продукта, лояльности клиентуры. Для анализа среднесрочных трендов используются учетные записи за 1-2 года, текущих - за последние полгода.

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

При выборе аналитического решения банком рассматривались SAS и Kxen. По оценкам экспертов рынка, SAS более функционален, даже "монструозен" в хорошем смысле этого слова, поддерживает все необходимые методы анализа, зато Kxen быстрее. "Сбербанк" выбрал SAS.

Потихоньку подтягивается и пространство СНГ - Казахский "Каспийский банк" в 2009 году внедрил аналитический скоринг, а в этом году - аналитический CRM. В результате маркетинговая политика банка приобрела узкоцелевую направленность - каждому клиенту предлагается именно та услуга, в которой он заинтересован в данный момент. Актуальность предложений поддерживается автоматически.

На Западе, где от модели взаимодействия с клиентами CRM уже начали переходить к PCM (Personal Customer Management), целевой маркетинг служит для крупных банков одним из важнейших каналов продвижения розничным клиентам своих услуг. С 2010 года эта тенденция получила активное развитие в России и в Казахстане. Так сейчас одна из самых развитых в СНГ банковских систем, и уровень конкуренции за клиентов очень высок.

В Европе, США работают виртуальные банки, использующие исключительно дистанционные модели. Одна такая организация есть и в России: банк "Тинькофф. Кредитные системы" (ТКС) выпустил более 1,3 млн кредитных карт клиентам по всей России, но имеет только "штаб-квартиру" в Москве. Офисов просто нет. Конечно, его операционные расходы несравнимо меньше, чем у "стационарных" коллег. Однако и возможностей привлечь клиентов тоже меньше. Подобные предприятия могут серьезно конкурировать с классическими банковскими моделями только одним способом - стать удобнее для пользователя. А воплотить все чаяния клиента в жизнь можно, лишь досконально изучив их. Человеку должно быть не просто комфортно, система должна "подыгрывать" ему. При этом все предложения по лимитам, ставкам и срокам должны формулироваться таким образом, чтобы минимизировать риски банка.

Иногда удается находить очень интересные закономерности. "Клиенты, которые указывают свой e-mail, являются для банка менее рискованными. И вовсе не потому, что если заказчик пользуется электронной почтой, значит, он более богатый и "продвинутый". А по той причине, что он просто готов рассказать о себе больше", - говорит он. С помощью CRM-аналитики руководство ТКС намерено сократить расходы на традиционный маркетинг, отказавшись от полномасштабных рекламных кампаний. Персональные предложения адресуются непосредственно клиенту, например, через социальные сети. Но ТКС - пионер в этой сфере на российском рынке. Другие банки пока не идут дальше аккаунта в Twitter и странички в Facebook.

Вообще маркетинг - основное направление использования клиентской аналитики, и российским банкам тут есть, куда расти. Бельгийское отделение банка ING, благодаря активному использованию подобных систем, проводит 5 рекламных кампаний в день, продавая одному клиенту 5-7 продуктов. Для сравнения, отечественные банки проводят столько же кампаний за месяц и продают одному клиенту в среднем 1-2 продукта.

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

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

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

2.2 Выбор средств программирования

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

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

Несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую.

Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует «стабилизации» языка.

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

SQL - язык, который дает возможность создавать и работать в реляционных базах данных, являющихся наборами связанной информации, сохраняемой в таблицах.

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

Стандарт SQL определяется ANSI (Американским Национальным Институтом Стандартов) и в данное время также принимается ISO (Международной Организацией по Стандартизации). Однако, большинство коммерческих программ баз данных расширяют SQL без уведомления ANSI, добавляя различные особенности в этот язык, которые, как они считают, будут весьма полезны. Иногда они несколько нарушают стандарт языка, хотя хорошие идеи имеют тенденцию развиваться и вскоре становиться стандартами "рынка" сами по себе в силу полезности своих качеств.

SQL работает согласно реляционной информационной модели.

В реляционной модели данных таблица обладает следующими основными свойствами:

· идентифицируется уникальным именем;

· имеет конечное (как правило, постоянное) ненулевое количество столбцов;

· имеет конечное (возможно, нулевое) число строк;

· столбцы таблицы идентифицируются своими уникальными именами и номерами;

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

· строки таблицы не имеют какой-либо упорядоченности и идентифицируются только своим содержимым (т.е. понятие номер строки не определено);

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

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

требования уникальности содержимого каждой ячейки какого-либо столбца и/или совокупности ячеек в строке, относящихся к нескольким столбцам;

запрета для какого-либо столбца (столбцов) иметь пустые (NULL) ячейки.

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

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

Основными операциями над таблицами являются следующие:

Проекция - построение новой таблицы из исходной путем включения в нее избранных столбцов исходной таблицы.

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

Объединение - построение новой таблицы из 2-ух или более исходных путем включения в нее всех строк исходных таблиц (при условии, конечно, что они подобны).

Декартово произведение - построение новой таблицы из 2-ух или более исходных путем включения в нее строк, образованных всеми возможными вариантами конкатенации (слияния) строк исходных таблиц.

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

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

 В настоящее время наибольшее распространение получили реляционные SQL СУБД двух групп:

· мощные крупные коммерческие СУБД, ориентированные на хранение огромных объемов информации (от гигабайт);

· мобильные компактные свободно распространяемые (в том числе и в исходных кодах) СУБД, использование которых оправдано и для БД объемом всего лишь в десятки килобайт, т.к. они распространяются совершенно бесплатно.

Наиболее известными СУБД первой группы являются:

· Sybase SQLserver фирмы Sybase, Inc.;

· Oracle фирмы Oracle Corporation;

· Ingres фирмы Computer Associates International;

· Informix фирмы Informix Corporation.

К наиболее популярным СУБД второй группы относятся:

· PostgreSQL организации PostgreSQL;

· microSQL фирмы Hughes Technologies Pty. Ltd.;

· mySQL фирмы T.C.X DataKonsult AB.

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

Таким образом, в качестве протокола обмена используются вызовы функций (API) библиотеки SQLite. Такой подход уменьшает накладные расходы, время отклика и упрощает программу. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа Когаловский М.Р. Энциклопедия технологий баз данных. М.: Финансы и статистика, 2011. 800 с.: ил..

В данном проекте, управление сервером баз данных, реализуются средствами СУБД MySQL.

Преимуществами MySQL по сравнению с остальными СУБД являются:

· производительность (использует Yahoo и Google);

· масштабируемость (в компании Omniture в реальном масштабе времени используется 7000 серверов MySQL);

· надежность (в коде проприетарных продуктов содержится в десять с лишним раз больше уязвимостей);

· простота использования, простота внедрения (за 15 минут можно скачать и запустить систему);

· открытая и модульная разработка;

· низкие совокупные затраты (платить нужно только при потребности в поддержке).

SQL-сервер реализует собственно хранение данных и манипулирование ими. Он принимает запросы на языке SQL от своих клиентов, выполняет их и возвращает результаты (чаще всего в виде вновь построенных таблиц) клиентам. Для общения с клиентами используется специальный протокол (как правило, реализованный в виде протокола прикладного уровня стека сетевых протоколов TCP/IP).

Программа на языке SQL представляет собой простую линейную последовательность операторов языка SQL. Язык SQL в своем чистом виде операторов управления порядком выполнения запросов к БД (типа циклов, ветвлений, переходов) не имеет.

Клиентскую часть СУБД составляют клиенты трех основных типов.

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

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

WWW-клиенты, встраиваемые в World Wide Web-сервера и обеспечивающие доступ к информационным возможностям SQL-сервера пользователям сети Internet по протоколу HTTP (протоколу передачи гипертекстовых документов).

Именно с последним типом клиентов и работает программа, разработанная для работы с БД клиентов и заказчиков, которая в свою очередь написана на простом и широко распространенном языке PHP.

Основным языком программирования при создании системы бы выбран PHP (англ. PHP: Hypertext Preprocessor -- «PHP: препроцессор гипертекста», -- «Инструменты для создания персональных веб-страниц») -- язык программирования, созданный для генерирования HTML-страниц на веб-сервере и работы с базами данных.

В области программирования для Сети, PHP -- один из популярнейших скриптовых языков благодаря своей простоте, скорости выполнения, богатой функциональности и распространению исходных кодов на основе лицензии PHP. PHP отличается наличием ядра и подключаемых модулей, «расширений»: для работы с базами данных, сокетами, динамической графикой, криптографическими библиотеками, документами формата PDF и т. п. Любой желающий может разработать своё собственное расширение и подключить его. Не нужно писать свои собственные функции. При использовании, к примеру, C, придется это делать самим.

В PHP переданные сценарию параметры автоматически станут переменными сценария, с которыми можно работать, как с обыкновенными переменными. То же самое происходит с переменными окружения сервера.

Следует упомянуть, что PHP поддерживает работу с различными базами данных (MySQL, PostgresSQL, Sybase, Informix, др.). Поддержка всех этих возможностей уже имеется в PHP.

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

Основными достоинствами являются Кристина Пейтон, Андре Меллер. PHP 5 и MySQL 5 в примерах и на проектах - М.: Бином, 2009.- 368с.:

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

· полная поддержка всеми web-серверами (Apache, IIS) и интернет хостингами;

· простота работы c запросами SQL.

Проведем сравнительный анализ двух технологий создания динамических Web-страниц - ASP.net и PHP, и СУБД - MySQL и MS-SQL чтобы обусловить выбор PHP и MySQL для разработки программы управления БД клиентов и заказчиков (табл. 2.1).

Таблица 2.1

Сравнительный анализ PHP - ASP.net и MySQL - MS-SQL

№ п/п	Критерий	PHP (СУБД MySql, Web-сервер Apache, ОС Linux)	ASP.net (СУБД MS SQL Server, Web-сервер IIS, ОС Windows)
1	Стоимость	Открытая и бесплатнаятехнология (однако разработка и поддержка коммерческих проектов обходится дорого)	Платная технология (придется оплатить несколько лицензий Microsoft)
2	Сложность освоения	Не нужна дорогая среда программирования, достаточно пары учебников	Необходима среда разработки Visual Studio, MSDN, доступ в Интернет
3	Основное предназначение	Мелкие и средние проекты, рассчитанные на небольшие группы программистов	Средние и большие проекты, рассчитанные на большие группы программистов под четким управлением
4	Скорость работы	Скорость работы обеспечивается тем, что все PHP-приложения работают в едином адресном пространстве. Подход более быстр, но менее надежен, но абсолютно не требователен к аппаратным ресурсам.	За счет сложной модели классов ASP.net многократно перепроверяет данные, удерживая каждое приложение в отдельном адресном пространстве. Подход более надежен и не менее быстр, но более требователен к ресурсам
5	Кэширование данных из БД	Генерирует множество запросов к СУБД	Старается делать из БД как можно меньше выборок, помещая все актуальные таблицы и даже связи между ними в кэш (технология ADO.NET )
6	Наличие отладчика	Полноценного отладчика нет, но может компенсироваться Фреймворками сторонних производителей	Удобный отладчик Visual Studio

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

Фреймворк (Framework) -- термин, имеющий размытое значение. Обычно используется в программировании, обозначая «простую концептуальную структуру, используемую для решения сложной, проблемной задачи». Значение этого термина существенно зависит от контекста его использования. В нашем случае фреймворк выступает как набор инструментов, библиотек и соглашений, предназначенный для вынесения рутинных задач в отдельные модули, которые можно использовать многократно. Главная цель фреймворка, позволить программисту сфокусироваться на задачах уникальных для каждого проекта, вместо изобретения модулей, уже имеющихся в наборе инструментов среды разработки.

Основными достоинствами Фреймворка CodeIgniter являются Рева О.Н. Создание Web-страниц. Просто как дважды два. - М.: Эксмо, 2010. - 208с., ил.:

· CodeIgniter бесплатен. Он лицензирован под Apache/BSD-style open source license для того, чтобы вы могли использовать его как угодно.

· поддержка версий PHP4 и PHP5;

· модель MVC (Model-View-Controller);

· поддержка баз данных MySQL, PostgreSQL, MSSQL, SQLite, Oracle;

· легко расширяемая система через подключение собственных библиотек и плагинов;

· возможность использование ЧПУ. Так же возможно использовать стандартый вид адресной строки;

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

· обладает возможностью кеширования на стороне сервера SQL-запросов и генерируемых html-страниц;

· хорошо спроектированная документация на английском языке с примерами;

· очень быстр в работе. В этом смысле -- эталон скорости и пример для подражания.

Многие PHP-программисты считают CodeIgniter лучшим выбором.

2.3 Структурная схема программы

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

Web-интерфейс. Если аналитик работает с банком через Web-интерфейс, единственным требованием является наличие на его компьютере программы Microsoft Internet Explorer версии 5.5 или выше. Клиенты системы, используя Web-браузер, подключаются к Web-серверу банка через сеть Интернет, либо через коммутируемую или выделенную линию, как это показано на рис. 2.5.

Таким образом, при работе аналитика через Web-интерфейс обработка документов в системе производится следующим образом: клиент, используя стандартный браузер Internet Explorer, заполняет экранные формы требуемых документов. Java-классы, работающие на Web-сервере, обрабатывают полученные данные и помещают их в базу данных.



Рис. 2.5 Структурная схема системы

Работа с системой происходит следующим образом. Банковский аналитик заходит в программу. Выбирает меню (расчет какого показателя его интересует в данный момент), вводит данные, система производит расчет.

Таким образом, функциональную схему системы можно представить в виде рис. 2.6.



Рис. 2. 6 Функциональная схема системы

2.4 Разработка интерфейсных форм

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

Одним из подходов по снижению психологических нагрузок пользователя является создание интерактивного интерфейса пользователя.

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

Человеко-машинное взаимодействие (HCI - Human-Computer Interaction) - это наука, которая изучает, как люди используют компьютерные системы, чтобы решить поставленные задачи. HCI обеспечивает нас знаниями о компьютере и человеке для того, чтобы взаимодействие между ними было более эффективным и более удобным.

Интерфейс пользователя выполнен на языке разметки HTML с использованием JavaScript и библиотеки jQuery, что позволило построить интерактивный пользовательский интерфейс программы.

Имеется ряд стилей взаимодействий, которые делятся на два основных вида. Первый - это использование интерфейса языка команд - ввод команд текстовыми средствами, а второй - это непосредственное манипулирование.

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

· языки команд - пользователь управляет системой, вводя соответствующие команды в тестовом режиме;

· вопрос и ответ - диалог, где компьютер задает вопросы, а пользователь отвечает ему (или наоборот);

· формы - пользователь заполняет формы или поля диалога, вводя данные в необходимые поля;

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

· прямое манипулирование - пользователь управляет объектами на экране посредством устройства манипулирования, типа мыши.

Другой термин, используемый для прямого интерфейса манипулирования - графический интерфейс пользователя.

В своей программе я использовал комбинированную систему управления - формы, меню и диалоговые варианты, вида «вопрос-ответ».

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

Основные принципы создания интерфейса:

а) Естественность (интуитивность).

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

б) Непротиворечивость.

Если в процессе работы с системой пользователем были использованы некоторые приемы работы с некоторой частью системы, то в другой части системы приемы работы должны быть идентичны. Также работа с системой через интерфейс должна соответствовать установленным, привычным нормам (например, использование клавиши Enter).

в) Неизбыточность.

Это означает, что пользователь должен вводить только минимальную информацию для работы или управления системой. Например, пользователь не должен вводить незначимые цифры (00010 вместо 10). Аналогично, нельзя требовать от пользователя ввести информацию, которая была предварительно введена или которая может быть автоматически получена из системы. Желательно использовать значения по умолчанию, где только возможно, чтобы минимизировать процесс ввода информации.

г) Непосредственный доступ к системе помощи.

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

д) Гибкость.

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

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

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



Рис. 2.7 Первая страница веб-интерфейса

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

<?php

if(isset($_POST['val1']) && isset($_POST['val2']))

{

$val1=strip_tags($_POST['val1']);

$val2=strip_tags($_POST['val2']);

if($val2!==0)

{

$res=round($val1/$val2,6);

$response=array('status'=>'ok','res'=>$res);

}

else

{$response=array('status'=>'error','msg'=>'Р?РµР?Р?С?С? Р?Р? 0 Р?РµР?С?Р?С?!');}

}

else

{

$response=array('status'=>'error','msg'=>'Р?С?Р?Р?РєР? Р?С?Р? Р?С?Р?С?Р?Р?РєРµ Р?Р?Р?С?Р?С?Р?!');

}

echo(json_encode($response));

?>

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

<?php

if(isset($_POST['val1']) && isset($_POST['val2']) && isset($_POST['val3']) && isset($_POST['val4']) && isset($_POST['val5']) && isset($_POST['val6']) && isset($_POST['val7']) && isset($_POST['val8']) && isset($_POST['val9']) && isset($_POST['val10']) && isset($_POST['val11']))

{

$val1=strip_tags($_POST['val1']);

$val2=strip_tags($_POST['val2']);

$val3=strip_tags($_POST['val3']);

$val4=strip_tags($_POST['val4']);

$val5=strip_tags($_POST['val5']);

$val6=strip_tags($_POST['val6']);

$val7=strip_tags($_POST['val7']);

$val8=strip_tags($_POST['val8']);

$val9=strip_tags($_POST['val9']);

$val10=strip_tags($_POST['val10']);

$val11=strip_tags($_POST['val11']);

$res=$val1+$val2+$val3+$val4+$val5-$val6-0.14*$val7-0.11*$val8-0.08*$val9-0.09*$val10-0.05*$val11;

$res = round($res,6);

$response=array('status'=>'ok','res'=>$res);

}

else

{

$response=array('status'=>'error','msg'=>'Ошибка при отправке запроса!');

}

echo(json_encode($response));

?>

При выборе расчета объема свободных кредитных ресурсов выполняется модуль:

<?php

if(isset($_POST['eff']) && isset($_POST['fac']))

{

$eff=strip_tags($_POST['eff']);

$fac=strip_tags($_POST['fac']);

$res=$eff-$fac;

$res = round($res,6);

$response=array('status'=>'ok','res'=>$res);

}

else

{

$response=array('status'=>'error','msg'=>'Ошибка при отправке запроса!');

}

echo(json_encode($response));

?>

Для анализа эффективности использования кредитных ресурсов реализован следующий модуль:

<?php

if(isset($_POST['effKredRes']) && isset($_POST['facKredRes']) && isset($_POST['per']))

{

$eff=strip_tags($_POST['effKredRes']);

$fac=strip_tags($_POST['facKredRes']);

$per=strip_tags($_POST['per']);

$res=($fac*$per)/($eff*$per);

$res = round($res,6);

$response=array('status'=>'ok','res'=>$res);

}

else

{

$response=array('status'=>'error','msg'=>'Ошибка при отправке запроса!');

}

echo(json_encode($response));

?>

Степень недоиспользхования ресурсо оценивается с помощью следующего модуля:

<?php

if(isset($_POST['effLast']))

{

$eff=strip_tags($_POST['effLast']);

$res=(1-$eff)*100;

$res = round($res,6);

$response=array('status'=>'ok','res'=>$res);

}

else

{

$response=array('status'=>'error','msg'=>'Ошибка при отправке запроса!');

}

echo(json_encode($response));

?>

Таким образом, система реализуется с помощью пяти функциональных модуля (приложение 1):

- расчет коэффициента рефинансирования (Кр) - koeffRefin.php

- расчет эффективных кредитных ресурсов (КРэ) - effKredRes.php

- расчет объём свободных кредитных ресурсов (КРс) - obSvobKredRes.php

- анализ эффективности использования кредитных ресурсов (Экр) - effIspKredRes.php

- анализ степени недоиспользования ресурсов (Rисп) - stepNedoisp.php

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

Кроме того, описаны способы применения PHP для разработки приложений, рассмотрены методы объектно-ориентированного программирования на PHP, отладки и тестирования приложений.

Данные, полученные в экономическом разделе, показали высокую эффективность программы, что во многом связано с использованием в разработке систем с открытым программным кодом (OpenSource).

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

Работа с системой происходит следующим образом. Банковский аналитик заходит в программу. Выбирает меню (расчет какого показателя его интересует в данный момент), вводит данные, система производит расчет.

Система реализуется с помощью пяти функциональных модуля:

- расчет коэффициента рефинансирования (Кр) - koeffRefin.php

- расчет эффективных кредитных ресурсов (КРэ) - effKredRes.php

- расчет объём свободных кредитных ресурсов (КРс) - obSvobKredRes.php

- анализ эффективности использования кредитных ресурсов (Экр) - effIspKredRes.php

- анализ степени недоиспользования ресурсов (Rисп) - stepNedoisp.php

Глава 3. ОЦЕНКА ЭФФЕКТИВНОСТИ СИСТЕМЫ АВТОМАТИЗАЦИИ ПРОЦЕССА ФОРМИРОВАНИЯ ОСНОВНЫХ ПОКАЗАТЕЛЕЙ БАНКА ДЛЯ АНАЛИЗА ПРИВЛЕЧЕННЫХ СРЕДСТВ

3.1 Планирование и организация процесса разработки систем управления

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

Согласно ГОСТ 23501.1-79 регламентируются следующие стадии проведения исследования:

· техническое задание - ТЗ (ГОСТ 23501.2-79);

· эскизный проект - ЭП (ГОСТ 23501.5-80);

· технический проект - ТП (ГОСТ 23501.6-80);

· рабочий проект - РП (ГОСТ 23501.11-81);

· внедрение - ВП (ГОСТ 23501.15-81).

· эксплуатация и сопровождение.

Все эти работы выполняются одним исполнителем - программистом.

Содержание основных работ по всем стадиям разработки приведены в табл. 3.1.

Таблица 3.1

Перечень работ по стадиям разработки

Наименование работ	Этап
Постановка задачи	ТЗ
Сбор материалов и анализ существующих разработок
Подбор литературы
Определение требований к системе
Определение стадий, этапов и сроков разработки базы данных
Анализ программных средств схожей тематики	ЭП
Разработка функциональной схемы программы
Разработка структуры программы управления по подсистемам
Документирование
Определение требований к программе управления	ТП
Выбор инструментальных средств
Определение свойств и требований к аппаратному обеспечению
Разметка таблиц структуры БД	РП
Программирование
Тестирование и отладка программы управления
Разработка программной документации
Согласование и утверждение работоспособности системы
Опытная эксплуатация	ВП
Анализ данных, полученных в результате эксплуатации
Корректировка технической документации по результатам испытаний

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

Трудоемкость каждого вида работ определяется по формуле:

, (3.1)

Где:

T_min - минимально возможная трудоемкость выполнения отдельного вида работ;

T_max - максимально возможная трудоемкость выполнения отдельного вида работ.

Продолжительность каждого вида работ в календарных днях (t_i) определяется в днях по формуле:

,(3.2)

Где:

T_i - трудоемкость работ, человек-дней;

Ч_i - численность исполнителей, человек;

K_вых - коэффициент, учитывающий выходные и праздничные дни:

(3.3)

Где:

К_кал. - число календарных дней;

К_раб. - рабочие дни;

Согласно производственному и налоговому календарю на 2012 год, количество рабочих дней составляет 249 дней, количество предпраздничных дней - 7, таким образом: K_вых=1,5.

Полный список видов и этапов работ по созданию ПО, экспертные оценки и расчетные величины их трудоемкости, а также продолжительность каждого вида работ, рассчитанные по формулам (3.1) и (3.2), представлены в приложении 2.

Таким образом, общая продолжительность проведения работ составит 96 рабочих дней, при последовательном выполнении всех вышеозначенных в приложении 2 этапов работы.

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