TDT4140 Systemutvikling Kompendium

Størrelse: px
Begynne med side:

Download "TDT4140 Systemutvikling Kompendium"

Transkript

1 TDT4140 Systemutvikling Kompendium Vegard Aas, 2006 Side 1

2 Innledning Prosesser Veikart for systemutvikling Prosjektegenskaper Prosesser Fossefallmodellen (utvidet) Spiralprosessmodellen Inkrementell prosessmodell Prosessammenligninger Unified Software Development Process (USDP) Dokumentasjon Aktuelle organisasjoner IEEE-standard Kvalitet Kjennetegn på høy kvalitet Metrikker Kvalitetssikringsprosessen IEEE standard for SQAP Prosjektledelse Prosjektledelse Introduksjon Prosjektplanlegging Prosjektledelse Tidsplanlegging Gant-diagram s Personalledelse Risikohåndtering Definering av risiko Risikoanalyse: Braude s Kostnadsestimering Constructive Cost Modell (COCOMO) Funksjonspoeng Use case poeng Software Project Management Plan (SPMP) IEEE SPMP innholdsfortegnelse Kvalitetssikring Typer krav Sjekkpunkter for krav Roadmap til kravanalyse IEEE : Software Requirements Specification Kravbeskrivelse Operasjonskonsept Use cases Dataflytdiagrammer Tilstandsdiagrammer Prototyping Kravanalyse: Utviklerkrav Typer krav Roadmap Typer krav Egenskaper ved D-krav Systemarkitektur Systemutvikling Modeller, rammeverk og design patterns Use Case Diagram Klassediagram (UML) Rammeverk Design patterns Valg av riktig arkitektur Arkitektur, standarder og verktøy Detaljert design Detaljert design Modelleringsteknikker Roadmap for detaljert design Dataflytdiagram Spesifisering av klasser og funksjoner Estimering av størrelse og tid Roadmap Implementasjon Programmering Generelle prinsipper Vurdering av kvalitet Standard metrikk for kildekode Enhetstesting Testing Mål med testing Enhetstesting...25 Side 2

3 8.2 Testtyper Sort-, hvit- og gråbokstesting Grenseanalyser Testdekking Planlegge enhetstesting Plan for enhetstesting Systemintegrasjon, verifisering og validering Integrasjon Testprosedyre ANSI/IEEE 829 Software Test Documentation Testgjennomføring Alpha/betatesting Vedlikehold Introduksjon Typer vedlikehold extreme programming Bakgrunn Prosjektrisiko Prosjektkanselleringer extreme programming Verdier Praksis...29 Side 3

4 Innledning Systemutvikling Fokus Prosessen med å bygge applikasjoner med hensiktsmessig omfang som tilfredsstiller krav til funksjonalitet, brukervennlighet og ytelse 4P: people, process, project, product+ quality Applikasjonstyper Stand-alone: Kjøres på enkelt maskin, ikke koblet til annen hw/sw Integrert Del av unik applikasjon som involverer hw Real time Må kjøre funksjoner på svært kort tidsmargin Nettverkssystemer Deler interagerer over nettverk Side 4

5 1 Prosesser 1.1 Veikart for systemutvikling 1. Forstå problemet og systemet som skal bygges 2. Velg utviklingsprosess og lag en plan - Prosjektstyring: tilgjengelig tid, ressurser og personell - Dokumenthåndtering 3. Samle krav - Kravspesifikasjon og produktbeskrivelse 4. Designe og utvikle produktet - Design - Implementering 5. Test produktet - Enhetstesting: Teser del av systemet, for eksempel en klasse, metode eller funksjon - Integrasjon og systemtesting: Tester systemet som helhet, på tvers av klasser og funksjoner 6. Lever og vedlikehold produktet: Vedlikehold står gjerne for 80 % av kostnadene Prosjektegenskaper 1. Hva slags system som skal utvikles 2. Kundens krav sammenlignet med erfaring fra tidligere prosjekter 3. Kostnadsramme og leveringstid 4. Graden av interaksjon med kunden - Kunden vet hva han vil ha - Kunden har et problem han vil ha løst - Kunden tror han har et problem 5. Kunnskap og erfaring Kunnskap Høy Middels risiko Lav risiko Lav Høy risiko Middels risiko Lav Høy Erfaring 1.2 Prosesser Fossefallmodellen (utvidet) Konseptanalyse Bestemmelse av overordnet funksjonalitet Kravanalyse Kravinnhenting og -dokumentasjon Objektorientert analyse Beskrivelse av klassestruktur Design Beskrivelse av produktets struktur: diagram og tekst Implementering Programmering Enhetstesting Tester hver klasse/funksjon individuelt Integrering Sette sammen deler Systemtesting Tester systemet som helhet Vedlikehold Reparasjon, tilpasninger og modifiseringer Gjerne overlapp mellom delene av prosessen ettersom det ofte er upraktisk å fullføre en del før en begynner på neste Spiralprosessmodellen Kjøres i spiral Kravanalyse, design, implementering og testing Fordeler - Fjerne en del risiko (big bang-implementering) - Kan tidlig bygge delvis modell som kan vises kunden og gi tilbakemelding - Kjørbart system letter integrering - Samle erfaringsdata til senere for hver iterasjon Typisk 2-3 iterasjoner Side 5

