Договор № _____

Договор № _____
г. Москва
« » ________201__ г.
Банк ВТБ 24 (закрытое акционерное общество), в лице члена Правления, директора Департамента
банковских и информационных технологий Русанова Сергея Георгиевича, действующего на
основании доверенности №1529 от 20.06.2012 г., именуемый в дальнейшем - Заказчик, с одной
стороны, и ______________________, в лице _______________________, действующего на основании
_________________, именуемое в дальнейшем - Исполнитель, с другой стороны, совместно
именуемые - Стороны, заключили настоящий договор (далее – Договор) о нижеследующем:
1.
Термины и определения
1.1. ДБО – дистанционное банковское обслуживание.
2.
Предмет договора
2.1. Исполнитель по заданию Заказчика обязуется выполнить работы по внедрению Системы
предотвращения мошенничества - RSA Transaction Monitoring and Adaptive Authentication
(далее – Система) в системах ДБО и системах обслуживания банковских карт (далее – Работы) в
соответствии с функциональными и нефункциональными требованиями к Системе, изложенными
в Приложении № 1 к настоящему Договору.
2.2. Характеристики выполняемых Работ, срок, порядок их выполнения, стоимость и прочие условия
определяются Сторонами в соответствующих заказах (далее – Заказ), которые являются
неотъемлемой частью Договора. Форма Заказа приведена в Приложении № 2 к Договору.
2.3. Требования к производительности Системы приведены в Приложении № 3 к Договору.
3.
Стоимость Работ и порядок расчетов
3.1. Предельная цена Договора
рублей, включая НДС (18 %).
3.2. Цена Договора состоит из стоимости всех Заказов, согласованных Сторонами в рамках Договора.
3.3. Стоимость Работ, указываемых в Заказе, определяется из количества затраченного Специалистами
Исполнителя времени в человеко-днях. Стоимость одного человеко-дня Специалистов
Исполнителя приведена в Таблице 1 «Дневные ставки Специалистов Исполнителя». Один
человеко-день составляет 8 (восемь) рабочих часов.
Роль Специалиста Исполнителя
Таблица 1. Дневные ставки Специалистов Исполнителя
Ставка (руб. с учетом НДС)
Архитектор
Аналитик
Разработчик
Руководитель проекта
Специалист по тестированию
Инженер - специалист по базовым прикладным
системам
(ОС,
БД)
и
вычислительному
Оборудованию
Технический писатель
Эксперт по системам безопасности
3.4. Расчеты по Договору производятся в безналичной форме в рублях Российской Федерации.
 Оплата производится путем перечисления денежных средств в размере 100 (ста) % от
стоимости Работ, установленной в Заказе, в течение 15 (пятнадцати) рабочих дней с даты
подписания Акта сдачи-приемки выполненных работ и выставления счета на оплату.
3.5. По согласованию Сторон Акт сдачи-приемки выполненных работ может быть подписан
Заказчиком и Исполнителем без передачи в тестирование результатов выполнения Работ.
3.6. Датой оплаты считается дата списания денежных средств с расчетного счета банка Заказчика.
4.
Права и обязанности Сторон
1
4.1. Правами на результат выполненных Работ по Договору – новый функционал Системы обладает
Заказчик.
4.2. Исполнитель обязуется передавать Заказчику все исходные коды систем, дорабатываемых
(расширяемых) в рамках Договора. Передача исходных кодов систем является неотъемлемой
частью Работ, выполняемых в рамках Договора. Порядок передачи исходных кодов определяется
Заказчиком.
4.3. Исполнитель обязуется предоставить квалифицированных штатных работников (далее Специалисты), которые должны иметь соответствующую квалификацию и соответствовать
необходимым профессиональным стандартам для выполнения Работ по Договору. Состав
Специалистов, предоставляемых Исполнителем, указывается в Заказах. Квалификационные
требования к Специалистам приведены в Приложении № 4 к Договору.
4.4. Исполнитель имеет право изменить состав Специалистов, предоставив Специалистов, уровень
подготовки и опыт которых не ниже заявленных первоначально, в случае если первоначально
заявленные Специалисты в силу объективных причин (нетрудоспособности, расторжение
трудовых отношений с Исполнителем и пр.) не в состоянии выполнять возложенные на них
функции.
4.5. Заказчик вправе инициировать замену Специалистов Исполнителя в случае их несоответствия
необходимой квалификации, а также требованиям и правилам режима и поведения на территории
Заказчика. Исполнитель в этом случае обязуется заменить Специалиста в течение 2 (двух) рабочих
дней с даты получения уведомления Заказчика Замена должна быть произведена на Специалиста
с аналогичной квалификацией и опытом, при этом Исполнителем должна быть обеспечена
преемственность в выполнении Работ при осуществлении замены, а Заказчик вправе не
согласовать новую кандидатуру Специалиста после изучения его опыта и квалификации на базе
предоставленной информации (резюме, опыт работы и личная встреча), предоставив
мотивированное заключение.
4.6. По согласованию Сторон Работы могут быть выполнены как на территории Заказчика, так и на
территории Исполнителя.
4.7. Заказчик обязуется обеспечить Специалистам Исполнителя необходимые и достаточные условия
для своевременного и качественного выполнения Работ, предоставление соответствующего
помещения, оборудования и программного обеспечения в согласованном Сторонами объеме.
4.8. Заказчик обязуется обеспечить Специалистам Исполнителя необходимый уровень доступа к
информационным системам Заказчика в рамках выполнения Работ по Договору.
4.9. Заказчик обязуется обеспечить активное сотрудничество Специалистов, а также оперативно
предоставлять информацию, необходимую Исполнителю для выполнения Работ по Договору, в
устной, и, при необходимости, в письменной форме. Несоблюдение Заказчиком указанных в
настоящем пункте условий может повлечь за собой изменение сроков выполнения Работ.
4.10. Заказчик вправе изменить состав Специалистов Исполнителя по согласованию с Исполнителем,
письменно уведомив Исполнителя об этом не менее чем за 2 (две) недели до начала выполнения
Работ.
5.
Порядок сдачи и приемки выполненных Работ
5.1. По окончании выполнения Работ, предусмотренных Заказом, Исполнитель и Заказчик
(уполномоченные надлежаще оформленной доверенностью представители Сторон) подписывают
Акт сдачи-приемки выполненных работ, удостоверяющий принятие Работ Заказчиком и
отсутствие у него претензий.
5.2. Заказчик подписывает Акт сдачи-приемки выполненных работ в течение 5 (пяти) рабочих дней с
даты его получения от Исполнителя, либо в этот же срок направляет Исполнителю
мотивированный отказ от подписания Акта сдачи-приемки выполненных работ в письменной
форме. В случае отказа Заказчика от приемки Работ Сторонами составляется двусторонний Акт с
перечнем необходимых доработок и сроков их устранения, который подписывается
уполномоченными представителями Сторон и скрепляется печатями Сторон.
5.3. В случае если Заказчик не направляет Исполнителю подписанный со своей стороны Акт сдачиприемки выполненных Работ или мотивированный отказ в соответствии с п.5.2.настоящего
раздела, Работы считаются выполненными надлежащим образом, принятыми Заказчиком в
полном объеме и подлежащими оплате в соответствии с условиями Договора.
5.4. Исполнитель предоставляет Заказчику счет-фактуру в сроки, предусмотренные законодательством
Российской Федерации.
2
5.5. Производимые Исполнителем модификации Системы и порядок их тестирования и установки на
вычислительные средства Заказчика должны удовлетворять требованиям «Порядка Приемосдаточных испытаний программного обеспечения, разработанного по заказу Банка ВТБ24 (ЗАО)»
(приведён в Приложении № 5 «Стандарты и требования по ведению разработок на языке Java» к
настоящему Договору)
6.
Гарантийный период
6.1. В течение 12 (двенадцати) месяцев с даты подписания Сторонами Акта сдачи-приемки
выполненных работ Исполнитель обязуется поддерживать Систему в режиме гарантийного
периода. В данном режиме Исполнитель обязуется принимать к анализу инциденты, связанные с
некорректностью работы модулей Системы, измененных или разработанных в рамках выполнения
Работ по Договору, проводить их анализ и, если необходимо, вносить изменения в логику работы
Системы. Если причиной инцидента явилась некорректное функционирование Системы,
Исполнитель за свой счет дорабатывает Систему в согласованные Сторонами сроки. Некорректное
функционирование Системы подразумевает несоответствие логики работы всей или части
Системы согласованным Сторонами в процессе исполнения Договора спецификациям, при
условии корректной работы пользователей.
7.
Условия конфиденциальности
7.1. Договор и все приложения к нему, а также иная (устная) информация, полученная Сторонами при
исполнении Договора, рассматриваются как конфиденциальные документы (сведения) и не
подлежат раскрытию третьим лицам в течение всего срока действия Договора без
предварительного письменного согласия на это другой Стороны, за исключением случаев,
предусмотренных законодательством Российской Федерации.
7.2. Стороны обязуются использовать конфиденциальную информацию только для цели выполнения
обязательств по Договору.
7.3. Стороны обязуются не разглашать и не использовать в своих интересах, равно как и в интересах
третьих лиц, прямо или опосредованно, конфиденциальную информацию, как в течение срока
действия Договора, так и в течение 3 (трех) лет с даты прекращения (расторжения) Договора.
8.
Обстоятельства непреодолимой силы
8.1. Стороны освобождаются от ответственности за частичное или полное неисполнение обязательств
по Договору, если такое неисполнение явилось следствием обстоятельств непреодолимой силы,
определяемых в соответствии с п.3 ст.401 Гражданского кодекса Российской Федерации.
8.2. Сторона, для которой создалась невозможность исполнения своих обязательств по Договору,
обязана не позднее 10 (десяти) рабочих дней с момента возникновения обстоятельств
непреодолимой силы, в письменной форме уведомить другую сторону о возникновении
обстоятельств такого рода, о предполагаемом сроке их действия и прекращения. Сторона, не
уведомившая другую сторону в указанный срок, не вправе ссылаться на действие обстоятельств
8.3. В случае если срок действия обстоятельств непреодолимой силы составит более 3 (трех) месяцев,
любая из Сторон вправе отказаться от исполнения Договора или его неисполнимой части.
9.
Ответственность Сторон
9.1. Стороны
несут ответственность за исполнение условий Договора в соответствии с
законодательством Российской Федерации.
9.2. В случае неисполнения или ненадлежащего исполнения Заказчиком обязательств по оплате
Исполнитель имеет право начислить Заказчику неустойку в размере 0,1 (ноля целых одной
десятой) % от суммы просроченного платежа, указанного в Заказе, за каждый календарный день
просрочки, но не более 10 (десяти) % от стоимости Работ, указанных в соответствующем Заказе.
9.3. В случае просрочки исполнения Исполнителем обязательств, предусмотренных заказом, Заказчик
имеет право начислить Исполнителю неустойку в размере 0,1 (Ноля целых одной десятой)% от
стоимости Работ, указанных в Заказе, за каждый календарный день просрочки исполнения
обязательств, но не более 10 (десяти) % от указанной суммы.
9.4. Уплата неустойки не освобождает Стороны от исполнения принятых на себя обязательств по
Договору.
10. Порядок разрешения споров
3
10.1. Все споры и разногласия по Договору Стороны будут стремиться разрешить в порядке
досудебного разбирательства: путем переговоров, составлением необходимых протоколов,
дополнений и изменений и др.
10.2. В случае невозможности урегулирования разногласий мирным путем, все споры и разногласия,
возникающие из Договора или в связи с ним подлежат разрешению в соответствии с
законодательством Российской Федерации в Арбитражном суде г. Москвы.
11. Срок действия Договора
Договор вступает в силу с даты его подписания Сторонами и действует до момента
выполнения Сторонами принятых на себя обязательств.
11.1.
12. Общие положения
12.1. Все названия статей Договора приведены исключительно для удобства пользования текстом и не
принимаются во внимание при толковании пунктов Договора.
12.2. Стороны могут внести изменения в существенные условия Договора путем подписания
дополнительного соглашения.
12.3. Все акты, извещения и иная переписка Сторон по Договору должны доставляться по указанным
в Договоре адресам и считаются полученными:
а) при направлении курьером – от даты, указанной в курьерском уведомлении о доставке;
b) при направлении заказным письмом – от даты, указанной на уведомлении о вручении;
c) при отправке телеграфом – от даты получения телеграфного или электронного подтверждения
о принятии телеграммы;
d) при отправке по e-mail – от даты получения электронного подтверждения о принятии e-mail.
12.4. Договор может быть расторгнут досрочно по соглашению Сторон. При достижении Сторонами
решения о расторжении Договора Договор считается расторгнутым с даты, предусмотренной в
Соглашении о расторжении Договора, при этом Стороны обязаны осуществить взаимную сверку
расчетов в порядке и сроки, определяемые ими по согласованию.
12.5. Любая из Сторон может прекратить действие Договора полностью или частично, если другая
Сторона:
а) не выполняет любое обязательство по Договору и такое неисполнение не устраняется в
течение 30 календарных дней после получения письменного уведомления о возникновении
такового;
б) осуществляет процедуру банкротства, подвергается ликвидации (за исключением
реорганизации) или в ее отношении назначается управляющий имуществом и такое
назначение не аннулируется в течение 30 календарных дней после его осуществления.
12.6. Договор может быть досрочно расторгнут по инициативе одной из Сторон в одностороннем
порядке при условии письменного уведомления другой Стороны о расторжении договора не
меньше чем за 30 календарных дней до предполагаемой даты расторжения договора.
12.7. В случае расторжения договора Стороны производят взаиморасчеты в течение 15 рабочих дней от
даты, указанной в уведомлении об отказе от исполнения Договора, но не менее чем с даты
получения такого уведомления другой Стороной.
12.8. После подписания Договора все предварительные переговоры по нему и соглашения, переписка,
протоколы о намерениях, касающиеся Договора, теряют юридическую силу
12.9. Ни одна из Сторон не имеет права передавать третьим лицам свои обязанности по Договору, без
письменного согласия другой Стороны.
12.10. Все приложения к Договору являются его неотъемлемыми частями.
12.11. В отношениях, не урегулированных Договором, но непосредственно вытекающих из его
правовой природы и содержания, Стороны руководствуются законодательством Российской
Федерации.
12.12. Договор составлен в двух экземплярах, по одному для каждой из Сторон, каждый из которых
имеет равную юридическую силу.
13. Приложения
13.1. Приложение № 1 – «Функциональные и нефункциональные требования к Системе
предотвращения мошенничества».
13.2. Приложение № 2 – «Форма заказа на выполнение Работ».
13.3. Приложение № 3 – «Требования по производительности».
4
13.4. Приложение № 4 – «Квалификационные требования к Специалистам Исполнителя».
13.5. Приложение № 5 – «Стандарты и требования по ведению разработок на языке Java».
14. Местонахождение, реквизиты и подписи Сторон
Заказчик:
ВТБ 24 (ЗАО)
101000, г. Москва, ул. Мясницкая, д. 35
ИНН: 7710353606, КПП: 775001001
ОКПО: 20606880, ОКОНХ: 96120
В ОПЕРУ Москва
кор. счет: 30101810100000000716
БИК: 044525716
_______________________
М.п.
Исполнитель:
_______________________
М.п.
5
Приложение № 1 к Договору от __________ № ________
Требования к
Системе противодействия
мошенничеству
Г. МОСКВА
6
Введение
1.1 Назначение документа
Данный документ содержит необходимые требования к созданию Системы
противодействия мошенничеству (СПМ), включающие в себя общие, функциональные и
нефункциональные требования.
Документ составлен на основании описания целевой архитектуры СПМ, описанной в
Отчете №1 и учитывает бизнес-требования, предъявляемых к СПМ со стороны Банка, а
также функциональные возможности ведущих решений в области противодействия,
выбранных для дальнейшего анализа, и технологических возможностей ИТ Банка.
1.2 Используемые термины
Таблица 1 Используемые термины
Термин
Определение
Авторизация
Разрешение, предоставляемое Эмитентом для проведения
финансовых операций, то есть выдача подтверждения
гарантии оплаты товаров (работ, услуг, результатов
интеллектуальной деятельности)/получения наличных,
приобретаемых/получаемых Держателем в ходе конкретной
операции.
Банкомат (АТМ)
Электронный программно-технический комплекс,
предназначенный для совершения операций выдачи наличных
денежных средств без участия уполномоченного работника
кредитной организации, с использованием платежных карт и
передачи распоряжений кредитной организации о
перечислении денежных средств с банковского счета (счета
вклада) клиента, а также для составления документов,
подтверждающих соответствующие операции.
Диспутный счет
Внутренний банковский счет Банка, открытый в
процессинговой системе для каждого Держателя Основной
карты при заведении клиентского контракта, предназначенный
для отражения спорных операций, требующих
дополнительного документального подтверждения с целью
определения правомерности их проведения или особых
действий Банка.
Диспутный цикл
Комплекс мероприятий, осуществляемых Банком в целях
урегулирования Спорной транзакции по платежной карте и
проводимый в рамках Правил международных платежных
систем Visa International и MasterCard Worldwide.
Инцидент
Это объект, используемый в рамках Системы
Противодействия Мошенничеству для проведения
расследования по несанкционированным операциям. В случае
поступления информации о несанкционированной операции в
Системе создается инцидент для проведения расследования и
7
Термин
Определение
принятия решения о мошенническом характере операции.
Карта
Эмитированная банком (кредитной организацией) Расчетная
карта, Кредитная карта, Предоплаченная карта одной или
нескольких российских или международных платежных
систем как инструмент безналичных расчетов,
предназначенный для совершения физическими лицами,
юридическими лицами и индивидуальными
предпринимателями Операций на территории Российской
Федерации и за рубежом с денежными средствами,
находящимися на банковском счете. Карта является
собственностью Эмитента и выдается во временное
пользование на срок, установленный Эмитентом.
Клиент
Физическое или юридическое лицо, либо индивидуальный
предприниматель, резидент Российской Федерации или
нерезидент, заключивший с Банком договор о предоставлении
услуги или пользующийся услугами банка в соответствии с
законодательством Российской Федерации.
Клиент (Держатель)
Физическое лицо, представитель юридического лица или
индивидуальный предприниматель, на имя которого
выпущена Карта, чье имя нанесено на лицевой стороне Карты
(за исключением Карт, на которых имя Держателя не
указывается) и чей образец подписи указан на оборотной
стороне Карты.
Контур УСБС
Контур УСБС – это отдельный экземпляр интеграционного
ПО, установленный на независимое аппаратное обеспечение,
обеспечивающий работу определенной бизнесфункциональности по индивидуальному SLA. УСБС
разработан на базе линейки интеграционного ПО Oracle.
Международная
платежная система
(Платежная система)
Ассоциация, объединение кредитно-финансовых учреждений
и/или организаций, осуществляющее функции обмена
транзакциями и проведения взаиморасчетов между сторонамиучастниками системы под единой торговой маркой (Visa
International, MasterCard Worldwide).
Мошенническая атака
Серия Мошеннических операций, схожих по характеру.
Мошенническая
операция
Операция, которая была совершена лицом, не являющимся
законным Держателем Карты или владельцем счета, либо
использовавшим для ее совершения поддельную карту или
полученные незаконным путем данные о Карте и ее
Держателе, или о счете.
Несанкционированно
Списание денежных средств со Счета Клиента, которое
8
Термин
Определение
е списание денежных
средств
Клиент не подтверждает.
Нефинансовая
операция
Любая операция, осуществляемая Клиентом через каналы
взаимодействия с Банком, которая не связана с денежными
операциями по счету. Примеры нефинансовых операций: вход
в систему, смена ПИН-кода и т.д.
Оповещение
Оповещение возникает в результате выявления системой
мониторинга подозрительной операции либо создается
пользователем системы вручную. Оповещения
обрабатываются Дежурными по мониторингу в целях
принятия решения о легитимном / несанкционированном
характере операции.
Персональный
идентификационный
номер (ПИН)
Индивидуальный код, присваиваемый каждой Карте
Держателя и используемый для идентификации Держателя
при совершении Операции. ПИН рассылается в специальном
защищенном от просмотра третьими лицами конверте (ПИНконверте). Использование этого номера, возможное только в
банкомате и некоторых POS-терминалах, является аналогом
собственноручной подписи Держателя на документе.
Подозрительная
операция
Операция, определенная системой мониторинга, в
соответствии с установленными правилами, как операция с
высоким уровнем риска, подлежащая контролю.
Правило системы
мониторинга
Совокупность критериев и пороговых значений по операциям
(как авторизационных, так и финансовых сообщений),
устанавливаемых и настраиваемых в системе мониторинга,
посредством которых системой мониторинга определяются
Подозрительные операции.
Претензия
Обращение Клиента, по поводу восстановления его
нарушенных прав, установленных договорными
обязательствами Банка и/или законодательством Российской
Федерации.
Профиль
Это набор исторических данных о какой-либо сущности или
группе сущностей (Клиент, Счет, Карта, Устройство, ТСП и
т.д.), который описывает типичное поведение
рассматриваемой сущности (характерные операции).
Расследование
Это набор мероприятий, направленный на подтверждение или
опровержение факта мошеннических действий,
инициируемый по заявкам Клиентов (претензии) и внешних
Банков и МПС (диспуты) о несанкционированных списаниях
денежных средств и мошенничестве в каналах ВТБ-24.
9
Термин
Определение
Регистрация
Учет Претензий в Системе регистрации и учета обращений
Клиентов.
Скомпрометированна
я Карта
Карта, в отношении которой имеются сведения об утечке
информации с возможным использованием третьими лицами в
мошеннических целях или имеются подозрения на
совершение мошеннических операций.
Спорная транзакция
Операция с использованием платежной карты Банка,
совершенная в устройстве стороннего банка (Not-On-Us) по
факту отражения финансовых результатов которой на счете
карты держатель карты выражает свое несогласие.
Счет
Банковский счет Клиента, открытый в Банке на основании
договора банковского счета, заключенного между Клиентом и
Банком, в целях осуществления расчетов.
Тип профиля
Набор параметров, которыми обладает профилируемая
сущность, на основании которых создается и обновляется
профиль.
Торгово-Сервисное
Предприятие
Пользователь устройства (POS, ePOS, mPOS), которое
находится на эквайринговом обслуживании Банком, либо
через которое проходят операции по картам, выпущенным
Банком
УСБС-Фронт
Универсальный Слой Банковских Сервисов – интеграционный
слой, изолирующий потребителей Бизнес Сервисов от
особенностей их технической реализации.
Устройства Банка и
устройства,
обслуживаемые
Банком по договорам
эквайринга
Устройства, предназначенные для проведения Клиентами
операций по картам (и счетам). Устройствами Банка являются:

