1. Om prosesser. Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Om prosesser Tore Berg Hansen

Størrelse: px
Begynne med side:

Download "1. Om prosesser. Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Om prosesser Tore Berg Hansen"

Transkript

1 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Om prosesser Tore Berg Hansen Lærestoffet er utviklet for faget IFUD1019 Objektorientert systemutvikling 1. Om prosesser Resymé: Denne leksjonen handler om utviklingsprosesser. Den gir en introduksjon til prosessbegrepet. Vi ser på hvorfor det er viktig med en definert prosess ved utvikling av programvare. Eksempler på prosesser som er beskrevet i litteraturen blir gjennomgått. Det blir lagt spesiell vekt på Unified Process (UP). Innhold 1.1. DEFINISJONER INTRODUKSJON UTVIKLINGSPROSJEKTETS AKTIVITETER ITERATIV OG INKREMENTELL UTVIKLING SMIDIGE UTVIKLINGSMETODER EKSEMPLER PÅ ITERATIVE OG INKREMENTELLE UTVIKLINGSPROSESSER Generelt The Unified Process Ekstrem Programmering DSDM Scrum DEN PERSONLIGE PROSESSEN OM PROSESSER OG PROSESSFORBEDRING Et rammeverk Den definerte prosessen Kanban og slank LESESTOFF TIL DENNE LEKSJONEN LITTERATUR... 21

2 Om prosesser side 2 av Definisjoner Aktivitet (eng activity) Arbeidsstykke (eng work package) Oppgave (eng task) Utviklingsprosess En mengde arbeid som må utføres. En spesifikasjon av det arbeid som må utføres for å gjøre ferdig en aktivitet eller oppgave. Det omfatter arbeidsprodukter som skal leveres, ressurser, forventet varighet, akseptansekriterier, ansvarlige og andre eventuelle spesielle forhold som det må tas hensyn til. Den minste enhet av arbeid som kan defineres og styres i et prosjekt En fasedelt oppdeling av trinn og aktiviteter som utføres fra unnfangelsen av en ide til idriftsetting og vedlikehold. Egentlig en abstraksjon i form av en modell som i denne sammenheng beskriver aktivitetene ved utvikling av programvare Introduksjon Dagens mennesker er helt avhengige av godt fungerende programvare. Vi støter nesten daglig på systemer som enten er rene programvaresystemer eller systemer hvor programvare er en svært kritisk del av systemet. Avhengig av hvilket arbeid vi har, bruker vi mange hjelpemidler og verktøy for å gjøre en effektiv jobb. Mange av disse hjelpemidlene og verktøyene er programvaresystemer. I hjemmet har vi en rekke apparater. Noen av disse apparatene trenger vi i husholdningen (kjøleskap, mikrobølgeovner, komfyrer). Andre apparater brukes til underholdning (tv, radio, video). De fleste av oss kan heller ikke unnvære telefon/mobiltelefon og bil. Og med Internett handler vi, betaler regninger og finner informasjon om snart nesten det meste. Sikker transport enten det skjer med fly, buss eller båt er avhengig av programvaresystemer. Det dette betyr er at programvaresystemer blir både større og mer komplekse. Det gjør igjen at de som skal utvikle disse programvaresystemene stilles overfor store utfordringer. Utviklerne trenger støtte av metoder, verktøy og god praksis for å kunne håndtere den økende størrelse og kompleksitet. Dette er grunnleggende nødvendig fordi vi erfarer at svært mange utviklingsprosjekter er problematiske. Alt for ofte overskrides tids og kostnadsrammer. Brukerne får ikke det de har forventet. Noe av årsaken til problemet er mangel på en definert utviklingsprosess. Man må strukturere arbeidet. Dvs. at man må arbeide etter en prosessmodell. Med utgangspunkt i prosessmodellen skreddersys en prosess for det aktuelle utviklingsprosjektet. En definert prosess skal gi grunnlag for

3 Om prosesser side 3 av 22 - å finne frem til det arbeid som må gjøres og dele det opp - å følge opp fremdrift - planlegging av ressurser - estimering av tid og kostnader - å finne betingelsene for at en aktivitet kan starte - å spesifisere produkter fra hver aktivitet - å spesifisere teknikker som skal brukes i hver aktivitet - å samle erfaring En prosessmodell er likevel bare et element i et vellykket utviklingsprosjekt. Vi skal derfor før vi diskuterer noen aktuelle prosessmodeller, kort se hvilke elementer som må være på plass for at et utviklingsprosjekt skal bli vellykket Utviklingsprosjektets aktiviteter Vi kan dele et utviklingsprosjekt inn i tre hovedgrupper av aktiviteter: - Prosjektstyring Planlegging Organisering Bemanning Ledelse Kontroll - Programvare system engineering Problemdefinisjon Analyse av løsninger Prosessplanlegging Prosesskontroll Evaluering av ferdig produkt - Programvare engineering Design av programvaren Koding Enhetstest Integrasjon av enheter Aktivitetene under prosjektstyring utfører vi i alle typer prosjekter. Det å få på plass og kontrollere en prosess hører inn under systemaktivitetene. Det er aktiviteter som vi utfører enten vi skal utvikle utelukkende programvare eller programvaren er en del av et større system med både programvare og maskinvare. Den siste gruppen av aktiviteter er kun knyttet til programvare. Prosjektstyringsaktivitetene er ikke tema for dette kurset. Et overordnet ramme for dette kurset er objektorientering. Vi skal derfor se på aktiviteter i de to siste gruppene som må spesialiseres i en objektorientert sammenheng. Vi starter med prosesser, som derfor er tema for resten av denne leksjonen.

4 Om prosesser side 4 av 22 Det er beskrevet en rekke prosessmodeller. Det første forsøk på å lage en prosess for utvikling av programvare resulterte i den velkjente fossefallsmodellen. Forandrings analyse analyse Analyse Utforming Realisering Implementering Forvaltning og drift Avvikling Figur 1 En utforming av fossefallsmodellen. Den finnes i forskjellige varianter. Man kan finne forskjellig antall faser og navn på faser. Men hovedprinsippet er at man gjør seg ferdig med en fase før neste begynner. Erfaringer fra et utall prosjekter viser at dette sjelden er mulig i praksis. Det skjer stadig at krav endrer seg under veis. Det tar for lang tid før brukere får et produkt å forholde seg til. Flere undersøkelser har også vist at en av de aller viktigste årsaker til fiasko er manglende forståelse av kravene til systemet som utvikles. Svaret fra dem som sverger til en eller annen form for fossefallsmodell er å legge ned enda mer arbeid i analysen av krav. Men det er fåfengt. Virkeligheten er ikke slik. Det er umulig å fremskaffe alle krav på forhånd. Svakhetene med fossefallsmodellen har gitt opphav til andre modeller. En forbedring er spiralmodellen [1]. Men heller ikke den gir den nødvendige fleksibilitet for utvikling av objektorienterte systemer. Det er viktig at en prosess både kan kontrolleres og måles og at den samtidig tillater utviklerne å være kreative. Basert på erfaringer om hva som virker og ikke virker, er det etter hvert blitt utbredt enighet om en del beste praksiser. Disse beste praksiser er: - iterativ og inkrementell utvikling - tidlig kontroll med risikofaktorer - kontinuerlig involvering av brukere og andre interessenter - tidlig etablering av en arkitektur for programvaresystemet - kontinuerlig verifikasjon av kvalitet - use case som tråd i utviklingsprosessen - visuell modellering av programvare

5 Om prosesser side 5 av 22 - opptatthet av krav - praktisering av endringskontroll og konfigurasjonsstyring Det viktigste er den første praksisen, iterativ og inkrementell utvikling, fordi den legger på en måte grunnlaget for de andre. Vi skal i de etterfølgende kapitler se på noen prosessmodeller basert på disse praksisene. Vi starter med Unified Process (UP). Det gjør vi fordi læreboken [12] bruker den som eksempelmodell og ramme rundt de forskjellige utviklingsaktivitetene. Forfatterens begrunnelse for å bruke UP som eksempelmodell er at den er en iterativ prosessmodell, at praksisene i UP gir en struktur for å forklare objektorientert analyse og design og at den er fleksibel og kan brukes på en smidig måte Iterativ og inkrementell utvikling En iterativ og inkrementell utviklingsprosess består av en rekke iterasjoner som til slutt ender opp med det endelige system. Denne overordnete filosofien kan gi opphav til prosesser med forskjellig antall faser. Likedan kan graden av formalisme variere. Men et hovedpoeng er at ettersom kravene ikke er fullstendig kjente på forhånd, må denne kunnskap fremskaffes under veis. Man leverer systemet i inkrementer. Hvert inkrement realiserer deler av systemets funksjonalitet, samtidig som man får mer kunnskap om systemet og risikoene man står overfor. Et inkrement er i seg selv er miniprosjekt som leverer et kjørbart system. Brukerne får presentert håndfaste resultater tidlig og i en jevn strøm og kan gi stadig tilbakemelding om systemet tilfredsstiller forventningene. Det endelige systemet bygges dermed i inkrementer ved at det legges til ny funksjonalitet etter hvert. Hvert inkrement vil inneholde innsamling av krav, analyse, design, implementasjon og test. Filosofien har en parallell i Shewhart/Deming syklusen for kontinuerlig forbedring som er sentral innenfor total kvalitets tenkningen. Denne syklusen har fire faser: 1. Planlegg hva som skal gjøres. 2. Gjør det. 3. Sjekk resultatet. 4. Handle og start en ny syklus

