Система електронних платежів національного банку україни

План

1. Методологія розробки платіжних систем

2. Визначення потреб, формулювання цілей та специфікацій проекту

3. Створення платіжної системи

4. Досягнення практичного результату

Методологія розробки платіжних систем

Процес розробки платіжної системи такий:

Визначення потреб, формулювання цілей та специфікацій проекту

1.1. Аналіз стратегії проекту, в результаті якого початкова концепція переводиться до форми "переліку потреб користувачів" і створюються попередні варіанти обґрунтування проекту та плану організації робіт за цим проектом.

1.2. Аналіз потреб, у результаті чого перелік потреб користувачів розширюється і формулюється за допомогою однозначних термінів, що відповідають цілям розробників. У результаті створюється детальний перелік потреб користувача. Одночасно уточнюються та конкретизуються початкові варіанти обґрунтування проекту та плану організації робіт за цим проектом.

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

Створення платіжної системи

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

2.2. Підготовка випробувань, під час якої на підставі детального переліку потреб користувачів визначається загальна методика випробувань. Виходячи з цієї загальної методики, створюються конкретні варіанти та сценарії випробувань, де викладені детальні процедури їх проведення. На цьому етапі опрацьовуються моделі випробувань, які будуть використовуватися в наступних етапах розробки системи.

2.3.Побудова системи (робочий проект), під час якої на основі детального проекту створюється програмний продукт і випробовуються окремі компоненти системи. Готуються попередні варіанти довідників користувача, щоб сприяти побудові моделей випробувань на стадії їх підготовки.

2.4. Інтеграція системи, під час якої здійснюється все більше (за масштабами) випробувань комбінацій програмних та апаратних елементів системи і, врешті, відбувається випробування та оцінка системи загалом. Створюються остаточні варіанти довідників користувача.

2.5. Кваліфікаційне випробування, під час якого відбувається офіційна перевірка програмного продукту і документації для користувача з тим, щоб упевнитись, що кінцевий продукт відповідає вимогам, які висуваються до нього. Як правило, кваліфікаційне випробування виковується без виходу на реального користувача. Однак масштаб випробування може бути розширений і включатиме пілотні випробування за участю (можливо, обмежено) деяких користувачів.

Досягнення практичного результату

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

3.2. Підготовка плану введення системи в експлуатацію, під час якої визначаються відповідні вимоги та підходи і готується проект інфраструктури, необхідної для забезпечення роботи системи.

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

3.4. Підготовка підтримки функціонування системи, під час якої відбувається навчання персоналу, на який покладена відповідальність за функціонування системи, та введення у дію програми обслуговування, включаючи програми управління вирішенням проблем, та визначення процедури на випадок надзвичайних ситуацій.

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

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

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

Серед вимог користувачів можна виділити, зокрема, вимоги до:

- механізмів розрахунку;

- бухгалтерської моделі;

- графіка роботи системи;

- форми повідомлень;

- доступу до системи;

- реагування на нестандартні ситуації;

- швидкості обробки платежів;

- продуктивності системи;

- зберігання інформації;

- умов оплати за послуги системи;

- рівня захисту;

- ведення статистичної інформації;

- надійності системи;

- механізму вирішення спірних питань.

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

- зручною та простою у використанні (зокрема, статус платежів повинен бути зрозумілим для всіх учасників);

- високонадійною, особливо стосовно цілісності та захисту даних;

- такою, що забезпечує високий рівень готовності послуг;

- такою, що має необхідні операційні характеристики, забезпечує швидкість обробки, передачі та отримання даних;

- гнучкою та придатною до легкої адаптації;

- універсальною щодо доступу в різних режимах часу;

- такою, що гарантує неможливість відміни та безповоротність платежів і розрахунків;

- такою, що забезпечує управління системними ризиками та стримує їх вплив;

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

Для визначення потреб користувача потрібно знати розміри поточних та майбутніх потоків платежів на всій території, яку обслуговуватиме система.

Задоволення потреб користувачів залежить від архітектури системи загалом, включаючи її комп'ютерні та телекомунікаційні компоненти. Наприклад, система, яка користується мережами зв'язку низької якості, з низькою пропускною здатністю і низьким рівнем доступу до мережі, відповідно, матиме гірші робочі характеристики.

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

