Om prosesser 1. Om prosesser

Størrelse: px
Begynne med side:

Download "Om prosesser 1. Om prosesser"

Transkript

1 Tore Berg Hansen Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LV339D Objektorientert systemutvikling 1. 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 blir gjennomgått. Det blir lagt spesiell vekt på Unified Process (UP). Innhold 1.1. DEFINISJONER INTRODUKSJON UTVIKLINGSPROSJEKTETS AKTIVITETER ITERATIV OG INKREMENTELL UTVIKLING EKSEMPLER PÅ ITERATIVE OG INKREMENTELLE UTVIKLINGSPROSESSER Generelt The Unified Process Ekstrem Programmering SELECT Perspective Texel og Williams Den personlige prosessen og prosessforbedring LITTERATUR... 20

2 1.1. 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 side 2 av 21

3 - å 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. side 3 av 21

4 Det er beskrevet en rekke prosessmodeller. Det første forsøk på å lage etablere en prosess for utvikling av programvare resulterte i den velkjente vannfallsmodellen. Forandrings analyse Analyse Utforming Realisering Implementering Forvaltning og drift Avvikling Figur 1 En utforming av vannfallsmodellen. 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 vannfallsmodell 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 vannfallsmodellen 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 side 4 av 21

5 - opptatthet av krav - praktiseringa 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 legger hovedvekten på Unified Process. Det gjør vi fordi den ser ut til å ha fått en viss allmenn utbredelse og støttes av verktøy 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 fremskaffer 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 Anvendt på utviklingsprosessen blir det som i Figur 2 som er hentet fra [2]. Initielle risiki 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. side 5 av 21

6 1.5. Eksempler på iterative og inkrementelle utviklingsprosesser Generelt Vi vil ikke i dette notatet 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 metodikker og tilhørende notasjoner er lansert i forbindelse med den objektorienterte bølge som har slått 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) [8], Booch [9] med sine spesielle klasse og objektdiagrammer og verktøyet Rational og Jacobson [7] 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 1.3 utvidet med ideer fra andre av de mest kjente aktørene rundt objektorientering som Meyer, Wirfs_Brock, Shlear-Mellor, Gamma og andre. Revisjon 1.4 er i betaversjon og det arbeides med versjon 2.0. Et annet resultat av samarbeidet mellom de tre (amigos) er verktøyet Rational Rose som også ser ut til å vinne stor utbredelse i det objektorienterte miljø. 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 har resultert 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 [10] er hovedforfatter for, hvor prosessen beskrives. De som kun trenger en oversikt over prosessen kan lese i bl.a [2] og [11]. Prosessen omtales ofte som Rational Unified Process (RUP) fordi firmaet Rational 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 side 6 av 21

7 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 [7]) 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. 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 tidsplan med faser og milepæler. Prototyper er nyttige i denne fasen. - Detaljering (elaboration på engelsk). Problemdomenet analyseres. Man skal ha på plass en arkitektur, detaljere prosjektplaner og søke eliminere de største risikoelementene. Hovedkravene til systemet skal beskrives. - Konstruksjon (construction på engelsk). Her fremstilles systemet gjennom en rekke iterasjoner og inkrementer. 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. 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 side 7 av 21

8 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. 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 bearbeidingsfasen. 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 fundament og ramme 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 side 8 av 21

9 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 identifiserer aktører. - 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 beta-tester 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. Selv om det er UP vi legger vekt på er det i det følgende beskrevet noen andre prosessmodeller. Det gjør vi for at dere skal se at det finnes alternativer. side 9 av 21

10 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 [15]. 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. - 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. side 10 av 21