6 1.2.3 Inkrementell prosessmodell Forskjeller mot spiral - Hvert inkrement er mye mindre. Inkrementer Stegne i fossefallmodellen repeteres flere ganger helt eller delvis Tidsintervall Hele prosjektet (dokumentasjon, test, kode) oppdateres med jevne mellomrom, for eksempel ukentlig Fordeler - Kontinuerlig testing - Kjørbart system letter integrering Ulemper - Krever mye koordinering Prosessammenligninger Iterative Fossefall Spiral Inkrementell Dokumentkontroll Lett Vanskelig Medium/Vanskelig: Krever konsistente dokumenter i starten Kundeintegrasjon Vanskelig Lett Lett God design Medium/vanskelig Lett Vanskelig Få nok iterasjoner til god design, mange nok til naturlig problemforståelse Samling av Vanskelig Medium/Vanskelig Medium/Vanskelig prosessadata Som oftest er spiralmodellen best for semesterprosjekter (2 iterasjoner) Unified Software Development Process (USDP) I fire faser av prosjektet gjøres det forskjellig antall inkrementer Inception Initial kontaktfase med interessenter: brukere, ledelse, finansielle støttespillere Kan involvere prototyp Elaboration Bestemmelse av funksjonalitet og bekreftelse av arkitektur Construction Utvikling av selve systemet, men ikke helt ferdig Transition Klargjøre system for å slippes Modeller - Use casemodell - Analysemodell - Designmodell - Utviklingsmodell - Implmenteringsmodell - Testmodell 1.3 Dokumentasjon Aktuelle organisasjoner IEEE The International Institute of Electronic and Electrical Engineers ISO The International Standards Organization SEI The Software Engineering Institute OMG The Object Management Group IEEE-standard SVVP Software Verification and Validation Plan Verifikasjon er prosessen som sjekker at en applikasjon er bygd på riktig måte. Validering sjekker om riktig produkt har blitt bygd (løser problemene til kunden). SQAP Software Quality Assurance Plan Side 6

7 Har systemet oppnådd ønskete kvalitetsmål? SCMP SPMP Software Configuration Management Plan Hvor er dokumentasjon og kode lagret og hvordan fungerer de sammen? Versjonskontroll og mulighet for å rulle tilbake Software Project Management Plan SRS SDD STD Software Requirements Specification Krav Software Design Document Arkitektur og design for systemet. For eksempel klassediagrammer og sekvensdiagrammer/dataflytdiagrammer. Software Test Documentation Hvordan systemet skal testes. 1.4 Kvalitet Kjennetegn på høy kvalitet Kode - Tifredsstiller krav - Sjekker input og håndterer feil på en forutsigbar måte - Inspisert og testet av andre enn utvikler - Grundig dokumentert - Feilrate er kjent Applikasjon - Utvidbar (ny funksjonalitet kan legges til) - Fleksibel (kan tilpasses nye krav) - Portabel (kan brukes i ulike miljø) - Generell (kan brukes i ulike situasjoner) Metrikker - Mengde utført arbeid (LOC) - Tidsforbruk - Defektrate (D/KLOC) Kvalitetssikringsprosessen Sortboks Undersøker applikasjonen som enhet; korrekt output for ulik input? Hvitboks Undersøker de enkelte enheter i applikasjonen Inspeksjoner 10-15% av utviklingsbudsjettet - Defect detection only (reparerer ikke feil) - Peer process (sjekker arbeid under prosess) - Specified roles (moderator, author, reader, recorder) -Complete preparation (inspeksjon samme nøyaktighet som forfatteren, tar tid!) IEEE standard for SQAP 1. Hensikt 2. Refererte dokumenter 3. Prosjektledelse 3.1 Organisasjon 3.2 Oppgaver 3.3 Ansvar 4. Dokumentasjon 4.1 Hensikt 4.2 Minimum dokumenteringskrav 4.3 Annet Side 7

8 5. Standarder, praksis, konvensjoner og metrikk 5.1 Hensikt 5.2 Innhold 6. Gjennomgang og revidering 6.1 Hensikt 6.2 Minimumskrav Revidering av programvarekrav Revidering av foreløpig design Revidering av kritisk design Revidering av SVVP Revidering av funksjonelle krav Revidering av fysiske krav Revidering av pågående prosesser Revidering av prosjektledelse Revidering av SCMP Gjennomgang av driftsfase 6.3 Annet Side 8

9 2 Prosjektledelse 2.1 Introduksjon Prosjektplanlegging 1. Forstå prosjektinnholdet, størrelsen og tidsrammen 2. Velg utviklingsprosesser (metoder, verktøy, språk, dokumentasjon) 3. Velg organisasjonsstruktur (organisatoriske elementer involvert) 4. Velg ledelsesprosess (hvem har ansvar for hva) 5. Lag tidsdiagram (når skal ting være ferdig) 6. Lag arbeidsfordeling 7. Begynn risikoplanlegging 8. Velg dokumentasjonsmetoder 9. Begynn prosessen! Prosjektledelse Faktor Lederverktøy Total kostnad Struktur Produkt Administrasjonsprosess: ansvarsfordeling og overoppsyn Kvalitet Utviklingsprosess (metoder, verktøy, språk, dokumentasjon og støtte) Tid Tidsplan Tidsplanlegging Gant-diagram s Indiker fastsatte milepæler 2. Lag interne nødvendige milepæler: sett av tid til oppstart, integrasjon og testing 3. Vis første iterasjon 4. Vis oppgaver som identifiserer og unngår risiko 5. Vis ubrukt tid 6. Fullfør tidsplanen 2.2 Personalledelse Effektiv kommunikasjon Avhenger av antall deltakere, 3-7 er optimalt Antall kommunikasjonslinjer = (n-1)+(n-2) + 1 = n(n-1)/2 Side 9

10 2.3 Risikohåndtering Definering av risiko En risiko er en faktor som kan påvirke prosjektet negativt i stor grad. Typer Kilder Beskrivelse 1. Risiko som kan unngås eller omgås 2. Risiko som ikke kan unngås 1. Manglende engasjement hos toppledelsen 2. Mangel på engasjement fra kunde 3. Misforståtte behov 4. Mangel på involvering fra kunde 5. Klarer ikke å oppfylle brukerens forventninger 6. Endring av omfang og eller målsetninger underveis 7. Mangel på kvalifisert personell 1. Grad av påvirkning 2. Sannsynlighet 3. Kostnadsestimat for å fjerne risikoen Risk retirement Conquest Avoidance Risikoanalyse Risiko Sanns Virkn Kost Proaktive tiltak Reaktive tiltak Prosjektledelse Personellproblemer Ledelsesproblemer Mangel på brukerinvolvering Andre ansatte på stand-by Kontakt med konsulenter Prosjektmedarbeidere inkludert i ledelsesprosess Gi bruker/kunde eierskap. Tidlig involvering, use case Sette inn nye prosjektmedarbeidere Bytte leder Involver kunde Ansvar Systemutvikling Ufullstendige krav Misforståtte krav Endring av krav Manglende kompetanse Vanskelig testing For dårlige utviklingsverktøy Tett samarbeid med bruker Tett samarbeid med bruker Tett samarbeid med bruker Kompetansekartlegging og -utvikling på forhånd Grundig testdokumentasjon Bruk kjente verktøy Spesifisere krav Konkretisere krav Inkludere krav Sette inn nye prosjektmedarbeidere Del opp eller endre tester Bytte verktøy Side 10

