Gjesteforelesning kristin

Document Sample
Gjesteforelesning kristin Powered By Docstoc
					«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:
    NSIcom creme:


     www.nsicom.com
–    “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
Thinlet:


    http://www.thinlet.com/
–   Open source – LGPL
–   XML format
–   Genererer AWT komponenter
–   Inneholder de fleste gui elementer som
    trengs
–   Theodore – grafisk editor:
    http://carlsbadcubes.com/ (ThinG)
    HSQLDB


    http://hsqldb.sourceforge.net/
–   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
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
Design:

–   Utvidbart
–   Tjenestebasert
–   Modulært
–   Kjente designpatterns
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:
http://www.agilealliance.org
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
forts......

● 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.
Elementer i Scrum
             Prosess:
             ● Sprint planning meeting


             ● Sprint


             ● Daily Scrum meeting


             ● Sprint review meeting


             ● Sprint retrospective


   Roller: meeting
                              Artifakter:
   ● Product owner
                              ● Product backlogg
   ● Scrum team
                              ● Sprint backlogg
   ● Scrum master
                              ● Burndown chart
   ● (Stakeholders)
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)

     Del 1
    ● 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 2
    ●   Teamet (uten innvirkning fra andre) planlegger
        hvordan de skal gå frem for å levere.
    ●   Resultat: Sprint Backlog med oppgaver og
        estimater og innledende arbeidsfordeling
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

    http://www.controlchaos.com
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%)

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:3/1/2012
language:
pages:38