Модель потоків повідомлень, яка передбачає значні обсяги внутрішньо-регіональних і, відповідно, малі обсяги міжрегіональних платежів, вимагає не такої архітектури, як модель, що передбачає відносно високі обсяги міжрегіональних платежів.

Питання надійності вирішуються шляхом використання окремих машин для виконання різних функцій. У разі виходу з ладу однієї з машин на час її ремонту в розпорядженні користувачів залишаються всі інші функції системи. Однак, проблема надійності може бути вирішена також у разі використання одного центрального процесора за умови високої його надійності.

До мережі зв'язку стандартної платіжної системи висувають такі вимоги:

- забезпечення економічно ефективного механізму підключення всіх необхідних фінансових установ;

- наявність широко розгалуженої електронної мережі, яка охоплювала б усі регіони, що обслуговуватимуться системою;

- потенційна можливість враховувати постійні зміни існуючої телекомунікаційної інфраструктури (можливість, у разі необхідності, використання різних телекомунікаційних засобів: кабельний зв'язок, супутникові системи, радіо та інші безпровідні засоби зв'язку);

- відповідність існуючим міжнародним стандартам відкритого доступу;

- досить гнучка структура, здатна враховувати зміни у потребах фінансової сфери;

- висока надійність та захист передачі фінансової інформації;

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

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

- зв'язок з іншими інтерфейсами мережі;

- інтерфейс прикладного програмного забезпечення з місцевими мережами зв'язку;

- інтерфейс із глобальними мережами зв'язку;

- інтерфейс із резервними каналами зв'язку.

Вибір централізованої чи децентралізованої архітектури обробки даних залежить від чотирьох основних факторів:

1) типу прикладного використання при обробці інформації від користувачів;

2) характеру і приналежності даних та інформації, необхідних для задоволення потреб користувачів;

3) здатності забезпечувати повний контроль за станом системи телекомунікацій;

4) доступу користувача або можливості використання прикладних функцій системи та можливості введення та отримання інформації.

Часто вибір моделі визначається двома факторами, а саме: бухгалтерською моделлю та розміром капітальних витрат. З погляду бухгалтерської моделі необхідно отримати відповіді на такі суттєві питання:

1. Які процедури бухгалтерської проводки та обліку має виконувати прикладне програмне забезпечення?

2. Чим треба керуватися при визначенні місцезнаходження розрахункових рахунків (враховуючи, наприклад, необхідність контролю за ними)?

3. Який тип механізму розрахунків використовуватиметься: на чистій чи на валовій основі?

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

Здебільшого у країні одночасно функціонують кілька платіжних систем, тісно взаємодіючи. Отже, розробляючи нову систему, потрібно приділити достатньо уваги проблемам її сумісності та взаємозв'язку з уже існуючими та проектованими системами.

Більшість робіт із реалізації проекту виконуються власними силами розробників, наявність на ринку спеціалізованих фірм може наштовхнути на рішення розподілити всі роботи або їх частину серед субпідрядників. У такому разі необхідно розробити, запровадити та дотримуватись суворих вимог щодо порядку підписання контрактів.

Що стосується придбання обладнання для обробки даних, то поширеною практикою є конкурсний підхід, зокрема, методи офіційного запрошення до подачі пропозицій. Це стосується і придбання системного програмного забезпечення.

Винятком щодо організації придбання є прикладне програмне забезпечення. Це пов'язано з додатковими труднощами, адже необхідно скласти детальні технічні вимоги. Якщо передбачається придбати готовий програмний продукт, то потрібно проаналізувати обсяг робіт для його адаптації до власних потреб.

Стандартний процес підготовки контрактів на постачання та виконання субпідрядних робіт складається з шести окремих етапів:

1) розробки стратегії щодо постачання та субпідрядів;

2) попередньої оцінки потенційних постачальників та субпідрядників (можливі запити необхідної інформації);

3) підготовки документа, необхідного для відбору постачальників на конкурсній основі;

4) оцінки та вибору кращих пропозицій;

5) переговорів щодо укладення контракту та