11 2.4 Kostnadsestimering - Utvikle estimater på ulike måter, så kombinere resultatene Estimering Walstone & Felix: E = (a + b*kloc c )*(f(x1, X2, Xn) E = 5.2*KLOC 0.91 konstant gir produktivitet i månedsverk/1000 linjer kode X i kostnadsdrivere Constructive Cost Modell (COCOMO) Beregning av innsats og varighet ut fra antall kodelinjer Produktet sammenlignes med tilsvarende for å estimere nødvendig antall kodelinjer. Industristandard konverteringsfaktorer mellom ulike programmeringsspråk. Prosjekttype Beskrivelse a b c d Organisk Lite team med mye erfaring i kjente omgivelser Semidetached Mellomform Embedded Store beskrankninger, for eksempel i maskinvare Personmnd Varighet a * KLOC b c*a d *KLOC bd ) c * personmnd d Side 11

12 2.4.2 Funksjonspoeng 1. Identifiser brukernivåfunksjoner ( hent, vis etc.) 2. Beregn funksjonspoeng for hver funksjon Antall inputtyper I Bare input som krever endring i funksjonalitet regnes Antall outputtyper O Bare output som krever ulike algoritmer eller funksjonalitet regnes Antall spørringer E Hver uavhengige spørring teller som en Antall interne logiske filer L Hver unik gruppe data, kombinasjoner teller ikke Antall grensesnitt F Bruk eller utveksling av data med andre app 3. Multipliser med faktor avhengig av kompleksitet Enkel Medium Kompleks Subtotal Totalt Antall Faktor Antall Faktor Antall Faktor I O E L F Ujusterte funksjonspunkter: UFP = nfi + nfo + nfe + nfl + nff 4. Beregn vekter for 14 generelle karakteristika ved et prosjekt Nr Karakteristikk Vekt 1 Behov for backup/recovery Behov for kommunikasjon Distribuert prosessering Ytelse kritisk Kjør i allerede belastet miljø Behov for samtidighet Flere skjermer for input Hoveddata oppdatert on-line Kompleksitet for in- og output, samt filer Kompleksitet for intern prosessering Kode ment for gjenbruk Konvertering og installering inkludert Flere installasjoner i ulike miljø Bruker skal kunne endre Justerte funksjonspoeng = [ikke-justerte funksjonspoeng] * [0,65+0,01*(generelle karakteristika)] Antall kodelinjer: konverteres ved industristandard. [SPR] estimerer 53 l Javakode/ funksjonspoeng Use case poeng 0. Kravspesifikasjon Lag først en strukturert, tekstlig kravspesifikasjon, med krav nummerert som Ra.y (a:bokstav, y:siffer). Antas laget på forhånd. 1. Grafisk use case-modell Her avbildes aktører som en stilisert person og use cases med ovale rundinger, og med forbindelser (streker/piler) mellom. 2. Tekstlig modell-beskrivelse Gjøres for hver aktør og use case, etter 3. Kategorisering av aktører For hver aktør, kategorisér denne som enkel, gjennomsnittlig eller kompleks: En enkel aktør er et annet system med et definert programmeringsgrensesnitt. En gjennomsnittlig aktør er enten at annet system som kommuniserer via en protokoll, f.eks. TCP/IP, eller en person som kommuniserer via et tekstbasert grensesnitt. Side 12

13 En kompleks aktør er en person som kommuniserer via et grafisk grensesnitt. Tell opp antallet i hver kategori (NAgents_simple, NAgents_average og NAgents_complex, og der summen av disse er antall aktører). Legg inn disse tre tallene i vedlagte regneark. 4. Kategoriser use case som enkle, gjennomsnittlige eller komplekse Avhengig av antall hovedtransaksjoner og transaksjoner i alternativ hendelsesflyt. En transaksjon defineres som en hendelse som forekommer mellom aktør og system. Et enkelt use case har 3 eller færre transaksjoner. Et gjennomsnittlig use case har 4 til 7 transaksjoner. Et komplekst use case har 8 eller flere transaksjoner. Tell opp antall use case i hver kategori (NUsecases_simple, NUsecases_average og NUsecases_complex, og der summen av disse er antall use cases). Legg inn disse tre tallene i vedlagte regneark. 5. Kontekstfaktorer Gi en vurdering av betydningen til hver teknisk faktor (som TRating_i, i=1..13) og betydningen til hver omgivelsesfaktor (som ERating_j, j=1..8), begge etter en skala Se regnearket for karakterisering av disse 21 = 13+8 faktorene. Verdien 0 betyr at faktoren er irrelevant for dette prosjektet, mens 5 betyr at faktoren er av avgjørende betydning. Dvs. at dere må legge inn 21 tallverdier for disse to gruppene av faktorer i regnearket. På forhånd er det i regnearket lagt inn tilsvarende vekter (Tweight_i og Eweight_j), i alt 21 pre-definerte verdier. De samme faktorverdiene og vektene forutsettes å gjelde overalt i et prosjekt for alle dets aktører og use cases. 6. Produktiviteten Anslå EperUCP (timeverk/ use case-poeng ) og legg inn i regnearket. Dette ene tallet vil ligge mellom 15 og 30, ofte satt til 20 som er forhåndssatt i regnearket. Dere kan velge om dere vil bruke dette anslaget, eller sette inn noe annet. 7. Regnearket vil suksessivt beregne følgende størrelser: No. of unadjusted actor weights, UAW = NAgents_simple*1 + NAgents_average*2 + NAgents_complex*3 % Her er 1,2,3 vekter for agentene No. of unadjusted use case weights, UUCP = NUsecases_simple*5 + NUsecases_average*10 + NUsecases_complex*15 % Tilsvarende er 5,10,15 vekter for use cases No. of unadjusted use case points, UUCP = UAW + UUCW Sum Technical Factors, TFactor = Sum,i=1..13 (TWeight_i * TRating_i) Sum Environment Factors, EFactor = Sum,j=1..8 (EWeight_j * ERating_j) Technical Complexity Factor, TCF = (0.1*TFactor) % Merk magiske koeffisienter Environment Complexity Factor, ECF = (-0.03*EFactor) % Tilsvarende Adjusted use case points, UCP = UUCP * TCF * ECF Staff-hours (effort) per entire use case diagram = UCP * EperUCP % Her er EperUCP er , ofte 20. Registrér forbrukte timeverk per use case, dvs. lag en tabell/regneark for: <Aktivitet use case person-navn timeverk> Dvs. at dere for hver livsfase-aktivitet (konstruksjon, implementasjon) må registerere timeverk litt mer detaljert. Timeverk for et helt use case-diagram summeres så opp. Side 13