11 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 SELECT Perspective Generelt SELECT Software Tools er et firma, som navnet antyder, leverer verktøy til støtte for utvikling av programvare. SELECT Perspective er a collection of industry best-practice modeling tecniques that are applied and adapted using process templates within an architectural framework across a wide range of developments in a component-based setting [5]. Eller med andre ord så er det - en prosess - en komponentbasert arkitektur - retningslinjer for gjennomføring Utgangspunktet var Rumbaughs OMT. Det er senere supplert med Jacobsons Use case, komponent-basert 1 arkitektur og UML som notasjonsspråk. Til sammen skal dette muliggjøre raskere utvikling av applikasjoner med høy kvalitet. Det er også mulig å modellere inn eksisterende systemer (legacy systems). Prosessen tar hensyn til at fremtidens applikasjoner vil bli satt sammen av komponenter i stedet for at man hver gang starter fra bunnen. Det betyr at det opereres med to prosesser. En løsningsprosess (solution process) og en komponentprosess (component process). Løsningsprosessen skal sørge for løsninger som raskt gir en verdi for brukeren. Komponentprosessen skal gi komponenter som vil være felles for mange systemer i en virksomhet og som kan brukes av tredjepart. Prosessene skal hjelpe til med å - identifisere og dele opp det arbeid som skal gjøres - følge opp utviklingsarbeidet - sette på riktig bemanning - finne frem til behovet for fysiske ressurser - estimere tid og kostnader - identifisere betingelser som må være til stede før man starter en aktivitet - finne frem til produkter og resultater fra hver aktivitet - bestemme teknikker som skal brukes - dra nytte av erfaringer fra tidligere arbeid Filosofien bak prosessene er: - RAAD (Rapid Architected Application Development) - iterasjon - fokusering på produkter (ikke aktiviteter det er sluttresultatet som teller, ikke hvordan man kommer dit) 1 I en senere leksjon skal vi se nærmere på hva komponenter er. side 11 av 21

12 - inkrementell utvikling (tjenester leveres i deler for å redusere risiko) - evolusjonær utvikling (tidlig tilbakemelding, evolusjon av krav) - stadig validering (bygges det riktige produkt) - positiv politikk - rafinering av prosessen Man ser at filosofien har mye til felles med filosofien bak RUP. Starten på en løsnings- eller komponentprosess kan ha forskjellig opphav. Men en god start er å modellere foretningsprosesser. Løsningsprosessen I Figur 5 er løsningsprosessen skissert. Muligheter Analyser Prototyp Ta i bruk Planlegg inkrement Aksept fra brukere Design & bygg Figur 5 Hensikten med hvert trinn er: - Muligheter Mulige løsninger, grov prosjektplan. Undersøk om problemet er løst før. Høst gjenbruk. - Analyser Få tak i tilstrekkelige krav til å kunne lage en plan for inkrementell levering. Høst gjenbruk ved å se etter eksisterende tjenester som kan brukes til å løse problemet. side 12 av 21

13 - Prototyp Få tak i kravene til brukere ved å lage skjermbilder. Tett iterasjon med analysen. - Planlegg inkrement Legg en plan for produksjon av tjenester gjennom inkrementelle leveranser. - Design og bygg Konstruer, bygg sammen og test et inkrement. Se etter eksisterende komponenter. - Aksept fra brukere Sørg for aksept fra brukerne før inkrementet tas i bruk. Iterer med design og bygg. - Ta i bruk Installer et inkrement i brukermiljøet. side 13 av 21

14 Komponentprosessen Figur 6 viser komponentprosessen. Vurdering Mulighet Ny vei Arkitektonisk Oppgrader vei Analyse Ta i bruk Planlegg tjenester Aksepter Design & bygg Figur 6 Hensikten med trinnene er: - Vurdering - Vurder behovet for gjenbrukbare tjenester. - Planlegg tjenester Lag en plan for et komponentprosjekt. Planlegg inkrementer. - Design og bygg Konstruer, bygg og test komponentene - Aksepter Sørg for aksept og sertifisering før de rulles ut - Rull ut Installer et sett med komponenter i repositoriet For nye komponenter er det nødvendig med en runde med krav og analyse som i løsningsprosessen, mens oppgradering av komponenter kan gå direkte til planlegging av tjenester. I komponentprosessen må man legge større vekt på kvalitet enn i løsningsprosessen. side 14 av 21

