Case study – Nové Internetové bankovnictví František Řezáč
Přednášející - František Řezáč
• •
Promoce na FAV 2008 Velké projekty o o o
•
o
Mobilní podpora pozemního odbavení pro Letiště Václava Havla Technický a funkční redesign webového bankovnictví ČS Příprava projektu nové generace webového bankovnictví KB Aktuálně – webové bankovnictví "na zelené louce"
Oblíbené o o o
Java Web frontendy a UX SWI akademicky
Profinit
•
Zakázkový vývoj software o o
• •
o
IT byznys konzultace Orientace na o o
•
Informační systémy Datové sklady ...
o
Finance Telco Státní správa
Preference FTFP o
Vytváření týmů!
Obsah
•
• •
Zrození projektu o
Odhady
Ukázka typické bankovní infrastruktury o
Problémy rozsáhlých systémů
Web frontend technologie o o o
Vývoj webových frameworků Impedance mismatch komponentových frameworků ZKoss
Zákazník
• • • •
Menší banka v oblasti střední a východní Evropy Retail bankovnictví >10 000 klientů Hlavní portfolio o o
•
o
Běžný a spořící účet Půjčky Hypotéky
Typický příklad rozsáhlého informačního systému
Obsah
•
• •
Zrození projektu o
Odhady
Ukázka typické bankovní infrastruktury o
Problémy rozsáhlých systémů
Web frontend technologie o o o
Vývoj webových frameworků Impedance mismatch komponentových frameworků ZKoss
Idea formulation
• •
Zadání investora: Vstoupit do segmentu SME Retail bankovnictví postaveno na "krabicovém" řešení o o o
•
I malé změny jsou ohodnoceny velkou pracností Původní vývojový tým v zahraničí Pro SME je nutné zásadně přepracovat disponentský model - dopady téměř do všeho
Jaký je poměr ceny za vytvoření vlastního vývojového týmu vůči násobně dražšímu změnovému řízení? o
Jaké jsou předpokládané budoucí požadavky?
Proof of Concept (PoC)
•
•
Standardní nástroj pro ověření splnitelnosti byznys požadavků se zvolenými technologiemi Specificky pro tento projekt: účast zástupců firem ucházejících se o zakázku, výstupy: o
•
o
Demo aplikace Odpověď na RFP
Hlavní technologie zadány předem o
Důvody často iracionální Názor jediného (!!!) interního zaměstnance Dojem z obchodní prezentace Zkušenosti z typově rozdílných projektů
Request for Proposal
• • • •
Standardní fáze FTFP projektu Zadavatel dodá (byznys) specifikaci požadavků Dodavatel odpovídá závaznou nabídkou o
Včetně ceny => nutnost odhadu
Princip kvantifikace o o
Základem je byznys specifikace Konkrétní metodika je až sekundární
Odhady - podklady Transactions ............................ 21 3.1 Cash transactions ................... 21 3.2 Non-cash transactions................ 21 3.2.1 Domestic payment order (DPO) ...... 21 3.2.2 Standing instructions (SDPO) ...... 22 3.2.3 Foreign payment order (FPO) ....... 22 3.3 Common transaction functionalities... 23 3.3.1 Product/Transaction matrix ........ 23 3.3.2 Cut-off times ..................... 24 3.3.3 Accounting systems (Export/Import). 24 3.3.4 AML monitoring .................... 25 SME platform definition.................. 25 4.1 User roles........................... 25 4.1.1 Statutory representative role ..... 25 4.1.2 Power of attorney role ............ 25 4.1.3 Card holder role .................. 25 4.1.4 Read-only power of attorney role .. 25
Odhady - naše kvantifikace
•
Základní jednotka "flow", parametry:
o
o o o o o o o o
Use cases Počet use case, které může uživatel v tomto flow dělat. Data Počet významných datových entit, které participují v tomto flow. Složitost Složitost interakcí mezi entitami v typickém flow. 1 - nejmenší 3 - největší Obrazovky Autorizace Připodepsání Limity ... Risk
Odhady vs. realita
•
Odhady o
•
o
Nabídky firem téměř shodné Management banky očekával o 30% nižší
Současný stav o o
Vyčerpána třetina z původního odhadu Korigovaný odhad o 16% vyšší než původní
Zvolený režim dodávek
• •
Kritéria výběru dodavatele? Možnosti vztahu s dodavatelem o
•
o
Metodika vývoje o
•
FTFP - Záměr Bodyshop - Po dodání odhadů a analýz
o
Na úrovni projektu: PRINCE2 Na úrovni komponent: Scrum, Kanban
Subordinace: Banka -> Projekt -> Komponentové týmy
Obsah
•
• •
Zrození projektu o
Odhady
Ukázka typické bankovní infrastruktury o
Problémy rozsáhlých systémů
Web frontend technologie o o o
Vývoj webových frameworků Impedance mismatch komponentových frameworků ZKoss
High level architektura - SOA Internetové bankovnictví SME SME disp. model Primární data neautorizovaných příkazů
Online Data Store Záložní zdroj dat Primární zdroj přehledů
• •
• •
Internetové bankovnictví retail Uživatelské nastavení
•
Pobočkový systém CRM
•
Enterprise service bus, workflow
Payment Transaction System Záloha core systémů Rozcestník pro různé druhy plateb
• •
Core banking Transakční historie Primární data účtů
• •
Core banking - ... Scoring
Technické vs. integrační problémy
•
•
Poměr závisí na velikosti projektu o
Integrační problémy rostou exponenciálně s počtem subsystémů
Typické problémy rozsáhlých systémů o
o
o
Prostředí Jednotná definice dat Release management Monitoring a výpadky Vlastnictví dat Jak získat přehledová data? Komplexita vyplývající z existence záložních zdrojů dat
Obsah
•
• •
Zrození projektu o
Odhady
Ukázka typické bankovní infrastruktury o
Problémy rozsáhlých systémů
Web frontend technologie o o o
Vývoj webových frameworků Impedance mismatch komponentových frameworků ZKoss
Low level architektura - Maven
Web frontend
WS
...
SME byznys logika
Autorizační centrum ESB
WS
ESB
Web frontend technologie
•
Historie
o Servlet - před r. 2000 o JSP - 2001 o MVC - Průběžně o
•
o
Komponenty - 2005 ? Flow - 2008
V posledních letech definitivní vítězství komponentového paradigmatu o o o o o
ČS: JSF KB: Wicket Airbank: Wicket ZUNO: JSF zákazník: ZKoss
Impedance mismatch Request-Response
Component
• • •
• • •
Nestavový (by default) Markup Requesty
Stavový (by default) Strom komponent Události
ZKoss
•
• • •
Java enterprise component framework o
OSS
V ČR vzácně, v zahraničí běžný MVVM pattern View: XML
MVVM
• •
Model-View-Viewmodel Specializace MVC o o
Formální separace C a V VM: POJO modelující LOGICKÝ model UI
Výhody
• • • •
Posunutí úrovně automatické testovatelnosti na view vrstvu Svatý grál zaměnitelnosti prezentační vrstvy Design podle byznys logiky, ne podle struktury komponent Dobrá abstrakce pro impedance mismatch o
•
o
Stav udržován pouze pro byznys parametry, ne pro celé komponenty Události nezávislé na view, markup vůbec neřešen
Nevýhoda: nutnost uznat, že Microsoft něco udělal dobře
www.profinit.eu
Děkuji za pozornost
