1. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В КАЗАХСТАНСКИХ БАНКАХ
Традиционно в казахстанских банка доработка банковского ПО велась «на коленке». Классическая «водопадная» схема бизнес как правило не устраивает, поскольку предполагает, что 90% требований к разрабатываемому (дорабатываемому) модулю должны быть продуманы и зафиксированы, а это большой труд требующий предвидения и тщательного бизнес анализа. Поэтому проще было начать что-то, а потом долго переделывать, пока не получится что-то похожее на то что ожидалось. Понятно что при этом почти не возможно гарантировать каких-то сроков завершения доработок. Они спонтанно могут продолжаться неопределенное время. Понятно что и качество доработок при это сильно страдает, поскольку требования на ходу меняются, тестов тщательных не проводится, а когда уже сроки все истекли стараются сдать то что получилось.
Если в 90-х годах банкам надо было обеспечить хоть какую-то доработку имеющегося банковского ПО, то в к 2010-м годам надо было обеспечивать еще и достаточно хорошую динамику разработок. При этом мы понимаем, что банковское программное обеспечение должно быть к тому же еще и очень надежным. Поскольку финансы не любят неоднозначностей, а лояльность клиентов зависит от того насколько качественно и бесперебойно их обслуживают. И планируемые банковские продукты должны выходить в оговоренные сроки. Т.е . Банковская разработка должна обеспечивать надежность, качество, гибкость и обеспечение запланированных сроков
2. КАК СОВМЕСТИТЬ В РАЗРАБОТКЕ БАНКОВСКОГО ПО ГИБКОСТЬ И НАДЕЖНОСТЬ.
В 90-х годах начинает развиваться и становится популярной в западных станах технология предложенная компанией Rational Software, позволяющая обеспечить и гибкость и качество в разработке критичного программного обеспечения - Rational Unified Process (RUP) - унифицированный процесс разработки. Процесс в общем то является прародителем столь популярных ныне гибких методологий разработки. С той разницей, что у него можно было найти описание множества артефактов, а в гибких методологиях предполагается, что эти артефакты породят команды.
Идея подхода Rational Unified Process такая: по разрабатываемому модулю пишется Концепция (видение основных моментов и высокоуровневых требований) . Потом разработка делится на небольшие итерации в одну две недели. Первыми в работу берутся те участки на которых уже более детальные требования известны, и которые лежат в основе продукта и могут уже как-то работать. Требования по остальным итерациям постепенно уточняются. Т.е. все требования к началу разработки не детализируются, и могут меняться до тех пор пока итерация с этими требованиями не взята в работу.
3. RUP В РАЗРАБОТКЕ БАНКОВСКОГО ПО
RUP 2009 году был принят как основа для разработки процесса управления изменениями в kaspi bank. Понятно что RUP нигде не внедряется полностью как описан. Он адаптируется под каждый конкретный случай. Берется только то, что может быть полезным.
По RUP процесс разработки состоит из трех этапов: анализ, разработка, тестирование (как отдельный этап можно считать внедрение). Разработчики были разбиты на соответствующие тройки: аналитик, разработчик, тестер. Каждая тройка работает на определенное бизнес направление у которого есть свой бизнес заказчик. Разработка оформляется запросом на разработку. Весь объем разработки по запросу делится на итерации (заявки) по 6-9 рабочих дней на три этапа. Запросы выстраиваются в очередь. Приоритеты в очереди запросов может поменять бизнес заказчик этого направления самостоятельно, пока запрос не взят в работу. По взятому в работу запросу приоритеты не меняются. И требования тоже.
По запросам система автоматически считает плановые сроки завершения исходя из того на сколько итераций они разбиты. При смене приоритетов плановые сроки автоматически пересчитываются. В каждый запрос вкладываются высокоуровневые требования. Детальные требования прорабатываются уже в пределах итерации когда она взята в работу. Итерации переходят от одного участника разработки к другому поэтапно и в каждый момент времени каждый из них занят очередной работой. Скажем если запрос состоит из трех итераций (заявок), то в момент когда тестер работает с первой итерацией, разработчик работает со второй, а аналитик с третьей. Причем каждая итерация как правило содержит законченный функционал который можно уже переносить на рабочую схему. В крайнем случае собираются несколько итераций которые можно перенести на рабочую схему как работающий функционал.
Для сбора, анализа и фиксации требований были разработаны опросники и спецификации бизнес требований, для модуля (продукта), операции, представления, отчета. Для обеспечения качественного программирования были написаны правила программирования регламентирующие как оформлять код, как обыгрывать какие ситуации. Для обеспечения выполнения правил программирования были разработаны правила тестирования ПО на соответствие бизнес требованиям и требованиям надежности. Был организован выборочный контроль каждого этапа разработки с заполнением чек листов.
Разработка ведется на отдельных серверах, тестирование - на отдельных. Перенос на рабочую схему проводят специально выделенные люди, не разработчики и не тестеры, а работники сопровождения.
Автоматизация процесса управления изменениями ПО была реализована на продукте компании Rational Software – Clear Quest – специализированный продут по управлению изменениями. Но базовый функционал был существенно доработан чтобы обеспечить управление очередями, управление требованиями, управление ошибками и дефектами, автоматический контроль по пересечению разработок и управлению версиями, интеграция с банковской системой и 1С.
В системе работают как работники ИТ, так и бизнес заказчики. Разработана отчетность по показателям как процесса в общем, так и по каждому направлению и работнику. На основе информации из системы построена система мотивации участников разработки по тому насколько вовремя и качественно выполняются разработки. Рядовым работникам до 25% от базовый ЗП выплачивается в виде премиальных бонусов.
4. ЧЕГО УДАЛОСЬ ДОСТИГНУТЬ ИСПОЛЬЗУЯ RUP В РАЗРАБОТКЕ БАНКОВСКОГО ПО?
Внешне кажется что процесс разработки должен был бы удлинится, так как в нем появилось много новых обязательных работ и этапов.
Посмотрим как изменились показатели процесса управления изменениями на примере департамента банковских систем, который ведет доработку основной банковской системы ИБСО производства центра финансовых технологий за период 2011 – 2014 годы. При этом надо отметить, что количество разработчиков оставалось неизменным
•Соответствие плановым срокам возросло в 2.9 раза
•Время реализации заявки (6-9 нормодней) уменьшилось в 5.7 раза
•Заявок закрывается в 3.2 раза больше
•Нормодней выполняется в 2.2 раза
На рисунках 4.1. - 4.4. представлена динамика по метрикам процесса