14 Enter values in this column Actors Weight Factors Description Weight Enter NActors_i Weighted Value Comment Simple_Actor Program interface Average_Actor Interactive or protocol driven interface Complex_Actor Graphical interface Total Actor Weight 9 Use Cases Weight Factors (Bases on the number of transactions in a use case) Weight Enter NUsecases_i Weighted Value Comment Simple_Use_Case 3 or fewer transactions Average_Use_Case 4 to 7 transactions Complex_Use_Case more than 7 transactions Transaction Based Factors 115 Unadjusted Use Case Points 124 Technical Weight Factors Rating Scale is 0 to 5 TWeight_i Enter TRating_i Weighted Value Reason T1 Distributed System 0 =not important 5 =essential T2 Response or throughput performance objectives 0 =not important 5 =essential T3 End-user efficiency (online) 0 =not important 5 =essential T4 Complex internal processing 0 =not important 5 =essential T5 Code must be reusable 0 =not important 5 =essential T6 Easy to install 0 =not important 5 =essential 0,5 3 1,5 T7 Easy to use 0 =not important 5 =essential 0,5 3 1,5 T8 Portable 0 =not important 5 =essential T9 Easy to change 0 =not important 5 =essential T10 Concurrent 0 =not important 5 =essential T11 Includes special security features 0 =not important 5 =essential T12 Provides direct access for third parties 0 =not important 5 =essential T13 Special user training facilities are required 0 =not important 5 =essential TFactor TFactor 42 Technical Factor (TCF).6 + (.01*TFactor) 1,02 Environmental Factors for Team and Weights Rating Scale is 0 to 5 EWeight_j Enter ERating_j Weighted Value Reason Experience Stability F1 Faimilar with the Rational Unified Process 0 = no experience, 3=average, 5=expert 1,5 3 4,5 0 F2 Application experience 0 = no experience, 3=average, 5=expert 0,5 3 1,5 1 F3 Object-Oriented Experience 0 = no experience, 3=average, 5=expert F4 Lead analyst capability 0 = no experience, 3=average, 5=expert 0,5 3 1,5 1 F5 Motivation 0=no motivation, 3=average, 5=high F6 Stable requirements 0=extremly unstable, 5=unchanging F7 Part-time workers 0=no part time, 5=all part time F8 Difficult programming language 0=easy language, 3=average,5=difficult EFactor EFactor 13,5 2 Environmental Factor (EF) 1.4+(-0.03*EFactor) 0,995 Use Case Points UUCP 125,8476 Person-hours per use case point EperUUCP 20 Estimated person-hours in project Effort in person-hours 2516,952 Side 14

15 2.5 Software Project Management Plan (SPMP) IEEE SPMP innholdsfortegnelse 1. Introduksjon 1.1 Prosjektoversikt 1.2 Prosjektleveranser 1.3 Videreutvikling av SPMP 1.4 Referansemateriale 1.5 Definisjoner og forkortelser 2. Prosjektorganisering 2.1 Prosessmodell 2.2 Organisasjonsstruktur 2.3 Organisasjonens begrensninger og grensesnitt 2.4 Prosjektansvar 3. Ledelsesprosess 3.1 Ledelsesmål og prioriteringer 3.2 Antakelser, avhengigheter og begrensninger 3.3 Risikohåndtering 3.4 Monitorering og kontrollmekanismer 3.5 Arbeidsplaner 4. Teknisk prosess 4.1 Metoder, verktøy og teknikker 4.2 Software dokumentasjon 4.3 Prosjektstøtte 5. Arbeidspakker, tidsplan og budsjett 5.1 Arbeidspakker 5.2 Avhengigheter 5.3 Ressursbehov 5.4 Budsjett og ressursallokering 5.5 Tidsplan 2.6 Kvalitetssikring Mål av effektivitet gjøres via prosessmetrikk: 1. Antall feil pr KLOC 2. Varians i tidsplan for hver fase: (Faktisk varighet prosjektert varighet)/prosjektert varighet 3. Varians i kostnad (Faktisk kostnad prosjektert kostnad)/prosjektert kostnad 4. Total designtid/total programmeringstid (bør være minst 50 %) 5. Feilinnsetting og -detektering pr fase Side 15

16 3 Kravanalyse: Kundekrav ganger dyrere å reparere feil i krav - Brukere har ofte svært uklare behov - Motstridende krav fra ulike interessenter 3.1 Typer krav C-krav Kundekrav: kundens ønsker og behov formulert slik at han forstår det - introduksjon - generell beskrivelse D-krav Utviklerkrav: strukturert systemspesifikasjon Sjekkpunkter for krav - uttrykt klart og tydelig - lett tilgjengelig - nummerert - koblet til en test som verifiserer - tatt høyde for i designet - tatt høyde for i koden - testet separat - testet sammen med andre - validert ved systemtest Roadmap til kravanalyse 1. Bli kjent med kunden 2. Intervju kunderepresentanter a. hva ønsker kunden b. tegn, skisser, forklar slik at kunden kan fortelle om du har forstått riktig 3. Skriv C-krav 4. Inspiser C-krav (gå til punkt 2 om nødvendig, kunder vet ofte ikke i starten av et prosjekt hva de trenger og vil ha) 5. Skriv D-krav IEEE : Software Requirements Specification 1. Introduksjon 1.1 Hensikt 1.2 Omfang 1.3 Definisjoner, forkortelser 1.4 Referanser 1.5 Oversikt 2. Overordnet beskrivelse 2.1 Produktperspektiv Systemgrensesnitt Brukergrensesnitt Maskinvaregrensesnitt Programvaregrensesnitt Kommunikasjonsgrensesnitt Minnebegrensninger Operasjoner Stedstilpasningsbehov 2.2 Produktfunksjoner 2.3 Brukerkarakteristikk 2.4 Begrensninger 2.5 Forutsetninger og avhengigheter Side 16

