«Systemutvikling i praksis» Kristin Meyer Kristiansen Systemkonsulent Unified Consulting AS

Agenda: ● MT-prosjektet ● Utfordringer and suksesser i MT-prosjektet ● Smidige metoder (Agile methods) ● Forvaltning

MT-prosjektet : ● MT – Mobile terminaler ● Portabelt blletteringssystem til bruk i tog

Funksjonalitet: ● Salg og utskrift av billetter ● Annullering av solgte billetter ● Telling av passasjerer ● Oppgjør og innsending av oppgjør ● Utskrift av salgsoversikt ● Utskrift av X-stopplister

Systemet:

– “The fastest and most stable JVM for the Mobile and Embedded market “ – JVM for Windows CE (Pocket PC) – CrEme 3.25 er PersonalJava (tilsvarer JRE 1.1.8) – CrEme 4 kommer med J2ME/CDC/PersonalProfile NSIcom creme:

– Open source – LGPL – XML format – Genererer AWT komponenter – Inneholder de fleste gui elementer som trengs – Theodore – grafisk editor: (ThinG) Thinlet:

– Liten og kjapp – Utforma i java – støtter alle java versjoner – Open source – LGPL lisens – Mange forskjellige tabelltyper ● Vanlig, cached og temp – Enkelt filformat ●.script,.data,.log,.properties HSQLDB

KISO (Kunde i selvbetjente omgivelser): ● Samferdselsdepartementet har besluttet at elektronisk billettering, og derigjennom takst- og billetterings-samarbeider mellom regioner og tjenesteytere, er et satsningsområde for å øke andelen kollektivreisende i Norge og rundt de store byene i særdeleshet. ● Elektronisk billett er når billetten overføres fra papir til et elektronisk medium

● Billetten kan lagres ● I et elektronisk baksystem, med elektronisk identifikasjon av kunden ● Magnetstripekort, evt smartkort ● Strekkode ● Annet ● På et elektronisk medium ● Smartkort ● Magnetstripe ● Annet ● Forskjellen ligger i hvor selve verdien (billetten lagres) ● Hos operatøren vs hos kunden

Smartkort ● Kontakt/kontaktløse kort ● Mini-pc, med mikroprosessor og minne ● Kan inneholde identifikasjon ● Kan lagre komplekse data. ● Kan utføre enkle instruksjoner på lagrede data ● Kraftforsyning og kommunikasjon skjer gjennom antenne som går langs kanten på kortet Tips: Ikke bruk hullemaskin

– Utvidbart – Tjenestebasert – Modulært – Kjente designpatterns Design:

Utfordringer og suksess-faktorer i MT prosjektet

Utfordringer ● Veldig liten tid ● Dårlig spesifikasjon ● Ukjent teknologi ● Liten plass og dårlig ytelse på hardware ● Off-line løsning ● Treg utvikling på hardware til industrimarkedet ● Manglende java-API på printeren ● Mange stakeholders

Suksessfaktorer: ● Stort engasjement hos kunden ● Ukentlige workshops med kunden ● Nærhet til kompetanse om baksystemene ● Godt samarbeid i prosjektgruppa ● Godt fordelt kompetanse i prosjektgruppa

