Softwarearkitektur og kvalitet

Presentasjon om: "Softwarearkitektur og kvalitet"— Utskrift av presentasjonen:

1 Softwarearkitektur og kvalitet
Smidig kvalitetsprosesser i utvikling hos BBS

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

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

4 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

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

6 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

7 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?

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

9 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)

10 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

11 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

12 Tekniske løsninger CVS Maven Cruise Controll Tester

13 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”)

14 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

15 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

16 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!

17 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

18 ”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

19 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

20 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

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

22 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

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

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

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