17 2.6 Kravfordeling 3. Spesifikke krav (kapittel 4) 4. Støtteinformasjon (kapittel 4) 3.2 Kravbeskrivelse Operasjonskonsept Kundens imaginære modell for hvordan applikasjonen vil fungere Use cases Grafisk beskrivelse av interaksjon mellom aktør og applikasjon Forholdet til andre kan være sekvensiell eller ortogonal (annet synspunkt) Et use case er et sett av scenarier satt sammen for å utføre brukerens mål. Scenario Aktør Tekstlig En sekvens av steg som beskriver interaksjonen mellom bruker og system En aktør kan utføre mange use cases, men et use case kan også bli utført av mange aktører. En aktør trenger ikke være et menneske, men kan være en webbrowser/ bankautomat/printer Skrive ned hovedscenariet som en sekvens av nummererte steg.kan skrive andre scenarier og bruke dem som extensions, hvor de fungerer somvariasjoner/avvik (f.eks. bruker er ikke innlogget, be om brukernavn og passord). Use Case <navn> Aktør <navn> Trigger <Hendelse som starter use caset> Pre-betingelser <Betingelser som må være oppfylt for at use caset skal kunne utføres> Post-betingelser <Betingelser som er oppfylt når use caset avsluttes> Normal hendelsesflyt <En liste av transaksjoner som utføres i en normal gjennomgang av use caset> Variasjoner <En liste med beskrivelser av mulige transaksjonsvariasjoner til den normale flyten i use caset> Relatert informasjon Diagram Disse skal bare være skisser, ikke legg for mye arbeid i dem.viktigere å legge vekt på tekstlig use case.skal vise hvilke aktører som kan kjøre hvilke use cases.viser også hvilke use cases som inkluderer andre use cases. Include Include peker på en use case som brukes av en eller flere andre use cases. For eksempel i en bank kan man spørre om boliglån. Denne use casen inkluderer kredittvurdering for å sjekke vedkommendes økonomi. Om personen kommer tilbake senere og skal ha billån eller opprette aksjeselskap vil også kredittvurdering kjøres. Kredittvurderingen er den samme uansett, men prosessen med å søke billån, boliglån Side 17

18 eller opprette aksjeselskap/søke lån er forskjellig. Disse use casene inkluderer altså det som er felles for dem. Finn produkt Finner ikke produkt Finn kundekrav Finner ikke krav Legg inn test Dataflytdiagrammer Beskriver overordnet dataflyt mellom sentrale prosesseringsenheter (sirkler), eksterne entiteter (firkanter) og datalager (strek over og under) Tilstandsdiagrammer Prototyping Raskt laget prototyp/modell er en bra måte å få reaksjoner/tilbakemeldinger frakunden på. Dermed kan man identifisere risikable deler av prosjektet, og prøve unngå disse. Å øke forståelsen kan spare mye arbeid! En prototyp står som regel bare av en enkel GUI, og lite kode under panseret. Hvis det er lav kostnad ved å lage en prototyp, og høy verdi for å lage en/mottatilbakemeldinger, er det absolutt lønnsomt. Se s. 162 for graf. Kostnadsestimater kan utbedres når c-kravene har blitt analysert. Side 18

19 4 Kravanalyse: Utviklerkrav Spesifikke, nummererte, testbare og sporbare og navngitte krav for applikasjonsutvikling 4.2 Typer krav Roadmap 1. Velg organisering for D-kravene 2. Lag sekvensdiagrammer for use casene 3. Lag D-krav ut fra C-krav - Lag testplaner - Inspiser 4. Valider mot kunden (tilbake til punkt 3 om kunden har ting å tilføye) 5. Release Typer krav 1. Funksjonelle krav 2. Ikke-funksjonelle krav 2.1 Ytelse - Hastighet - Kapasitet (trafikk) - Minnebruk 2.2 Pålitelighet og tilgjengelighet 2.3 Feilhåndtering og forutsigbarhet 2.4 Grensesnitt 2.5 Begrensninger - Nøyaktighet - Verktøy- og språkbegrensninger - Designbegrensninger - Standarder som må brukes - Maskinvareplattform 3. Inverse krav (hva kan applikasjonen ikke gjøre) Egenskaper ved D-krav Sporbarhet Hvilken kode som realiserer hvilke krav Sporingsmatrise Krav Modul 1 Modul 2 Modul 3 Id funksjon funksjon funksjon id funksjon funksjon funksjon Ikke-funksjonelle krav spores vha testplan Testbarhet Validering omfatter å teste at applikasjonen/funksjonene gjør det de skal Prioritet Essential absolutt nødvendig krav Desiarable ønsket, men ikke nødvendig Optional valgfritt, om nok tid Fullstendighet Konsistens Ingen selvmotsigelser innad i kravene Side 19