6 Om prosesser side 6 av 22 Anvendt på utviklingsprosessen blir det som i Figur 2 som er hentet fra [2]. Initielle risiki Initielt prosjektomfang Definer iterasjoner med høyeste risiko Planlegg og utvikle iterasjonen Iterasjon N Vurder iterasjonen Revider prosjektplaner Risiki eliminert Revider risikovurderingen Figur 2 Inkrementell og iterativ utvikling Smidige utviklingsmetoder Smidig (engelsk: agile) utvikling er et begrep som er blitt vanlig i den senere tid. Det finnes ingen entydig definisjon av begrepet. Ofte brukes det som et synonym for iterativ og inkremetell utvikling. Det vil si at smidige metoder er karakterisert ved iterasjoner med fast lengde og evolusjonær utvikling og kjapp og fleksibel reaksjon på endringer. Begrepet dukket antagelig opp ved etableringen av «Agile Alliance». Det står litt om det i kapittel 2.6 i boken til Larman[12] Eksempler på iterative og inkrementelle utviklingsprosesser Generelt Vi vil ikke i denne leksjonen trekke frem en prosess som den riktige. Den prosessen finnes neppe. Prosesser må velges slik at de passer til den kulturen som er i bedriften og hvor det tas hensyn til et utviklingsprosjekts størrelse og type. Det utvalget prosesser som presenteres kan brukes som maler som kan tilpasses produkttype og egne ønsker og behov. Den informasjon man kan hente i litteraturen om forskjellige prosesser er ikke like detaljert. Noen forfattere nøyer seg med å beskrive de forskjellige faser i prosessen uten å gå detaljert inn på aktiviteter og produkter. Andre gir detaljerte beskrivelser av de aktiviteter som skal utføres i den enkelte fase med angivelse av hvilke resultater hver aktivitet skal gi. Mange nøyer seg med retningslinjer og erfaringer. Man kan også registrere motsetninger mellom anbefalinger gitt av forskjellige forfattere The Unified Process Historien For å få det hele i et perspektiv skal vi se kort på historien. Mange sett av metoder og tilhørende notasjoner er lansert i forbindelse med den objektorienterte bølge som har slått

7 Om prosesser side 7 av 22 over oss. Tre av de mange pionerer innen feltet er James Rumbaugh, Grady Booch og Ivar Jacobson. De har bidratt med hver sine metoder. Rumbaugh med OMT (Object Modelling Technique) [6], Booch [7] med sine spesielle klasse og objektdiagrammer og verktøyet Rational og Jacobson [5] med Use Case og metoden/verktøyet Objectory. Disse slo seg for noen år tilbake sammen. Et av resultatene er UML (Unified Modeling Language) som er et notasjonsspråk, dvs. det redskapet man trenger når man skal visualisere forskjellige sider av et objektorientert system. UML forener OMT, Booch og Objectory. Det ser ut som de har vunnet notasjonskrigen og at UML har blitt det allment aksepterte notasjonsspråket. Det er nå en standard i regi av organisasjonen OMG (Object Management Group). UML er nå i versjon 2.0 utvidet med ideer fra andre av de mest kjente aktørene rundt objektorientering som Meyer, Wirfs_Brock, Shlear-Mellor, Gamma og andre. Et annet resultat av samarbeidet mellom de tre (amigos) er verktøyet Rational Rose. Det markedsføres og videreutvikles av IBM. Det har en høy pris og rimeligere alternativer finnes nå. Et verktøy kan ikke stå alene. Det må være en støtte for det arbeidet som gjøres i utviklingsprosessen. Samarbeidet mellom de tre amigos resulterte i en prosessmodell som har fått betegnelsen Unified Process (opprinnelig kalt Objectory Process). Den overordnede filosofi for denne prosessen er inkrementell og iterativ utvikling. Det er utgitt en bok som Jacobson [8] er hovedforfatter for, hvor prosessen beskrives. De som kun trenger en oversikt over prosessen kan lese i bl.a [2] og [9]. Prosessen omtales ofte som Rational Unified Process (RUP) fordi firmaet Rational (nå overtatt av IBM) støtter prosessen med verktøy. Prosessen The Unified Process (UP) er en livsløpsmodell som skal være godt egnet for bruk sammen med UML. UML er imidlertid ikke avhengig av noen spesiell prosess. Heller ikke er UP avhengig av noe spesielt notasjonsspråk. Imidlertid har UP og UML utviklet seg sammen og involvert noen av de samme personer. Målet med denne prosessen, som med alle andre livsløpsprosesser, er å sørge for produksjon av programvare av høy kvalitet som tilfredsstiller brukerkravene innenfor forutsigbare tids- og budsjettrammer. Prosessen skal kunne skreddersys til å passe mange forskjellige prosjekter og organisasjoner. Prosessen legger vekt på at det skal produseres og vedlikeholdes modeller i stedet for dokumenter. Den er arkitektursentrert. Med det menes at det tidlig i prosessen må lages en grunnleggende arkitektur. Denne arkitekturen skal være robust for å kunne videreutvikles i iterasjon etter iterasjon. Prosessen er Use Case drevet (Jacobsons bidrag [5]) og produserer objektmodeller under veis. Det legges vekt på at prosessen skal bidra til å redusere risiko og fremme kvalitet på sluttproduktet. Risikovurdering og kvalitetsvurdering er bygget inn i prosessen. Fasene i prosessen er vist i figur 3.

8 Om prosesser side 8 av 22 Oppstart Detaljering Overlevering Konstruksjon Figur De fire fasene utgjør til sammen en livssyklus for programvaren. Hver fase ender i en milepæl. Man itererer seg gjennom hver fase. Dette utgjør tidsdimensjonen i modellen. Dette gjøres i de forskjellige fasene: - Oppstart (inception på engelsk). Her skal man legge grunnlaget for prosjektet. Det vil si å finne frem til suksesskriterier, vurdere risikoer, estimere ressursbehov og utforme en grov tidsplan med faser og milepæler. Prototyper er nyttige i denne fasen. - Detaljering (elaboration på engelsk). Problemdomenet analyseres. Man skal iterativt implementere en arkitektur, detaljere neste iterasjon og søke eliminere de største risikoelementene. Hovedkravene til systemet skal beskrives. - Konstruksjon (construction på engelsk). Her implementers gjennom en rekke iterasjoner og inkrementer lavrisikoelementene i systemet. Man finner flere krav og akseptansekriterier. Design detaljeres og systemet inplementeres og testes. - Overlevering (transition). Systemet leveres til brukerne. Dette vil typisk være en betaversjon av systemet.ved at systemet tas i bruk kan nye krav og problemer dukke opp som gjør at livsløpet må startes på nytt. Et viktig poeng er at dette ikke er en sekvensiell prosess som ligner på en fossefallsprosess hvor man starter med å definre alle krav. Oppstartsfasen er ikke en kravanalysefase. Slutten av hver fase ender i en milepæl. Hver fase i prosessen kan deles i flere iterasjoner. En iterasjon er et fullstendig utviklingsløp som skal resultere i et frislipp (release) som enten er internt eller eksternt. Hvert slikt frislipp er en kjørbar del av systemet som er under utvikling. Det endelige systemet blir gradvis komplettert etter hver iterasjon. Dvs. hver iterasjon bringer frem et nytt inkrement av systemet. Iterasjonene i hver fase har forskjellig fokus. I den første fasen vektlegges å få frem kravene, deretter vektlegges analyse og design. Under konstruksjon er det implementasjon som vektlegges. Man kan si at prosessen har to dimensjoner som vist i Figur 4.

9 Om prosesser side 9 av 22 Faser (tidsdimensjonen) Disipliner (aktivitetsdimensjonen) Oppstart Detaljering Konstruksjon Overføring Virksomhetsmodellering Krav Analyse og design Implementasjon Test Deployment Konfig & endringsstyring Prosjektstyring Omgivelser Innledende iterasjoner Iter #1 Iter Iter #n Iter #1 Iter Iter #m Iter #1 Iter Figur 4 Disiplinene (tidligere kalt workflows) representerer aktiviteter som må utføres. Hver disiplin har i tillegg et sett artefakter. Et poeng er at hver iterasjon inneholder nesten alle aktiviteter, men med forskjellig omfang og at man arbeider med de samme artefakter. Det vil si at artefaktene til å begynne med stadig endres, men etter hvert vil de konvergere mot en stabil tilstand. F.eks. så vil kravene være flytende i oppstartsfasen og i begynnelsen av detaljeringsfasen. Hovedpoenget er at man gjennom iterasjoner med tilbakemelding fra brukere kommer frem til sikrere og sikrere krav. Også i de senere faser kan det bli endringer, men etter hvert færre og færre. Et hovedmål med detaljeringsfasen er å få på plass en arkitektur for programvaresystemet. Arkitekturen er det fundamentet og rammen som skal gi grunnlaget for et kvalitetssystem. Vi kommer tilbake til temaet arkitektur i en senere leksjon. I UP defineres disse disipliner: - Virksomhetsmodellering er aktiviteter for å modellere forretningsprosesser. Målet er å få frem kunnskap om de virksomhetsområder som det skal utvikles programvare for. På den måten bygger man bro mellom systemutviklere og de som skal bruke systemene. Disse aktivitetene vil være forskjellige avhengige av hvilken type virksomhet det dreier seg om. - Krav. Her er målet å komme frem til hva programvaresystemet skal gjøre. Man skal frem til funksjonelle krav uttrykt ved use case og ikke-funksjonelle krav. Det utarbeides en visjon for systemet og aktører identifiseres.