Smidige metoder (Agile methods): ● Oppstått som en reaksjon på byråkratiske metoder ● Mindre dokument-orientert mer kodeorientert ● Tettere samarbeid mellom utviklere og brukere. (Face-to-face kommunikasjon er mer effeltivet enn (dokumentasjon) ● Hyppigere leveranser ● Bred kompetanse i teamet ● Endringsdyktig kode

Smidige metoder: ● Crystal ● FDD – Feature driven developement ● DSDM – Dynamic SystemDevelopement Method ● Lean Software Developement ● Scrum ● TDD – Test Driven Developement ● Xbreed ● XP - eXtreeme programming Mer om smidige metoder:

Scrum: In rugby football a scrummage or scrum is a way of restarting the game, either after a minor infringement […], or when the ball has gone onto the ground after a successful tackle […].

En iterativ, inkrementell prosess for å utvikle ethvert produkt eller styre enhver type arbeid ● En smidig metode for å håndtere og kontrollere utviklingsarbeid ● En innpakning for eksisterende tekniske metoder ● En lettvekts angrepsmåte for å utvikle sytemer og produkter iterativt, inkrementelt når kravene endrer seg hurtig ● En prosess som kontrollerer kaoset som følger av ulike interesser og behov ● En måte og forbedre kommunikasjon og maksimere samarbeid

● En måte og oppdage og fremkalle fjerning av alt som kommer i veien for å utvikle og levere produkter ● En metode for å maksimere produktivitet ● Skalerbar for enkeltprosjketer til hele organisasjoner ● En metode for å få alle til å føle seg vel med jobben sin, sine bidrag, og med at de har gjort så godt de på noen mulig måte kan. forts......

Elementer i Scrum Prosess: ● Sprint planning meeting ● Sprint ● Daily Scrum meeting ● Sprint review meeting ● Sprint retrospective meeting Roller: ● Product owner ● Scrum team ● Scrum master ● (Stakeholders) Artifakter: ● Product backlogg ● Sprint backlogg ● Burndown chart

En Sprint omformer krav til potensielt leverbar funksjonalitet

Sprint ● 30 kalenderdager ● Nok tid til å produsere noe ● Ikke så lenge at man må lage midlertidige artifakter for å huske hva man driver med ● Holder interessen oppe hos Stakeholders ● Teamet kan søke råd, hjelp, informasjon og støtte fra andre ● Ingen gir teamet råd, instruksjoner, kommentarer eller retningslinjer underveis. Teamet styrer seg selv.

● ScrumMaster kan stoppe en Sprint hvis den ikke viser seg levedyktig for eksempel av teknologiske grunner (ugjennomførlig løsning), endring i forretningsmessig grunnlag eller hvis noen tukler med teamet i løpet av Sprint’en ● Hvis Teamet ser de kan klare mer eller ser de ikke klarer hele Sprint Backlog kan de konsultere med Product Owner om å ta inn mer eller ta ut elementer. ● Teamet må delta på Daily Scrum og holde Sprint Backlog ajour med gjenstående (som innspill til Burndown Chart).

Roller PRODUCT OWNER: Ansvar for å organisere Product backloggslik at den har maksimal verdi. Representant for Stakeholders. SCRUM TEAM En flerfaglig gruppe på maks 7-8 personer som organiserer seg selv før hver Sprint.

SCRUM MASTER Ansvarlig for prosessen for korrekt gjennomføring og for maksimering av nytten. (STAKEHOLDERS) Andre med interesse i prosjektet. Sponsorer, brukere og andre som påvirkes.

Sprint Planning Meeting (8t) ● Product Owner stiller med Product Backlog (bestemmer hva som kan tas med i en Sprint) ● Team bestemmer seg for hvor mye av Product Backlog de vil ta på seg i denne Sprint’en Del 1 ● Teamet (uten innvirkning fra andre) planlegger hvordan de skal gå frem for å levere. ● Resultat: Sprint Backlog med oppgaver og estimater og innledende arbeidsfordeling Del 2

Daily scrum meeting (15 min) ● Samme tid og sted hver dag ● Alle i teamet må delta, og komme i tide ● Scrum master setter møtet igang ● Alle besvarer: ● Hva har jeg gjort siden forrige daily scrum? ● Hva skal jeg gjøre til neste daily scrum? ● Hva forhindrer meg i å gjøre arbeidet mitt så effektivt som mulig? ● Knallhard møtedisiplin ● Diskusjoner og digresjoner tas etter møtet ● Chikens kan observere, men ikke interagere med teamet under eller etter møtet

Burndown chart

Sprint Review Meeting (4 t) ● Teamet presenterer for Product Owner og alle interesserte Stakeholders den funksjonaliteten som er ferdig i løpet av Sprint’en. ● Teamet bruker maks 1 time til å forberede seg. ● Funksjonalitet som ikke er ferdig kan ikke presenteres. ● Artifakter som ikke er funksjonalitet kan ikke presenteres unntatt for å forklare funksjonaliteten. Kildekode er ikke funksjonalitet.

● Funksjonalitet demonstreres fra en arbeidsstasjon og kjøres mot QA/systemtestmiljø. ● Sprinten presenteres med hva teamet påtok seg og hva det har levert. ● På bakgrunn av funksjonalitetspresentasjon og åpen diskusjon mellom stakeholders, Product Owner og Team kan man legge inn nye elementer i Product Backlog til prioritering.

Sprint Retrospective Meeting (3 t) ● Deltakere er Team, ScrumMaster og Product Owner (frivillig). ● Alle i Team besvarer: ● Hva gikk bra i siste Sprint? ● Hva kan forbedres i neste Sprint? ● Svarene oppsummeres av ScrumMaster ● Teamet prioriterer hva det vil snakke om med tanke på forbedring. ● Hensiktsmessige endringer som kan gjøres i neste Sprint bør legges inn i Product Backlog som høyt prioriterte ikke-funksjonelle elementer.

Nøkkelelementer – Selvorganiserende Team på maks 7-8 personer – Funksjonalitet prioriteres etter forretningsmessige mål – Tett oppfølging av gjenstående (burndown chart) – Aktiv, intelligent ledelse som fjerner hindringer og fostrer problemløsning – Scrum er en utmerket innpakning av mer spesifikke teknikker som (utvalgte) XP-teknikker

Forvaltning og vedlikehold

Vedlikehold er alt det som tilføres et system etter at det er levert. Dette innebærer både feilretting og endringer. Feilretting (17%) Tilpasninger (18%) Endringer (65%)