Softwarearkitektur og kvalitet Smidig kvalitetsprosesser i utvikling hos BBS

Bakgrunn: Hva er STAY BBS skriver om mainframe til Java Cirka 50 personer Cirka 20 utviklere (cirka 50% konsulenter) I dag kjører 15 000 jobber daglig på mainframe! Vi har svært sikker og stabil drift! Bygger på konsept utarbeidet i 1988

Utfordringene Mange personer involvert Sikker og stabil drift Dårlig erfaring med Java Driftsopplegget fra 1988 er ikke veldig passende Kompliserte systemer 15 000 jobber om dagen Kritiske systemer Milliarder av kroner om dagen

STAY – Pågående arbeid 3 utviklingsprosjekter Utbetaling (direkte remittering) NICS (interbank) Applikasjonsteknisk infrastruktur Andre interessenter (ikke tema her) Drift Basis infrastruktur (maskinvare og nettverk) Database Støttefunksjoner: Innkjøp, arkitektur, sikkerhet Forretningsansvarlige Prosjektledelse

Mine arbeidsoppgaver Programvarearkitekt Visjon, konsistens Innkjøp Designavklaringer Gjenbruk Faglig ansvarlig applikasjonsinfrastruktur Driftsmessige løsninger Kode som integrerer med maskinvare og overvåkingsløsning

Typisk dag for undertegnede 8:45 Daglig statusmøte NICS 9:00 Daglig statusmøte regningsbetaling 9:15 Avklaringer regningsbetaling 9:30 Daglig statusmøte infrastruktur 10:00 Dokumentasjonsarbeide 12:00 Kodearbeide 14:00 Diverse møter og avklaringer 16:00 Formaliseringer av avgjørelser 17:00 Avklaringer med hovedarkitekt Bilde av SCRUM

Typisk uke for applikasjonsteknisk infrastruktur Mandag: Oppsummering av sist uke Planlegging av neste uke Utvikling og dokumentering Tirs-, ons-, torsdag: Daglig scrum Fredag: Fremdriftsdemo Bilde av kode på skjerm?

Inspirasjoner for arbeidsprosess Extreme programming 12 teknikker Scrum Daglig scrum Crystal 7 egenskaper for prosjekter (overlapper med extreme programming)

STAY helhet Daglige Scrum-møter for alle prosjekter (scrum, XP) Tett kommunikasjon (XP, Crystal) Kollektivt kodeeierskap og gjenbruk (XP) Inkrementelt design (XP) ”Barely-sufficient” prosesser (XP) Tekniske hjelpmidler (XP, Crystal) Feedback (XP, Crystal)

Daglige scrum-møter Felles følelse av hva som skjer Inspirerer til framdrift Inspirerer til samarbeid Koordinering mellom prosjekter (meg) Utenforstående får sett framdrift Fare: Må ikke ta for lang tid Ti personer er smertegrensen Under 10 minutter er målet Trening hjelper Bilde av scrum

Tett kommunikasjon Alle i samme etasje Hvert team sitter i åpent landskap Delarkitekter snakker sammen God tone Dyktig hovedarkitekt Stor takhøyde Mange dyktige fagfolk Bilde av landskapet

Tekniske løsninger CVS Maven Cruise Controll Tester

Teknisk løsning: Testing Kravtester FIT og JUnit Enhetstesting (typisk dekning ~70% line) På hver enkel arbeidsstasjon Ved innskjekking Integrasjonstest (gåes fortsatt opp) Etter manuell deployment Ytelsestester (gåes fortsatt opp) Formell test (”U05”)

Teknisk løsning: Cruisecontrol Sender mail dersom tester feiler Ved feil kan andre gå inn å rette feilen Vi skal forsøke å få til bedre krysskontroll Mange ting å gå opp Veldig positive erfaringer Men: Koster en del tid! Screenshot av cruise

Kollektivt kodeeierskap og gjenbruk To ”gjenbruksområder” i CVS Common, domain Regler for kode Checkstyle testgrad Regler for hva som skal gjenbrukes Inkubert i delprosjekter Vi ønsker å unngå a priori gjenbruk Krever teknisk miljø Cruisecontrol-mail Bilde av cruise-control

BBS lever av stabil og sikker drift! Gjenbruk Gir konsistens Driftsovervåking Feilhåndtering Sikkerhet (!) Gir kvalitet der det gjelder Vi har et krav om at systemet skal ”virke” ved en hver enkel defekt i programmer! Men det koster mye! BBS lever av stabil og sikker drift!

Inkrementelt design Bilde av design ved whiteboard Utgangspunkt (grunnlov): ”Enterprise Software Architecture Document” Fortløpende avklaringer Form: Design jam Typisk bruker jeg 5-10 timer i uken på dette Problem: Dårlig dokumentasjon fører til gjentatte diskusjoner

”Barely-sufficient” prosesser Gjenbruk: Godkjennelse og koderegler Komité på fire personer 2 personer for godkjennelse, 1 for veto Innspill fra alle prosjekter Best practices Komité på seks personer Design krav Diktatorisk av sjefsprogramvarearkitekt Kan overstyres av majoritetsveto av BP-komité Anskaffelsesprosess for open source

Feedback Første leveranse går i produksjon i desember. Dette er lenge til! Tidlige leveranser til test (første leveranse har alt vært) Tidlig integrasjon med infrastruktur Tidlig måling av ytelse Automatiserte tester gjør dette billig! Vi har måttet ”gå videre” uten ordentlig deployment Kommunikasjon med driftsmiljøet tar tid

Applikasjonsteknisk infrastruktur Har levert Filoverføring Overvåking Signering Hyppige interne leveranser Fredagsdemo for andre prosjekter Sitter tett ved driftspersonell Hyppig møter og workshops

ATI: Driftsmessige UC BBS tilpasser seg et standard konsept for driftsavvikling ATI utvikler Overvåkingskomponenter Driftsportal Workflow Service Level Management Leveransehåndtering

ATI: Fredagsdemo Gir en viss driv over arbeidet Uformell design- og kodegjennomgang etter behov Synliggjør nye komponenter og behov Kommunikasjons med ”kunder” Kode på skjerm

Oppsummering: Vellykkede prosesser Daglig scrum Automatisert bygging og test Avklaringer og design etter behov Felles kodeeierskap

Oppsummering: Trenger arbeid Gjenbruk – krever at prosjekter gjør endringer for å koordinere Driftsettelse til test Kodegjennomgang Dokumentasjon

Arkitektur i store prosjekter handler om én ting: Kommunikasjon Konklusjon Arkitektur i store prosjekter handler om én ting: Kommunikasjon