10 Om prosesser side 10 av 22 - Gjennom analyse og design beskriver man hvordan systemet skal realiseres. Man fastlegger en arkitektur, hvilke objekter programvaren skal bestå av, eventuelt database, nettverk og desslike. - Implementasjon omfatter aktiviteter for å realisere systemet. Koding av klasser utføres. Systemet organiseres i delsystemer og komponenter. Enheter testes. - Deployment er aktivitetene for å produsere et frislipp (relesase) og levere programvaren til sluttbruker. Det kan inkludere planlegging og gjennomføring av betatester og konvertering av eksisterende programvare og data. - Konfigurasjons og endringsstyring skal sikre at de forskjellige artefakter ikke er i konflikt med hverandre. Man må ha kontroll med oppdateringer, endringer, versjoner, varianter og frislipp av programvaren. Dette er ikke praktisk mulig å få til uten automatiserte verktøy. - Prosjektstyring er gjennomgående aktiviteter hvor man planlegger og følger opp progresjonen i prosjektet. - Omgivelsesdisiplinen er aktiviteter for å få på plass det som trengs for å støtte gjennomføringen av prosjektet. Man skal finner frem og tilrettelegge nødvendig verktøy og tilpasse prosessen til det aktuelle prosjekt. Etter første gjennomløp av de fire hovedfasene har man utviklet første versjon av systemet. Nye generasjoner produseres ved nye løp gjennom hovedfasene. Det er dette som ligger i begrepet evolusjonær utvikling. I løpet av prosessen fremstilles flere modeller. Disse er: - Domenemodell som plasserer systemet i sin kontekst. - Use Case modell som utgjør de funksjonelle kravene. - Modell over ikke-funksjonelle krav. - Analysemodell som gir en implemetasjonsuavhengig arkitektur (her aner vi Jacobson). - Designmodell - Prosessmodell som viser samtidighet og synkroniseringsmekanismer. - Deployment modell som viser topologien for maskinvaren som systemet skal kjøre på. - Komponentmodell viser hvordan systemet fysisk settes sammen. - Testmodell. Det er fremstillingen av disse modellene som står sentralt i senere leksjoner i dette faget. UP blir av enkelte påstått å være en tung og lite smidig prosess. Etter mitt syn er det en feilaktig oppfatning. En grunn til denne oppfatningen kan være at UP med tilhørende verktøy er kommersialisert av IBM til en prosessmodell som kalles Rational Unified Process (RUP). De fleste av aktivitetene og artefaktene i RUP er valgfrie. De som skapte UP ville lage en smidig (agile UP) prosess som kan tilpasses og være så «lett» som ønskelig. Det vil si at man velger ut det minimum av aktiviteter og artefakter som er hensiktsmessig i et gitt prosjekt og vektlegger tidlig programmering fremfor dokumentasjon. Man lager heller ikke en detaljplan for hele prosjektet i starten. Detaljplanlegging gjøres iterasjon for iterasjon. Modellering gjøres etter prinsippene for smidig modellering. Mer om det i neste leksjon.

11 Om prosesser side 11 av Ekstrem Programmering Generelt Extreme Programming (XP) er en prosessmodell som har fått en god del oppmerksomhet i den senere tid. Hovedpoenget for de som står bak er at for å utvikle god programvare må man føre ut i det ekstreme det som er nedfelt som de beste praksiser. Han som står bak er Kent Beck. Ideene er forklart i [13]. Her følger en kort presentasjon av prosessen. Hva er ekstremt? Kent Beck skriver følgende om hva som er det ekstreme: - Hvis koderevisjoner er bra, må vi revidere kode hele tiden. To programmere må arbeide sammen hele tiden. (Pair programming) - Hvis testing er bra, skal alle teste hele tiden, også kundene. - Hvis det å designe er bra, må det være noe enhver holder på med hver dag. - Hvis enkelhet er bra, skal systemet være i den enkleste form som støtter ønsket funksjonalitet. - Hvis arkitektur er viktig, skal alle arbeide med å definere og raffinere arkitekturen hele tiden. - Hvis integrasjonstesting er viktig, så skal man integrere og teste mange ganger hver dag. - Hvis korte iterasjoner er bra, gjør man iterasjonene virkelig korte sekunder, minutter og timer, ikke uker, måneder og år. Videre skriver han at XP, i tillegg til en del andre ting, er en morsom måte å utvikle programvare på. Den skiller seg ut fra andre prosesser ved - ved tidllig, konkret og kontinuerlig tilbakemelding fra korte sykluser - inkrementell planlegging som tidlig frembringer en grov overordnet plan som skal utvikles videre gjennom livsløpet - fleksibel implementasjon av funksjonalitet i takt med endrede behov - bruk av automatiske tester skrevet av programmerere og kunder for tidlig å fange opp defekter - muntlig kommunikasjon, tester og kildekode for å kommunisere strukturen for og hensikten med systemet - basering på en evolusjonær design prosess som varer så lenge systemet varer - tett samarbeid mellom programmere med gjennomsnittlige ferdigheter - praksiser som for programmere instinktivt føles riktige i det daglige og som tjener prosjektene på lang sikt. Det som er innovativt med XP er - Alle gjennomprøvde praksiser settes under en paraply.

12 Om prosesser side 12 av 22 - At man sikrer at praksisene følges så nøye som mulig. - At man sikrer at alle som er involvert støtter hverandre på best mulig måte. En god del av dette finner man igjen i UP. Felles er fokusering på å kontrollere risikofaktorer gjennom iterasjon. I UP legger man stor vekt på visuelle modeller for å kommunisere forskjellige sider av systemet. I XP er muntlig kommunikasjon og kildekode det sentrale DSDM Bakgrunn DSDM står for Dynamic Systems Development Method. Det er altså en utviklingsmetode, men begrepet assosieres også med et konsortium, DSDM-Consortium. Konsortiet ble etablert i 1996 i England. Stifterne kom fra både store og små bedrifter i IT-industrien. Senere har konsortiet fått medlemmer i flere land både i Europa og i Nord-Amerika, men er ennå ikke etabler i Norge. Motivasjonen for etableringen var de problemer vi tidligere har omtalt som typiske for programvareindustrien med forsinkede prosjekter og overskridelser av budsjetter. Konsortiet skal ikke tjene penger, men sørge for å dyktiggjøre medlemmene. Inntektene kommer fra medlemskontingenter. Det konkrete resultatet fra arbeidet i konsortiet er DSDM som utviklingsmodell eller det er kanskje riktigere å si at det er et rammeverk for en lettvekts og smidig (agil) utvikling av programvaresystemer. Man kan godt si at konsortiet har som mål å bidra til å fjerne oppfatningen om at smidig utvikling er noe som bare hackere holder på med. Samtidig mente man at det var helt nødvendig med alternativer til fossefallsmodellen med de åpenbare svakheter den har. Prinsippene DSDM-rammeverket beskriver en prosessmodell basert på prinsippet om iterativ og inkrementell utvikling. Det inneholder også en del artefakter som skal lages i løpet av en utviklingsprosess. Men bortsett fra disse overordnede prinsipper gir ikke modellen detaljerte anvisninger for hvordan utviklingsarbeid skal drives. Det vil si at rammeverket skal tilpasses det aktuelle utviklingsprosjektet og at dette kan gjennomføres etter mange forskjellige paradigmer. Man kan altså følge et tradisjonelt funksjonsorientert paradigme så vel som objektorientering og sågar extreme programming. Det siste er kan hende naturlig ettersom både XP og DSDM er påvirket av den smidige (agile) bevegelsen. En introduksjon til DSDM finner vi i Stapleton [18]. Rammeverket er basert på disse ni prinsippene: 1. Aktiv brukermedvirkning er uomtvistelig. 2. Grupper som praktiserer DSDM må ha stor grad av selvstyre. Det vil si at gruppen må ha fullmakt til å fatte vidtrekkende beslutninger. 3. Fokus er på hyppig levering av produkter. 4. For at det som leveres skal aksepteres må det vise sin nytte for virksomheten som skal ha programvaren. 5. Iterativ og inkrementell utvikling er nødvendig for at man skal oppnå en riktig løsning. 6. Alle endringer som gjøres er reversible. 7. Krav fastsettes (is base lined) på et høyt nivå.

13 Om prosesser side 13 av Testing er integrert gjennom hele livsløpet. 9. Det er essensielt at det er et tett samarbeid og samspill mellom alle interesseparter. Det er konsortiets oppfatning at alle disse prinsippene må følges hvis resultatet skal bli et kvalitetssystem. Modellen DSDM-rammeverket deler et utviklingsprosjekt inn i syv faser. Eller hvis man skal være mer presis så er det to faser som ikke er knyttet direkte til utvikling og fem utviklingsfaser. Det er en forprosjektfase (pre-project phase) hvor man sikrer at prosjektet får en sunn forankring og en etterprosjektfase (post-project phase) hvor man summerer opp erfaringer og sikrer at den leverte løsning fortsatt er operativ. Figur 5 viser utviklingsfasene i DSDM. Feasibility Business study Agree schedule Implement Create Functional prototype Functional model iteration Identify Functional prototype Review business Implementation Train users Review prototype Identify Design prototypes User approved and User guidelines Agree schedule Design and bild iteration Review Design prototype Create design prototype Figur 5 Utviklingsfasene i DSDM Modellen kalles populært for tre pizzaer og en ost. Osten viser to lineære faser. De iterative og inkrementelle faser utgjøres av de tre pizzaer. Den første delen av osten er forstudien hvor man gjør de tradisjonelle tingene for å få en overordnet vurdering av ønsket funksjonalitet og løsningsmuligheter samt grove kostnads- og ressursestimater. I business study analyseres virksomheten og grunnlaget for videreføring av prosjektet legges. Så følger tre iterative faser som man kan gå frem og tilbake mellom. I Functional model iterasjonen detaljeres det arbeidet som ble startet i business modelling. Man starter arbeidet med en evolusjonær prototyp. Høynivåarkitekturen fastsettes. Man itererer gjennom denne fasen inntil man har skaffet nok informasjon om funksjonaliteten som ønskes slik at man kan gå over i design and build, hvor systemet videreutvikles slik at det kan overføres til virksomheten i implementasjonsfasen. DSDM tillater, i god smidig stil, endringer hvis ny kunnskap tilsier det. Derfor piler frem og tilbake mellom pizzaene.