15 Texel og Williams Disse har hva de kaller en komplett objektorientert system og programvare utviklingsprosess [6]. Den er komplett fordi den starter med å finne frem til krav (requirements engineering) og slutter med vedlikehold. Prosessen kan brukes som et rammeverk hvor det kan trekkes inn forskjellige objektorienterte utviklingsmetodikker. Prosessen er evolusjonær. Basis for prosessen er Use cases som ble introdusert av Jacobson [7]. Den overordnede filosofi er at prosessen skal støtte - iterativ utvikling, - inkrementell uvikling, - utvikling gjennom forskjellige abstraksjonsnivåer. Prosessen består av 17 faser. Disse er vist i Figur PV OOD - PV OOD - metode design metode design Klasse Klasse imp/test imp/test Kategori test Kategori test PV OOD - PV OOD - språk språk representasjon representasjon HW/SW HW/SW splitting splitting Programvare Programvare OOA- statisk OOA- statisk syn syn PV PV integrasjon og integrasjon og test test Innsamling av Innsamling av krav krav PV OOD - PV OOD - dynamisk syn dynamisk syn System OOA- System OOAdynamisk syn dynamisk syn System OOA- System OOAstatisk syn statisk syn PV - OOA PV - OOA dynamisk syn dynamisk syn System test System test PV OOD- PV OODstatisk syn statisk syn PV OOD - PV OOD - prosess syn prosess syn Vedlikehold Vedlikehold Sporing av Sporing av krav krav Figur 7 Boken [6] gir en meget detaljert beskrivelse av hva som skal gjøres i hver fase: - hva som er forutsetningen for å starte en fase (input) - hvilke aktiviteter som skal utføres - hvilke resultater som skal leveres (work product) side 15 av 21

16 Fasene kan være iterative, samtidige eller overlappende. Sentralt i prosessen er en Requirements Trace Matrix (RTM). Denne matrisen kompletteres i løpet av utviklingstiden. Det gjør det mulig å spore tilbake og se at det systemet som utvikles er i henhold til kravene. Her følger en grov beskrivelse av hva som gjøres i hver fase: 1. Innsamling av krav. Det innebære å finne frem til kravene til både maskinvare og programvare. Fokus er på det ytre grensesnitt for systemet. Fasen avsluttes med en prioritering av kravene. 2. System OOA statisk bilde. Det man skal frem til er hovedkomponentene i systemet. Hensikten med denne fasen er å omforme programvarekrav til Use Case få laget en liste over kategorier (forfatternes ord for klasse eller gruppe av klasser i denne sammenheng) lage scenarier og skissere brukergrensesnittet for hver Use Case lage et kategoridiagram 3. System OOA dynamisk bilde. I denne fasen skal man frem til et dynamisk bilde, dvs samspillet mellom kategoriene. Man lager interaksjonsdiagrammer for kategoriene funnet i den foregående fasen. Et poeng er at det skal utpekes en ansvarlig for utviklingen av hver kategori. Den hovedansvarlige kan fordele ansvaret for maskinvarekategorier og programvarekategorier på forskjellige personer. 4. Maskinvare/programvare splitting. Hensikten er å få klarlagt hvilke kategorier som skal realiseres som maskinvare, programvare eller en kombinasjon. Selv om en kategori skal implementeres i maskinvare er det behov for grensesnittklasse som er programvare. 5. Programvare OOA statisk bilde. Hensikten med fasen er å følge opp med klassediagrammer for hver kategori. 6. Programvare OOA dynamisk bilde. Her fokuseres det på den dynamiske oppførsel med vekt på hver klasses oppførsel samarbeidsrollen til hver enkelt klasse 7. Programvare OOD språkavhengig. Her skal man se på prosesser 2 og fordeling på prosessorer. Man lager et prosessarkitekturdiagram. 8. Programvare OOD statisk bilde. Hensikten er å omforme det statiske logiske bilde fra fase 5 til et fysisk eller implementasjonsbilde. Det innebærer å oppdatere klassediagrammene for hver kategori og spesifikasjon av hver klasse. Det introduseres ikke nye produkter, men eksisterende produkter raffineres ved at flere detaljer legges til. Man skal også se etter muligheter for å gjenbruke design mønstre som allerede er i bruk. 9. Programvare OOD dynamisk bilde. Det dynamiske bildet fra fase 6 detaljeres og kompletteres med nyoppdagede klasser. 10. Programvare OOD språkavhengig. Poenget er å ta hensyn til egenskaper ved det aktuelle språket som skal brukes, f.eks pakker i Java. 11. Programvare OOD design av metoder. Man ser på algoritmisk struktur til metodene. 12. Implementasjon og test av klasser. Kode skives for hver klasse. Teststrategier for den enkelte klasse utformes og klassene testes. 13. Test av kategorier. Man utformer strategier for testing av hver kategori og gjennomfører tester for kategorier og mellom kategorier. 2 Prosess i denne forbindelse er en kjørbar enhet bestående av klasser og deres tilhørende metoder. En prosess kjører på en prosessor. side 16 av 21

