Размещено на http://www.allbest.ru/

Тема: Программа автоматического учета системы кредитования

1. Учет кредитов и займов

Специалистами компании «БизнесПроект» разработан блок учета «Учет кредитов». Реализованы следующие основные функции:

· Регистрация и учет договоров кредита и займа в рублях и в валюте;

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

· Автоматический расчет размера платы за пользование заемными средствами на основании данных бухгалтерского учета исходя из следующих показателей:

· Годовая ставка процентов (размер дневной ставки рассчитывается автоматически);

· Количество дней использования заемных средств.

· Размер платы (процентов) рассчитывается по формуле:

Сумма процентов за 1 день = Сумме кредита в этот день *%ставку/100/366 (дней в году);

· Отражение начисления процентов по кредиту/ займу в бухгалтерском и налоговом учете;

· Учет постоянных разниц и постоянных налоговых обязательств по начисленным процентам.

Блок учета включает в себя:

Документ «Договор займа / кредита» - документ предназначен для учета основных сведений о договоре (сумма займа, размер платы (%) и прочие реквизиты);

Документ «Дополнительное соглашение к договору займа» - документ предназначен для регистрации изменений условий основного договора, которые могут оказывать влияние на расчет суммы процентов;

Документ «Справка - расчет процентов по займам» - документ предназначен для автоматического расчета суммы процентов за пользование заемными средствами. Сумма процентов рассчитывается автоматически исходя из сумм поступления и возврата кредита, количества дней использования заемных средств в течение отчетного месяца, ставки процентов. Документ формирует проводки по бухгалтерскому и налоговому учету. По налоговому учету автоматически рассчитывается сумма, признаваемая расходом для целей налогообложения прибыли и не принимаемая к расходам (проценты по долговым обязательствам сверх установленных норм). Нормы по налоговому учету зафиксированы согласно статье 269 и 270 НК РФ. Документ «Справка - расчет процентов по займам» позволяет автоматически рассчитать и сформировать проводки, отражающие постоянное налоговое обязательство (в соответствии с ПБУ №18/2000). Блок учета «Учет кредитов» содержит набор отчетов, позволяющих пользователю получать информацию об учете кредитов и начисленных процентах.

2. Рынок кредитования: тенденции, возможности, решения

В настоящее время рынок розничных финансовых услуг в России переживает период бурного роста, банки энергично осваивают данное перспективное направление и открывают все новые и новые возможности для развития бизнеса. Одной из основных причин всплеска банковской активности в розничном секторе является увеличение спроса на услуги кредитования, в особенности на потребительские кредиты. По данным Банка России, на 1 января 2005 г. общий объем кредитов, выданных физическим лицам, составил 620 млрд руб., что в 2,7 раза больше, чем в предыдущем году. В ближайшие годы, по прогнозам аналитиков, этот показатель вырастет еще в несколько раз, достигнув к 2009 г. уровня 4300 млрд руб.

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

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

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

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

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

В результате тщательного анализа международного рынка IT-решений для банковского бизнеса и после проведения подготовительных работ в области локализации БПЦ предложил на российский рынок универсальную банковскую систему BANCS -- продукт компании Financial Network Services (FNS), являющейся одним из мировых лидеров в сфере разработки решений для розничного банковского бизнеса. Выбор BANCS для продвижения на рынках России и стран СНГ был во многом обусловлен разнообразием функциональных возможностей системы, которая по ряду параметров, таких, как, например, скорость, на сегодняшний день не имеет аналогов на российском рынке, а также безукоризненной репутацией компании FNS, подтвержденной многочисленными успешными инсталляциями системы BANCS в банках различного масштаба по всему миру.

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

В процессе создания комплексного решения между BANCS и SmartVista был реализован on-line интерфейс, благодаря чему обе системы используют при работе единую базу информации о клиентах и счетах. В результате проведения полной интеграции систем БПЦ удалось получить полнофункциональное клиенто- и продуктоориентированное решение, обеспечивающее поддержку всего спектра розничных услуг и обладающее разнообразными возможностями в области реализации кредитных программ.

BANCS -- банковское решение международного класса

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