14 Om prosesser side 14 av 22 Et viktig element i DSDM er MoSCoW-reglene. MoSCoW er et akronym for prioritering av krav. Som konsortiet selv skriver er de to o-ene satt inn for moro skyld. De andre bokstavene står for: Must have de krav som er helt nødvendige for at systemet skal kunne brukes i det hele tatt. Should have er krav som ville blitt satt som nødvendige hvis tidsrammene ikke er for stramme, men som man i første omgang kan klare seg uten. Could have er krav man kan klare seg uten i det inkrementet man er inne i. Want to have but will not have this time round er krav som kan vente til eventuell videreutvikling av systemet. Det viktige med MoSCoW-reglene er de danner basisen for beslutninger som skal gjøres i en bestemt timebox. Og timeboxing er et viktig redskap for alltid å levere i tide og innenfor busjett. Det betyr at i en timebox er man ikke opptatt av aktiviteter, men at noe skal leveres etter hver timebox. I en timebox, som kan være mellom to og seks uker lang, skal man ha både Must have og Should have krav. Slik kan man ha krav som kan kastes ut hvis ting av uforutsette årsaker ikke skulle gå som opprinnelig planlagt i en timebox. Av andre ting som vektlegges i DSDM er at lange arbeidsdager ikke skal være normen. Målet er å arbeide normale arbeidsdager og bruke kvelder og helger til rekreasjon og avkobling Scrum Bakgrunn Det kan se ut som Scrum nå er det mest populære smidige prosessrammeverk. Det ble formalisert av Ken Schwaber og Jeff Sutherland i begynnelsen av 1990-tallet. Begrepet Scrum er hentet fra sporten Rugby hvor selvstyrte team jobber tett sammen mot et felles mål. Scrum er et iterativt, inkrementelt rammeverk. Det kan brukes på prosjekter og produktutvikling, spesielt programvareutvikling. Et av de sentrale poengene i Scrum er at prosessen deles opp i iterasjoner av fast lengde. En slik iterasjon kalles en Sprint. En Sprint gis en lengde på fra en til fire uker. Det er et poeng at en sprint ikke er for lang. Da vil det gå for lang tid før nødvendig tilbakemelding fra brukere og andre interessenter kan gis. En Sprint kan heller ikke være for kort. Da vil ikke teamet rekke å gjøre noe nyttig arbeid. Det mest vanlige er derfor en sprintlengde på 14 dager. Du finner en introdusjon til Scrum i [14]. Prinsippene Figur 6 viser flyten i en Scrumprosess. Det sentrale er Sprinter. Disse har en fast varighet gjennom hele prosjektet. Det mest vanlige er to uker slik at teamet får tid til å gjøre noe fornuftig arbeid samtidig som det er kort tid mellom hver tilbakemelding om prosjektet og produktets status.

15 Om prosesser side 15 av 22 Figur 6 Prosessflyten Tallet 3 går igjen. Det er tre artefakter, tre roller og tre seremonier. De tre artefaktene er produktkø, sprintkø og «burndown chart». Produktkø og sprintkø består av brukerfortellinger (user stories). En brukerfortelling er et krav formulert i noen få setninger. Produktkøen inneholder alle kjente krav til systemet som skal utvikles. Sprintkøen inneholder kravene som skal realiseres i den forestående sprinten. Resultatet av sprinten er et kjørbart inkrement av det totale systemet. Det kjørbare inkrementet skal om mulig kunne brukes og gi nytte for oppdragsgiver. Et burndown chart er et diagram som viser gjenstående arbeid i sprinten. Det oppdateres hver dag. De tre rollene er produkteier, scrummaster og scrumteam. Produkteier er kunden eller alternativt en kundekontakt, og har ansvaret for å få laget brukerfortellingene. Scrumteamet er de som gjør arbeidet i sprintene. Størrelsen er 5 9 personer med tverrfaglig kompetanse. De er selvstyrte. Scrummaster er en fasilitator som skal hjelpe scrumteamet til å nå sine mål. Han/hun er ikke en prosjektleder i tradisjonell forstand ettersom teamet er selvorganiserende og selvstyrt. I en sprint skal teamet arbeide uforstyrret. Scrummaster skjermer teamet ved å være kontaktpunktet mot produkteier og bidrar ellers til at teamet følger reglene for Scrum. De tre seremoniene er sprintplanleggingsmøtet, det daglige scrummøte og sprintrevisjonsmøtet. Sprintplanleggingsmøtet gjøres i forkant av hver sprint. Her bestemmes hvilke brukerfortellinger fra produktkøen som skal realiseres i den kommende sprinten. Produkteier prioriterer, mens teamet estimerer hvor mange brukerfortellinger det vil klare å realisere. På det daglige sprintmøtet, også kalt «stand up» møtet, rapporterer hvert teammedlem sin status. Det gjøres ved at scrummaster stiller tre spørsmål til hvert teammedlem Hva gjorde du i går? Hva planlegger du å gjøre i dag? Hvilke hindringer ser du for deg? Møtet skal være kort. Det betyr at problemer som avdekkes ikke løses i dette møtet. I stedet vil det ved behov berammes møter for problemløsning. På standupmøtet oppdateres burndown kartet. Sprintrevisjonsmøtet holdes ved slutten av hver sprint. Poenget er å finne ut hvor man står. Møtet er todelt. I den første delen får interessentene presentert produktet og kan gi tilbakemelding. Den andre delen er en såkalt retrospektiv hvor teamet analyserer selve prosessen for å finne mulige områder for forbedring ved gjennomføringen av fremtidige

16 Om prosesser side 16 av 22 sprinter. Læring og forbedring er sentralt i Scrum. Møtet skal derfor få frem hva som gikk galt, hva som gikk bra og hvilke forbedringstiltak som må tas med til neste sprint. Sprintgjennomføring Arbeidet i Scrum skjer altså i sprinter med sine roller og seremonier. Det visuelle hjelpemiddel til å følge med på det som skjer er en enkel oppgavetavle på en vegg. Det fortutsetter at teamet jobber sammen daglig i det samme rommet. Figur 7 Oppgavetavle Figur 7 viser et eksempel på en oppgavetavle. Den viser på en enkel måte tilstanden til Srumprosjektet. Vi ser en tavle (white-board) med Post-It lapper. De hvite lappene er brukerfortellinger. En brukerfortelling kan være delt opp i flere oppgaver. De er representert med de gule lappene. En brukerfortelling kan være i en av tre tilstander illustrert med de tre kolonnene: Ikke påbegynt (Not checked out), under arbeid (Checked out) og ferdig (Done). På det aktuelle tidspunktet ser vi at en brukerfortelling er ferdig, en oppgave fra en brukerfortelling betående av tre oppgaver er under arbeid. Det vil si at brukerfortellingen er delvis påbegynt. En brukerfortelling er ennå ikke startet.til venstre ser vi et «burn down» kart. Den prikede linjen viser det idelle forløp. Verd slutten av sprinten skal alle brukerfortellinger være realisert ved at gjentående arbeidsmengde er null. Den blå linjen viser virkelig gjenstående arbeidsmengde. Det ser ut som prosjektet så langt går som planlagt fordi den virkelige linjen stort sett følger den ideelle. De gule lappene til venstre er oppgaver som ikke var planlagt, men blir avdekket i løpet av sprinten. De hvite lappene til venstre er brukerfortellinger som kan påbegynnes hvis arbeidet i sprinten går raskere enn planlagt Den personlige prosessen Ideen om den personlige prosessen er lansert av Watts S. Humphrey. Hans poeng er at profesjonelle programvareutviklere må kunne levere programvare av høy kvalitet innenfor avtalte tids- og kostnadsrammer. Dette oppnås ved at den enkelte utvikler definerer sin egen personlige utviklingsprosess. Gjennom erfaring med prosessen og enkle målinger, tar man sikte på stadig å forbedre prosessen. Man blir kjent med sine styrker og svakheter og hvor

17 Om prosesser side 17 av 22 man kan forbedre seg. En definert prosess som følges, fører til at man får et stadig bedre grunnlag for å gjøre gode estimater. En skisse av den personlige prosessen er vist i Figur 8. Krav Planlegging Plan Scripts Retningslinjer Design Kod Kompiler Test Post Mortem Resultater Logger Logger Plan sammendrag Tid Defekter Ferdig produkt Prosjekt og prosess data Sammendragsrapport Figur Om prosesser og prosessforbedring Et rammeverk De prosesser som er beskrevet foran er med et unntak laget av personer som er først og fremst opptatt av metoder for objektorientert utvikling av programvare. Unntaket er den personlige prosessen. Humphrey [3] [4] arbeider ved Software Engineering Institute (SEI) ved Carnegie Mellon Universitetet i USA. I det miljøet er de opptatt av utviklingsprosesser i sin allminnelighet og sammenhengen mellom kvaliteten på prosessen og de produkter som er resultatet av prosessen. Fokus på prosesser blir et annet, enn når prosessen blir noe man legger på en utviklingsmetode. SEI har utviklet et rammeverk som skal hjelpe virksomheter i å forbedre sine utviklingsprosesser. Det startet med at amerikanske myndigheter, spesielt forsvaret, ønsket metoder for å kunne vurdere om leverandører var i stand til å gjennomføre utvikling av programvare med nødvendig kvalitet. Bakgrunnen for dette var igjen de mange problemer med forsinkelser, kostnadsoverskridelser og problemer med kvaliteten på levert programvare som man stadig opplevde. For å gjøre historien kort, så ble resultatet det som nå er kjent under betegnelsen Capability Maturity Model (CMM). CMM er basert på sunn praksis som har vist seg å fungere i vellykkede organisasjoner. Det har i seg elementer som skal hjelpe utviklerne til stadig å forbedre utviklingsprosessen.