17 14. Programvare integrasjon og test. Fokus er på å teste funksjonaliteten for et bestemt frislipp representert ved Use Casene. 15. System integrasjon og test. Hovedhensikten er å teste hele systemet som en helhet for et gitt frislipp. Testingen utføres av kunden (akseptansetest). 16. Sporing av krav. Poenget er å se hvilken kode som representerer spesielle deler av funksjonaliteten. Kildekodefiler som deltar eller er ansvarlig for hvert krav identifiseres. 17. Vedlikehold. De samme 16 fasene om igjen 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 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 Logger Logger Resultater Kompiler Test Post Mortem Tid Defekter Plan sammendrag Ferdig produkt Prosjekt og prosess data Sammendragsrapport Figur 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. side 17 av 21

18 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. 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 [12] og [13]. Et av elementene i CMM er at virksomheter som ønsker å forbedre sine prosesser gjør det gjennom en langsiktig forbedringsprosess. I denne prosessen 3 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: 3 Legg merke til at man har prosesser for å forbedre prosesser! side 18 av 21

19 - 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 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 side 19 av 21

20 nøkkelvirksomheter innenfor hvert nøkkelområde. Innenfor hvert nøkkelområde settes det mål som skal oppnås. 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 Litteratur 1. Berry W. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer, Mai Terry Quantrani, Visual Modeling with Rational Rose and UML, Addison-Wesley 1998, ISBN Watts S. Humphrey, Introduction to the Personal Software Process, Addison-Wesley 1997, ISBN Watts S. Humphrey, A Dicipline for Software Engineering, Addison-Wesley 1995, ISBN Paul Allen and Stuart Frost, Component-Based Development for Enterprise Systems, Cambridge University Press 1998, ISBN Putnam P. Texel and Charles B. Williams, Use cases combined with Booch, OMT, UML, Prentice Hall 1997, ISBN X. 7. Ivar Jacobson & al., Object-Oriented Software Engineering, A Use Case driven Approach, Addison-Wesley 1992, ISBN James Rumbaugh & al, Object-Oriented Modeling and Design, Prentice Hall 1991, ISBN Grady Booch, Object-Oriented Analysis and Design, Benjamin/Cummings 1994, ISBN Ivar Jacobson, Grady Booch, James Rumbaugh, The Objectory Software Development Process, Addison Wesley 1999, ISBN Martin Fowler and Kedall Scott, UML Distilled, Addison Wesley 1997, ISBN Watts S. Humphrey, Managing the Software Process, Addison-Wesley 1989, ISBN Mark C. Paulk & al, The Capability Maturity Model: Guidelines for improving the Software Process, Addison-Wesley 1995, ISBN side 20 av 21

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