POS-терминалы

Мобильные POS-терминалы

Электронные или виртуальные POS-терминалы

Банкоматы

ИПТ - Информационно-платежные терминалы

ИТТ - Информационно-транзакционный терминал
Факт компрометации
Подтвержденная информация о проведенной Мошеннической
операции или о том, что данные по Карте или счету стали
известны третьим лицам.
Фасилитатор
Организация, упрощающая юридическую схему
взаимодействия между ТСП и Банком
10
Термин
Определение
Финансовая операция
Любая операция по банковскому счету, осуществляемая в
соответствии с банковскими правилами и правилами
участников расчетов, проводимая по требованию Клиента или
без такового, в том числе: платеж, перевод, конвертация,
снятие или взнос наличных средств, влекущая списание
средств с банковского счета или зачисление средств на
банковский счет в соответствии с условиями договора
банковского счета, заключенного между Клиентом и Банком.
Черные списки
Черные списки – это списки объектов – счетов, Клиентов,
устройств и т.д., которые признаны используемыми в
мошеннических целях.
Эквайер
Кредитная организация (за рубежом – кредитно-финансовое
учреждение), являющаяся участником российской и/или
международной платежной системы и осуществляющая
эквайринг.
Эквайринг
Деятельность Банка, включающая в себя осуществление
расчетов с предприятиями торговли (услуг) по операциям,
совершаемым с использованием Карт, и осуществление
операций по выдаче наличных денежных средств Держателям
Карт, не являющихся клиентами данной организации.
Эмиссия
Деятельность Банка по выпуску и выдаче Карт, включающая
открытие Счетов Клиентам для совершения операций с
использованием Карт.
Эмитент
Кредитная организация (за рубежом – кредитно-финансовое
учреждение) – член платежной системы, сертифицированная
на персонализацию платежных карт, которая осуществляет
Эмиссию Карт, получает данные об Операциях,
произведенных Держателями, осуществляет Авторизацию,
относит суммы Операций на Счета Клиентов.
1.3 Используемые сокращения
Таблица 2 Используемые сокращения
Сокращение
Определение сокращения
ATM
Automated Teller Machine
IVR
Interactive voice response
ODS
Operational Data Store
POS/ mPOS
Point of Sale / Mobile Point of Sale
АБС
Автоматизированная банковская система
11
Сокращение
Определение сокращения
МПС
Международная платежная система
НСИ
Нормативно-справочная информация
ПВН
Пункт выдачи наличных
ПИН
Персональный идентификационный номер
СПМ
Система Противодействия Мошенничеству
ТП
Территориальное подразделение
ТСП
Торгово-сервисное предприятие
УСБС
Универсальный Слой Банковских Сервисов
ФБ/ДО
Филиал Банка / Дополнительный офис
ФЛ
Физическое лицо
ЮЛ
Юридическое лицо
12
2 Требования к Системе Противодействия Мошенничеству
2.1 Требования к системе в целом
2.1.1 Требования к структуре систем
2.1.1.1
Подсистемы Системы Противодействия Мошенничеству (далее Система) должны быть
построены по модульному принципу для обеспечения включения в их состав подсистем и
модулей подсистем, которые могут быть изменены, внедрены или модернизированы без
перепроектирования всей Системы
В состав Системы должны входить следующие функциональные подсистемы:
 Подсистема «Оценки риска операций»
 Подсистема «Обнаружения и предотвращения мошенничества»
 Подсистема «Подсистема расследования мошенничества»
 Подсистема «Анализа мошенничества»
 Подсистема «Отчетности»
 Подсистема «Реестр мошенничества»
 Подсистема «Оперативное хранилище данных»
 Подсистема «Локальное хранилище данных (витрина данных)»
 Подсистема «Управление Системой Противодействия Мошенничеству»
Функциональная композиция подсистем Системы Противодействия Мошенничеству представлена на
рисунке ниже
2.1.1.2
Онлайн и квази-онлайн предотвращение
мошенничества
Подсистема оценки риска операций
Оценка риска
операций
Управление
правилами
Управление
дополнительной
аутентификацией
Управление
профилями
Управление
списками
Сбор информации о
клиентском
устройстве в канале
ДБО
Оценка
подозрительности
поведения
пользователя ДБО в
рамках Web-сессии
Оценка
подозрительности
поведения Клиента в
ходе совершения
операций через Callцентр
Выявление и расследование
мошенничества
Подсистема обнаружения и
предотвращения мошенничества
Управление
оповещениями
Оперативный
анализ
оповещений
Запуск
процедур
реагирования
на
подозрительны
е операции
Учет точек компроментации,
выявленных в рамках оперативного
анализа
Подсистема
анализа
мошенничества
Подсистема
расследования
мошенничества
Подсистема
отчетности
Data Mining и
статистический
анализ
Управление
инцидентом
Бизнесаналитика
(Business
Intelligence)
Учет схем
проведения
мошенничества
Учет информации по
инциденту
Подготовка
отчетности
Подсистема «Реестр Мошенничества»
Учет мошеннических операций
Учет моешнничества, выявленного
третьей стороной
Оперативное хранилище данных
по противодействию
мошенничеству
Локальное хранилище данных
Подсистема «Управления Cистемой Противодействия Мошенничеству»
Управление доступом
пользователей
Управление учетными записями
пользователей
Администрирование системы
Диагностики и эксплуатации
системы
Рисунок 1.Функциональная композиция подсистем
2.1.1.3
Подсистема «Оценки риска операций» должна обеспечивать решение следующих задач:
 Сбор данных о клиентских устройствах в каналах ДБО Ф/Л и Ю/Л
 Оценка подозрительности поведения пользователя ДБО в рамках Web-сессии в каналах
ДБО Ф/Л и Ю/Л (для систем, реализованных по принципу тонкого клиента)
 Оценка подозрительности поведения Клиента в ходе совершения операций через Callцентр
 Оценка уровня риска проходящей операции с использованием пластиковых карт и по
счетам Клиентов Банка
 Поддержку процессов дополнительной аутентификацией при авторизации операций
через каналы ДБО
 Управление правилами и политиками проведения операций в соответствии с
рассчитанным уровнем риска
13
 Управление профилями объектов мониторинга
 Управление списками объектов мониторинга и их составом
2.1.1.4
Подсистема «Обнаружение и предотвращение мошенничества» должна обеспечивать
решение следующих задач:
 Управление оповещениями о подозрительных операциях и подозрениях на
мошенническую активности по счетам Клиентов Банка и пластиковым картам в различных
канал обслуживания Клиентов
 Оперативный анализ проводится в целях принятия решения о легитимном /
несанкционированном характере операции:

Исследование оповещений по подозрительным операциям,
подсистемой «Оценки риска операций» либо вручную,

Исследование подозрений на мошенническую активность в каналах ДБО и Callцентра

Выявление взаимосвязанных оповещений.
создаваемым
 Запуск процедур реагирования на подозрительные операции
 Вести учет выявленных точек компрометации: устройств Банка, ТСП, клиентских
устройств, источников совершения подозрительных / несанкционированных операций
 Обеспечивать процесс выявления точек компрометации как в автоматическом, так и в
«ручном режиме» (посредством формирования запроса к БД)
2.1.1.5
Подсистема «Расследование мошенничества» должна обеспечивать решение следующих
задач:
 Управление инцидентами по случаям несанкционированного списания / попытках
несанкционированного списания денежных средств с банковских счетов Клиентов Банка
 Вести учет как структурированной, так и не структурированной информации по инциденту