20 5 Systemarkitektur 5.1 Systemutvikling Systemutvikling Design- og analyseprosess som dekomponerer en applikasjon til software og hardware. Systemarkitektur Kohesjon (maks) Kobling (min) Overordnet design, for eksempel oppdeling i moduler Dekomponerer for å minske kompleksitet Arkitekturmål: - Utvidelse - Endring - Enkelhet - Effektivitet intern kommunikasjon innen en modul ekstern kommunikasjon med andre moduler (reduserer med fasader) 5.2 Modeller, rammeverk og design patterns Use Case Diagram Samling av use-cases som beskriver overordnet hva applikasjonen skal gjøre. Videreutvikles til sekvensdiagrammer, som er D-krav Klassediagram (UML) Objektmodeller med oversikter og klasser, deres attributter, metoder og relasjoner Rammeverk En samling av klasser som er nyttige for flere applikasjoner. Java API har en del nyttige frameworks, som f.eks. awt, swing osv. Et framework må inkluderes i en annen klasse for å kunne brukes. Framework layer Ligger øverst og inneholder frameworks Generelle klasser Application layer Bruker/inkluderer framework Høy kohesjon fås her ved å gruppere ting som hører logisk sammen, og holde ting som ikke hører sammen fra hverandre. Mer om systemarkitekturer s Design patterns Kombinasjon av komponenter (klaser og objekter) som løser felles designproblemer Strukturelle Representerer samlinger av objekter: trær, lenkede lister Opprettelse Laging av komplekse objekter som trær og lenkede lister Funksjonelle Håndterer oppførsel Pattern Fasade Tilstand Observer Iterator Oversetter Model View Controller Pipe and filter Funksjonalitet Tilby en interface for en samling av objekter fra forskjellige klasser Forsikre om at et objekt oppfører seg etter en innehavende tilstand Gi respons fra interessante entiteter når de endres i kilden/databasen, bruker notify() og update() Måter å besøke objekter i en samling Oversetter utsagn skrevet i formell grammatikk Skiller datamodell, presentasjon og nødvendig logikk Dataflytarkitektur hvor prosesseringselementene tar inn datastrøm og produserer output strømmer ved filtrering Side 20

21 Klient-tjener Parallellprosessering Virtuell maskin Dataarkitektur Server betjener behov fra klient på forespørsel. Lav kobling, smalt grensesnitt, ofte i ulike tilstander Applikasjon behandles som et program skrevet i et spesialisert språk Gir enhetlig presentasjon av data - Database - Blackboard - Hypertekst Valg av riktig arkitektur 1. Dekomponer til mindre moduler 2. Sammenlign med standardarkitekturer 3. Velg blant arkitekturene 4. Legg til klasser fra kravanalysen 5. Benytt et eksisterende framework/design pattern 6. Del opp i pakker (med 4-8 klasser) 7. Sjekk at det er høy kohesjon og lav kobling 8. Vurder bruk av fasade Arkitektur, standarder og verktøy Notasjon UML, ER Verktøy Computer-aided software engineering (CASE) Interactive development environments (IDE) Side 21

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

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

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

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

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

Eksamen i fag TDT4140 Systemutvikling. 8. juni, 2007 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 8. juni, 2007 kl 0900-1300 Side 1 av 15 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 29. juni, 2007 Eksamen

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

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

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

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

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

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

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

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

Use case drevet design med UML

Use case drevet design med UML Use case drevet design med UML Bente Anda 26.09.2005 23.09.04 INF3120 1 I dag Domenemodeller System sekvensdiagrammer Operasjonskontrakter GRASP patterns Designmodeller med sekvens- og klassediagram 26.09.05

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

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

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

Måling Hvordan ta beslutninger Estimeringsteknikker

Måling Hvordan ta beslutninger Estimeringsteknikker Tradisjonelle estimeringsmetoder Estimering med use case modeller Måling Hvordan ta beslutninger Estimeringsteknikker Ekspertestimering, estimering ved analogi, estimering ved bruk av algoritmer Kirsten

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

Tom Røise 18. Februar 2009

Tom Røise 18. Februar 2009 Forelesning IMT2243 18. Februar 2009 Tema : Kravspesifisering : litt mer om prosessen Viewpoint en myk tilnærming Use Case en scenariebasert teknikk innen metoden Objektorientert Analyse brukes til å avklare

Detaljer

Metrikker og målte størrelser. Vi måler fakta for å bestemme systemets egenskaper

Metrikker og målte størrelser. Vi måler fakta for å bestemme systemets egenskaper Metrikker og målte størrelser Vi måler fakta for å bestemme systemets egenskaper Hva vil vi vite? Hvor stort er programmet? Hvor godt er programmet? Hvor lett er det å vedlikeholde? Hvor mange feil er

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

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

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse IMT2243 Systemutvikling 26. februar 2007 Tema : Domenemodellering og Kravspeken - Repetisjon konseptuelle klassediagram - Eksempler - konseptuelle klassediagram (IHID løsningen og OL-Veiviseren) - Maler

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

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

ISTQB Foundation Level Prøveeksamen

ISTQB Foundation Level Prøveeksamen ISTQB Foundation Level Prøveeksamen Svar på følgende spørsmål For hvert spørsmål er der ETT og BARE ETT rett svar! (Unntak er avmerket spesielt). Spørsmål til Kap 1 ("Fundamentals") 1.1. (K2) Hva er betydningen

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

Kap. 10 Systemutvikling System Engineering

Kap. 10 Systemutvikling System Engineering Kap. 10 Systemutvikling System Engineering - Utvikling og integrering av både maskin- og programvare. - Hvordan oppstår behov for programvare? - Hvordan inngår programvare i en sammenheng med andre (del)systemer,

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

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

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

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

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

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

Arkitektur. Kirsten Ribu Høgskolen i Oslo 10.02.04 10.02.2004 1

Arkitektur. Kirsten Ribu Høgskolen i Oslo 10.02.04 10.02.2004 1 Arkitektur Kirsten Ribu Høgskolen i Oslo 10.02.04 10.02.2004 1 I dag Generelt om arkitektur N-lags arkitektur MVC Model View Controller mønsteret 10.02.2004 2 Hva er arkitektur? Oppdelingen av et system

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

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering 1 2 Læringsmål og pensum TDT4110 Informasjonsteknologi grunnkurs: Uke 38 Utvikling av informasjonssystemer Læringsmål Kunne seks faser for systemanalyse og design Kunne femstegs prosedyre for programmering

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300 Side 1 av 11 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 15. juni, 2008 Eksamen

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

Testbilag til IT kontrakter

Testbilag til IT kontrakter Testbilag til IT kontrakter Grunner til å lage dette testbilaget Unngår å diskutere de samme problemstillingene i hver kontrakt testfaglige selvfølgeligheter blir landet av testfaglig personell en gang

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

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler?