Центральным компонентом системы BANCS является Хранилище информации о клиентах (Customer Information File (CIF)), с которым тесно интегрированы следующие прикладные функциональные модули: Deposits (Депозиты), Loans (Кредиты), Payments (Платежи), Treasury (Казначейство), Trade Finance (Торговое финансирование), Accounting (Бухгалтерский учет), Executive Information System (Управленческая информационная система), модуль для поддержки работы филиалов BANCS Link, модуль BANCS Connect, позволяющий оказывать финансовые услуги через Интернет, и ряд других.

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

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

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

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

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

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

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

3. Кредитование в системе BANCS

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

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

Модуль BANCS Loans тесно интегрирован с Хранилищем информации о клиентах (CIF), с главной бухгалтерской книгой (General Ledger), управленческой информационной системой BANCS EIS и модулем отчетов BANCS Reports, что позволяет генерировать выписки и отчеты в реальном времени, а кроме того, получать полное представление о каждом клиенте, группах клиентов, кредитах или группах кредитов. BANCS Loans может быть также интегрирован с различными внешними системами, например кредитными бюро, и иными компонентами IT-комплекса банка: скоринговой системой, процессинговым центром, CRM-системой, системой Интернет-Банк и другими прикладными решениями, реализованными на различных платформах.

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

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

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

В системе BANCS реализованы такие возможности, как управление просроченными кредитами (NPL), отслеживание кредитов (Loans Tracking System), выдача кредитов под обеспечение (Equity Lending) и синдицирование.

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

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

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

Система отслеживания кредитов Loans Tracking System служит для управления процессом обслуживания кредитов и позволяет финансовому учреждению существенно оптимизировать централизованную схему работы с кредитами или сделать механизм выдачи ссуд полностью децентрализованным.

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

Loans Tracking System обеспечивает автоматизацию «кредитной политики» финансового учреждения путем внесения установленных значений в таблицы системы, соблюдение которых отслеживается в ходе обработки кредита. Чтобы свести к минимуму количество случаев просрочки выплат, предусмотрена автоматизированная подготовка своевременных писем-напоминаний и управленческих отчетов.

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

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

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

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

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

4. Решение BANCS в России: адаптация к требованиям рынка

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

Система BANCS обладает разнообразными возможностями в области локализации и кастомизации. Компании БПЦ и FNS совместно выработали специальные принципы адаптации решения к требованиям национального рынка, опираясь на опыт БПЦ по реализации проектов для российских и зарубежных финансовых структур и знание специфики национального банковского сектора.

Локализация системы BANCS затрагивает такие важные аспекты, как ведение учета и формирование отчетности в соответствии с требованиями регулирующих органов, а также обеспечение возможностей интеграции решения с другими компонентами IT-инфраструктуры банка по стандартным протоколам, как в on-line, так и в off-line режиме. В системе BANCS предусмотрены различные способы интеграции с главной бухгалтерской книгой, функциональность которой может быть реализована и собственной разработкой FNS, и решениями других международных или российских разработчиков. В рамках кастомизации в системе BANCS настраиваются различные шаблоны документов и правила документооборота в соответствии с индивидуальными требованиями заказчика, а кроме того, поскольку BANCS является мультиязычной системой, поддержка русского и других языков.

Согласно стратегии компании FNS по продвижению решения BANCS в России и странах СНГ, ведущая роль в реализации проектов отводится БПЦ. На сегодняшний день БПЦ обладает всем необходимым для того, чтобы успешно осуществлять внедрение и сопровождение решения FNS на российском рынке: компания имеет уникальный опыт в области построения технологической инфраструктуры для финансовых организаций различного масштаба и обладает глубоким пониманием требований, предъявляемых сегодня к решениям для автоматизации банковской деятельности.

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

Высокие технологии меняют представление о привычном. Банковская деятельность -- одна из самых консервативных, однако представляемые технические новшества, по мнению «БО», способны внести в нее радикальные изменения. // «Банковское обозрение», № 1 (144), январь 2011 года

Видеорегистратор

В Массачусетском технологическом институте при поддержке Bank of America действует лаборатория Center for Future Banking. Одна из разработок лаборатории -- система видеорегистрации, которая позволяет фиксировать и анализировать поведение клиентов в офисе: как они передвигаются и реагируют на информационные стенды, что привлекает их внимание и т.д. Такие системы уже в ближайшее время станут незаменимым инструментом изучения клиентских предпочтений и совершенствования эргономики банковских отделений.