(документы, скан-копии документов, выписки со счетов и т.д.), собранной в ходе процесса
расследования
по
случаям
несанкционированного
списания
/
попытках
несанкционированного списания денежных средств с банковских счетов Клиентов Банка.
2.1.1.6
Подсистема «Анализ мошенничества» должна обеспечивать решение следующих задач:
 Проведения интеллектуального анализа данных с использование различных алгоритмов
и методов выявления зависимости между операциями в т.ч. прописанных пользователем
системы (аналитиком)
 Выявления паттернов осуществления мошенничества по счетам и пластиковым картам
клиентов через различные каналы обслуживания Клиентов
 Выявления характеристик мошеннического поведения в различных каналах
обслуживания Клиентов
 Вести учет документации, изображений и другой информации с описанием схем
осуществления мошенничества
 Осуществлять моделирование работы мер противодействия/ работы правил мониторинга
в заданном диапазоне данных (сформированы пользователем или взяты из БД)
2.1.1.7
Подсистема «Отчетность по противодействию мошенничеству» должна обеспечивать
решение следующих задач:
 Формирование и предоставление отчетности по историческим и оперативным данным о
деятельности противодействия мошенничеству
 Формирование и предоставление отчетности по эффективности обработки оповещений
 Формирование и предоставление отчетности по эффективности расследования
инцидентов
 Формирование и предоставление отчетности по эффективности деятельности групп
мониторинга и расследования мошенничества
 Формирование и создание отчетности по противодействию мошенничеству
 Визуализация информации
2.1.1.8
Подсистема «Реестр Мошенничества» должна обеспечивать решение следующих задач:
 Централизованное ведение информации обо всех выявленных фактах мошенничества,
признанных таковыми в ходе проведения внутренних расследований
 Централизованное
ведение
информации обо
всех
фактах
мошенничества,
осуществленных в сторонних организациях, выявленных и предоставленных третьими
сторонами
14
2.1.1.9
Подсистема «Оперативное хранилище данных» должна обеспечивать решение
следующих задач:
 Ведение актуальной оперативной информации по клиентам, последних совершенных ими
операциях, информацию по пластиковым картам, и счетам (данные по результатам
авторизации транзакций, текущие установленные лимиты, актуальной статусы по
статусам блокировки и т.д.). Системой обеспечивается временное хранение информации
СПМ и внешних систем, необходимой Дежурным по мониторингу для принятия решения о
характере операции, в целях снижения нагрузки на внешние системы. (Глубина хранения
должна детализироваться на этапах внедрения по всему составу необходимых данных)
2.1.1.10
Подсистема «Локальное хранилище данных (витрина данных)» должна обеспечивать
решение следующих задач:
 Сбор исторической информации по совершенным операциям по счетам и платежным
картам из внешних систем и ее предоставление для задач анализа и исследования
мошеннического поведения. Данные необходимы для выявления шаблонов
мошеннического поведения и разработки правил мониторинга
 Сбор, хранение и предоставление исторической информации, накопленной СПМ в рамках
процессов противодействия мошенничеству
2.1.1.11
Подсистема «Управление Системой Противодействия Мошенничеству» должна
обеспечивать решение следующих задач:
 Поддержка процессов ведения учетных записей и доступом пользователей в Системе
 Продержка процессов администрирования и эксплуатации Системы
2.1.2 Требования к поддерживаемым каналам обслуживания клиентов
2.1.2.1
В рамках процессов противодействия мошенничеству Система должна обеспечивать
мониторинг операций, совершаемых по следующим каналам обслуживания клиентов
 Эмиссия (использование платежных карт Клиентов Банка в устройствах, обслуживаемых
сторонними банками)
 Интернет-эквайринг
 Торговый эквайринг и Сеть Банкоматов
 POS
 ATM и ИПТ
 Информационно-Платежные Терминалы
 m-POS(опционально)
 Дистанционное банковское обслуживание
 ДБО Физических Лиц
 ДБО Юридических Лиц
 Опционально:
 Точки продаж / Филиалы Банка
 Кол-центр
 IVR
2.1.3 Требования к взаимодействию Системы со смежными информационными
системами
2.1.3.1
В целях унификации, взаимодействие Системы со смежными информационными системами
должно быть реализовано через контуры УСБС, если не будет выявлено существенных
требований, ввиду которых необходима реализация интеграции по схеме «Host-2-Host» или
с использованием других способов взаимодействия.
2.1.3.2
В рамках проекта по внедрению СПМ, решение о реализации интеграционного потока через
УСБС должно приниматься по результатам изучения вариантов его реализации
2.1.3.3
Система должна обеспечивать информационный
использованием следующих протоколов:
 SOAP1.1/HTTP, XML/HTTP, REST
 SOAP1.1/JMS, XML/JMS
 JDBC
2.1.3.4
В рамках процессов противодействия мошенничеству
взаимодействие со следующими внешними системами:
обмен
с
внешними
должно
быть
системам
с
обеспечено
15
Таблица 3 Используемые термины
№
Название
системы
Бизнес-задачи
Информационные потоки
1
Avaya (Центр
Обработки
Вызовов)
Обработка операций
Avaya предоставляет голосовые данные Системе Противодействия
Мошенничеству для оценки голосового отпечатка звонившего и
сопоставления его с голосовыми профилями мошенников и профилями
клиента
Система Противодействия Мошенничеству предоставляет подсказки
оператору по необходимым действиям.
В случае необходимости дополнительной аутентификации Система
Противодействия Мошенничеству предоставляет Avaya
сформированные КВА и получает полученные ответы для
аутентификации
2
Интернет Банк
3
Мобильный Банк
Обработка операций
В рамках процессов онлайн обработки операций и взаимодействия
пользователей с сервисами ДБО ФЛ обеспечивается:

Передача сырого трафика от клиентских приложений ДБО физ. лиц
в Систему Противодействия Мошенничеству для оценки поведения
пользователя
Система Противодействия Мошенничеству в случае выявления
подозрительного поведения пользователя в системе Интернет-Банк,
Мобильный-Банк может разорвать web-сессию клиента, ограничить вход
пользователя на определенный промежуток времени и т.д.
4
ДБО физ. лиц
(ДБО ФЛ)
Обработка операций
В рамках процессов обработки операций (как онлайн обработки
транзакций, так и квази-онлайн обработки) по счетам клиентов – физ.
лиц система ДБО ФЛ предоставляет данные о:



Операции по счету / карте ФЛ / вкладу
Данные о клиентском устройстве (данные о МАС адресе ПК,
«слепок» характеристик мобильного устройства, используемые
версии браузера и т.д.)
Данные об условиях совершения платежа (местоположение, IP
адрес, текущее время в месте совершения операции, средство
подтверждения и т.д.)
В рамках онлайн обработки операций Система Противодействия
Мошенничеству передает Системе ДБО ФЛ:

Решения по легитимности операций (авторизация, отклонение,
дополнительная аутентификация)
В случае дополнительной аутентификации в рамках задач онлайн
обработки операций:
Система ДБО ФЛ:


Вызывает сервисы дополнительной аутентификации операции
Предоставляет полученные ответы пользователя для
дополнительной аутентификации
Система Противодействия Мошенничеству взаимодействие
осуществляет:


Реагирование на
подозрительные операции
Отправку сформированных контрольных вопросов, ОТР для
проведения дополнительной аутентификации
Уведомление о корректности ответов на контрольные вопросы,
введение ОТП
Система Противодействия Мошенничеству осуществляет следующие
действия:





Отправляет запрос на блокировку счетов ДБО ФЛ
Отправляет запрос на блокировку учетных записей в ДБО ФЛ
Отправляет запрос на введение лимитов по счету(ам) в ДБО ФЛ
Отправляет запрос на блокировку счетов получателей – клиентов
Банка (ПК, текущие счета, расчетные счета в АБС)
Отправляет информацию о получателях мошеннической /
подозрительной операции – клиентов сторонних банков
ДБО ФЛ уведомляет Систему Противодействия Мошенничеству о
принятых мерах по блокировкам (подтверждение принятых мер)
16
№
Название
системы
Бизнес-задачи
Информационные потоки
Анализ подозрительных и
мошеннических операций
Для задач оперативного анализа Система Противодействия
Мошенничеству выгружает в режиме реального / квази-реального
времени из систем ДБО ФЛ:

Данные с остатками по счетам, данные по статусам счетов и
учетных записей, по установленным лимитам
Для задач выявления мошеннического поведения (оффлайн анализа
транзакций) из системы ДБО ФЛ производится выгрузка:
 Истории авторизаций по операциям
 Историю по платежным операциям по счетам ДБО ФЛ
5-6
ДБО юр. лиц
Обработка операций
(ДБО ЮЛ)
В рамках процессов онлайн обработки операций по счетам клиентов –
юр.лиц предоставляется следующие данные:



Операции по счету ЮЛ
Данные о клиентском устройстве (данные о МАС адресе ПК,
«слепок» характеристик мобильного устройства, используемые
версии браузера и т.д.)
Данные об условиях совершения платежа (местоположение, IP
адрес, средство подтверждения и т.д.)
Также в рамках процессов онлайн обработки операций и
взаимодействия пользователей с сервисами ДБО ЮЛ обеспечивается:

Передача сырого трафика от клиентских приложений ДБО ЮЛ в
Систему Противодействия Мошенничеству для оценки поведения
пользователя
Система Противодействия Мошенничеству в рамках задач по онлайн
обработке операций предоставляет следующую информацию:

Решения по легитимности операций (авторизация, отклонение,
дополнительная аутентификация)
В случае дополнительной аутентификации в рамках онлайн обработки
операций, системы ДБО ЮЛ:


Вызывает сервисы дополнительной аутентификации операции
Предоставляет полученные ответы пользователя для
дополнительной аутентификации
Система Противодействия Мошенничеству взаимодействует с Системой
ДБО ЮЛ в части:


Реагирование на
подозрительные операции
Отправки сформированных контрольных вопросов, ОТР для
проведения дополнительной аутентификации
Получения ответов от пользователя в рамках процедуры
дополнительной аутентификации
Система Противодействия Мошенничеству осуществляет следующие
действия:

Отправляет запрос на блокировку учетных записей в ДБО ЮЛ
Отправляет информацию о получателях мошеннических /
подозрительных операций
ДБО ЮЛ уведомляет Систему Противодействия Мошенничеству о
результатах блокировки учетных записей
7
Модуль расчётнокассового
обслуживания
(РКО)
Обработка операций
В рамках процессов онлайн обработки операций по счетам и картам
клиентов Банка через каналы ТП / ДКО Система Противодействие
Мошенничеству получает данные:




Операции по счету / карте
Данные о сотруднике (операционный сотрудник ТП/ДКО),
совершающем операцию
Признак подозрительности операции (подозрении, выявленном
сотрудником Банка)
Данные о ТП/месте проведения операции (в случае проведения
операции через Кол-центр специалист Кол-центр может уточнить
место, откуда звонит клиент, что позволит провести простые
проверки)
Система Противодействия Мошенничеству в рамках процессов онлайн
обработки операций предоставляет следующую информацию:

Решения по легитимности операций (авторизация, отклонение,
дополнительная аутентификация)
17
№
Название
системы
Бизнес-задачи
Информационные потоки
В случае дополнительной аутентификации в ходе онлайн обработки
операций, модуль РКО:


Вызывает сервисы дополнительной аутентификации операции
Предоставляет полученные ответы пользователя для
дополнительной аутентификации (либо признак правильности
аутентификации в зависимости от реализации)
Система Противодействия Мошенничеству в рамках онлайн обработки
операций взаимодействует с модулем РКО в части:


7
Аутентификацион
ный Центр
Реагирование на
подозрительные операции
Отправки сформированных контрольных вопросов, ОТР для
проведения дополнительной аутентификации
Получения ответов от пользователя в рамках процедуры
дополнительной аутентификации
Система Противодействия Мошенничеству в рамках онлайн обработки
операций осуществляет вызов сервисов Аутентификационного Центра
для:



Определения доступных политик для дополнительной
аутентификации операций по счету / карте для пользователя
(клиента)
Уведомления Клиентов о принятых мерах реагирования
Блокировки учетных записей пользователей в ДБО
Аутентификационный Центр в рамках онлайн обработки операций
предоставляет Системе Противодействия Мошенничеству:


8
Система
регистрации и
учета обращений
клиента
Проведение
расследований
Доступные политики для дополнительной аутентификации
Результаты блокировки учетных записей пользователей в ДБО
Взаимодействие с Системой регистрации и учета обращений
пользователей осуществляется в рамках процессов обработки
претензий Клиентов о несанкционированном списании / попытке
несанкционированного списания денежных средств.
Система противодействия мошенничеству получает из Системы
регистрации и учета обращений Клиентов


Данные о претензии
Список оспариваемых операций
Система противодействия мошенничеству предоставляет Системе
регистрации и учета обращений Клиентов в данные о:


9
Система
Диспутных Циклов
Проведение
расследований
Текущем статусе расследования
Результатах расследования
Взаимодействие с Системой Диспутных Циклов осуществляется в
рамках процессов обработки диспутов о несанкционированном списании
/ попытке несанкционированного списания денежных средств,
полученных от внешних банков-эмитентов пластиковых карт или МПС
Система противодействия мошенничеству получает из Системы
Диспутных Циклов


Данные о претензии
Список оспариваемых операций
Система противодействия мошенничеству предоставляет Системе
Диспутных Циклов данные о:


10
Процессинговая
система
Обработка операций
Текущем статусе расследования
Результатах расследования
В рамках процессов онлайн и квази-онлайн обработки операций по
картам Система Противодействия Мошенничеству получает из
процессинговой системы следующие данные:





Операции (финансовые и нефинансовые), совершаемой по
пластиковым картам
Данные по каналу, в рамках которого была совершена операция
Данные по ТСП, в котором осуществлена операция
Данные по POS-устройству, в котором осуществлена операция
Данные по ИПТ, в котором осуществлена операция
Система Противодействия Мошенничеству в рамках процессов онлайн
обработки взаимодействует с процессинговой системы следующим
18
№
Название
системы
Бизнес-задачи
Информационные потоки
образом:

Передает результаты оценки легитимности операции и решение о
проведении / задержке / отказе в операции
В рамках онлайн и квази-онлайн мониторинга операций:
 Передает данные о выявленных скомпрометированных
устройствах
Анализ подозрительных и
мошеннических операций
Для задач оперативного анализа и актуализации данных по банковским
счетам, Процессинговая система уведомляет Систему Противодействия
Мошенничества обо всех изменениях статусов блокировки /
разблокировки карт, изменению лимитов / остатков на карточных счетах,
статусов устройств.
Для задач выявления мошенничества Система Противодействия
Мошенничеству получает информацию обо всех авторизациях и
информацию по платежным операциям из процессинговой системы
Реагирование на
подозрительные операции
Система Противодействия Мошенничеству осуществляет следующие
действия:




12
АБС
Анализ подозрительных и
мошеннических операций
Отправляет запрос на блокировку / разблокировку карт
Отправляет запрос на блокировку / разблокировку устройств
Отправляет запрос на введение лимитов по картам
Процессинговая система уведомляет Систему Противодействия
Мошенничеству о принятых мерах по блокировкам (подтверждение
принятых мер)
В рамках оперативного анализа подозрительных операций по счетам
АБС, Система Противодействия Мошенничеству получает следующие
данные из АБС:

Информация по статусам блокировки счетов / остаткам по счетам /
установленным лимитам
В рамках задач выявления мошеннического поведения из АБС
производится выгрузка:
 Истории по авторизациям операций по счетам АБС
 История платежных операций по счетам АБС
Реагирование на
подозрительные операции
Система Противодействия Мошенничеству предоставляет АБС
следующую информацию:


Запросы на блокировку счетов в АБС
Запросы на введение лимитов по счетам АБС
Динамическое
хранилище
аналитической
информации
Анализ подозрительных и
мошеннических операций
14
MDM
Для всех задач
Взаимодействие с MDM решением осуществляется в целях получения
идентификатора Клиентов Банка и мастер-информации по клиенту:
контактные данные Клиента, регистрационные данные
15
Система НСИ
Для всех задач
Взаимодействие с Системой НСИ осуществляется в целях получения
информации об организационной структуре Банка, данных по
сотрудникам.
16
Система
Управления
Контентом (ECM)
Анализ подозрительных и
мошеннических операций
Взаимодействие с Системой Управления Контентом осуществляется в
целях вызова сервисов печати, а также хранения и учета
неструктурированной информации, накопленной в рамках процессов
противодействия мошенничеству (документы, скан-копии, изображения и
т.д.)
13
2.1.3.5
Отчетность
Проведение
расследований
Взаимодействие с Динамическим Хранилищем Аналитической
Информации осуществляется в целях периодической выгрузки данных
по противодействию мошенничеству из СПМ и загрузке исторической
информации по операциям из Хранилища в СПМ.
Детальные схемы и технологии информационного взаимодействия Системы с внешними
системами должны быть сформулированы на этапах микро-дизайна решения и закреплены в
Частных Технических Заданиях на реализацию подсистем
2.2 Функциональные требования к Системе
2.2.1 Требования к подсистеме «Оценки риска операций»
2.2.1.1
Функционал «Сбор данных о клиентских устройствах»
19
 Подсистема должна обеспечивать автоматический сбор информации, характеризующие
клиентское устройство, в момент совершения операции:




Характеристики сети, из которой осуществлен вход в систему ДБО
Характеристики программного и аппаратного обеспечения устройства, с
которого осуществлен вход
Платформа устройства и ее характеристики (язык, текущая временная зона)
Гео-локационные данные нахождения устройства в момент совершения
операции
 Подсистема должна обеспечивать передачу собранных данных о клиентском устройстве
в онлайн режиме для расчета уровня риска операции
2.2.1.2
Функционал «Оценка подозрительности поведения пользователя ДБО в рамках Web-сессии»
 Подсистема должна обеспечивать мониторинг трафика, генерируемого пользователем, в
ходе использования приложений ДБО, построенных по принципу тонкого клиента, с
момента входа в систему до момента прекращения работы (завершения сессии)
 Подсистема должна обеспечивать учет и анализ последовательности перемещения
клиента между окнами приложения / страницами в системе ДБО в рамках сессии
 Подсистема должна обеспечить учет и анализ событий при взаимодействии
пользователя с UI систем ДБО (нажатие клавиш, мыши, кнопок) в рамках сессии
 Подсистема должна поддерживать функции расчета и оценки скорости навигации клиента
по сайту / приложению в рамках сессии
 Подсистема должна предоставлять возможности анализ параметров, характеризующих
заполнение полей пользователем в рамках сессии
 На основе собранных данных подсистема должна обеспечивать оценку риска
использования системы ДБО в мошеннических целях (например, в результате атак вида
«Человек посередине» (man-in-the-middle или MITM), троянов («Человек в браузере»,
man-in-the-browser Trojans) и других видов атак)
 В случае выявления угроз использования клиентского устройства в мошеннических целях
в результате кибератаки или заражения система должна иметь возможность в
соответствии с установленными правилами мониторинга осуществлять автоматический
вызов процедур прекращения пользовательской сессии, блокировки учетных записей в
системе ДБО для скомпрометированных учетных записей
 В случае выявления угрозы подозрительного использования систем ДБО, подсистема
должна формировать оповещение о подозрительном активности пользователя в рамках
веб-сессии для Дежурных по мониторингу
 Подсистема должна обеспечить автоматическое обновление профиля поведения
пользователя в канале ДБО на основе собранных данных в рамках сессии
 Подсистемой должен вестись автоматической учет рассчитанного
использования систем ДБО в мошеннических целях в рамках сессии
уровня
риска
 Подсистемой должен вестись учет мер, принятых автоматически в случае выявления
мошеннического использования системы ДБО
2.2.1.3
Функционал «Оценка подозрительности поведения Клиента в ходе совершения операций
через Call-центр»
 Подсистема должна обеспечивать анализ голосового потока звонящего в ходе
телефонного соединения в целях оценка голосовых данных звонящего с голосовым
отпечатком из профиля клиента или голосовыми профилями мошенников
 На основании оценки голосового потока подсистемой должен быть рассчитан уровень
риск совершения операция мошенническим путем
 В соответствии с правилами мониторинга голосового потока на основании рассчитанного
уровня риска подсистема должна принимать решение о подозрительном / легитимном
совершении операции в ходе совершения операции через Call-центр или IVR
 В случае выявления подозрительного поведения на основании анализа голосового потока
подсистема должна формировать оповещение для Дежурных по мониторингу и
специалистов Call-центра
20
 В случае выявления подозрительного поведения Система должна в режиме реального
времени предоставлять подсказки оператору Сall-центра по мерам дополнительной
аутентификации звонящего, либо о необходимых действиях (блокировки счетов, карт,
создания «подставного» счета и т.д.)
 В случае выявления подозрительного поведения Система должна Система должна
обеспечить обновление голосового профиля Клиента
 В подсистеме должен вестись автоматический учет уровня риска, рассчитанного на
основании анализа голосового потока
 В подсистеме должен вестись учет принятых автоматически принятых мер (если
применимо) по реагированию на подозрительные операции и подозрительную
активность, выявленные в результате анализа голосового потока
2.2.1.4
Функционал «Оценка риска операций»
 Подсистема должна быть встроена в рамки процесса авторизации операций.
 Оценка риска должна проводиться по операциям через выделенные в пункте 1.1.2
каналы, совершаемым:


По счетами ФЛ и ЮЛ клиентов Банка в АБС Банка
По платежным картам, эмитированным в процессинговых системах Банка
 Система должна обеспечивать расчет уровня риска операций, совершаемых по
выделенным каналам путем сравнения собранных данных по условиям совершения
обрабатываемой операции с данным по профилю Клиенту, счету, устройству. Для
анализа предполагается использование информации:






Устройство, с использование которого осуществляется операция (клиентское
устройство, или устройство, обслуживаемое Банком, либо сторонним банком).
Данные по местоположению, сетевым данным клиентского устройства (IP
address, тип соединения и т.д.)
Доступные данные о мошеннических устройствах, счетах
Данные о поведении пользователя в канале ДБО
Данные по поведению клиента в рамках веб-сессии
Данные по проводимой операции (счет отправителя, счет получателя и т.д.)
 Все результаты оценки операций должны быть логироваться в специальных журналах
оценки операций с обоснование выставленного уровня риска
 Система должна обеспечивать
авторизации операций
учет
применения
и
использования
правил
для
 Система должна обеспечивать регистрацию всех случаев изменения в оценки риска
операции
 Система должна обеспечивать обновление профилей Клиентов, счетов, Устройств на
основании данных по проводимых операциях
 Система должна предоставлять возможность автоматического обновления внутренних
моделей расчета и оценки риска, используя данные по операциям, условиям их
совершения, выявленных несанкционированных и мошеннических операциях, и другой
накопленной информации либо их ручного обновления
 В соответствии с рассчитанным уровнем риска и в соответствие с установленными
правилам Система должна принимать решение о подозрительности / легитимности
операции
 В соответствии с принятым решением о подозрительности / легитимности операции
система должна принимать следующие меры:





Принять операцию
Отклонить операцию
Провести дополнительную аутентификацию операцию
Отложить операцию
Не предпринимать никаких действий (в случае
функционирования)
тестового
режима
 В случае выявления подозрительной операции Система должна иметь возможность
автоматический запуск мер реагирования на подозрительную активность (блокировка
21
карты, счета, учетной записи, устройства, введение лимитов по счету, карте, банкомату,
лимиты на операции в АБС)
 В случае выявления подозрительной активности (операций) Система должна
формировать оповещения о подозрительной активности (или операциях) для Дежурных
по мониторингу операций
 При расчете уровня риска операции необходимо, чтобы Система принимала во внимание
следующую информации (набор не является достаточным):











тип канала совершения операции
IP/MAC-адреса и их геолокационные данные совершения операции
идентификационный номер устройства (device ID), с которого осуществлена
операция
используемые ресурсы (например, браузер) для осуществления операции
информационный отпечаток устройства (cookies), с которого осуществлена
операция
типичное время начала работы внешнего пользователя
среднее количество открытых сессий у клиента
суммы платежей;
получателей и банки получателей платежа;
назначения платежей;
среднее/общее количество операций и их сумма в интервал времени;
 В системе должны быть предусмотрены возможности:



2.2.1.5
добавления новых параметров,
включения/отключения параметров в профиль клиента и в правила анализа
изменения значений параметров мониторинга
Функционал «Управление дополнительной аутентификаций»
 Подсистема должна предоставлять возможность регистрации запросов от внешних
систем на проведение дополнительной аутентификации
 Подсистема должна обеспечивать
дополнительной аутентификации
логирование
всех
запросов
на
проведение
 Подсистема должна иметь возможность принимать решения о методе дополнительной
аутентификации в соответствии с доступными для данного Клиента в данном канале
политик аутентификации
 Подсистема должна предоставлять возможности для автоматического уведомления
ответственных исполнителей о необходимости совершения обратного подтверждающего
звонка Клиенту для подтверждения операции
 На основе полученных ответов по дополнительной аутентификации подсистема должна
уведомлять об успешном / неуспешном прохождении процедуры дополнительной
аутентификации
 В случае неуспешного прохождения процедуры дополнительной аутентификации
подсистема должна иметь возможность автоматического запуска необходимых мер
реагирования
 По результатам проведения дополнительной аутентификации подсистемой должно
приниматься решение о подозрительности / легитимности операции
 В случае если по результатам дополнительной аутентификации операция признана
подозрительной, то должно быть создано оповещение о подозрительной операции для
Дежурного аналитика
 Результаты дополнительной аутентификации должны логироваться
2.2.1.6
Функционал «Управление правилами»
 Подсистема должна обеспечивать создания / редактирования / изменения правил,
применяемых в рамках мониторинга операций, совершаемых по различным каналам
обслуживания клиентов
 В подсистеме должна быть предусмотрена возможность построения правил:

С помощью конструктора правил (удобный пользовательский интерфейс)
22


С помощью специального внутреннего языка
С помощью языков программирования высокого уровня (С++, Java и т.д.)
 Подсистема должна предоставлять возможности настройки правил и осуществления
мониторинга для поддержки фасилитаторских схем
 Подсистема должна предоставлять возможности по запуску правила как в режиме
тестирования (без влияния на осуществляемые операции), так и «боевом» режиме (с
возможностью управляющего воздействия на операцию)
 Подсистема должна предоставлять возможности по настройке применения правил к
различным спискам и объектам мониторинга, каналам обслуживания клиентов,
профилям.
 Подсистема должна предоставлять возможность формирования последовательности
применения правил при мониторинге операций
 Подсистема должна обеспечивать возможность моделирования и тестирования правил
на исторических/искусственных данных
 Подсистема должна предоставлять возможность тестирования правил на предмет
создаваемой нагрузки на системы Банка
 Подсистема должна обеспечивать учет применения правил к операциям в рамках
процессов мониторинга операций
2.2.1.7
Функционал «Управления профилями»
 Подсистема должна обеспечивать ведение профилей клиентов, счетов, карт, клиентских
устройств, ТСП на основании данных о совершаемых операциях
 Подсистема должна обеспечивать ведения поведенческих профилей клиентов в каналах
ДБО
 Подсистема должна предоставлять
(отпечатков) клиентов
возможность
по
учету
голосовых
профилей
 Подсистема должна предоставлять возможности по настройке параметров, на основании
которых осуществляется профилирование объектов
 Подсистема должна обеспечивать предоставление информации о профиле объекта по
требованию с учетом установленных политик обеспечения доступа к конфиденциальной
информации
 Подсистема должна обеспечивать современную и автоматическую актуализацию
параметров профилей объектов на основании собранной информации в рамках онлайн
мониторинга операций
 Подсистема должна обеспечивать ведение истории изменения профиля
2.2.1.8
Функционал «Управления списками»
 Подсистема должна предоставлять возможности по ведению реестров списков («черных,
«белых» и других списков) объектов мониторинга (клиентов, устройств, обслуживаемых
Банком, клиентских устройств, счетов, карт, ТСП)
 Подсистема должна предоставлять возможности по редактированию иерархии списков,
создание / редактирование дочерних списков
 Подсистема должна предоставлять возможности по созданию / редактированию
параметров, характеризующих списки мониторинга и принадлежности объекта к
указанному списку мониторинга
 Подсистема должна предоставлять возможности формирования состава объектов,
входящих в список мониторинга (в ручном и / или автоматическом режиме)
2.2.2 Требования
к
мошенничества»
2.2.2.1
подсистеме
«Обнаружения
и
предотвращения
Функционал «Управления оповещениями»
 Подсистема должна обеспечивать ведение журнала созданных подсистемой «Оценки
риска операций» оповещений
23
 Подсистема должна предоставлять возможность ручной регистрации оповещения о
подозрительных операции сотрудникам в случае выявления информации о
несанкционированных операциях либо получения информации о несанкционированных
операциях от Клиента
 Подсистема должна автоматически предоставлять список операций, по которым было
сформировано оповещение, и, при необходимости, предоставлять пользователям
возможности редактирования данного списка (добавление, удаление операцией)
 Подсистема должна предоставлять возможность выявления взаимосвязи
оповещениями, или заведению данных взаимосвязей в ручном режиме
между
 Подсистема должна в оперативном режиме предоставлять всю необходимую
информацию об оповещении (время создания, список операций, по которым создано
оповещение и т.д.)
 Подсистема должна осуществлять назначение задач по обработке оповещений на
Дежурного аналитика, уведомления дежурного персонала о новых задачах по обработке
оповещений
 Система должна предоставлять возможности по распределению задач по обработке
оповещений между Дежурными по мониторингу, в соответствии с текущим графиком
дежурства
 Подсистема должна осуществлять приоретизацию
оповещений о подозрительных операциях
всех
созданных
оповещений
 Подсистема должна предоставлять возможности по формированию преднастроенных
шаблонов по обработке оповещения
 Подсистема должна осуществлять формирование списка и последовательности задач