1. Om prosesser. Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Om prosesser Tore Berg Hansen 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

Detaljer

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1 Innhold Innledning... 2 Faseplan... 2 Iterasjonsplanlegging... 3 Oppstartsfasen... 3 Artefaktene i oppstartsfasen... 4 Utdypingsfasen... 5 Konstruksjonsfasen... 5 Overføringsfasen... 6 Litteratur... 7

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

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

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG INF1050 V16 HVA ER EN SYSTEMUTVIKLINGSPROSESS? De aktivitetene som utføres for å utvikle et IT-system Eksempler på aktiviteter:

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

Modellering 1. Modellering

Modellering 1. Modellering Tore Berg Hansen 25.8.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget SO328D Programutviklingsmetoder 1. Resymé: I dette notatet skal vi se på hva som genererelt ligger

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

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

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

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

2. HVA ER EN KOMPONENT?

2. HVA ER EN KOMPONENT? Innholdsfortegnelse 1. INTRODUKSJON 3 2. HVA ER EN KOMPONENT? 3 2.1. Litt av historien 3 2.2. UML og komponenter 5 2.3. Noen definisjoner 5 REFERANSER 7 1. Introduksjon Komponenter og komponentbasert systemutvikling

Detaljer

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055 UKE 9 Prosesser og prosessmodeller inkludert smidige metoder Gruppetime INF1055 Hva skal vi i dag? Introduksjon til modul B - systemutvikling (kap. 1, 2 og 3) Prosesser og prosessmodeller + smidig utvikling

Detaljer

Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu

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

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

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

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

A Study of Industrial, Component-Based Development, Ericsson

A Study of Industrial, Component-Based Development, Ericsson A Study of Industrial, Component-Based Development, Ericsson SIF8094 Fordypningsprosjekt Ole Morten Killi Henrik Schwarz Stein-Roar Skånhaug NTNU, 12. des. 2002 Oppgaven Studie av state-of-the-art : utviklingsprosesser

Detaljer

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

GJENNOMGANG UKESOPPGAVER 7 REPETISJON GJENNOMGANG UKESOPPGAVER 7 REPETISJON INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Oppgaver hentet fra tidligere eksamensoppgaver om temaene vi har gått gjennom til nå DAGENS PLAN Gjennomgang av oppgaver Repetisjon

Detaljer

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling Innledning Læringsmål Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling 21.1.2009 Forstå hvorfor systemutviklingsprosessen er viktig Forstå de viktigste prinsippene for ulike prosesser

Detaljer

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006

Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006 Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006 INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................

Detaljer

Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider.

Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider. 1 For hver del, alle sub deler teller likt. Prøv å skrive alle svar på alle spørsmål i det tomme rom i disse sidene. Hvis du trenger mer plass, bruk ekstra sider. For hvert spørsmål, hvis du trenger å

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

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

Model Driven Architecture (MDA) Interpretasjon og kritikk

Model Driven Architecture (MDA) Interpretasjon og kritikk Model Driven Architecture (MDA) Interpretasjon og kritikk Ragnhild Kobro Runde (Ifi, UiO) Veileder: Ketil Stølen (Ifi/SINTEF) Stuntlunsj SINTEF Oversikt Bakgrunn/utgangspunkt for presentasjonen MDA stuntlunsj

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

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

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

21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA)

21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA) 21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA) Når vi skal lage en OO analysemodell, bruker vi 5 hovedprinsipper: 1. Lag en modell av informasjonsdomenet. 2. Beskriv modul-funksjonene

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

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

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering Use case realisering Designmodellering 31.01.2005 Kirsten Ribu UML-Unified Modeling Language Use Case diagram Klassediagram Oppførselsdiagrammer Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram

Detaljer

Distributed object architecture