18 Om prosesser side 18 av 22 Kunnskapen er hentet inn gjennom erfaringer fra både statlige og offentlige virksomheter (i USA) i tillegg til en rekke andre kilder. Dette er nærmere beskrevet i bla [10] og [11]. Et av elementene i CMM er at virksomheter som ønsker å forbedre sine prosesser gjør det gjennom en langsiktig forbedringsprosess. I denne prosessen 1 skal virksomheten gå gjennom flere nivåer. Hvert nivå representerer en forbedring i forhold til nivået under. Det er fem nivåer. Disse er vist i Figur 9 og betegnes som modenhetsnivåer. Optimalisert Styrt Definert Repeterbar Initiell Figur 9 Det som karakteriserer utviklingsprosessene til virksomheter på det initielle nivå er: - ad hoc - tilfeldig og kaotisk - suksess avhengig av spesielt begavede enkeltpersoner - suksess vil ikke nødvendigvis kunne gjentas Det finnes ikke noe stabilt miljø som gjør at virksomheten kan inngå forpliktende avtaler om tids og kostnadsrammer eller kvaliteten på de produkter som utvikles. Men det betyr ikke at slike virksomheter ikke kan levere utmerkede produkter - av og til. Det er eksempler på at grupper bemannet med meget dyktige, entusiastiske og effektive utviklere har levert innovative produkter. Men noe av hensikten med å ha definerte prosesser er at selv middels 1 Legg merke til at man har prosesser for å forbedre prosesser!

19 Om prosesser side 19 av 22 utviklere skal kunne levere gode produkter; om ikke eksepsjonelle; om igjen og om igjen. Det er nettopp det som karakteriserer andre ingeniørvirksomheter. Neste nivå er det repeterbare. Her er noen nøkkelområder på plass: - styring av økonomi, tid og funksjonalitet - kan gjenta suksess med nye prosjekter av samme type som tidligere prosjekter Det vil si at man har på plass de nødvendige retningslinjer for å kunne planlegge og følge opp prosjekter. Man tar vare på erfaringer og data om kostnader og varighet fra tidligere prosjekter. Disse erfaringene og dataene er grunnlaget når nye prosjekter planlegges. Tidligere suksess kan gjentas (repeteres). På definert nivå har man en utviklingsprosess som består av aktiviteter som er dokumenterte, standardiserte og integrerte. Alle prosjekter følger en skreddersydd versjon av standardprosessen. En gruppe er gitt ansvaret for aktiviteter knyttet til arbeidet med å forbedre prosessen. Det eksisterer et opplæringsprogram som skal gi ledere og utviklere de nødvendige kunnskaper og ferdigheter. Prosessen kalles definert fordi det er på plass kriterier for start og avslutning av et prosesstrinn. Det er etablert standarder og retningslinjer for hvordan arbeidet skal utføres. Det er lagt inn rutiner for verifikasjon. Kostnader og ressursbruk er under kontroll. Karakteristisk for det styrte nivå er at man gjennomfører målinger på produkt og prosess. Produkter og prosesser kan uttrykkes gjennom tall som sier noe om kvaliteten. Prosessen er under statistisk kontroll. Man kan si at prosessen er kvantifiserbar og forutsigbar. Det er mulig å forutsi resultater innenfor kvantifiserbare grenser og man kan skille ut uvanlige hendelser fra normal variasjon i prosessen. Når slike avvik fra det normale inntrer er man i stand til å aksjonere for å korrigere situasjonen. Når man har nådd det øverste nivå er man i stand til å gjøre stadige forbedringer gjennom tilbakemelding fra prosessen. Alle i virksomheten er opptatt av kontinuerlig forbedring av utviklingsprosessen. Man er i stand til å handle proaktivt, ikke reagere i ettertid. Det vil si at man har så god innsikt i prosessen at man kan forutsi nytten og konsekvensene av å ta i bruk ny teknologi og de endringer man gjør. Forhindring er sentralt. Feil som gjøres analyseres og årsaker blir funnet slik at feil ikke gjentas. Kontinuerlig forbedring er stikkordet for det optimaliserende modenhetsnivå.cmm legger opp til at virksomheter skal arbeide seg oppover i modenhet. Nøkkelen til suksess ligger i å gå alle trinnene. Det er en langsiktig utfordring. Man kan ikke hoppe over noen av nivåene. Man må være etablert på et nivå før man kan begynne arbeidet for å nå neste nivå.cmm er et abstrakt rammeverk. Det betyr at man beskriver hva som forventes av utviklingsprosessen på hvert nivå, ikke hvordan prosessen detaljert utformes på hvert nivå. Hvert modenhetsnivå er karakterisert ved nøkkelområder og nøkkelvirksomheter innenfor hvert nøkkelområde. Innenfor hvert nøkkelområde settes det mål som skal oppnås. Etter hvert har det kommet CMM-er for forskjellige områder bl.a. systems engineering, SE- CMM, i tillegg til CMM for programvareutvikling SE-CMM, som vi har beskrevet foran. Man har derfor kommet frem til at det er hensiktsmessig å integrere flere av disse modellene slik at man får en enhetlig struktur og felles terminologi. Dette tiltaket har resultert i CMMI, en integrert CMM og hvor arbeidet med prosessforbedringsmodeller er samlet.

20 Om prosesser side 20 av Den definerte prosessen De fleste vil innse behovet for en definert utviklingsprosess for programvare. I arbeidet med å definere en prosess er det to krav som må tilfredsstilles. - Prosessen må være standardisert - Prosessen må være fleksibel Standardisering er nødvendig for å være forutsigbar. Fleksibilitet må til fordi prosjekter er forskjellige og det må være rom for kreativ utfoldelse som kan lede til innovasjoner. Forskjellige virksomheter har forskjellige behov. Forskjellige typer programvare krever forskjellige prosesser. Utviklernes dyktighet vil også variere og vil bestemme valg av prosess Kanban og slank Vi har i tidligere kapitler skrevet om smidige prosesser og gitt eksempler på smidige prosessrammeverk som UP, Ekstrem programmering, DSDM og Scrum. I dette kapitlet skal vi kort se litt på de prinsippene som ligger bak og som kan begrunne hvorfor smidige prosesser fungerer. Vi tar det med under overskriften prosessforbedring fordi kontinuerlig forbedring er et viktig element. Prinsipppene har sitt utgangspunkt i slanktankegangen (engelsk: lean). Slankprinsippene har fått generell stor oppmerksomhet innen industrien vesten (også Norge) de senere årene. Grunnen til det er at man har ønsket å finne ut hvorfor spesielt japansk bilindustri har hatt så stor suksess. Det er Toyotas produsjonssystem som har fattet interessen fordi Toyota har vist at de kan produsere biler med høy kvalitet på en meget effektiv måte. Begreper som kanban og kaizen ser man også ofte i faglitteraturen. Kanban er signalkort som brukes i produksjonsprosessen for å signalisere ledig kapasitet. Kaizen betyr kontinuerlig forbedring på japansk. Også folk innen programvareutvikling har sett til Japan og slanktankegangen. De som lanserte smidige prosesser er klart influert. Et eksempel er pionerene Mary og Tom Poppendieck. De har skrevet flere bøker om temaet. I [15] lanserer de syv prinsipper basert på slanktankegangen som de argumenterer for at man skal følge i programvareutviklingsprosesser. Disse syv prinsippene i kortform er: 1. Eliminer sløsing. Sløsing er sikt som ikke gir verdi for kunden. Still spørsmål ved om alt papirarbeidet er nødvendig. 2. Sørg for kontinuerlig læring. God programvare er resultat av stadig læring gjennom prøving og feiling. 3. Vent med beslutninger så lenge som mulig. Beslutninger blir bedre når de er basert på fakta og ikke spekulasjoner. Det må derfor legges inn muligheter for å endre. Det skjer gjennom korte iterasjoner. 4. Lever så raskt som mulig. Kunder vil ha resultater raskt. Kjør korte sykluser med design-implementasjon-tilbakemelding-forbedring.

Om prosesser 1. Om prosesser

Om prosesser 1. Om prosesser Tore Berg Hansen 27.1.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LV339D Objektorientert systemutvikling 1. Resymé: Denne leksjonen handler om utviklingsprosesser.

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

HiST/AITeL - RAPPORT 20O6: 2 Avdeling for informatikk og e-læring Høgskolen i Sør-Trondheim. utviklingsmodeller

HiST/AITeL - RAPPORT 20O6: 2 Avdeling for informatikk og e-læring Høgskolen i Sør-Trondheim. utviklingsmodeller HiST/AITeL - RAPPORT 20O6: 2 Avdeling for informatikk og e-læring Høgskolen i Sør-Trondheim utviklingsmodeller ISBN 82-7877-137-5 ISSN 1504-5587 HiST/AITeL - RAPPORT 2 Trondheim 2006 av Tore Berg Hansen

Detaljer

CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM

CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM CONNECTING BUSINESS & TECHNOLOGY KURS OG SERTIFISERINGER - SCRUM Scrum Master og Product Owner i Høst 2015 1 Om Scrum Scrum er et populært rammeverk laget med henblikk på å utvikle komplekse informasjonssystemer.

Detaljer

Prosjektledelse - fra innsiden

Prosjektledelse - fra innsiden Prosjektledelse - fra innsiden Presentasjon hos UiO 31.08.2012 Ida Lau Borch, fagansvarlig i Metier AS Det ligger et fantastisk potensial i det å være best i prosjektledelse og -styring Prosjekteierstyring

Detaljer

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP

Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Hva gjøres i design? 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

Programvare arkitekturer

Programvare arkitekturer Programvare arkitekturer 14. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker

Detaljer

Innhold. Innledning... 15. Del 1 En vei mot målet

Innhold. Innledning... 15. Del 1 En vei mot målet Innledning.............................................. 15 Del 1 En vei mot målet Kapittel 1 Utviklingsarbeidet.............................. 22 1.1 Systemutviklerens arbeid...............................

Detaljer

Presentasjon 1, Requirement engineering process

Presentasjon 1, Requirement engineering process Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv

Detaljer

Smidig utvikling NTNU 10.01.2014 Tor-Erik Mathisen tor-erik.mathisen@accenture.com

Smidig utvikling NTNU 10.01.2014 Tor-Erik Mathisen tor-erik.mathisen@accenture.com Smidig utvikling NTNU 10.01.2014 Tor-Erik Mathisen tor-erik.mathisen@accenture.com Accenture, its logo, and High Performance Delivered are trademarks of Accenture. Agenda Hvorfor Hva Scrum Prosjekteksempel

Detaljer

1. Hvilke type krav angår sikkerhet og pålitelighet?

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan

Detaljer

Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP

Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Hva gjøres i analysen? 2. oktober 2001, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

Scrum. en beskrivelse V 2012.12.13

Scrum. en beskrivelse V 2012.12.13 Scrum en beskrivelse Scrum prinsipper Verdier fra Agile Manifesto Scrum er det mest kjente av de smidige (Agile) rammeverkene. Scrum er også kilden til mye av tankegodset bak verdiene og prinsippene i

Detaljer

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Scrum. -nøkkelbegreper og noen personlige erfaringer

Scrum. -nøkkelbegreper og noen personlige erfaringer Scrum -nøkkelbegreper og noen personlige erfaringer Agile Manifesto Manifest for smidig systemutvikling Vi oppdager stadig nye og bedre måter å utvikle systemer på, både ved å gjøre det selv og ved å hjelpe

Detaljer

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Høgskolen i Telemark 2 Lars- Martin Hejll Høgskolen I Telemark Oppgave 1 Spørsmål fra pensum (20%) 1. Nødvendige aktiviteter i systemutvikling:

Detaljer

1. Modellering av objektorienterte systemer

1. Modellering av objektorienterte systemer Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Modellering av objektorienterte systemer Tore Berg Hansen Lærestoffet er utviklet for faget IFUD Objektorientert systemutvikling 1. Modellering

Detaljer

det offentlige kartgrunnlaget (DOK)

det offentlige kartgrunnlaget (DOK) geografiske data som er tilrettelagt for plan- og byggesaksarbeid = det offentlige kartgrunnlaget (DOK) Terje Nuland, geodataavdelingen Det offentlige kartgrunnlaget ØK FKB DOK Lover forskrifter veiledning

Detaljer

Smidig innhold Hvordan smidige metoder hjelper oss å lage kvalitetsinnhold. Ove Dalen

Smidig innhold Hvordan smidige metoder hjelper oss å lage kvalitetsinnhold. Ove Dalen Smidig innhold Hvordan smidige metoder hjelper oss å lage kvalitetsinnhold Ove Dalen There is a lack of discipline in many web publishing processes because managers in charge of websites often don't respect

Detaljer

Erfaringer fra bruk av Scrum i PS2000-prosjekter NSP temadag Agile metoder i prosjekt 13.05.2009. Motivasjon av kunder og Nyttige verktøy

Erfaringer fra bruk av Scrum i PS2000-prosjekter NSP temadag Agile metoder i prosjekt 13.05.2009. Motivasjon av kunder og Nyttige verktøy Erfaringer fra bruk av Scrum i PS2000-prosjekter NSP temadag Agile metoder i prosjekt 13.05.2009 Motivasjon av kunder og Nyttige verktøy 2009-05-20 Computas AS 2008 Computas-metodikk fra da til nå Computas

Detaljer

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser 1 Ulike typer prosessmodeller Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

Detaljer

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 29.04.2009. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

Detaljer

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner Software Engineering - definisjoner Kap. 2 Prosessen Utviklingsprosessen Modeller for utvikling Bauer: Etablering og bruk av gode ingeniørmessige prinsipper for å fremskaffe økonomisk programvare som er

Detaljer

Prosjektledelse, prosjektplanlegging, teamarbeid

Prosjektledelse, prosjektplanlegging, teamarbeid INF1050: Systemutvikling 25. mars 2015 Prosjektledelse, prosjektplanlegging, teamarbeid Universitetslektor Yngve Lindsjørn INF1050 Systemutvikling ->Prosjektledelse og teamarbeid 1 Temaer i dagens forelesning

Detaljer

Bruk av HP Quality Center med smidige utviklingsmetoder. HP Sofware Norge

Bruk av HP Quality Center med smidige utviklingsmetoder. HP Sofware Norge Bruk av HP Quality Center med smidige utviklingsmetoder Kjell Lillemoen HP Sofware Norge QC og smidige metoder Agenda Smidig terminologi Smidig metoder og verktøy Hvilke krav bør vi stille QC med Scrum

Detaljer

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler:

Detaljer

Flere design mønstre. 19. september 2002, Tore Berg Hansen, TISIP

Flere design mønstre. 19. september 2002, Tore Berg Hansen, TISIP Flere design mønstre 19. september 2002, Tore Berg Hansen, TISIP Kursleksjonene er forfatters eiendom. Som kursdeltaker kan du fritt bruke leksjonene til eget personlig bruk. Kursdeltakere som ønsker å

Detaljer

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 30.04.2007. IMT2243 : Systemutvikling 1

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise 30.04.2007. IMT2243 : Systemutvikling 1 Oppsummering : IMT2243 Systemutvikling Målformuleringen i emnebeskrivelsens : Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

SCRUM Smidig prosjektledelse og utvikling. 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG

SCRUM Smidig prosjektledelse og utvikling. 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG SCRUM Smidig prosjektledelse og utvikling 10 september 2009 JOSÉ MANUEL REDONDO LOPERA AVDELINGSLEDER PROSJEKT OG RESSURSANSVARLIG HVORDAN SPISER DU EN ELEFANT? EN BIT AV GANGEN 'HOW WILL YOU LIVE, RAMBO?'

Detaljer

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009 Kravspesifikasjon med UML use case modellering Erik Arisholm 25.02.2009 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

SCRUM EB og TMG 2010

SCRUM EB og TMG 2010 SCRUM Hovedmål Mer om roller i SCRUM Es/mering av innhold i sprinter Visualisering av fremdri; ved burndown Scrum Daily SCRUM 24h Product backlog Sprint backlog 1 uke Sprint Delprodukt / delleveranse Roller

Detaljer

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: XX Eksamen i fag SIF8018 Systemutvikling

Detaljer

Introduksjon,l SCRUM. EB og TMG 2010 1

Introduksjon,l SCRUM. EB og TMG 2010 1 Introduksjon,l SCRUM EB og TMG 2010 1 Hva er Scrum? Kilde: http:/image.google.com EB og TMG 2010 2 Kompleksitet Kilde: http://www.coderfriendly.com/ EB og TMG 2010 3 SCRUM - kortversjonen Scrum er en smidig

Detaljer

AlgDat 12. Forelesning 2. Gunnar Misund

AlgDat 12. Forelesning 2. Gunnar Misund AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av

Detaljer

Undervisning i Smidige metoder ved Universitetet i Oslo

Undervisning i Smidige metoder ved Universitetet i Oslo Undervisning i Smidige metoder ved Universitetet i Oslo Dag Sjøberg Professor ved Ins4tu7 for informa4kk Universitetet i Oslo Dag Sjøberg, Universitetet i Oslo 1 Planer for undervisning Kurs INF1050 Systemutvikling/software

Detaljer

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse Dagens forelesning Kravspesifikasjon Kravspesifikasjon og objektorientert analyse Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? Noen resultater fra et UML-eksperiment

Detaljer

Prosessmodeller og smidig programvareutvikling

Prosessmodeller og smidig programvareutvikling 1/21/14 INF1050: Systemutvikling 22. januar 2014 Prosessmodeller og smidig programvareutvikling Professor Dag Sjøberg Slide 1 INF1050/ 22.1.2014 / Dag Sjøberg Plan Kap. 2: Begrepet prosessmodell Prosessmodeller

Detaljer

Løsningsforslag til Case. (Analysen)

Løsningsforslag til Case. (Analysen) Løsningsforslag til Case (Analysen) Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen

Detaljer

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet

Lykke til! Eksamen i fag TDT4140 Systemutvikling 28.11.2012 9.00. NTNU Norges teknisk-naturvitenskapelige universitet Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

Detaljer

Kontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012

Kontrakter og test i smidige prosjekter. Fagmøte Dataforeningen i Trondheim 12.Mars 2012 Kontrakter og test i smidige prosjekter Fagmøte Dataforeningen i Trondheim 12.Mars 2012 Agenda Smidige manifest Smidige prosjekter og testing Samarbeid og tillit teori Hva er en kontrakt Gjennomgang av