обработки оповещения для в соответствии с шаблоном обработки
 Подсистема должна обеспечивать ведение статуса обработки оповещения
 Подсистема должна предоставлять возможность регистрации инцидента для
расследования по оповещению (или группе оповещений) в случае, если по результатам
обработки оповещения или оперативного анализа операция(ии) была признана
«нелегитимной»
2.2.2.2
Функционал «Запуск процедур реагирования на подозрительные операции»
 Подсистема должна иметь возможность направить в системы АБС приказ на блокировку
(разблокировку) пластиковых карт, выпущенных Банком, в случае принятия решения о
несанкционированном (легитимном) характере совершения операции
 Подсистема должна иметь возможность направить в системы АБС приказ на блокировку
(разблокировку)
счетов
клиентов
Банка
в
случае
принятия
решения
о
несанкционированном (легитимном) характере совершения операции
 Подсистема должна иметь возможность направить в системы ДБО приказ на блокировку
(разблокировку) учетных записей, используемых клиентами для доступа к счетам через
ДБО в случае принятия решения о несанкционированном (легитимном) характере
совершения операции
 Система должна иметь возможность по введению лимитов на проводимые операции по
картам, счетам, либо в банкоматах и устройствах, обслуживаемых Банком
 Система должна иметь возможность задержки проведения в АБС
необходимости проведения дополнительных процедур анализа операции
в
случае
 Система должна иметь возможность направить приказ на разрыв web-сессии клиента,
использующего систему ДБО, в случае принятия решения о несанкционированном
использовании системы ДБО
 Система должна вести журнал всех предпринятых мер по несанкционированным
операциям выявленных в рамках обработки оповещения
2.2.2.3
Функционал «Оперативный анализ»
 Подсистема должна предоставлять полную информацию обо всех подозрительных
операция и результатах их оценки для Дежурного по мониторингу операций (по счету /
карте) в целях оперативной обработки оповещений:
24















Уровень риска подозрительной операции
Правила, которые были применены для оценки подозрительности операции
Причина, по которой операция была помечена как «подозрительная»
Меры по реагированию, предпринятые автоматически (если были применены)
Результаты и историю аутентификации (и дополнительной аутентификации)
операции
Канал, через который была совершена подозрительная операция
IP/MAC-адреса и гео-локационные данные совершения подозрительной
операции
Идентификационный номер устройства (device ID), с которого осуществлена
подозрительной операция
Используемые ресурсы (например, браузер) для осуществления подозрительной
операции
Информационный отпечаток устройства (cookies), с которого осуществлена
подозрительной операция
ТСП, в котором осуществлена
Данные об оценке поведения клиента в рамках сессии, если операция была
совершена через системы ДБО
Информацию о сумме операции;
Информацию о получателях и банках получателей платежа;
Информацию о назначении платежей;
 Подсистема должна предоставлять (в случае необходимости) Дежурному по мониторингу
подсказки и рекомендации по действиям, которые необходимо осуществить для принятия
решения о несанкционированном / легитимном характере операции
 Подсистема должна предоставлять возможность по изменению статуса подозрительной
операции(ий) Дежурным по мониторингу на «несанкционированная» или «легитимная»
 Подсистема должна предоставлять Дежурному по мониторингу возможность отклонить /
провести операцию по результатам ее оперативного анализа
 Подсистема должна
операции на предмет:



2.2.2.4
возможность
анализировать
подозрительные
Выявления взаимосвязей между подозрительными операциями по счетам и
платежным картам
Выявления точек компрометации (пересечение карт и счетов, по которым
обнаружены подозрительные операции, в каких-либо устройствах, ТСП, точках
интернет-коммерции, клиентских устройствах)
Выявление карт, которые могли быть скомпрометированы, на основании данных
о точках компрометации
 Подсистема должна
информацию об:



предоставлять
по
требованию
предоставлять
Дежурному
по
мониторингу
Истории проведения операций Клиентом
Истории операций по карте, счету, в устройстве
Истории аутентификации Клиента
Функционал «Учет выявленных точек компрометации»
 Подсистема должна вести реестр выявленных точек компрометации пластиковых карт,
счетов, учетных записей (добавление / удаление ID Банкомата, ИПТ, POS-терминалов,
клиентских устройств, ТСП, e-Commerce ТСП и т.д.), в которых были скомпрометированы
карты, счета, учетные записи
 Система должна предоставлять информацию о точках компрометации по требованию
 Система должна поддерживать ведение данных об предполагаемых
компрометации – времени, даты, описание точки компрометации и т.д.
2.2.2.5
условиях
Подсистема должна вести журнал действий с оповещениями, операциями, объектами
мониторинга (карты, счета, устройства, учетные записи клиентов)
25
2.2.3 Требования к подсистеме «Подсистема расследования мошенничества»
2.2.3.1
Функционал «Управление инцидентами»:
 Подсистема
инциденту
должна
обеспечивать
регистрацию/редактирование
информации
по
 Подсистема должна обеспечивать заведение/изменение/удаление взаимосвязей между
инцидентами
 Подсистема должна обеспечивать регистрацию
мероприятиях по расследованию инцидентов
информации
о
проведенных
 Подсистема должна предоставлять возможности по регистрации изменений в процесс
расследования инцидента (изменение / добавление задач, делегирование задач,
формирования последовательности исполнения задач, регистрацию фактов исполнения
задач)
 Подсистема должна обеспечивать предоставление информации о статусе инцидентов по
требованию
 Подсистема должна уведомлять специалистов по расследованию о новых инцидентах,
задачах и мероприятиях в рамках расследования
 В подсистеме должна реализована возможность создания / редактирования / удаления
шаблонов расследования инцидентов
 В подсистеме должна реализована возможность создания / редактирования / удаления
задач и подзадач по расследованию инцидента
 Подсистема должна предоставлять возможности по назначению ответственных за
исполнение задач расследования из числа сотрудников Банка
2.2.3.2
Функционал «Учет информации по инциденту»:
 Подсистема должна предоставлять возможность прикрепления / добавления документов /
изображений / другой неструктурированной информации к инциденту
 Подсистема должна обеспечивать учет полной информации о несанкционированных
(оспариваемых) операциях, связанных с инцидентом (претензией)
 Подсистема должна обеспечивать учет электронных документов, скан-копий документов,
изображений и другой документальной информации, связанной либо полученной в ходе
расследования инцидента
 Подсистема должна обеспечивать учет заключений, комментариев, полученных в ходе
расследования инцидента
 Подсистема должна предоставлять возможность учета переписки, копий электронных
писем и других результатов коммуникаций, проведенных в ходе расследования в рамках
расследования
 Подсистема должна обеспечивать предоставление полной информации связанной с
инцидентом по требованию
2.2.4 Требования к подсистеме «Анализа мошенничества»
2.2.4.1
Подсистема должна предоставлять возможности для проведения анализа исторических
данных по мошенничеству
2.2.4.2
Подсистема должна предоставлять возможности для проведения глобального анализа
данных как по выявленным фактам мошенничества, так и по всем операциям
2.2.4.3
Подсистема должна позволять производить анализ действий дежурного на предмет скорости
отклика на оповещение, соответствия действий дежурного по отношению к определенным в
инструкциях
2.2.4.4
Подсистема должна позволять тестировать новые правила на исторических данных. Для
тестирования важно определить количество срабатываний правил, точность выявления
фактического мошенничества и частота ложноположительных срабатываний
2.2.4.5
Функционал «Инструменты Data Mining и статистического анализа операций»:
 Подсистема должна обеспечивать загрузку необходимых данных для проведения
анализа операций из Локального Хранилища Данных и других источников
26
 Подсистема должно позволять создавать модели анализа на выборке данных с
использованием методов статистического анализа, классификации, кластеризации,
выявления общих признаков, прогнозирования мошеннических, подозрительных и других
операций на выборке данных
 Подсистема должна предоставлять возможности применения созданных моделей
анализа к выборке данных
 Подсистема должна предоставлять возможность предоставления результатов анализа
выборки данных в различных формах (графиков, таблиц, диаграмм)
2.2.4.6
Функционал «Учет схем проведения мошенничества»:
 Подсистема должна предоставлять возможность ведения информации о мошеннической
схеме (шаблоне)
 Подсистема должна предоставлять возможность учета графической, визуальной,
текстовой информации с описанием схемы или шаблона мошеннической деятельности
 Подсистема должна предоставлять возможности по учету взаимосвязей между людьми,
событиями и другими объектами, задействованных в рамках осуществления
мошеннической деятельности
 Подсистема должна предоставлять возможности по учет информации по методам,
руководствам, инструментам, применяемым для выявления мошеннической схемы
 Предоставление информации о схеме мошенничества по требованию