Distributed object architecture Forelesning IMT2243 6. April 2010 Tema: forts. arkitektur og design av programvare Prosjektstatus Programvarearkitektur Oppsummering fra før påske Distribuerte objektarkitektur MDA - Model Driven Architecture

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

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

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

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

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO DRI 2001 13.9 : Introduksjon til systemutvikling. Introduksjon til systemutvikling Systemutvikling og nettstedsutvikling Om ulike typer offentlige nettsteder Kvalitetskrav til offentlige nettsteder Litt

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

UML-Unified Modeling Language

UML-Unified Modeling Language UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram

Detaljer

CORBA Component Model (CCM)

CORBA Component Model (CCM) CORBA Component Model (CCM) INF5040 Høst 2005 Erlend Birkedal Jan Erik Johnsen Tore Ottersen Løkkeberg Denne presentasjonen CORBA Svakheter ved CORBA Object Model Komponenter CORBA Component Model Hva

Detaljer

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02 Prosessmodeller og smidig programvareutvikling INF1050: Gjennomgang, uke 02 Kompetansemål Prosessmodeller Kunne redegjøre for hva som kjennetegner ulike prosessmodeller Vurdere prosesser for utvikling

Detaljer

Kravhåndtering. INF1050: Gjennomgang, uke 03

Kravhåndtering. INF1050: Gjennomgang, uke 03 Kravhåndtering INF1050: Gjennomgang, uke 03 Kompetansemål Kravhåndtering Anvende metoder og teknikker for å Innhente / Analysere / Spesifisere krav Ulike typer krav Funksjonelle krav Ikke-funksjonelle

Detaljer

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 21. sept. 05 Informasjonssystem og datasystem Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer og perspektiver for SU-arbeidet

Detaljer

DRI2001 h04 - Forelesning Systemutvikling og nettsteder

DRI2001 h04 - Forelesning Systemutvikling og nettsteder Systemutvikling utvikling av offentlig nettsteder DRI2001 forelesning 20.10 Litt om eksperimentell systemutvikling og prototyping Systemutviklingsprosessene og utvikling av [offentlige] nettsteder Fasene

Detaljer

Grunnleggende testteori

Grunnleggende testteori 1 Grunnleggende testteori Industri - og software produkt Industriprodukt: Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes, og justeres så

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

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

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

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

Detaljer

Grunnleggende testteori

Grunnleggende testteori 1 Grunnleggende testteori Error-Fault-Failure 2 Error : når en programmerer koder feil eller utelater kode (evt. miljøpåvirkning) årsaken til en fault Fault (defect eller bug): feil i kode kan lede til

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

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

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

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

GJENNOMGANG UKESOPPGAVER 9 TESTING

GJENNOMGANG UKESOPPGAVER 9 TESTING GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

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

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning

DRI 2001 Systemutviklingsarbeidet et overblikk Forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 12. sept. 06 Forholdet mellom informasjonssystemet og virkeligheten Hva innebærer utvikling av et IS (systemutvikling: SU) Å utvikle et IS det

Detaljer

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted. Presentasjon nummer 5 The changing system and the nature of maintenance Silde 1 Gruppen introduseres Slide 2 The changing system and the nature of maintenance The Changing system Systemutviklingen er ferdig

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

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Prøveeksamen i: INF1050 Eksamensdag: 0. mai, 2011 Tid for eksamen: 00:00 00:00 Oppgavesettet er på 6 sider Vedlegg:

Detaljer

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12 Løsningsforslag: Oblig 1 INF1050: Gjennomgang, uke 12 Obligatorisk oppgave 1: Pensum Bakgrunn for systemet Aktører og interessenter Utviklingsprosesser Kravhåndtering og kravspesifikasjon Use case-modellering

Detaljer

1. Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid

1. Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Leksjon 01: Introduksjon til faget Prosjektrettet systemarbeid Greta Hjertø og Tore Berg Hansen 30.08.2005 Revidert av Kjell Toft Hansen

Detaljer

STE6221 Sanntidssystemer LØSNINGSFORSLAG TIL EKSAMEN