Видеоконсультант

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

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

Интерактивная витрина

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

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

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

Тачскрин--стол

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

В России такие столы стоят в экспериментальном «офисе будущего» Сбербанка.

Биометрическая камера

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

Планшеты для ЭЦП

Для полноценного обслуживания клиентов в удаленном режиме не обойтись без внедрения электронной цифровой подписи. Осенью 2010 года компания Wacom, мировой лидер в разработке графических планшетов, выпустила специализированное устройство для электронной подписи Wacom STU-520. Специалисты предрекают, что оно произведет настоящую революцию на рынке.

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

Вендорный аппарат

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

Терминал для интернет--банкинга

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

NFC

Уже несколько лет назад MasterCard анонсировал карточку PayPass. Специальные терминалы списывают с карты стоимость покупок дистанционно -- физический контакт и дополнительная авторизация не требуются, -- что позволяет резко сократить время обслуживания покупателей в магазинах. В России данные карты на базе технологии NFC до сих пор не получили сколько-нибудь серьезного распространения.

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

Бесконтактные транспортные карты можно пополнять в терминалах «Элекснет», о пилотных проектах с использованием NFC заявлял Сбербанк. Думается, что в 2010-2011 годах начнется период бурного роста популярности данной технологии в нашей стране.

Мобильный картридер

Один из создателей социальной сети Twitter Джек Дорси в 2009 году анонсировал свое новое детище -- устройство Square. Это крохотный картридер (размеры устройства 2,5 х 2,5 х 3 см), который подключается к сотовому телефону через разъем для наушников. Идея в том, что с помощью Square принимать к оплате банковские карты сможет кто угодно -- даже бабушка, торгующая семечками на улице, если уж пользоваться российскими образами.

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

5. Повышение качества компьютерных программ

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

Значение качества для компьютерных программ

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

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

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

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

6. Понятие качества

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

Подходы к обеспечению качества

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

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

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

7. Проблемы тестирования и обеспечения качества

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

Перечислим распространенные проблемы тестирования.

* нет единого инструмента планирования и получения отчетности по проведенному или запланированному тестированию, покрытию кода/функциональности тестами;

* управление тестовой средой ведется вручную с минимальным использованием автоматизации;

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

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

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

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

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

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

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

Итак, как решить подобные проблемы и минимизировать их влияние на производство и внедрение программных продуктов?

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

Современные среды разработки должны предоставлять инструменты управления и поддержки тестирования, такие как протоколирование проверок, управление дефектами и изменениями, планирование тестирования, задание расписания и назначения задач, как на людей, так и на виртуальные и реальные тестовые машины, управление виртуальными тестовыми средами и «снимками» их состояний и т. д.

Подобный инструментарий должен решать следующий набор проблем, часто возникающих при тестировании сложных систем:

* постановка проблем и целей в тестировании;

* информирование об изменениях;

* управление серьезными изменениями в тест-скриптах при минимальных изменениях кода;

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

* создание одинаковых сред для воспроизведения ситуации у разных участников команды (в частности, работающих в разных организациях);

* протоколирование -- что, когда, кем тестировалось;

* с каким результатом, на каких средах и данных закончился тот или иной прогон тестов;

* статистика и ее динамическое измерение;

* отчетность о тестировании.

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

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

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

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

Эффективность тестирования резко возрастает, когда оно интегрировано с кодом. Чрезвычайно полезно, когда связи прослеживаются до требований и можно проверять покрытие и степень протестированности каждого требования. Сценарий сборки обычно включает в себя построение исполняемых программ, получение отчета о том, какие тесты необходимо повторить из-за изменений в собранной системе (impacted tests). Если эти тесты автоматические, они этим же скриптом самостоятельно запускаются сразу после сборки. Все тесты и протоколы их выполнения должны быть документированы.

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

9. Процесс обеспечения качества и распределение ответственности

кредитование автоматизация компьютерный

Как определить рамки и границы ответственности при обеспечении качества, кто несет ответственность за качественный результат работы или продукта?

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

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

