Види банківських операцій. Поняття та характеристика міжбанківських операцій.
Важливим елементом грошових розрахунків є міжбанківські розрахунки. Вони є обов'язковою передумовою міжгосподарських розрахунків, що здійснюються між економічними суб'єктами — клієнтами різних банків або різних філій одного банку. В цих випадках виникає потреба переказувати кошти з банку платника в банк одержувача. Для забезпечення міжбанківських розрахунків створюються спеціальні платіжні системи. Україна створила досить оперативну, ефективну й надійну систему міжбанківських розрахунків — Систему електронних платежів (СЕП)у що відповідає світовим стандартам. Ця система розбудована на державному рівні, оскільки її ініціатором і організатором був НБУ. Через неї здійснюється переважна частина міжбанківських розрахунків в Україні, вона спроможна задовольнити потреби в розрахунках усіх банків. У структурній побудові СЕП чітко вимальовуються три рівні: нижній, середній та верхній.
На верхньому рівні функціонують операційне управління НБУ, Центральна розрахункова палата (ЦРП) разом із програмно-технічним комплексом АРМ-1, засобами захисту інформації та електронної пошти.
Середній рівень — це територіальні управління НБУ, Територіальні розрахункові палати (ТРП) разом із програмно-технічним комплексом АРМ-2, засобами захисту інформації та електронної пошти.
На нижньому рівні перебувають комерційні банки, їхні філії — учасники СЕП разом із власною електронною системою автоматизації (САБ), програмно-технічним комплексом АРМ-3, засобами захисту інформації та електронної пошти.
Крім Системи електронних платежів, міжбанківські розрахунки можуть здійснюватися і через інші системи, а саме:
— внутрішньобанківську платіжну систему (ВПС);
— комбінацію систем ВПС і СЕП;
— міжнародні системи електронних розрахунків, наприклад, SWIFT;
— двосторонні прямі кореспондентські відносини.
Головним призначенням кожної з названих систем є якнайшвидше транспортування розрахункових документів між банками та переказування коштів від платника до одержувача. Для цього банки повинні відкривати один для одного особливі рахунки, які називаються кореспондентськими (коррахунками), та мати недорогу, швидкісну та надійну систему зв'язку для передання інформації.
Функціонування СЕП базується на таких принципах:
— усі операції здійснюються виключно в електронній формі;
— система є абсолютно закритою, тобто грошові кошти не можуть вийти з фінансового простору СЕП на жодній з її ділянок;
— обіг коштів у системі здійснюється за принципом "брутто", коли кожний платіж відображається на коррахунку учасника СЕП;
— ініціатива проведення платежу належить банку-платнику, який дебетує свій рахунок. Право дебетувати коррахунки інших учасників СЕП надається тільки установам НБУ в обмежених, передбачених чинним законодавством, випадках;
— виконання платіжних доручень платника з його коррахунку здійснюється в черговості їх календарного надходження в СЕП і в межах наявних на рахунку коштів;
— платежі здійснюються в режимі реального часу, що дає можливість завершити розрахунки між банками протягом операційного дня;
— зарахування коштів одержувачу здійснюється тільки після списання їх з коррахунку банку, що обслуговує платника, і надходження на коррахунок обслуговуючого його банку.
Методологія екстремального програмування (ХР).
Екстремальне програмування (XP від англ. Extreme Programming) — методологія розробки програмного забезпечення, найпопулярніша серед так званих гнучких методологій. Має на меті поліпшення якості програмного забезпечення та чутливість до змін у вимогах замовників. Як вид гнучких методологій, XP радить часті "випуски" програми у коротких циклах розробки, що має на меті поліпшити продуктивність праці та покращити можливості виконання вимог замовника що змінюються. Авторами даної методології є Кент Бек, Ворд Каннінгем, Мартін Фаулер та інші.[джерело?]
Інші елементи екстремального програмування включають в собі: парне програмування, проведення обширної перевірки сирцевого коду, модульне тестування всього коду, уникання створення функціональності до того як вона дійсно необхідна, простота та ясність коду, очікування на зміну вимог замовників з плином часу та коли вимоги до продукту стають ясніші, досить часте спілкування із замовником та між самими програмістами. Назва методології походить від ідеї застосувати корисні методи і практики розробки програмного забезпечення, піднявши їх до "екстремальних" рівнів.
Критики XP зауважують на потенційні недоліки цієї методології - нестабільні вимоги, незадокументовані компроміси конфліктів користувачів, відсутність загального документу дизайну програми.
Посібник Extreme Programming Explained: Embrace Change описує Екстремальне Програмування, як:
Спроба примирити гуманність і продуктивність
Механізм для соціальної зміни
Шлях до удосконалення
Стиль розвитку
Дисципліна розробки програмного забезпечення
Головною метою Екстремального Програмування є скорочення вартості неочікуваних змін. У традиційних методах розробки (на кшталт SSADM) вимоги до розвитку системи визначаються на початку роботи над проектом, і часто виправляються пізніше. Це означає, що вартість проекту через зміни буде більшою за заплановану (традиційна особливість для програмного забезпечення, що проектується).
XP використовується для скорочення вартості змін, завдяки представленню простих значень, принципів і методів. При використанні екстремального програмування, проект повинен стати гнучкішим щодо змін.
Дванадцять основних прийомів екстремального програмування (за першим виданням книги Extreme programming explained) можуть бути об'єднані в чотири групи:
Короткий цикл зворотного зв'язку (Fine scale feedback)
Розробка через тестування (Test driven development)
Гра в планування (Planning game)
Замовник завжди поруч (Whole team, Onsite customer)
Парне програмування (Pair programming)
Безперервний, а не пакетний процес
Безперервна інтеграція (Continuous Integration)
Рефакторинг (Design Improvement, Refactor)
Часті невеликі релізи (Small Releases)
Розуміння, що поділяється всіма учасниками
Простота (Simple design)
Метафора системи (System metaphor)
Колективне володіння кодом (Collective code ownership) або обраними шаблонами проектування (Collective patterns ownership)
Стандарт кодування (Coding standard or Coding conventions)
Соціальна захищеність програміста (Programmer welfare) :
40-годинний робочий тиждень (Sustainable pace, Forty hour week)
Основні принципи функціонального моделювання.
Функціональне моделювання дає перспективу процесу моделі аналізу об'єктно-орієнтованого і огляд того, що система повинна робити. Він визначає функцію внутрішніх процесів в системі за допомогою діаграм Data Flow (DFDS). Вона зображує функціональний висновок значень даних, без вказівки того, як вони отримані, коли вони обчислюються, або чому вони повинні бути обчислені.
три базові принципи моделювання процесів:
принцип функціональної декомпозиції;
принцип обмеження складності;
принцип контексту.
Принцип функціональної декомпозиції являє собою спосіб моделювання типової ситуації, коли будь-яка дія, операція, функція можуть бути розбиті (декомпозіровани) на більш прості дії, операції, функції.
Принцип обмеження складності. При роботі з IDEF0 діаграмами істотним є умова їх розбірливості і легкості читання. Суть принципу обмеження складності полягає в тому, що кількість блоків на діаграмі має бути не менше двох і не більше шести.
Принцип контекстної діаграми. Моделювання ділового процесу починається з побудови контекстної діаграми. На цій діаграмі відображається тільки один блок - головна бізнес-функція, що моделюється.
Діаграми класів UML.
Діаграмою класів UML називається діаграма, на якій зображений набір класів (і деяких інших сутностей), які не мають явного відношення до проектування БД), а також зв'язків між цими класами) Крім того, діаграма класів може включати коментарі та обмеження.
Класом називається іменований опис сукупності об'єктів із загальними атрибутами, операціями, зв'язками і семантикою. Графічно клас зображується у вигляді прямокутника.
Атрибутом класу називається іменовану властивість класу, що описує безліч значень, котрі можуть приймати екземпляри цієї властивості. Клас може мати будь-яке число атрибутів.
У діаграмі класів можуть брати участь зв'язку трьох різних категорій: залежність (dependency), узагальнення (generalization) і асоціація (association).
Платіжні системи, їх характеристика і призначення.
Платіжну систему можна представити у вигляді набору платіжних інструментів, банківських процедур, а також міжбанківських систем переказу коштів, поєднання яких забезпечує грошовий обіг разом з інституційними та організаційними правилами та процедурами, що регламентують використання цих інструментів та механізмів.
Обов'язковою функцією платіжної системи є переказ коштів, який здійснюється за допомогою комплексу програмного та технічного забезпечення, із застосуванням електронних засобів приймання, оброблення, передавання та захисту інформації відповідно до принципів і правил проведення переказів. Деякі платіжні системи включають в себе кредитні механізми, але по суті, інший аспект оплати. Платіжні системи використовуються замість торгів грошових коштів у внутрішніх і міжнародних угодах і складаються з основних послуг, що надаються банками та іншими фінансовими інститутами.
Платіжні системи можуть бути фізичні або електронні, які мають свої власні процедури та протоколи. Стандартизація дозволила деяким з цих систем і мереж зростати в глобальному масштабі, але все ще є багато продуктів, що орієнтовані на конкретні країни або системи
Згідно зі ст. 9 Закону переказ в Україні може здійснюватися за допомогою:- внутрішньодержавних платіжних систем- міжнародних платіжних систем,
Виходячи з того, яку роль відіграють платіжні системи відповідно до характеру здійснюваних платежів,розрізняють:
1. Системи міжбанківських розрахунків.
2. Внутрішньобанківські платіжні системи
3. Системи "клієнт-банк.
4. Системи масових платежів
Необхідними елементами ефективно функціонуючих платіжних систем є: - нормативно-правова база, - бухгалтерська й технологічна модель - технологічна інфраструктура - захист інформації.
Test Driven Development (TDD).
Керована тестами розробка (КТР), Розробка через тестування (англ. Test-driven development (TDD)) — технологія розробки програмного забезпечення, яка використовує короткі ітерації розробки, що починаються з попереднього написання тестів, які визначають необхідні покращення або нові функції. Кожна ітерація має на меті розробити код, який пройде ці тести. Нарешті, програміст або група вдосконалюють код для погодження змін. Один із ключових моментів TDD полягає у тому, що підготовка тестів перед написанням самого коду пришвидшує процес внесення змін. Варто зауважити, що керована тестами розробка є методологією розробки програмного забезпечення, а не його тестування.
Test-Driven Development відноситься до концепції екстремального програмування, яка стверджує, що першим ділом потрібно писати тести, а вже потім код, яка веде свій початок з 1999 року, однак, останнім часом спостерігається загальніший інтерес до даної методології
Програмісти також використовують дану методологію для вдосконалення і зневадження сирцевого коду, раніше написаного з використанням інших методологій розробки
Вимоги:
Керована тестами розробка вимагає від розробника створення автоматизованих модульних тестів, які визначають вимоги до коду безпосередньо перед написанням самого коду. Тест містить перевірки умов, які можуть або виконуватися, або ні. Коли вони виконуються, кажуть, що тест пройдено. Проходження тесту підтверджує поведінка, передбачувана програмістом. Розробники часто використовують програмні каркаси для тестування (англ. testing frameworks) для створення та автоматизації запуску наборів тестів. На практиці модульні тести покривають критичні та нетривіальні ділянки коду. Це може бути код, схильний до частих змін, код, від роботи якого залежить працездатність великої кількості іншого коду, або код з великою кількістю залежностей.
Середовище розробки повинно швидко реагувати на невеликі модифікації коду. Архітектура програми повинна базуватися на використанні безлічі сильно пов’язаних компонентів, які слабо залежать одне від одного , завдяки чому тестування коду спрощується.
TDD не тільки пропонує перевірку коректності, а й впливає на дизайн програми.
Спираючись на тести, розробники можуть швидше уявити, яка функціональність необхідна користувачеві. Таким чином, деталі інтерфейсу з'являються задовго до остаточної реалізації рішення.
Зрозуміло, що до тестів застосовуються такі ж вимоги щодо якості коду, як і до основного коду
Основні можливості IDEF0.
IDEF0 — Function Modeling — методологія функціонального моделювання і графічного описання процесів, призначена для формалізації і опису бізнес-процесів. Особливістю IDEF0 є її акцент на ієрархічне представлення об'єктів, що значно полегшує розуміння предметної області. В IDEF0 розглядаються логічні зв'язки між роботами, а не послідовність їх виконання в часі (WorkFlow).
Так само відображаються всі сигнали управління. Така модель є однією з найпрогресивніших моделей і використовується в організації бізнес проектів і проектів, що базуються на моделюванні всіх процесів як адміністративних, так і організаційних.
Діаграми послідовності в UML.
Діаграма послідовності - діаграма, на якій для деякого набору об'єктів на єдиній тимчасової осі показаний життєвий цикл будь-якого певного об'єкта (створення-діяльність-знищення якоїсь сутності) і взаємодія акторів (дійових осіб) ІС в рамках якогось прецеденту (відправка запитів і отримання відповідей). Використовується в мові UML.
Основні елементи діаграми послідовності є позначення об'єктів, вертикальна «лінія життя», що відображає плин часу, прямокутники, що відображає діяльність об'єкта або виконання ним певної функції (прямокутники на пунктирною «лінія життя»), і стрілки, що показують обмін сигналами або повідомленнями між об'єктами.
Характеристика видів організації платіжних систем на валовій та чистій основі.
Система розрахунків на чистій основі («нетто»)
З метою скорочення потреби в коштах та спрощення порядку обміну платіжними документами банки використовують механізм розрахунків на чистій основі.
Згідно цього механізму банки домовляються між собою не проводити розрахунки по кожному документу в реальному масштабі часу, а накопичувати його певну кількість за якийсь відрізок часу (як правило, за один операційний день) і виконувати розрахунки по його закінченні. Розрахунки при цьому проводяться на чистій основі. Залік дебіторської та кредиторської заборгованості може виконуватись двома чи більше сторонами.
Двосторонній залік виконується між двома банками, які домовляються про залік відправлених та отриманих платіжних доручень, обчислення нетто-залишку і виконання розрахунків на певний термін по отриманому сальдо. Такий метод дозволяє скоротити суму розрахунків між двома банками, оскільки в кінці дня робиться тільки один залік по чистому залишку.
Багатосторонній залік виконується між трьома і більше банками. В цьому випадку створюється клірінгова палата, якою може бути один із якихось банків, чи банки створюють окреме акціонерне товариство, що буде виконувати функції клірінгової палати.
Кінцевий розрахунок, тобто зарахування коштів на кореспондентський рахунок банки мають виконувати через центральний банк.
Система, що побудована на «нетто» розрахунках, дозволяє виконувати операції навіть при недостачі коштів. Але ці системи характеризуються великим рівнем ризику.
В тих випадках, коли якийсь із банків, по якому отримано дебетове сальдо, захоче забрати з клірінгової палати якийсь платіжний документ, це може викликати принцип «доміно», і на дебетове сальдо вийдуть інші банки. Вилучення будь-якого платіжного документа призводить до перегляду взаєморозрахунків між банками. Тому відкликання платіжних документів, як правило, забороняється.
Система розрахунків на валовій основі («брутто»)
Система на валовій основі виконує розрахунки відразу після отримання документа. Розрахунок виконується в тому випадку, якщо на рахунку є необхідна сума коштів. Ця система отримала ще назву «брутто» розрахунків.
В системі електронних платежів, що зараз функціонує в Україні, закладена модель «брутто» розрахунків.
В цій системі операції виконуються лише в межах наявних коштів на момент виконання розрахунку. В деяких системах «брутто» розрахунків дозволяється овердрафт. В Україні овердрафт заборонений.
Раніше платежі, для яких не вистачало коштів на кореспондентському рахунку банку, ставились на картотеку. Зараз в НБУ відмовились від ведення картотек і ті платежі, які виконати не можливо з причини відсутності чи нестачі коштів на кореспондентському рахунку, відправляються в комерційний банк.