STE6221 Sanntidssystemer LØSNINGSFORSLAG TIL EKSAMEN HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer LØSNINGSFORSLAG TIL EKSAMEN Tid: Torsdag 09.03.2006, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar

Detaljer

Distributed object architecture

Distributed object architecture Forelesning IMT2243 1. April 2009 Tema: forts. arkitektur og design av programvare Oppsummering fra forrige gang Programvarearkitektur i distribuerte systemer Programvarearkitektur i RUP Eksempler på arkitekturvurderinger

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

DRI2001 forelesning

DRI2001 forelesning Systemutviklingsarbeidet et overblikk DRI2001 forelesning 6.10.04 Hva er systemutvikling (SU) Et enkelt eksempel å bygge et hus Rammer for SU-arbeidet Ulike SU-metoder Perspektiver i SU-arbeidet SU er

Detaljer

Forslag til løsning. Oppgave 1

Forslag til løsning. Oppgave 1 Forslag til løsning Eksamen 2003 Oppgave 1 A) Lag en Business Model (COMET) for krisehåndteringssystemet. B) Diskuter fordeler og ulemper ved bruk av COMET i forhold til (Rational) Unified Process for

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

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

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

prosjektarbeid Forelesning 3 - INF1050 Systemutvikling

prosjektarbeid Forelesning 3 - INF1050 Systemutvikling Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 28.1.2009 Rune Steinberg International Development Manager ERP INF1050 Systemutvikling Vår 2009 - Copyright Rune Steinberg

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

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017

Systemutvikling. Universitetet i Oslo, Institutt for informatikk Vår 2017 Systemutvikling Universitetet i Oslo, Institutt for informatikk Vår 2017 Dagens plan Introduksjon Emnets oppbygging Praktisk om ukesoppgaver og obligatoriske oppgaver Gjennomgang av ukesoppgaver Registrering

Detaljer

Guri Kjørven, ISO 9001:2015 LEDELSESSYSTEMER FOR KVALITET

Guri Kjørven, ISO 9001:2015 LEDELSESSYSTEMER FOR KVALITET Guri Kjørven, 2015-12-02 ISO 9001:2015 LEDELSESSYSTEMER FOR KVALITET ISO 9001 hadde behov for endring for å: tilpasse seg til en verden i endring forbedre en organisasjons evne til å tilfredsstille kundens

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

Konfigurasjonsstyring

Konfigurasjonsstyring INF1050: Systemutvikling 28. mars 2017 Konfigurasjonsstyring Yngve Lindsjørn ynglin@ifi.uio.no INF1050 Systemutvikling ->Konfigurasjonsstyring 1 Temaer i dagens forelesning Versjonshåndtering Systembygging

Detaljer

Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet?

Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet? Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet? HelsIT 2011 Roar Engen Leder for arkitekturseksjonen,teknologi og ehelse, Helse Sør-Øst RHF Medforfatter: Jarle

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

Løsningsforslag Sluttprøve 2015

Løsningsforslag Sluttprøve 2015 Høgskolen i Telemark Løsningsforslag Sluttprøve 2015 Emne: IA4412 Systemutvikling og dokumentasjon Fagansvarlig: Hans- Petter Halvorsen, Olav Dæhli Klasse: IA2, A- vei Dato: 2015.05.27 Time: 09:00-12:00

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

Krav som bør stilles til leverandørens verifikasjon og test

Krav som bør stilles til leverandørens verifikasjon og test Krav som bør stilles til leverandørens verifikasjon og test Av Hans Schaefer Versjon 1.2, 14.9.2005 Dette dokument beskriver krav en bør stille til verifikasjon under utviklingen og test hos en seriøs

Detaljer

prosjektarbeid Forelesning 3 - INF1050 Systemutvikling Eksempel Evolusjonære modeller Utviklingsprosesser Evolusjonære modeller Foranalyse