Отсюда следует, что «нельзя полагаться на системы обеспечения качества на 100%», «тестеры не занимаются обеспечением качества» .

Другими словами, обеспечение качества - более широкое понятие, чем это принято считать. Обеспечение качества плотно переплетено со всеми процессами разработки и оптимизируется не только по инженерным, но и по экономическим и политическим критериям.

Необходимо подчеркнуть важность становления процесса обеспечения качества на высоком уровне. Для этого нужно руководствоваться положениями широко распространенных стандартов и руководств: ISO, CMMI, ГОСТ, LEAN Six Sigma, SWEBOK, PMBOK, BABOK и др. При сопровождении программ и сервисов можно порекомендовать использование стандартов ITSM, ITIL, COBIT...

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

Уровень качества

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

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

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

10. Завершение тестирования

Еще один очень важный вопрос - определение готовности программного обеспечения к выпуску (поставка заказчику или выход на рынок). Кто принимает это решение? Какая информация необходима для вывода о готовности программы? В какой момент времени это решение должно быть принято?

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

Не все найденные дефекты будут исправлены, особенно в конце проекта. В этот момент критично решение: продолжать ли искать дефекты? Так, большинство серьезных дефектов должны быть уже выявлены в случае применения подхода тестирования, основанного на рисках (risk based testing), когда критичный и наиболее используемый функционал, а также тот функционал, в котором ошибки наиболее вероятны, тестируется в первую очередь. Дальнейший поиск дефектов не повысит уровня качества, тем более что не все найденные ошибки успеют исправить.

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

Рис. 1. График зависимости прибыли от уровня качества

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

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

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

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

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

Рис. 2. Схема модели минимальной функциональности

Необходимо как можно раньше начинать процесс взаимодействия (обратной связи) с принимающей стороной. Тогда можно динамически наблюдать прогресс уровня качества. Каскадная методология (waterflow) этого не позволяет, а инкрементальные agile-процессы, в том числе XP (eXtreme programming), обеспечивают быструю обратную связь.

Критерии готовности

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

Критерии готовности функциональности:

* специфицированы и утверждены критерии приемки;

* готовы скрипты тестирования (в том числе автоматизированные), демонстрирующие достижение критериев;

* готов код, предназначенный для приемочного тестирования;

* тесты и код зарегистрированы в системе контроля версий;

* программа из поставленного кода успешно компилируется и собирается на сервере сборки;

* приемочные тесты (unit, component, system) для построенной программы успешно выполнены;

* ни один из всех остальных приемочных и блочных тестов не закончился неуспешно;

* пользовательская документация готова и обновлена;

* владелец продукта принял результат изменений. Критерии готовности версии: * весь рыночно значимый функционал включен в версию-кандидат;

* инспекция безопасности проведена успешно;

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

все обнаруженные ошибки высокой и очень высокой критичности исправлены,

проведено конфигурационное тестирование,

проведено минимальное тестирование локальной версии (в разрезе стран, языков),

проведено минимальное тестирование глобального продукта,

проверена доступность,

проверена достаточность уровня опыта пользователей,

проверена производительность;

* достигнуто соответствие бизнес-целям;

* созданы понятные, лаконичные инструкции по установке и откату для команды поддержки;

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

* каждая включенная функция была продемонстрирована и принята владельцем продукта.

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

Что дальше?

Во второй части нашей статьи предполагается рассмотрение следующих тем:

* дизайн программ для тестирования (под тестирование);

* количественные метрики для требований;

* методики тестирования ниже уровня интерфейса с пользователем;

* автоматизация тестирования;

* инструментарий поддержки процессов обеспечения качества и автоматизации тестирования;

* тестирование производительности и конкурентный анализ параллельных систем;

* сетевая эмуляция;

* «поведенческо-ориентированный» подход к разработке программ;

* «правильные» unit tests;

* Domain-Driven Design (DDD);

* прочие виды тестирования.

И еще много интересного!

Александр Горшков, Консультант Департамента консалтинга NVision Group

В практике реализации процесса тестирования наблюдается два варианта, когда тестирование осуществляют сотрудники:

* подразделения тестирования;

* различных подразделений.

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