Detaljer

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav?

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav? Kravspesifikasjon Kravspesifikasjon Erik Arisholm Simula Research Laboratory & Institutt for Informatikk Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? o Noen resultater

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? 1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten

Detaljer

Oppgave 1 Multiple Choice

Oppgave 1 Multiple Choice Oppgave Multiple Choice a 2c 3a 4c 5d 6d 7a 8b 9b 0a b 2c 3c 4a 5b 6b 7a 8d 9c 20b Se video fra forelesningen (Kahoot) for mer detaljer) Eksamen INF050-204 Oppgave 2 a Aktivitetsdiagram Enkelt Eksamen

Detaljer

Et IT-prosjekt = et prosjekt uten styring, er det virkelig slik det er?

Et IT-prosjekt = et prosjekt uten styring, er det virkelig slik det er? Et IT-prosjekt = et prosjekt uten styring, er det virkelig slik det er? Presentasjon hos UiO 03.09.2010 Christian Stensholt, prosjektleder i Bouvet ASA Agenda Innledning: De umulige IT-prosjektene Hva

Detaljer

Kommende Trender Innenfor Test

Kommende Trender Innenfor Test Kommende Trender Innenfor Test Jennifer Blechar, Sopra Steria April 2015 Trondheim Test Conference Jennifer Blechar Studerte matematikk i USA, mastergrad fra London School of Economics, doktorgrad fra

Detaljer

Kanban. Anine Ragnif

Kanban. Anine Ragnif Kanban Anine Ragnif Hvorfor spille KANBAN-spillet? Prinsipper for KANBAN Forstå KANBAN rask og effektivt Mekanismer for god arbeidsflyt Morsom læring Kanban 2014 2 Historikk Kanban har sin opprinnelse

Detaljer

Prosessmodell. Hurtigguider - rammeverk Sist redigert 13.06.2009. Snorre Fossland Eier og driver Snorres Modellbyrå

Prosessmodell. Hurtigguider - rammeverk Sist redigert 13.06.2009. Snorre Fossland Eier og driver Snorres Modellbyrå Prosessmodell Hurtigguider - rammeverk Sist redigert 13.06.2009 For å arbeide med prosessene, må du kunne synliggjøre og kommunisere dem på overordnet nivå. Du må også kunne bryte dem ned i mer detaljerte

Detaljer

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste?

Kort om evaluering og testing av It-systemer. Hvordan vurdere, verdsette, velge og teste? Kort om evaluering og testing av It-systemer Hvordan vurdere, verdsette, velge og teste? Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme

Detaljer

IT Service Management

IT Service Management IT Service Management Forelesning uke 7 Innhold Endringer Endringer i ITIL: Service Transition Endringer - en nødvendig onde? If it ain t broke don t fix it. De fleste supportsaker synes å skyldes endringer

Detaljer

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Fastsatt som forskrift av Utdanningsdirektoratet 3. april 2006 etter delegasjon i brev 26. september 2005 fra Utdannings-

Detaljer

Introduksjon til prosjektarbeid del 1. Prosjektet som arbeidsform Begrep, fundament og definisjoner

Introduksjon til prosjektarbeid del 1. Prosjektet som arbeidsform Begrep, fundament og definisjoner Introduksjon til prosjektarbeid del 1 Prosjektet som arbeidsform Begrep, fundament og definisjoner For å lykkes i konkurransen Er innovasjon viktig Nye produkter, markedsføring, produksjonsmåter, opplæring,..

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

Grunnleggende testteori. Etter Hans Schaefer

Grunnleggende testteori. Etter Hans Schaefer Grunnleggende testteori Etter Hans Schaefer Industri- og softwareprodukt Industriprodukt Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes,

Detaljer

Smidig Integrasjon - Hvordan bruke Lean teknikker for å få bedre kontroll over integrasjonsprosessen.

Smidig Integrasjon - Hvordan bruke Lean teknikker for å få bedre kontroll over integrasjonsprosessen. Smidig Integrasjon - Hvordan bruke Lean teknikker for å få bedre kontroll over integrasjonsprosessen. Integrasjonsdagene, 31. august 2012 Hvorfor jobbe Lean Integrasjon står for over 20-40% av et IT budsjett

Detaljer

Agile metoder i ulike prosjektfaser, betydning for anvendelse og fokus. Elisabeth Krogh Svendsen, Terramar 05.11.2009

Agile metoder i ulike prosjektfaser, betydning for anvendelse og fokus. Elisabeth Krogh Svendsen, Terramar 05.11.2009 Agile metoder i ulike prosjektfaser, betydning for anvendelse og fokus Elisabeth Krogh Svendsen, Terramar 05.11.2009 Hensikt med forskningsprosjektet Effektmål 1: Webside og formidling NSP (bedrifter/partnere/medlemmer)

Detaljer

DRI2001 / FINF september Utvikling av en offentlig nettjeneste: MinSide. 21. september 2006 Marius Pellerud 1

DRI2001 / FINF september Utvikling av en offentlig nettjeneste: MinSide. 21. september 2006 Marius Pellerud 1 DRI2001 / FINF4001 21. september 2006 Utvikling av en offentlig nettjeneste: MinSide 21. september 2006 Marius Pellerud 1 1 Tema i forelesningen Hva skal MinSide bli? Faser i prosjektet Eksempel på strategi

Detaljer

Lean Mining. Presentasjon på Norsk Bergforenings Vårmøte 2015 Gällivare 06.05.2015. Professor i gruvedrift, Sunniva Haugen

Lean Mining. Presentasjon på Norsk Bergforenings Vårmøte 2015 Gällivare 06.05.2015. Professor i gruvedrift, Sunniva Haugen Lean Mining Presentasjon på Norsk Bergforenings Vårmøte 2015 Gällivare Professor i gruvedrift, Sunniva Haugen 1 Institutt for geologi og bergteknikk Håndverk Håndarbeid Lave faste kostnader, høy marginalkostnad

Detaljer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

Detaljer

Lean Six Sigma. Lean Six Sigma tilpasset norske forhold. Fonn Software AS

Lean Six Sigma. Lean Six Sigma tilpasset norske forhold. Fonn Software AS Lean Six Sigma Lean Six Sigma Kort innføring i: Hva er Lean Six Sigma? Hvilke resultat gir metodene? Hva kan min bedrift få ut av metodene? GoFlyten, få flyt i prosessene dine! Hvordan kommer jeg i gang?

Detaljer

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING

GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING GJENNOMGANG UKESOPPGAVER 3 KRAVHÅNDTERING INF1050 V16 HVA ER KRAVHÅNDTERING? Kravhåndtering er prosessen å identifisere, analysere og spesifisere kravene til et nytt system eller et system som skal forbedres

Detaljer

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04

God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04 Mer om UML God objektorientert design Flere UML diagrammer UML Distilled kap. 7,8, 9 Using UML, kap. 11, 12, 14 Kirsten Ribu 17.03.04 1 I dag Litt repetisjon GRASP mønstre og OO design Prosjektoppgaven:

Detaljer

Introduksjon til prosjektarbeid del 3. Prosjektadministrasjon Styring, organisasjon og ledelse

Introduksjon til prosjektarbeid del 3. Prosjektadministrasjon Styring, organisasjon og ledelse Introduksjon til prosjektarbeid del 3 Prosjektadministrasjon Styring, organisasjon og ledelse Prosjektadministrasjon Er alle oppgaver som har å gjøre med styring, organisasjon og ledelse av prosjektutførelsen

Detaljer

Oppsummering. Prosjektdelen

Oppsummering. Prosjektdelen Oppsummering Prosjektdelen Tre Prosjektdefinisjoner Et prosjekt er en engangsoppgave for å nå et klart formulert mål innen en gitt tidsfrist og med en gitt kostnadsramme En organisasjonsform for mest mulig

Detaljer

INF1500 Høst 2015 Magnus Li Martine Rolid Leonardsen. Utviklingsprosesser & krav og behov

INF1500 Høst 2015 Magnus Li Martine Rolid Leonardsen. Utviklingsprosesser & krav og behov INF1500 Høst 2015 Magnus Li Martine Rolid Leonardsen Utviklingsprosesser & krav og behov I DAG GENERELT - Generell informasjon - Et par eksempler på dårlig utforming UTVIKLINGSPROSESSER - Fire tilnærminger

Detaljer

Obligatorisk oppgave 1: Foranalyse og Kravhåndtering Lars- Martin Hejll 5611 Systemutvikling

Obligatorisk oppgave 1: Foranalyse og Kravhåndtering Lars- Martin Hejll 5611 Systemutvikling Obligatorisk oppgave 1: Foranalyse og Kravhåndtering LarsMartin Hejll 5611 Systemutvikling Høgskolen i Telemark Oppgave 1: Bakgrunn for systemet LarsMartin Hejll A) Ved å sentralisere bookingsystemet til

Detaljer

IT I PRAKSIS!!!!! IT i praksis 20XX

IT I PRAKSIS!!!!! IT i praksis 20XX IT I PRAKSIS 1 IT i praksis 20XX 2 IT I PRAKSIS FORORD 3 INNHOLD 4 IT I PRAKSIS Styringsmodell for utviklingsprosjekter (SBN) 5 Fra en idé til gevinstrealisering styringsmodell for utviklingsprosesser

Detaljer

Smidig metodikk, erfaringer fra NAV Fagportal

Smidig metodikk, erfaringer fra NAV Fagportal Smidig metodikk, erfaringer fra NAV Fagportal Gry Hilde Nilsen, NAV Morten Tveit, Fornebu Consulting NAV, 08.03.2011 Side 1 Smidig gjennomføring i NAV Fagportal Individer og samspill framfor prosesser