prosjektarbeid Forelesning 3 - INF1050 Systemutvikling Eksempel Evolusjonære modeller Utviklingsprosesser Evolusjonære modeller Foranalyse Evolusjonære modeller Foranalyse Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 28.1.2009 Rune Steinberg International Development Manager ERP Iterasjonsplan Iterasjon

Detaljer

UKE 11 UML modellering og use case. Gruppetime INF1055

UKE 11 UML modellering og use case. Gruppetime INF1055 UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav

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

1. Modellering av objektorienterte systemer

1. Modellering av objektorienterte systemer Tore Berg Hansen 3.2.2004 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LV339D Objektorientert systemutvikling 1. Resymé: I denne leksjonen skal vi se på hva som genererelt

Detaljer

Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur

Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur 14. juni 2010 Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur Lill Kristoffersen lill.kristoffersen@ssb.no Statistisk sentralbyrå IKT Abstract:

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

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering.

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering. Bakgrunn Modellering har lenge vært et kjent begrep innen systemutvikling. På 80-tallet ble metoder som Yourdon/Demarco og Gane&Sarson brukt for å lage dataflyt-diagrammer. Etter hvert ble disse integrert

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

Validering og verifisering. Kirsten Ribu

Validering og verifisering. Kirsten Ribu Validering og verifisering Kirsten Ribu 2005 1 I dag Validering og verifisering Inspeksjon Testing 2 Noen ord om prosjektet Sjekk kurssidene jevnlig. Endringer forekommer (forelesningsplanen) Hvordan fungerer

Detaljer

OptimalJ-kurs UIO Oppsummering av kurset. De ulike modellene egenskaper og formål

OptimalJ-kurs UIO Oppsummering av kurset. De ulike modellene egenskaper og formål OptimalJ-kurs UIO 2004 Agenda Time 1: Oppsummering av kurset Time 2: De ulike modellene egenskaper og formål Team Development med OptimalJ Domain Patterns Egenutviklede transformasjoner (krever Architect

Detaljer

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0> Gruppenavn Prosjektnavn Beskrivelse av design For Navn på systemet Versjon Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter Innhold 1. Innledning

Detaljer

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven 2015. - Prosessdokumentasjon - Alternativ 1

HiOA TDK. Ingeniørfag data. DATS1600 Programutvikling. Eva Hadler Vihovde. Prosjektoppgaven 2015. - Prosessdokumentasjon - Alternativ 1 HiOA TDK Ingeniørfag data DATS1600 Programutvikling Eva Hadler Vihovde Prosjektoppgaven 2015 - Prosessdokumentasjon - Alternativ 1 - Forsikring - Gruppe #14 Studentnavn Marius Alexander Skjolden Hans Christian

Detaljer

Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 1. feb.2010

Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 1. feb.2010 Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 1. feb.2010 Arne Maus, Ifi med takk til Gerhard Skagstein(Ifi), Rune Steinberg, (Visma), Jo Hannay (Ifi), Ian Sommerville

Detaljer

Neste generasjon ERP-prosjekter

Neste generasjon ERP-prosjekter Neste generasjon ERP-prosjekter Jan-Olav Arnegård 27. okt 2016 Nøkkeltall 2015 22 Land der vi er direkte representert 36 BearingPoint-kontorer 67 Kontorer der vi er representert via vår globale alliansepartnere

Detaljer

Oppgave 1. Finn krav. Finn krav. Finn test

Oppgave 1. Finn krav. Finn krav. Finn test Oppgave 1 1. Hensikten med use case er å oppnå en felles forståelse av krav til systemet mellom brukere / kunder og utviklere. Et use case er et scenario, ikke en komplett, deltaljert kravspesifikasjon.

Detaljer

Brukersentert design Kapittel 3 i Shneiderman

Brukersentert design Kapittel 3 i Shneiderman Brukersentert design Kapittel 3 i Shneiderman ISO 9241-210 Iterativ og brukernær systemutvikling. Kriterier for valg av metode. Brukersentrert design vs. RUP. Deltagende design Den skandinaviske arven.

Detaljer