Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Softwarearkitektur og kvalitet Smidig kvalitetsprosesser i utvikling hos BBS.

Liknende presentasjoner


Presentasjon om: "Softwarearkitektur og kvalitet Smidig kvalitetsprosesser i utvikling hos BBS."— 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:45Daglig statusmøte NICS 9:00Daglig statusmøte regningsbetaling 9:15Avklaringer regningsbetaling 9:30Daglig statusmøte infrastruktur 10:00Dokumentasjonsarbeide 12:00Kodearbeide 14:00Diverse møter og avklaringer 16:00Formaliseringer av avgjørelser 17:00Avklaringer 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 –Utvikling og dokumentering •Fredag: –Fremdriftsdemo –Utvikling og dokumentering •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 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 –2 personer for godkjennelse, 1 for veto •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!

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 Konklusjon Arkitektur i store prosjekter handler om én ting: Kommunikasjon


Laste ned ppt "Softwarearkitektur og kvalitet Smidig kvalitetsprosesser i utvikling hos BBS."

Liknende presentasjoner


Annonser fra Google