Detaljer

I dag. Prosjektstyring og prosjektgjennomføring. Hva er et prosjekt? Oppdeling i. Planlegging. arbeidsoppgaver. Hva er en prosess? En prosessmodell?

I dag. Prosjektstyring og prosjektgjennomføring. Hva er et prosjekt? Oppdeling i. Planlegging. arbeidsoppgaver. Hva er en prosess? En prosessmodell? Prosjektstyring og prosjektgjennomføring Prosesser, tidsplanlegging, risikostyring G&H: kap 16, 17,19 I dag Prosessmodeller og prosjekter Prosjektplanlegging, inkl. tidsplanlegging Risikostyring Kirsten

Detaljer

Endrings- og konfigurasjonsstyring JavaZone 2003

Endrings- og konfigurasjonsstyring JavaZone 2003 Endrings- og konfigurasjonsstyring JavaZone 2003 Espen Green espen.green@ca.com Om brobygging The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone,

Detaljer

Avegility og ledelse av smidige prosjekter. Avenir AS > slide 1

Avegility og ledelse av smidige prosjekter. Avenir AS > slide 1 Avegility og ledelse av smidige prosjekter Avenir AS > slide 1 Avenir AS > slide 2 Erfaringer fra utvikling av Energimerkesystemet for NVE Bakgrunn for Energimerkesystemet Stortinget har besluttet innføring

Detaljer

Smidig utvikling med Balsamiq

Smidig utvikling med Balsamiq Smidig utvikling med Balsamiq «Smidig prototyping: Dialog mellom produkteier, utviklere og kunde» Nettverksmøte i Den Norske Dataforening 4. september 2013, Trondheim Velkommen til dette foredraget som

Detaljer

Sertifisert Tester. Foundation Level Extension Pensum Agile Tester

Sertifisert Tester. Foundation Level Extension Pensum Agile Tester Sertifisert Tester Foundation Level Extension Pensum Agile Tester Norsk versjon 2015.N1 Basert på Engelsk versjon 2014 Norwegian Testing Board Copyright Dette dokument kan kopieres helt eller delvis, eller

Detaljer

Lynkurs 10. Januar 2012

Lynkurs 10. Januar 2012 Lynkurs 10. Januar 2012 Mål : Dagens lynkurs skal gi dere noen holdepunkter for å komme i gang med arbeidet med bacheloroppgaven på en systematisk og strukturert måte. Fokus er rettet mot arbeidet knyttet

Detaljer

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen

STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag kontinuasjonseksamen Tid: Mandag 06.08.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent

Detaljer

Du er mer lik meg! enn jeg er lik deg!!! Asymmetri i relativ estimering!

Du er mer lik meg! enn jeg er lik deg!!! Asymmetri i relativ estimering! Du er mer lik meg! enn jeg er lik deg!!! Asymmetri i relativ estimering! Magne Jørgensen Estimering av arbeidsmengde er alltid relativt til noe annet ( Alt er relativt )! Sammenligning kan være eksplisitt:!

Detaljer

Erfaringsoverføring fra prosjekt til linje

Erfaringsoverføring fra prosjekt til linje Erfaringsoverføring fra prosjekt til linje av Nils Faugli, Telenor Networks Tema: Kunnskapsledelse og kunnskapsforvaltning i prosjekter Dato: 16. Mars 2005 Sted: Norsk Hydro, Vækerø Bakgrunn Praksis i

Detaljer

Lean IT + ITIL = sant?

Lean IT + ITIL = sant? Lean IT + ITIL = sant? Hva er Lean IT, og hvordan benytte dette i ITIL-miljøer Oslo 30. mai 2012 Monica Strand Seniorkonsulent Steria Steria Hva er Lean? Lean handler om å skape kundeverdi VA Verdiskapende

Detaljer

Systemutviklingsmetoder

Systemutviklingsmetoder Systemutviklingsmetoder Kapittel 2, 4, 5 07.01.2004 Kirsten Ribu 1 I dag Et eksempel på et system med kravspesifikasjon Utviklingsmodeller: Strukturert systemutvikling (Fossefall-modellen) Evolusjonær

Detaljer

Delt opp i tre strategier: forretningststrategi, organisasjonsstrategi og informasjonstrategi.

Delt opp i tre strategier: forretningststrategi, organisasjonsstrategi og informasjonstrategi. Oppsummering infosys Strategier Delt opp i tre strategier: forretningststrategi, organisasjonsstrategi og informasjonstrategi. Forretningststrategi Porters modell - konkurransefordel Bedriften oppnår konkurransefordel

Detaljer

Ettersom IT-bransjen er meget kompleks, kan kurset også anbefales til andre bransjer.

Ettersom IT-bransjen er meget kompleks, kan kurset også anbefales til andre bransjer. KURSBESKRIVELSE Del 1: Grunnleggende kurs, 3 dager Del 2: Prosjektoppstart med fokus på IT-prosjekter, 2 dager Del 3: Utviklingsfaser innenfor IT integrasjonsprosjekter, 2 dager Del 4: Prosjektavslutning

Detaljer

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

Livsløpstesting av IT-systemer

Livsløpstesting av IT-systemer Livsløpstesting av IT-systemer Testing, validering og evaluering Teste Undersøke ved hjelp av tester om systemet fungerer slik det er beskrevet Validere Bekrefte hvordan systemet virkelig fungerer, om

Detaljer

Prosess til folket! AICIT work in progress. Copyright 2012 Accenture All Rights Reserved

Prosess til folket! AICIT work in progress. Copyright 2012 Accenture All Rights Reserved Prosess til folket! AICIT work in progress AICIT Oslo er et innovasjonssenter innen Business Process Management (BPM) og Mobil Accenture Innovation Center for IBM Technologies Samarbeid mellom Accenture,

Detaljer

Vakt og lønnssystem - Rema 1000

Vakt og lønnssystem - Rema 1000 Avdeling for ingeniørutdanning Høgskolen i Oslo og Akershus Prosjektrapport Systemutvikling (LO138A) Høst 2011 Vakt og lønnssystem - Rema 1000 Gruppe 8 Forfattere: Andreas Baaserud, s169982 Ravi Agnihotri,

Detaljer

Metadata for samordning og samhandling

Metadata for samordning og samhandling Metadata for samordning og samhandling DNV/ Industry Geir Jevne, principal 16 October 2008 Problemløsning i en teknologisk hverdag Slide 2 Trærne i samordnings-, samarbeids- og samhandlingsskogen 1. Status

Detaljer

User Story Mapping gir en nyttigere backlog

User Story Mapping gir en nyttigere backlog User Story Mapping gir en nyttigere backlog Workshop, Smidig 2011 Nils Christian Haugen nch@scienta.no Christian Stensholt christian.stensholt@bouvet.no 1 Agenda Intro til User Story Mapping (15 min) Demo

Detaljer

SPPR Software Project Progress Report Uke 38-39

SPPR Software Project Progress Report Uke 38-39 SPPR Software Project Progress Report Uke 38-39 Heiskontrollsystem Gruppe 7 Gunhild Kristiansen, Arne Enger Hansen, Cecilie Vådahl, Kristian Vågen, Magnus Asbjørnsen, Martin Stenmark Høgskolen i Østfold

Detaljer

SOSI standard - versjon 4.0 1 Del 1: Introduksjon. DEL 1: Introduksjon

SOSI standard - versjon 4.0 1 Del 1: Introduksjon. DEL 1: Introduksjon SOSI standard - versjon 4.0 1 DEL 1: Introduksjon SOSI standard - versjon 4.0 2 DEL 1: Introduksjon 0 Innledning.....3 1 Endringslogg fra SOSI-versjon 3.4......4 2 Organisering......5 2.1 Målsetting...5

Detaljer

Mellom barken og veden Smidig testing i krevende terreng TTC 2015

Mellom barken og veden Smidig testing i krevende terreng TTC 2015 Mellom barken og veden Smidig testing i krevende terreng TTC 2015 FOREDRAGSHOLDERE Kristian Bjerke-Gulstuen Accenture siden 1999 Fra utvikler til Testleder og Kvalitetsansvarlig Leder Accenture Norway

Detaljer

VERDIER Mot og Refleksjon Generøsitet og Ambisjon Lidenskap og Arbeidsdisiplin

VERDIER Mot og Refleksjon Generøsitet og Ambisjon Lidenskap og Arbeidsdisiplin Til styremøte, arbeidsdokument pr 14.06.2011 STRATEGISK PLAN 0. VERDIER Strategisk plan 2011-15 bygger på vår Kultur og merkeplattform som ble etablert høsten 2009. Vår virksomhetside og våre verdier er

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

INF329: Utvalgte emner i programutviklingsteori Sikkerhetsanalyse av programvare

INF329: Utvalgte emner i programutviklingsteori Sikkerhetsanalyse av programvare INF329: Utvalgte emner i programutviklingsteori Sikkerhetsanalyse av programvare Kap. 6, «Auditing Software» (s. 115) Kristian Harms, harms@ii.uib.no Presentert 21. september 2005 Merriam-Webster: Audit

Detaljer

Veileder for kravspesifisering. for digitale læringsplattformer og digitale læringsressurser

Veileder for kravspesifisering. for digitale læringsplattformer og digitale læringsressurser Veileder for kravspesifisering for digitale læringsplattformer og digitale læringsressurser Kravspesifisering s.2av54 Innholdsfortegnelse KRAVSPESIFISERING...3 BEOVSANALYSE...8 OMFANGSBESKRIVELSE...12

Detaljer