2.2.5 Требования к подсистеме «Отчетности»
2.2.5.1
Для отчетности в подсистеме должен быть доступен "конструктор" отчетов, а также
функционал построения отчетов по запросам пользователей
2.2.5.2
Подсистема должна позволять проводить анализ и строить отчеты по эффективности
применения правил (частота срабатывания, % ложноположительных срабатываний и т.д.)
2.2.5.3
Подсистема должна проводить расчет и предоставлять аналитическую информацию по
ключевым показателям эффективности деятельности по противодействию мошенничеству
2.2.5.4
Подсистема должна проводить расчет и предоставлять статистику по количеству
мошеннических операций в разрезах различных каналов и типов операций
2.2.5.5
Подсистема должна проводить расчет и предоставлять статистику по противодействию
мошенничеству по различным отчетным периодам
2.2.5.6
Подсистема должна позволять выгружать отчеты в другие системы, а также в файлы
2.2.5.7
Подсистема должна предоставлять инструменты визуализации данных в различных
форматах (графики, таблица, диаграммы)
2.2.6 Требования к подсистеме «Реестр мошенничества»
2.2.6.1
Подсистема должна вести информацию обо всех операциях, признанных мошенническими и
предоставлять доступ к ним по требованию
2.2.6.2
Подсистема должна иметь возможность вести информацию о фактах мошенничества,
произошедшего в сторонних организациях / банках и предоставлять доступ к ним по
требованию
2.2.6.3
Подсистема должна вести реестр счетов, карт, устройств, клиентов и других объектах,
которые были задействованы при осуществлении мошеннических операций
2.2.7 Требования к подсистеме «Оперативное хранилище данных»
2.2.7.1
Подсистема должна предоставлять возможности временного хранения актуальной
информации по текущим счетам и картам клиентов Банка из процессинговых систем и АБС
за определенный период времени, достаточного для задач оперативного анализа
оповещений о подозрительных операциях
2.2.7.2
Подсистема должна предоставлять возможности загрузки и хранения
информации по устройствам, обслуживаемым Банком, и их статусам
актуальной
27
2.2.7.3
Подсистема должна предоставлять возможности загрузки и хранения актуальной
информации о текущих установленных лимитах по операциям в процессинговых системах
2.2.7.4
Подсистема должна обеспечивать загрузку и хранение информации о статусах блокировки
учетных записей пользователей в каналах ДБО
2.2.7.5
Подсистема должна позволять периодическую выгрузку информации в подсистему
«Локальное хранилище данных (витрина данных)»
2.2.7.6
Подсистема должна предоставлять информацию по счетам и картам клиентов по
требованию подсистем Системы
2.2.7.7
Подсистема должна предоставлять информацию по устройствам и их статусам по
требованию подсистем Системы
2.2.8 Требования
данных)»
к
подсистеме
«Локальное
хранилище
данных
(витрина
2.2.8.1
Подсистема должна осуществлять временное хранение исторической информации об
операциях (по авторизации, по платежным операциям) по счетам и пластиковым картам,
необходимой для целей анализа и выявления шаблонов мошенничества, оценки
эффективности и отчетности по противодействию мошенничеству
2.2.8.2
Подсистема должна обеспечивать сбор, хранение и предоставление исторической
информации, накопленной СПМ в рамках процессов противодействия мошенничеству.
2.2.8.3
Подсистема должна осуществлять загрузку и хранение исторической информации о
клиентских устройствах
2.2.8.4
Подсистема должна осуществлять загрузку и хранение исторической информации об
устройствах Банка и АТМ
2.2.8.5
Подсистема должна осуществлять загрузку и хранение исторической информации о
транзакционных профилях клиентов
2.2.8.6
Подсистема должна осуществлять загрузку и хранение исторической информации о ТСП
2.2.8.7
Подсистема должна осуществлять загрузку и хранение исторической информации об
оповещениях и инцидентах
2.2.8.8
Подсистема должна осуществлять загрузку и хранение исторической информации о
принятых мерах реагирования на подозрительные операции
2.2.9 Требования к подсистеме
Мошенничеству»
2.2.9.1
«Управление
Системой
Противодействия
Подсистема должна реализовывать задачи управления доступом пользователей к Системе:
 Управление ролями пользователей системы
 Управление иерархией ролей пользователей системы
 Управление правами доступа пользователей в системе
 Управление группами пользователей
 Управление учетными записями пользователей
 Назначение / снятие ролей и прав доступа для учетных записей пользователей или групп
пользователей
2.2.9.2
Подсистема должна реализовывать задачи администрирования Системы:
 Ведение и управление параметрами конфигурации приложений системы
 Ведение параметров работы функциональных сервисов системы (сервис «Оценки риска
операций», «Управления операциями», «Управления оповещения» и т.д.), например,
время повторного уведомления дежурных операторов о созданном оповещении
 Включение / отключение функций системы
 Управление
параметрами
обработки
обрабатываемых операций и т.д.)
операций
(количество
одновременно
28
2.2.9.3
Подсистема должна реализовывать задачи диагностики Системы:
 Обслуживание баз данных и компонент Системы
 Мониторинг состояния взаимодействия различных компонент Системы
 Ведение и учет инцидентов в работе системы
 Поиск и устранение неполадок в работе системы
 Ведение журналов работы системы
 Протоколирование событий по изменению правил, настроек, прав доступа, регистрации
пользователей, и других событий в Системе Противодействия Мошенничеству

2.3 Нефункциональные требования к Системе
2.3.1 Требования к диагностированию
2.3.1.1
Средства диагностирование программных и аппаратных средств Системы Управления
Мошенничеством должны предоставлять возможность своевременного предупреждения и
возникновения аварийных ситуаций в работе компонент Системы.
2.3.1.2
Средства Диагностирование Системы Управления Мошенничеством должны обеспечивать
выявление её неработоспособности во всех режимах функционирования.
2.3.1.3
Средства диагностировании Системы Управления Мошенничеством должны обеспечивать
возможность выполнения следующих работ:
 диагностирование работоспособности и правильного функционирования используемого
программного обеспечения
 диагностирование работоспособности и правильного функционирования комплекса
технических средств
 выявление неисправностей в работе Системы по результатам анализа журналов
сообщений
 выполнение контрольных проверок с целью определения
компонентов Системы Управления Мошенничеством.
работоспособности
2.3.2 Требования к возможностям развития и модернизации
2.3.2.1
Решения используемые для реализации Системы должны обеспечивать возможность ее
развития, масштабирования без потери качества функционирования уже реализованных
функций
2.3.2.2
Реализация Системы должна обеспечивать возможность дальнейшей модернизации,
обновления программного обеспечения, комплекса технических средств без нарушения ее
работоспособности и утраты реализованной функциональности.
2.3.2.3
База данных системы должна иметь возможность масштабирования без потери качества
данных и производительности работы системы.
2.3.2.4
Предлагается указать на необходимость наличия унифицированного инструмента для
подключения новых каналов/систем/БД
2.3.3 Требования к надежности
2.3.3.1
Доступность системы должна быть определена в рамках проекта по внедрению. Желаемый
уровень доступности должен составлять 99,9% 24х7
2.3.3.2
Эксплуатационный персонал системы должен осуществлять:
 техническое обслуживание и ремонт технических средств Системы
 эксплуатацию и сопровождение программного обеспечения
 контроль и обеспечение правильности
программных средств Системы
функционирования
всех
технических
и
 перенастройку Системы в соответствии с изменениями, вносимыми в технологический
процесс
29
2.3.3.3
Периодичность и режимы технического обслуживания программно-технических комплексов
должны быть определены на основе документации производителей на эти комплексы после
их выбора при рабочем проектировании.
2.3.3.4
Среднее время восстановления, средняя наработка на отказ аппаратно-программных
средств ИТ-инфраструктуры Системы могут уточняться в ходе технического проектирования.
2.3.3.5
Система должна сохранять работоспособность и обеспечивать восстановление своих
функций в условиях воздействия следующих факторов:
 неисправности оборудования;
 человеческий фактор;
 отказы и ошибки ПО;
 вредоносное ПО.
2.3.3.6
При внесении изменений в конфигурацию подсистем Системы, обновлению программного
обеспечения необходимо сохранять резервные копии работоспособного состояния системы
на случай внесения неудачных изменений в версии ПО и конфигурации подсистем
2.3.3.7
В Системе должны быть предусмотрены средства резервного копирования данных.
Детальные требования по резервному копированию должны быть определены в рамках
проектов по реализации Системы
2.3.3.8
В Системе должны быть предусмотрены средства архивирования, кодирования и
восстановления информации
2.3.3.9
В Системе должны быть предусмотрены средства балансировки нагрузки на ключевые
компоненты решения в целях обеспечения требуемого уровня отказоустойчивости.
Требуемый уровень отказоустойчивости должен быть определен в рамках технической
проработки решения.
2.3.3.10
В Системе должны быть разработаны и внедрены механизмы восстановления Системы
после сбоев с учетом требований работы компонент Системы в онлайн режиме. Период
восстановления Системы после сбоев должен быть определен в рамках проекта по
внедрению. Желаемый период восстановления работоспособности не должен превышать 10
минут.
2.3.4 Требования к эргономике и технической эстетике
2.3.4.1
Все компоненты Системы должны
пользовательским интерфейсом.
2.3.4.2
Взаимодействие пользователя с программным обеспечением
осуществляться с помощью графического интерфейса пользователя.
2.3.4.3
Пользовательский
русифицирован.
2.3.4.4
Пользовательский интерфейс программного обеспечения Системы должен быть Windowsориентирован.
2.3.4.5
Навигационные элементы программного обеспечения Системы должны быть выполнены в
удобной для пользователя форме.
2.3.4.6
Средства редактирования информации должны удовлетворять принятым соглашениям в
части использования функциональных клавиш, режимов работы, поиска, использования
оконной системы.
2.3.4.7
Средства отображения графиков, отчетов и другой информации должны предоставляться в
удобной для пользователя форме и должны быть согласованы на этапах технического
проектирования Системы и ее подсистем.
2.3.4.8
В Системе должны быть заложены механизмы и инструменты модификации и доработки
интерфейса под нужды пользователей.
2.3.4.9
Графические элементы, экранные формы пользовательского интерфейса должны быть
выполнены в едином графическом дизайне. Дизайн согласовывается на этапах технического
проектирования Системы и ее подсистем.
интерфейс
обладать
программного
удобным
обеспечения
и
интуитивно
понятным
Системы
Системы
должен
должно
быть
30
2.3.4.10
Задание критериев поиска и выбора информации в Системе должно производиться без
использования языков программирования.
2.3.4.11
Должен преследоваться принцип Единое Рабочее место дежурного специалиста службы
мониторинга (текущий мониторинг и принятие решений (блокировки/лимиты) в одном окне)
2.3.5 Требования к безопасности
2.3.5.1
В рамках реализации Системы должен быть реализован взаимосвязанный комплекс
организационных и технических мероприятий, направленных на реализацию и поддержание
принятых в Банке требований к защите информации с учетом особенностей
функционирования Системы
2.3.5.2
Внедряемые компоненты Системы не должны понижать общий уровень информационной
безопасности каких-либо других Систем Банка и внешних систем
2.3.5.3
Система должна обеспечивать возможность идентификации и аутентификации
пользователей через интеграцию с корпоративным каталогом Active Directory
2.3.5.4
В случае изменения идентификатора субъектов доступа к системе должно быть обеспечено
сопоставление субъекта доступа и истории изменений его идентификаторов
2.3.5.5
Собственные средства регистрации событий программного обеспечения Системы должны
фиксировать
 Успешные и неуспешные попытки входа в систему
 Дата и время входа
 Терминал, с которого осуществлён вход
 Учетная запись пользователя
 Совершенное действие пользователями в системе
2.3.5.6
Контроль доступа субъектов к защищаемым ресурсам и информации в Системе должен
осуществляться в соответствии с матрицей доступа
2.3.6 Требования к инструментальным средствам
2.3.6.1
Для реализации Системы должны использоваться инструментальные
соответствующие Технической политике Банка (на платформе Oracle)
средства,
2.4 Требования к обеспечению Системы
2.4.1 Требования к информационному обеспечению
2.4.1.1
Система должна обеспечивать хранение следующих видов информации:
 Данные и метаданные об объектах мониторинга
 Электронные документы:



Сканированные документы
Текстовые документы, созданные в Microsoft Office
Аудио/видео информацию
 Нормативно-справочная информация




Справочники
Классификаторы
Словари
Инструкции
2.4.1.2
Структура информационного хранения должна быть разработана на этапе проектирования
решения
2.4.1.3
Информация о клиентском устройстве должна поступать из внешних систем при каждой
совершаемой операции через канал ДБО
2.4.1.4
Текущий состав используемых клиентом устройств и история изменения данного состава
для совершения операций через ДБО должна храниться в Системе Противодействия
Мошенничества
31
2.4.1.5
В системе должна быть обеспечена доступность актуального реестр устройств, находящихся
на экваринговом обслуживании Банка, изменения в данном реестре
2.4.1.6
При каждой операции, совершенной в эквайринговой сети Банка или внешнего банка
(эмиссии), должна поступать информация о устройстве совершения операции
2.4.1.7
В системе должен быть доступен (или вестись) реестр устройств внешних банков,
используемых Клиентами Банка для совершения операций
2.4.1.8
Системе Противодействия Мошенничеству должен быть доступен актуальный реестр
Клиентов Банка с указанием их контактных данных, актуальный перечень используемых карт
и счетов.
2.4.1.9
Доступ к клиентским данным должен осуществлять в соответствии с установленными
политиками обеспечения конфиденциальности информации
2.4.1.10
Системе Противодействия Мошенничеству должен быть доступен актуальный перечень
пластиковых и виртуальных карт, эмитированных Банком
2.4.1.11
Системой Противодействия Мошенничеству должен вестись (либо быть доступен) реестр
карт, эмитированных сторонним банком, использованных для проведения операций в
эквайринг-сети Банка
2.4.1.12
Обновление профиля клиента, ТСП, счета, карты, устройства должно осуществлять рамках
процессов обработки операций
2.4.1.13
Информация о профиле объекта должна быть доступна в режиме реального времени для
задач обработки операций
2.4.1.14
Системе Противодействия Мошенничеству должен быть доступен актуальный перечень
обслуживаемых ТСП в рамках договоров эквайринга
2.4.1.15
Системой Противодействия Мошенничеству должен вестись (либо быть доступен) реестр
ТСП, обслуживаемых по договору эквайринга сторонним банком, в которых осуществляют
операции Клиенты Банка
2.4.1.16
В случае решения задач по обработке операции, информация об операции должна
поступать в реальном времени из внешних систем
2.4.1.17
Для задач обработки операций в Операционном Хранилище Данных СПМ необходимо
обеспечить временное хранение информации по всем совершенным операциям через все
каналы за определенный промежуток времени в объеме, необходимом для задач онлайн и
квази-онлайн противодействия мошенничеству
2.4.1.18
Для поддержки задач оценки риска операций и реализации мер противодействия
мошенничеству необходимо обеспечить доступность в режиме реального времени
информации о текущих остатках на счетах, текущих установленных лимитах на операции по
различным каналам, устройствам, счетам, картам, статусах блокировки
2.4.1.19
Системе Противодействия Мошенничеству должна быть доступна организационная
структура и нормативно-справочная информация
2.4.2 Требования к техническому обеспечению системы
2.4.2.1
Комплекс технических средств Системы должен включать в себя следующие компоненты:
 Основной серверный комплекс / ферму серверов,
обеспечение бесперебойной работы подсистем Системы
задачей
которого
является
 Тестовый серверный комплекс / ферму серверов, для задач нагрузочного тестирования
работы Системы
 Тестовый серверный комплекс
тестирования работы Системы
/
ферму серверов,
для
задач
функционального
 Систему хранения данных
 Систему резервного копирования / архивирования данных
 Рабочие станции пользователей
32
2.4.3 Требования к организационному обеспечению системы
2.4.3.1
Организационное обеспечение Системы должно включать следующие роли:
 Специалист по обработке оповещений
 Специалист по анализу мошеннических схем
 Специалист по управлению правилами
 Специалист по подготовке отчетов
 Специалист по проведению расследований
 Руководитель подразделения
 Потребитель отчетов
 Администратор
 Специалист по поддержке Системы
2.4.3.2
Организационное обеспечение Системы должно определять:
 состав пользователей, являющихся потребителями информации
 обязанности должностных лиц по использованию Системы
 организацию и обеспечение обучения пользователей и обслуживающего персонала
2.4.3.3
В ходе проведения работ по внедрению Системы должны быть разработаны должностные
инструкции, регламентирующие:
 функциональные обязанности пользователей и обслуживающего персонала
 порядок работы с Системой
2.4.3.4
Документация на систему должна быть разработана в соответствии с установленными
внутренними стандартами
2.4.3.5
К работе с системой должны допускаться сотрудники, имеющие навыки работы на
персональном компьютере, ознакомленные с руководствами пользователя и прошедшие
обучение работе с системой
2.4.3.6
В рамках разработки частных технических заданий на реализацию компонент (подсистем)
Системы должно быть определено число бизнес-пользователей Системы с определенными
ролями
2.4.3.7
Каждая подсистема должна быть обеспечена возможностью организации УРМ (удаленного
рабочего места), в приоритете подсистемы дежурного специалиста службы мониторинга.
_______________________
М.п.
_______________________
М.п.
33
Приложение № 2 к Договору от __________ № ________
Форма заказа на выполнение Работ
№ п/п
Наименование
Работ
Роль
Специалиста
Исполнителя
Ставка
Трудозатраты
Специалиста
(человекоИсполнителя
дни)
(руб. с учетом
НДС)
Итого (руб.
с
учетом
НДС)
Итого
Адрес выполнения Работ: _______________________
Период выполнения Работ: с _________________ по _______________
_______________________
М.п.
_______________________
М.п.
34
Приложение № 3 к Договору от __________ № ________
35
1. Требования по производительности
Система должна обеспечивать обслуживание указанного количества клиентов (
1.1. Конкурентная работа), выполнения операций в требуемом объеме (1.2. Производительность
операций), при соблюдении требований по времени обработки операций (1.3. Требования к
времени обработки) на КТС, описываемом в проектной документации, с учетом работы
смежных систем (1.4. Взаимодействие со смежными ИС).
1.1. Конкурентная работа
Система должна обеспечивать работу до 150 локальных клиентов в течение дня с
возможностью наращивания до 3000 УРМ. Система должна обеспечивать одновременную
работу до 75 локальных клиентов и до 450 УРМ (50% и 15% от количества активных клиентов
в течение дня соответственно)
1.2. Производительность операций
1.2.1. Производительность пользовательских операций
Система должна обеспечивать выполнения операций в количестве, указанном в таблице №1
Таблица № 1. Операции пользователей
№
Наименование операции
Количество Количество
операций в операций в
день
ЧПН (час
пиковой
нагрузки)
1.
Транзакция в ДБО ФЛ, в т.ч.:
1.1.
- web-сайт
1.2.
- PDA сайт
1.3.
- Мобильный банк
133 333
6 841
115 000
6 210
5 000
139
13 333
492
2.
Транзакция в ДБО ЮЛ («тонкий» клиент)
266 667
500 000
3.
Транзакция в ДБО ЮЛ («толстый» клиент)
17 767
70 000
4.
Карточная транзакция (эмиссионный поток)
2 666 667
5.
Карточная транзакция (эквайринговый поток)
2 166 667
1 440 000
*
6.
Количество обрабатываемых инцидентов
*
* - Требования по количеству обрабатываемых в системе инцидентов (в час и в день) должны
быть определены и согласованы с Банком на этапе разработки ТЗ.
1.2.2. Выполнение вспомогательных операций и обслуживающих процедур
Система должна обеспечивать выполнения вспомогательных операций и процедур в количестве
и со скоростью обработки, указанной в таблице №2
Таблица № 2. Вспомогательные и технологические операции, обслуживающие процедуры.
№
Наименование операции
Регламентное
время выполнения
1.
Разовый импорт суточных данных
не более 6 часов
2.
Разовая обработка импортированных суточных
данных
не более 6 часов
36
1.3. Требования к времени обработки
В данном разделе определяются требования на время, затрачиваемое на выполнение одной
отдельной операции, независящее от параллельной работы других пользователей или операций
системы.
1.3.1. Время отклика для интерфейсных операций
Система должна обеспечивать время отклика при выполнении 90% операций каждого вида в
пределе 2 секунд.
1.3.2. Время обработки операций
Время обработки операций, перечисленные в таблице №3, должно быть не более указанного в
таблице для <90%> исполняемых операций.
Таблица № 3. Время обработки операций, не требующих ожидания времени отклика системы.
Наименование операции
Максимальное время
обработки
№
1.
Транзакция в ДБО ФЛ, в т.ч.:
1 сек.
1.4.
- web-сайт
1 сек.
1.5.
- PDA сайт
1 сек.
1.6.
- Мобильный банк
1 сек.
2.
Транзакция в ДБО ЮЛ («тонкий» клиент)
1 сек.
3.
Транзакция в ДБО ЮЛ («толстый» клиент)
1 сек.
4.
Карточная транзакция (эмиссионный поток)
1 сек.
5.
Карточная транзакция (эквайринговый поток)
1 сек.
1.4. Взаимодействие со смежными ИС
Раздел описывает характеристики работы смежных ИС, которые влияют на обеспечение
требований производительности описываемой ИС.
1.4.1. Производительность внешних систем и интерфейсов
В соответствии с таблицей №1.
1.4.2. Время работы внешних интерфейсов и систем
Операции и предельно-допустимое время обработки для 90% операций каждого вида
приведены в таблице №3.
1.5. Объемные характеристики
Система должна обеспечивать выполнение требований в разделах 1.1-1.4 при условии хранения
объемов данных, указанных в таблице №4
Таблица № 4. Объемные характеристики БД
37
№
Наименование сущности
Количество клиентов – физических лиц,
использующих ДБО систему
Количество
~2,5 млн
из них «активными» пользователями
(осуществляли как минимум одну операцию за
последние 3 месяца)
~600 тыс.
2.
Количество физических лиц, использующих
мобильное приложение для осуществления
операций через ДБО
~300 тыс.
3.
Количество юридических лиц, использующих
системы ДБО
~160 тыс.
4.
Количество дебетовых карт, выпущенных Банком,
из них «активными» картами (по которым прошла
хотя бы одна транзакция за последние 3 месяца) я
~6,5 млн.
Количество кредитных карт, выпущенных Банком,
из них «активными» картами (по которым прошла
хотя бы одна транзакция за последние 3 месяца)
~6 млн.
6.
Банкоматы и устройства, находящиеся на
эквайринговом обслуживании у Банка
10 000 банкоматов
27 000 POS терминалов
7.
Оперативная БД аудита
Хранится информация о
действиях пользователей
за 6 месяцев
8.
Оперативное хранилище
Хранится информация о
действиях клиентов за 3
месяца
1.
5.
_______________________
М.п.
~4 млн.
~3,5 млн.
_______________________
М.п.
38
Приложение № 4 к Договору от __________ № ________
Квалификационные требования к Специалистам Исполнителя
1. Инженер:
Знание операционных систем Red Hat Enterprise Linux и IBM AIX, СУБД Oracle,
серверов web-application на базе Oracle WebLogic, IBM WebSphere. Опыт работы с
указанными системами более 2-х лет.
2. Разработчик:
Опыт разработки на интеграционных платформах J2EE более 2-х лет.
3. Аналитик:
Опыт внедрения решения RSA Transaction Monitoring & Adaptive Authentication более
2-х лет.
_______________________
М.п.
_______________________
М.п.
Приложение № 5 к Договору от __________ № ________
Банк ВТБ 24
(закрытое акционерное общество)
Стандарты и требования по ведению разработок на языке Java
Версия 1
МОСКВА, 2013
40
Содержание
1.
Термины и сокращения ..................................................................................................................... 42
2.
Общие положения ............................................................................................................................. 43
3.
Регламент приемо-сдаточных испытаний ....................................................................................... 44
4.
Объект проверки ................................................................................................................................ 45
5.
Базовые правила и концепции разработки в Java ........................................................................... 47
6.
Классификация критичности обнаруженных дефектов................................................................. 54
7.
Критерии успешности прохождение ПСИ ...................................................................................... 56
Приложение 1. Программа проверки обязательных функций .............................................................. 57
Приложение 2. Матрица покрытия требований тестами....................................................................... 58
Приложение 3. Протокол прохождения приемо-сдаточных испытаний ............................................. 59
41
1. ТЕРМИНЫ И СОКРАЩЕНИЯ
1.1. Сокращения
БФТЗ – бизнес-функциональное техническое задание.
ДБИТ – Департамент банковских и информационных технологий.
ПО – программное обеспечение.
ПСИ – приемо-сдаточные испытания.
УРИВ – Управление разработки и внедрения Департамента банковских и
информационных технологий.
42
2. ОБЩИЕ ПОЛОЖЕНИЯ
2.1. Данный порядок описывает стандарты и требования по ведению разработок на языке
Java.
2.2. Процесс приемки включает несколько этапов:
2.2.1. Подготовка к приемке:



разработка методики приемки;
оценка качества сопровождающего технического описания;
оценка качества сопровождающей документации.
2.2.2. Проверка комплектности:


наличие всех заявленных компонентов;
наличие всех необходимых по стандартам Банка сопровождающих документов.
2.2.3. Проведение приемочных испытаний:


проведение испытаний в соответствии с методикой приемки;
документирование выявленных дефектов в системе управления дефектами.
2.2.4. Доработка на стороне Поставщика (в случае необходимости):


руководитель проекта разработки на стороне Поставщика обеспечивает выпуск
исправленного ПО и документации;
передача релиза и документации для повторной приемки.
2.3. Комплект документации, который предоставляется на приемку поставщиком:







Финальная согласованная версия БФТЗ.
Руководство администратора – полное руководство по эксплуатации системы. В
Руководстве должен быть выделен раздел, в который отдельно от общего текста
включены все новые изменения по конфигурированию и настройке системы в
рамках данной доработки. В случае отсутствия изменений данный раздел в
Руководстве отсутствует.
Руководство пользователя – полное руководство для конечных пользователей. В
Руководстве должен быть выделен раздел, в который отдельно от общего текста
включены все новые изменения пользовательских интерфейсов или алгоритмов
работы пользователей, внесенные в ПО в рамках данной (доработки. В случае
отсутствия изменений данный раздел в Руководстве отсутствует.
Руководство по установке – подробная пошаговая инструкция по установке
системы в продуктивную среду и ее настройке.
Bug List – список ошибок выявленных на внутреннем тестировании УРИВ,
которые не были устранены до момента передачи инсталляционного пакета, с
описанием их воздействия на бизнес, а также workarounds для возможных
инцидентов. Предоставляется при наличии известных ошибок, исправление
которых на данном этапе было признано нецелесообразным.
Release Notes – документ, включающий все известные поставщику ограничения.
Все критичные ограничения Release Notes должны быть исправлены до установки
релиза в продуктивную среду
Исходный код
43
3. РЕГЛАМЕНТ ПРИЕМО-СДАТОЧНЫХ ИСПЫТАНИЙ
№
Этап ПСИ
1 Реализация методики ПСИ (с
указанием необходимых тестов
для проверки в продуктивной
среде)
Ответственный
Поставщик
Срок / Длительность
Согласно план-графику
2
Предоставление и
согласование полного пакета
документации по платформе
Поставщик
Согласно план-графику
3
Согласование методики ПСИ
Банк
Согласно план-графику
4
Анализ кода, полученного от
поставщика
Банк
Согласно план-графику
5
Проведение регрессионного
тестирования
Банк / Поставщик
Согласно план-графику
6
Анализ / трактовка результатов
тестирования и результатов
анализа кода.
Образец матрицы покрытия
требований тестами, а также
протокола прохождения ПСИ
приведен в Приложениях.
Банк / Поставщик
Не позднее одного дня после
окончания ПСИ.
По мере выявления
вопросов/ошибок к ПО,
ответственное лицо со
стороны Банка принимает
окончательное решение и
выставляет приоритет для
каждой ошибки
7
Подписание протокола
тестирования со списком
проблем
Банк / Поставщик
Не позднее двух дней после
окончания ПСИ
8
Согласование реализации по
обнаруженным замечаниям
Банк / Поставщик
Не позднее пяти дней после
окончания ПСИ
9
Согласование сроков
исправления по замечаниям
Банк / Поставщик
В течение двух рабочих дней
от даты предоставления
описания реализации
10
Исправление замечаний
согласно согласованным
срокам
Банк / Поставщик
Согласно согласованным
срокам
11
Анализ кода, тестирование
исправлений и окружения
Банк / Поставщик
Не позднее пяти дней после
окончания ПСИ
12
Заключение об успешности
ПСИ и принятие решения о
внедрении в продуктивную
среду
Банк
Не позднее пяти рабочих
дней после исправления
замечаний
44
4. ОБЪЕКТ ПРОВЕРКИ
4.1. Описание стартовых условий для начала проверки.
4.1.1. Проверка программного продукта проводится на работающем комплексе
оборудования в тестовой среде Банка. Перед началом тестирования программный
код проходит Code Review на стороне Банка для оценки качества исходного кода по
следующим параметрам:







читаемость кода (в том числе, наличие в коде комментариев);
лёгкость в поддержке, тестировании, отладке и устранении ошибок,
модификации и портировании;
экономное использование ресурсов – памяти, процессора, дискового
пространства;
отсутствие замечаний, выводимых компилятором;
отсутствие «мусора» – неиспользуемых переменных, блоков кода, ненужных
устаревших комментариев и пр.;
корректность обработки ошибок, исключительных ситуаций и формирование
информативных сообщений;
возможность локализации интерфейса;
4.1.2. Оценка соответствия заявленным требованиям осуществляется в соответствии с
методикой ПСИ, изложенной в данном документе.
4.1.3. Успешность прохождения тестов определяется совпадением ожидаемого и
действительного результатов, а также отсутствием замечаний по коду.
4.2. Факторы качества
4.2.1. Фактор качества ПО – это нефункциональное требование к программе, которое
обычно не описывается в договоре с заказчиком, но, тем не менее, является
желательным требованием, повышающим качество программы.
4.2.2. Некоторые из факторов качества:






Понятность – условный параметр, определяющий, что функциональность ПО
должно быть ясна из самой программы и документации.
Полнота – условный параметр, фиксирующий, что все необходимые части
программы должны быть представлены и полностью реализованы.
Краткость
–
отсутствие
лишней,
дублирующейся
информации.
Повторяющиеся части кода должны быть преобразованы в вызов общей
процедуры. То же касается и документации.
Портируемость – лёгкость в адаптации программы к другому окружению:
другой архитектуре, платформе, операционной системе или её версии.
Согласованность – использование во всей программе и в документации одних
и тех же соглашений, форматов и обозначений.
Сопровождаемость – параметр, определяющий, насколько сложно изменить
программу для удовлетворения новых требований. Это требование
предусматривает хорошее документирование программы, понятный, хорошо
структурированный код, разработанный и оформленный в соответствии с
единым стандартом.
45





Тестируемость – параметр, определяющий, позволяет ли программа выполнить
проверку приёмочных характеристик, поддерживается ли возможность
измерения производительности.
Эффективность пользовательского интерфейса (usability) – условный
параметр, определяемый ответами на наиболее важные из вопросов, которые
влияют на оценку:
o Является ли пользовательский интерфейс интуитивно понятным?
o Насколько просто выполнять простые, частые операции?
o Насколько легко выполняются сложные операции?
o Выдаёт ли программа понятные сообщения об ошибках?
o Всегда ли функционирование программы соответствует ожидаемому?
o Имеется ли в наличии документация, и насколько она полна?
o Всегда ли задержки с ответом программы являются приемлемыми?
Простота и удобство использования программы. Это требование относится,
прежде всего, к интерфейсу пользователя.
Надёжность – отсутствие отказов и сбоев в работе программ, а также простота
исправления выявленных дефектов и ошибок:
Эффективность – параметр, определяющий, насколько рационально
программа использует ресурсы (память, процессор) при выполнении задач.
46
5. БАЗОВЫЕ ПРАВИЛА И КОНЦЕПЦИИ РАЗРАБОТКИ В JAVA
5.1. Стандарт оформления программного кода
5.1.1. Начальные комментарии. Все файлы исходного Java-кода должны начинаться с
комментариев в стиле языка Java, где перечислены: автор, версия, компания,
описание, дата создания, например,
/**
*
* @author
*
* @version
*
* @company
*
* @description
*
* @creationDate
*
*/
5.1.2. Отступы. В качестве единицы отступа используются 4 пробела. Использование в
качестве отступов пробелов или табуляции жестко не определено. Табуляция
должна быть установлена как 8 пробелов.
5.1.3. Длина строк. Длина строк должна быть не более 80 символов.
5.1.4. Перенос строк. Если выражение не помещается на одной строке, его необходимо
разбить, руководствуясь следующими основными принципами:



перенос после запятой;
перенос перед оператором;
предпочтительны переносы на более высоком уровне, чем переносы на низком
(вложенном) уровне;
 выравнивание новой строки выражения должно быть выполнено таким образом,
чтобы ее начало совпадало с началом предыдущей строки.
Если приведенные выше правила снижают понимание кода, или код значительно
смещается вправо, следует использовать отступ в 8 пробелов.
Несколько примеров переноса строки в вызовах методов:
function(longExpression1, longExpression2, longExpression3,
longExpression4, longExpression5);
var = function1(longExpression1,
function2(longExpression2,
longExpression3));
Следующие два примера демонстрируют разбиение арифметического выражения.
Первый пример, с разрывом за пределами скобок, расположенных на верхнем
уровне, является предпочтительным:
longName1 = longName2 * (longName3 + longName4 – longName5)
+ 4 * longname6; // РЕКОМЕНДОВАНО
longName1 = longName2 * (longName3 + longName4
– longName5) + 4 * longname6; // НЕ РЕКОМЕНДОВАНО
Два следующих примера иллюстрируют отступы в объявлениях методов. Первый
пример демонстрирует обычный вариант. Во втором примере следует сдвинуть
47
вторую и третью строки значительно вправо, если бы применялись обычные
отступы. Вместо этого строки смещены вправо на 8 позиций табуляции.
//ОБЫЧНЫЕ ОТСТУПЫ
someMethod(int anArg, Object anotherArg, String yetAnotherArg,
Objеct andStillAnother) {
...
}
//ОТСТУП НА 8 СИМВОЛОВ, ВО ИЗБЕЖАНИЕ ДЛИННЫХ ОТСТУПОВ
private static synchronized horkingLongMethodName(int anArg,
Object anotherArg, String yetAnotherArg,
Object andStillAnother) {
...
}
В условии оператора if следует использовать в основном 8-ми символьный отступ,
т.к. использование 4-х символьного отступа затруднит поиск тела оператора.
Рассмотрим примеры отступов:
//НЕ РЕКОМЕНДОВАНО
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) { //Плохой перенос
doSomethingAboutIt(); //ОЧЕНЬ ЛЕГКО ПРОПУСТИТЬ ЭТУ СТРОКУ
}
// РЕКОМЕНДОВАНО В ПОДОБНЫХ СЛУЧАЯХ
if ((condition1 && condition2)
|| (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
// РЕКОМЕНДОВАНО
if ((condition1 && condition2) || (condition3 && condition4)
||!(condition5 && condition6)) {
doSomethingAboutIt();
}
Вот 3 допустимых способа форматирования тернарных выражений:
alpha = (aLongBooleanExpression) ? beta : gamma;
alpha = (aLongBooleanExpression) ? beta
: gamma;
alpha = (aLongBooleanExpression)
? beta
: gamma;
5.1.5. Комментарии. Программа на Java может содержать два вида комментариев –
комментарий реализации и документирующий комментарий. Комментарии
реализации те же, что и в C++, и обозначаются /* ... */ и //. Документирующие
комментарии, известные как «doc comments» или «Javadoc», присутствуют только в
Java и обозначаются /** ... */. Javadoc может быть извлечен из кода в HTML-файл
при использовании инструмента javadoc.
5.1.6. Комментарии используются для описания отдельных строк / блоков кода или
целого алгоритма. Комментарии для документирования используются с целью
описания спецификации кода (его интерфейса), не зависящей от его реализации.
Комментарии для документирования включают для разработчиков, которые будут
использовать программы (библиотеки классов), не имея исходного кода.
5.1.7. Комментарии необходимы для описания кода или пояснения функциональности,
которые сложно понять непосредственно из кода. Комментарии должны содержать
48
только ту информацию, которая необходима для чтения и понимания кода
программы. Например, информацию о том, как откомпилировать связанный пакет
или в какой директории он находится, не следует включать в комментарий.
5.1.8. Обсуждение нетривиальных или неочевидных решений необходимо, но описание
блоков, смысл которых понятен из кода, не требуется. Такие «избыточные»
комментарии очень быстро могут стать неактуальными. В общем случае, следует
избегать любых комментариев, которые могут стать неактуальными по мере
развития кода.
Примечание: большое количество комментариев иногда отражает низкое качество
кода. Когда вы чувствуете, что необходимо добавить комментарий, подумайте:
может лучше переписать код, чтобы он стал более понятным.
Не стоит делать большие комментарии, отделенные от основного кода строками из
«*» или других символов, например:
/************************************
* Сказание о Мамаевом побоище *
************************************/
Комментарии не должны содержать специальных символов, таких как, символ
конца страницы или backspace.
5.1.9. Объявления. Рекомендуется использовать одно объявление в строке, так как это
облегчает комментирование:
int level; // уровень отступа
int size; // размер таблицы
предпочтительней, чем
int level, size;
В любом случае переменная и функция не должны быть объявлены в одной строке.
Например:
long dbaddr, getDbaddr(); // НЕВЕРНО!
Не следует располагать различные типы данных в одной строке.
Например:
int foo, fooarray[]; // НЕВЕРНО!
Примечание: В вышеприведенных примерах используется один пробел между
типом и идентификатором. Пример альтернативного использования отступов
является следующий:
int level; // уровень отступа
int size; // размер таблицы
Object currentEntry; // текущий выделенный экземпляр таблицы
Располагать объявления нужно только в начале блока. Блок – это часть кода,
окруженного фигурными скобками «{» и» «}». Не следует допускать первое
использование переменной до её объявления. Это может дезориентировать
программиста и препятствовать переносимости кода.
void MyMethod() {
int int1; // начало блока метода
if (condition) {
int int2; // начало условного блока
...
49
}
}
Исключением из правила является случай индексирующей переменной в цикле,
которая в Java может быть объявлена внутри оператора for:
for (int i = 0; i < maxLoops; i++) { ...
Следует избегать локальных объявлений переменных, перекрывающих объявления
более высокого уровня. Например, не следует объявлять то же имя переменной во
внутреннем блоке:
int count;
...
func() {
if (condition) {
int count; // НЕ РЕКОМЕНДОВАНО
...
}
...
5.1.10. Инициализация. Необходимо инициализировать локальные переменные в том
месте, где они объявляются. Единственная причина отступления от данного
правила – это зависимость начального значения переменной от некоторых
предварительных вычислений.
5.1.11. Пробелы. Пустые строки улучшают читабельность выделенных участков кода,
которые логически связаны между собой. Две пустые строки всегда должны
использоваться в следующих случаях:


между секциями в файле исходного кода;
между определениями класса и интерфейса.
Одна пустая строка всегда должна использоваться в следующих случаях:




между методами;
между локальными переменными метода и его первым оператором;
перед блочным или однострочным комментарием;
между логическими участками кода внутри метода для улучшения
читабельности.
Разделяющие пробелы должны использоваться при следующих обстоятельствах:

ключевое слово и следующие за ним скобки должны быть разделены пробелом.
Например:
while (true) {
...
}
Примечание: разделяющий пробел не используется между именем метода и его
открывающей скобкой. Это помогает отличить ключевое слово от вызова функции.


разделяющий пробел должен появляться после запятой в списке аргументов;
все бинарные операции должны быть отделены от их операндов пробелами.
Разделяющие пробелы никогда не отделяют унарные операторы, такие как
унарный минус, инкремент («++») и декремент («--») от их операндов.
Например:
a += c + d;
a = (a + b) / (c * d);
50
while (d++ = s++) {
n++;
}
prints("size is " + foo + "\n");

выражения в операторе for должны быть разделены пробелами, например:
for (expr1; expr2; expr3);

за приведением типа должен следовать пробел, например:
myMethod((byte) aNum, (Object) x);
myFunc((int) (cp + 5), ((int) (i + 3))
+ 1);
5.1.12. Соглашение об именовании.
5.1.12.1. Классы. Имя класса должно определяться существительным, набранным в
смешанном регистре с первым символом каждого слова в верхнем регистре.
Следует сохранить имя класса простым и наглядным. Для этого следует
использовать целые слова, избегать сокращений и аббревиатур (не считая
аббревиатур, использующихся чаще своих длинных форм, таких как URL и
HTML).
class Raster; class ImageSprite;
5.1.12.2. Интерфейсы. Имена интерфейсов, как и имена классов, должны быть в верхнем
регистре.
interface RasterDelegate; interface Storing;
5.1.12.3. Методы. Методы должны определяться глаголами, набранными в смешанном
регистре с первым символом в нижнем регистре для первого, и с первым
символом в верхнем регистре для остальных слов.
run(); runFast(); getBackground();
5.1.12.4. Переменные. Исключая случаи названия переменных, все экземпляры классов и
констант классов набираются в смешанном регистре с первым символом в
нижнем регистре. Последующие слова набираются с прописной буквы.
Имена переменных должны быть короткими, но осмысленными. Выбранное имя
переменной должно быть запоминающимся. Оно предназначено для краткого
выражения своего содержимого для человека, временно использующего данную
переменную. Следует избегать односимвольных имен переменных, исключая
временные «одноразовые» переменные. i, j, k, m и n – это общеупотребительные
имена для временных целочисленных переменных; c, d и e – для символьных.
int i; float myWidth;
5.1.12.5. Константы. Названия переменных, объявленные константами класса, и ANSIконстанты должны быть набраны прописными буквами с разделенными знаком
подчеркивания "_" словами. (ANSI-констант следует избегать для более легкой
отладки):
int MIN_WIDTH = 4; int MAX_WIDTH = 999; int GET_THE_CPU = 1;
51
5.2. Критерии качества Java-кода
5.2.1. Методы. Метод класса должен быть относительно коротким, желательно, не более
30-40 строк для обеспечения лучшего восприятия. В противном случае следует
использовать механизмы декомпозиции для разбиения метода.
Количество параметров метода должно быть не более семи. В противном случае
рекомендуется создать DTO-объект.
5.2.2. Классы. Следует избегать чрезмерной раздутости
необходимости следует проводить разбиение класса.
интерфейса.
В
случае
Не следует увлекаться наследованием, а также следует избегать запутанных
иерархий.
Целесообразно использование GOF-паттернов. Однако не стоит использовать
паттерны ради паттернов.
5.2.3. Зависимость между Java-пакетами. Рекомендуется избегать циклической
зависимости между пакетами. По возможности добиваться разбиения системы на
слои.
5.2.4. Вложенность. Желательно избегать большой вложенности кода в методах. В
противном случае следует использовать декомпозицию метода.
Пример чрезмерной вложенности:
for (){
if(){
<фрагмент кода> ….
if() {
<фрагмент кода> ….
for () {
<фрагмент кода> ….
if () {
<фрагмент кода> ….
}
}
}
<фрагмент кода> ….
}
}
5.2.5. Покрытие тестами. Желательно чтобы критичный код был покрыт Unit-тестами.
По возможности следует использовать JUnit4+JMock.
5.2.6. Дублирование функциональности. По возможности следует избегать дублирования
функциональности. В случае необходимости такую функциональность следует
выносить в отдельный метод или класс.
5.2.7. Управление ресурсами. Необходимо следить за освобождением занимаемых
ресурсов. Для написания более безопасного кода можно использовать, где это
возможно, конструкции java7, обеспечивающие автоматическое закрытие ресурсов:
try (OutputStream os = new ….) {
}
Вместо
try {
} finally{
try {
os.close();
52
} catch(…..){
}
}
5.2.8. Стиль Java 5-7. Для итераторов следует по возможности использовать стандартную
форму java 5:
for(…….) {
}
вместо
for(Iterator<> it = ……) {
}
Для инициализации коллекций желательно пользоваться сокращенной нотацией
java7:
List<String> list = new List<>()
вместо
List<String> list = new List<String>()
5.2.9. Константы. Все константы должны быть static final.
5.2.10. Обработка исключений. Все исключения должны быть обработаны или переданы
на уровень выше. Обработка исключений должна проводиться в соответствии с
выбранной стратегией обработки исключений, принятой в проекте. В случае
обработки исключения должна присутствовать хотя бы запись в журнале.
try {
} catch (){
LOG.error(«Хотя бы протоколирование!»)
}
вместо
try {
} catch (){
// ПУСТОЙ ОБРАБОТЧИК! ЭТО ДОПУСТИМО.
}
Для множественных типов исключений там, где это целесообразно, следует
использовать стиль обработки java 7:
try {
} catch (Exception1| Exception2| Exception3 ex){
//Обработка
}
5.3. Протоколирование. При записи в журнал, помимо средств, специфичных для
данного проекта, рекомендуется использовать apache log4J.
53
6. КЛАССИФИКАЦИЯ КРИТИЧНОСТИ ОБНАРУЖЕННЫХ
ДЕФЕКТОВ
6.1. Неисправностью называется ошибка в работе ПО или неспособность ПО
функционировать в соответствии с технической документацией.
6.2. Неисправностью также считается ошибка в технической документации.
6.3. Неисправностями признаются любые ошибки в программном обеспечении и
оборудовании третьих лиц.
6.4. Неисправности ПО классифицируются по категориям Critical, Major, Minor,
представленным в таблице:
Уровень
приоритета
Категория
«Critical»
1
Описание
неисправности
Неисправность в работе
ПО, повлекшая
прекращение
функционирования, и
невозможность
Заказчиком осуществлять
обслуживание клиентов с
помощью ПО.
Признаки1
Обычно это фатальный сбой ПО,
оказывающий влияние на
функционирование сервера или
нескольких клиентов, в результате
которого ПО перестает
функционировать.
Категория «Major» Неисправность в работе
ПО, не повлекшая
прекращения
функционирования ПО,
но не позволяющая
Заказчику в полном
объеме осуществлять
обслуживание клиентов.
Обычно это фатальный сбой
компонента ПО, или его серьезное
ограничение по функционалу или
производительности. При этом другие
части ПО не затронуты.
Это неисправность, оказывающая
большое влияние на клиентов при
ежедневном использовании ПО,
серьезно сказывающаяся на его
производительности.
При этом в целом ПО функционирует.
Категория
«Minor»
Обычно ограничена функциональность
ПО, когда клиенты не могут делать все,
на что имеют право.
Это неисправность, ограничивающая
работу ПО. Она оказывает
минимальное влияние на
работоспособность и
производительность ПО.
Минимальный дефект, практически не
влияющий на производительность
работы ПО. Однако в совокупности
такие дефекты могут снизить удобство
использования ПО.
Неисправность в работе
ПО, не оказывающая
серьезного влияния на
работоспособность ПО.
Ошибка в технической
документации.
Косметический дефект,
ошибка надписи или
минимальное
ограничение по
функционалу.
Для удобства в трактовках ошибок, признаки ошибок могут обновляться по результатам предыдущих ПСИ
54
«Suggestion»
Неисправность
отсутствует
Предложение на усовершенствование
функциональности или интерфейса
ПО, а также технической
документации на ПО
6.5. Кроме неисправностей категорий Critical, Major, Minor, Заказчик вправе сообщить
Исполнителю о своих предложениях по усовершенствованию ПО («Suggestion»).
55
7. КРИТЕРИИ УСПЕШНОСТИ ПРОХОЖДЕНИЕ ПСИ
7.1. Цель проверки – проведение основных тестов для подтверждения корректной
работы заявленного функционала ПО.
7.2. Результаты ПСИ считаются успешными в случае отсутствия ошибок уровня Critical
и Major.
7.3. В случае наличия дефектов категории «Critical» и «Major» – ПО не устанавливается
на продуктивную среду, а возвращается на доработку.
7.4. При наличии дефектов «Minor» – ПО внедряется в продуктивную среду только
после согласования реализации и сроков по устранению обнаруженных дефектов.
7.5. Все оперативные исправления, выпускающиеся в ходе и/или после ПСИ, проходят
регрессионное тестирование с проверкой ближайшего окружения, на которое могло
повлиять данное исправление.
56
Приложение 1. Программа проверки обязательных функций
Тест 01. [краткое описание раздела тестов]
Цель: [описывается часть функционала или список требований, которые допустимы к
проверке данным списком тестов]
Необходимые условия: [описываются какие либо условия / ограничения.]
Тест 01-01[краткое описание теста]
Цель
[Детальное описание]
Необходимые условия
[Дополнительные условия / ограничения]
Действие
Ожидае
Выполнение действия
[Пошаговые действия]
[Описание результата]
Контроль выполнения действия
[Пошаговые действия]
[Описание результата]
Комментарий:
Необходимость повторного прохождения теста после
внедрения в продуктивной среде: ДА (в ночь внедрения/в
последующие дни после внедрения) / НЕТ
57
Приложение 2. Матрица покрытия требований тестами
Требование
Описание требования № 1 из БФТЗ
Тесты
Перечень тестов
Описание требования № 2 из БФТЗ
Перечень тестов
Описание требования № N из БФТЗ
Перечень тестов
ФИО ПРЕДСТАВИТЕЛЯ ЗАКАЗЧИКА:
ПРЕДСТАВИТЕЛЯ ИСПОЛНИТЕЛЯ:
ФИО
ПОДПИСЬ ПРЕДСТАВИТЕЛЯ ЗАКАЗЧИКА:
ПОДПИСЬ ПРЕДСТАВИТЕЛЯ ИСПОЛНИТЕЛЯ:
58
Приложение 3. Протокол прохождения приемо-сдаточных
испытаний
Дата проведения испытаний:
Место проведения испытаний:
Участники испытаний:
Фамилия И.О., Компания, Должность,
Фамилия И.О., Компания, Должность
...
№
Название теста
Отметка о
прохождении
Примечание
0101
0102
0103
……
010N
ФИО ПРЕДСТАВИТЕЛЯ ЗАКАЗЧИКА:
ПРЕДСТАВИТЕЛЯ ИСПОЛНИТЕЛЯ:
ФИО
ПОДПИСЬ ПРЕДСТАВИТЕЛЯ ЗАКАЗЧИКА:
ПОДПИСЬ ПРЕДСТАВИТЕЛЯ ИСПОЛНИТЕЛЯ:
0201
0202
…….
020N
59
ФИО ПРЕДСТАВИТЕЛЯ ЗАКАЗЧИКА:
ПРЕДСТАВИТЕЛЯ ИСПОЛНИТЕЛЯ:
ФИО
ПОДПИСЬ ПРЕДСТАВИТЕЛЯ ЗАКАЗЧИКА:
ПОДПИСЬ ПРЕДСТАВИТЕЛЯ ИСПОЛНИТЕЛЯ:
_______________________
М.п.
_______________________
М.п.
60