Kvalitet og programvare. Når bare det beste er godt nok. Produktet prosessen eller begge deler? Kvalitet og programvare Når bare det beste er godt nok. Produktet prosessen eller begge deler? To nøtter Hva forbinder du med et IT-system som har (høy) kvalitet? Formuler 3 kriterier for (høy) kvalitet

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

INF5120 - Oblig 2. Hour Registration System (HRS)

INF5120 - Oblig 2. Hour Registration System (HRS) INF5120 - Oblig 2 Hour Registration System (HRS) 1 av 40 1 Innholdsfortegnelse 1 Innholdsfortegnelse... 2 2 Innholdsfortegnelse for figurer... 3 3 Hour Registration System (HRS)... 4 3.1 Introduksjon...

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

Hvordan komme i gang med ArchiMate? Det første modelleringsspråket som gjør TOGAF Praktisk

Hvordan komme i gang med ArchiMate? Det første modelleringsspråket som gjør TOGAF Praktisk Hvordan komme i gang med ArchiMate? Det første modelleringsspråket som gjør TOGAF Praktisk Logica 2012. All rights reserved No. 3 Logica 2012. All rights reserved No. 4 Logica 2012. All rights reserved

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

STE6221 Sanntidssystemer Løsningsforslag

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

Detaljer

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere

Statisk testing. Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Statisk testing Testing uten datamaskin, men med vår egen evne til å vurdere og analysere Hva er statisk testing Analyser som utføres på skrevne dokumenter Hensikten er å finne avvik fra spesifikasjonene

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300 Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 27. juni, 2006 Eksamen

Detaljer

Technical Integration Architecture Teknisk integrasjonsarkitektur

Technical Integration Architecture Teknisk integrasjonsarkitektur Kap. 6 Technical Integration Architecture Studentpresentasjon av Cato Haukeland Oversikt Introduksjon -spesifikasjon Krav Beskrivelse Servicenivå Sikkerhet Plan Best practices Introduksjon Masterdokument

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

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

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

Spesifikasjon av Lag emne

Spesifikasjon av Lag emne Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Detaljer

INF 5120 Obligatorisk oppgave Nr 2

INF 5120 Obligatorisk oppgave Nr 2 INF 5120 Obligatorisk oppgave Nr 2 Vigdis Bye Kampenes Stein Grimstad Gruppe 26 INF 5120 Obligatorisk oppgave Nr 2... 1 1 Business model... 2 Innledende kommentarer... 2 Andre avgrensninger... 2 Scoping

Detaljer

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen.

Innholdsfortegnelse: Resymé: Denne leksjon gir en kort og enkelt oversikt over hvilke oppgaver som skal utføres i design- og programmeringsfasen. Kort innføring i design og programmeringsfasen Jarle Larsen/Tore Berg Hansen 2.11.04 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for faget LO314 Prosjektrettet systemarbeid Resymé:

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

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

Sikkerhet, risikoanalyse og testing: Begrepsmessig avklaring

Sikkerhet, risikoanalyse og testing: Begrepsmessig avklaring Sikkerhet, risikoanalyse og testing: Begrepsmessig avklaring Seminar om risikoanalyse og testing innen sikkerhet Bjørnar Solhaug SINTEF, 11. juni, 2013 Technology for a better society 1 Oversikt Risikoanalyse

Detaljer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer Fra krav til objekter Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050--1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use

Detaljer

TDT4735 Systemutvikling, fordypning. Metoder for systemtest av websystemer

TDT4735 Systemutvikling, fordypning. Metoder for systemtest av websystemer TDT4735 Systemutvikling, fordypning Metoder for systemtest av websystemer Hong Trang Thi Nguyen Veileder: Tor Stålhane Høst 20-12-2005 Norges teknisk-naturvitenskapelige universitet Forord Dette prosjektet

Detaljer

=Systemutviklingsprosjekt - WATCH - Gruppe 208=

=Systemutviklingsprosjekt - WATCH - Gruppe 208= =Systemutviklingsprosjekt - WATCH - Gruppe 208= 5 personer 5 laptops /m java lunsjpenger -Ressurser- -Arbeidsoppdeling- Hva Timer Ansvar Lete frem relevant informasjon fra uoversiktlig og spredd informasjon

Detaljer

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

Detaljer

20.01.2012. Brukerkrav og use case diagrammer og -tekst 19. januar 2012. Agenda. Brukerkrav og use case. Diagrammer Tekst.

20.01.2012. Brukerkrav og use case diagrammer og -tekst 19. januar 2012. Agenda. Brukerkrav og use case. Diagrammer Tekst. Brukerkrav og use case diagrammer og -tekst 19. januar 2012 Agenda Brukerkrav og use case Diagrammer Tekst Praktisk eksempel 1 OOAD i livsløpsperspektiv Krav Design Konstruksjon Her er vi i nå Testing

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

Kjørehjelperen Testdokumentasjon

Kjørehjelperen Testdokumentasjon 2013 Kjørehjelperen Testdokumentasjon Høgskolen i Oslo og Akershus Henrik Hermansen og Lars Smeby Gruppe 8 26.05.2013 Forord Dette dokumentet tar for seg to forskjellige ting. Først forklares det hvordan

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

19. januar 2012 Noen punkter fra i går

19. januar 2012 Noen punkter fra i går 1 19. januar 2012 Noen punkter fra i går Godkjente øvinger og prosjekt er obligatorisk for å få gå opp til eksamen Noen myter om systemutvikling Ariane 5 ulykken 2 Noen myter om systemutvikling Myte 1:

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

I dag Prosjektstyring og prosjektgjennomføring

I dag Prosjektstyring og prosjektgjennomføring I dag Prosjektstyring og prosjektgjennomføring Prosesser, tidsplanlegging, risikostyring Kirsten Ribu 28.01.2004 Prosessmodeller og prosjekter Prosjektplanlegging, inkl. tidsplanlegging Risikostyring Gurholt

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

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

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen

Agenda. TDT4140: Kravinnhenting. Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav. Den organisatoriske dimensjonen TDT4140: Kravinnhenting Torbjørn Skramstad IDI / NTNU Introduksjon til objektorientert design Agenda Kravprosessen Forståelsesproblemet Teknikker for innhenting av krav Intervju Scenarier Etnografi Eksempel

Detaljer

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon 24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Forprosjektrapport Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes

Detaljer

En kravspesifikasjon skal være så konkret og detaljert at det er mulig å teste det ferdige produkt/system opp mot store deler av denne.

En kravspesifikasjon skal være så konkret og detaljert at det er mulig å teste det ferdige produkt/system opp mot store deler av denne. A KRAVSPESIFIKASJON Dette notat er en generell beskrivelse av en kravspesifikasjon for et (teknisk) datasystem. Den er basert på «The STARTS Purchasers Handbook» kap.4 og Appendix B, oversatt til norsk

Detaljer

JigZaw. Teststategi utviklet av. Erik Drolshammer Bård Lind. Verifiser Forventet Funksjonalitet

JigZaw. Teststategi utviklet av. Erik Drolshammer Bård Lind. Verifiser Forventet Funksjonalitet JigZaw Verifiser Forventet Funksjonalitet Teststategi utviklet av Erik Drolshammer Bård Lind Bård Lind Java siden 1997 Arkitekt siden 2000 JavaBin siden 1999 Enterprise Domain Repository og JigZaw-teststrategi

Detaljer

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse

Tom Røise 2/28/2007. IMT2243 : Systemutvikling 1. Forelesning IMT2243 1. mars 2007. Tema : Litteratur : Strukturert analyse. Strukturert analyse Forelesning IMT2243 1. mars 2007 Tema : Litteratur : Art.saml. Punkt 9 : Kap. 9. SASD - modellen, E. Andersen Metoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller /beskrivelser

Detaljer

Repetisjon om evaluering av It-systemer. Hvordan vurdere og verdsette?

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

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

Programvareutvikling hos Sun Microsystems. Jørgen Austvik Sun Microsystems Database Technology Group

Programvareutvikling hos Sun Microsystems. Jørgen Austvik Sun Microsystems Database Technology Group Programvareutvikling hos Sun Microsystems Jørgen Austvik Sun Microsystems Database Technology Group Innhold Sun i Trondheim Hva vi lager Utviklingsprosesser Kvalitetsarbeid > Mål > Hva vi gjør Verktøy

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

Fellesprosjektet Gruppe 205

Fellesprosjektet Gruppe 205 Fellesprosjektet Gruppe 205 Lars Kirkholt Melhus, Morten Gjendemsjø, Stian Pedersen, Andreas H. Ulltveit-Moe og Fredrik Hvaring. Innholdsfortegnelse Fellesprosjektet: Watch... 1 Innholdsfortegnelse...

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

Mangelen på Internett adresser.

Mangelen på Internett adresser. 1. Av 2 Introduksjon og forord Internett er som kjent bygd opp i adresser, akkurat som husstander, byer og land, dette er fordi Internett er bygd opp mye likt post systemet, du kan sammenligne en maskin

Detaljer

Suksessfaktorer for styring av prosjekt

Suksessfaktorer for styring av prosjekt Suksessfaktorer for styring av prosjekt B2G utviklingscamp 20. oktober Erik Aursnes Dammen Metier i dag Forretningsidè: Vi forbedrer våre kunders forretningsmessige mål gjennom riktige og effektive prosjekter

Detaljer

LocalBank Prosjektbeskrivelse

LocalBank Prosjektbeskrivelse LocalBank Prosjektbeskrivelse INNHOLD MÅL... 2 STRUKTUR... 2 IMPLEMENTASJON AV ILOCALBANKREPOSITORY... 3 GUI... 4 EXCEPTION... 4 KODE... 4 NOEN KLASSER OG SPESIELLE EMNER SOM DE VISER... 5 KLASSE DIAGRAMMER...

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

AP221 Use Case - TUL - Utarbeid prosessflytmal og komponenter

AP221 Use Case - TUL - Utarbeid prosessflytmal og komponenter AP221 Use Case - TUL - Utarbeid komponenter Utarbeid komponenter En tjeneste i Sluttbrukerløsningen har en arbeidsflyt som bestemmer de forskjellige stegene som må gjennomføres i skjemainnsendingen. Disse

Detaljer

SPPR Software Project Progress Report Uke 44-45-46

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

Detaljer

Hva kreves av en god byggherre? «Store utbyggingsprosjekter», 23. okt 2014

Hva kreves av en god byggherre? «Store utbyggingsprosjekter», 23. okt 2014 Hva kreves av en god byggherre? «Store utbyggingsprosjekter», 23. okt 2014 Paul Torgersen Leder Metier Consulting 20. oktober 2014 Side 2 Innhold Hva er prosjektsuksess? Hva kjennetegner de beste? Mine

Detaljer

Vedlegg Side 83 av 155

Vedlegg Side 83 av 155 4 Side 83 av 155 Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon...

Detaljer

Læringsmål for forelesningen

Læringsmål for forelesningen Læringsmål for forelesningen Objektorientering Delegeringsteknikken Delegering vs. arv 1 Dagens forelesning Introduksjon og motivasjon Hvorfor forelese om standardteknikker, såkalte patterns? Hva slags

Detaljer

TDT4100 Objektorientert programmering

TDT4100 Objektorientert programmering Eksamensoppgave i TDT4100 Objektorientert programmering Tirsdag 2. juni 2009, kl. 09:00-13:00 Oppgaven er utarbeidet av faglærer Hallvard Trætteberg og kvalitetssikrer Trond Aalberg. Kontaktperson under

Detaljer

Oblig2 i INF5120 Modellering med objekter UiO V04, Timelisteføringssystem Ver 6. 040428

Oblig2 i INF5120 Modellering med objekter UiO V04, Timelisteføringssystem Ver 6. 040428 Oblig2 i INF5120 Modellering med objekter UiO V04, Timelisteføringssystem Ver 6. 040428 Gruppe 1: Fredrik Melsom Klausen, Andreas Limyr, Odd-Wiking Rahlff, Tho Diu Tang 1...1 2. BUSINESS MODEL...2 2.1

Detaljer