Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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

Liknende presentasjoner


Presentasjon om: "«Systemutvikling i praksis» Kristin Meyer Kristiansen Systemkonsulent Unified Consulting AS."— Utskrift av presentasjonen:

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

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

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

4 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

5 Systemet:

6 – “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:

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

8 – 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

9 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

10 ● 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

11 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

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

13 Utfordringer og suksess-faktorer i MT prosjektet

14 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

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

16 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

17 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:

18 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 […].

19 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

20 ● 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......

21 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

22 En Sprint omformer krav til potensielt leverbar funksjonalitet

23 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.

24 ● 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).

25 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.

26 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.

27 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

28 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

29 Burndown chart

30 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.

31 ● 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.

32 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.

33 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

34 Forvaltning og vedlikehold

35 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%)

36

37

38


Laste ned ppt "«Systemutvikling i praksis» Kristin Meyer Kristiansen Systemkonsulent Unified Consulting AS."

Liknende presentasjoner


Annonser fra Google