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

Fellesprosjekt: gruppe 214

Fellesprosjekt: gruppe 214 Fellesprosjekt: gruppe 214 Innholdsliste Use case diagrammer...3 Scenario 1 - Registrere prosjekt...3 Scenario 2 - Registrere erfaringer...4 Scenario 3, 4, 5 - Lese og kommentere erfaringer...5 Klassediagram...6

Detaljer

Use case modellering

Use case modellering Use case modellering Metode for å identifisere og beskrive de funksjonelle kravene til et system. Bente Anda 21.09.2004 1 Modellering i INF3120 Fordypning i objekt-orientert analyse og design Bygger på

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

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

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

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

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

Estimeringsmetoder. I dag. Kostnadsestimering. Kostnader og prisfastsettelse. Ulike estimeringsmetoder. Måling av programvare. Estimeringsteknikker

Estimeringsmetoder. I dag. Kostnadsestimering. Kostnader og prisfastsettelse. Ulike estimeringsmetoder. Måling av programvare. Estimeringsteknikker Estimeringsmetoder. Kirsten Ribu I dag Estimeringsteknikker Ekspertestimering, estimering ved analogi, estimering ved bruk av algoritmer Prosjektplanen med akrivitetetsdiagram HiO - Kirsten Ribu 2005 1

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

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

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

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

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. Thomas Lohne Aanes Thomas Amble

Oppsummering. Thomas Lohne Aanes Thomas Amble Oppsummering Thomas Lohne Aanes Thomas Amble 14.11.04 Kapittel 2: Data Modell Mål: Data som skal brukes av applikasjonen blir spesifisert på en formell og likevel intuitiv måte. Resultat: Vi får et konseptuelt

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

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

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

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller UML- Use case drevet analyse og design Bente Anda 23.09.2004 23.09.04 INF320 I dag Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller 23.09.04 INF320

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

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

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

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

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn INF1050: Systemutvikling 07. februar 2017 Modellering av krav Førstelektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering av

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

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

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11 Konfigurasjonsstyring INF1050: Gjennomgang, uke 11 Kompetansemål Konfigurasjonsstyring Hva og hvorfor? I en smidig sammenheng Endringshåndtering Versjonhåndtering Systembygging Release -håndtering Del

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

Unified Modeling Language (UML) Kravspesifikasjon med UML use case modellering. UML diagrammer. Notasjon som støtter opp under modellbasert

Unified Modeling Language (UML) Kravspesifikasjon med UML use case modellering. UML diagrammer. Notasjon som støtter opp under modellbasert 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

Kravspesifikasjon med. UML diagrammer. systemutvikling. Dokumentasjon av systemets krav, arkitektur, design og implementasjon

Kravspesifikasjon med. UML diagrammer. systemutvikling. Dokumentasjon av systemets krav, arkitektur, design og implementasjon Kravspesifikasjon med UML use case modellering Erik Arisholm 01.03.2010 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

Detaljer

UNIVERSITETET I OSLO

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

Detaljer

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

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

Kravspesifikasjon med. Erik Arisholm

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

Detaljer

Use Case-modellering. INF1050: Gjennomgang, uke 04

Use Case-modellering. INF1050: Gjennomgang, uke 04 Use Case-modellering INF1050: Gjennomgang, uke 04 Kompetansemål Modellering av krav Kunne modellere ulike typer krav UML-diagrammer Innføring i grunnleggende UML-modellering Bruksmønster (use case) Sekvensdiagram

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

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

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

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

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

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

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

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

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

Inf1055 Modul B 26 april 2017:

Inf1055 Modul B 26 april 2017: Inf1055 Modul B 26 april 2017: Del 1: - Testing Yngve Lindsjørn ynglin@ifi.uio.no 1 Oversikt - Testing Hva er testing? Validering &Verifisering Testfaser Enhetstesting Integrasjonstesting Systemtesting

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

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

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

Innholdsfortegnelse. 1. Testing Feiltesting av koden Funksjonstesting: Kilder.10

Innholdsfortegnelse. 1. Testing Feiltesting av koden Funksjonstesting: Kilder.10 1 Innholdsfortegnelse 1. Testing... 3 1.1 Feiltesting av koden... 3 1.2 Funksjonstesting:... 7 2. Kilder.10 2 1. Testing Testing av et system er nødvendig for å finne ut om systemet fungere slik det skal

Detaljer

Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte

Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte Universitetet i Oslo Institutt for informatikk Eskild Busch UML hefte 6. desember 2000 Innhold Dette heftet tar for seg deler av UML som er sentralt i kurset IN29. Use case-, sekvens-, tilstand- og klassediagrammer,

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

Kirsten Ribu

Kirsten Ribu Validering og verifisering Kirsten Ribu 03.03.04 1 I dag Validering og verifisering Prototyping Inspeksjon Testing 2 Validering og verifisering Å sørge for at et datasystem tilfredsstiller brukerens behov

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

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

Estimeringsmetoder. I dag. Estimering = måling. Kostnader og prisfastsettelse

Estimeringsmetoder. I dag. Estimering = måling. Kostnader og prisfastsettelse Estimeringsmetoder. Tradisjonelle estimeringsmetoder Estimering med use case modeller I dag Måling Hvordan ta beslutninger Estimeringsteknikker Ekspertestimering, estimering ved analogi, estimering ved

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

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

GJENNOMGANG OBLIGATORISK OPPGAVE 1

GJENNOMGANG OBLIGATORISK OPPGAVE 1 GJENNOMGANG OBLIGATORISK OPPGAVE 1 INF1050 V16 KRISTIN BRÆNDEN 1 Systemet for utleie av markasykler ønsker a benytte seg av en eksisterende betalingsløsning, og valget har falt pa det samme betalingssystemet

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

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

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

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

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

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

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

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

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

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

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) 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan folk faktisk jobber a)

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

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

Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5.

Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5. 2 Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein 5. april 2017 Innhold 1 Klassediagram 2 Sekvensdiagram 2.1 Oppgave 2a 2.2 Oppgave

Detaljer

Obligatorisk oppgave 3. INF1050: Gjennomgang, uke 16

Obligatorisk oppgave 3. INF1050: Gjennomgang, uke 16 Obligatorisk oppgave 3 INF1050: Gjennomgang, uke 16 Pensum for oppgaven Estimering Arkitektur 4+1 view-modellen og lagdeling Arkitektoniske stiler UML-modellering Tilstands- og aktivitetsdiagrammer Testing

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

Tom Røise 9. Februar 2010

Tom Røise 9. Februar 2010 Forelesning IMT2243 9. Februar 2010 Tema : Kravspesifisering : prosessen og produktet Viewpoint en myk tilnærming Pensum : Kap. 6 og 7 i Sommerville, Kravspesifisering Kravspesifisering = arbeidet med

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

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

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

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

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

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

Kapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20

Kapittel 7 & 8. Kravspesifikasjoner & Data design. Thomas Tjøstheim og Thomas Edvinsen. 20 September Kapittel 7 & 8 p.1/20 Kapittel 7 & 8 p.1/20 Kapittel 7 & 8 Kravspesifikasjoner & Data design Thomas Tjøstheim og Thomas Edvinsen 20 September 2004 Kapittel 7 & 8 p.2/20 Introduksjon Kravspesifikasjoner består av to underdeler:

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

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

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

Fra krav til objektdesign

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

Detaljer

Generelt om operativsystemer

Generelt om operativsystemer Generelt om operativsystemer Hva er problemet? Styring av maskinvare og ressurser tilknyttet en datamaskin er komplisert, detaljert og vanskelig Maskinvare, komponenter og programvare endres og forbedres

Detaljer

Prøveeksamen INF1050: Gjennomgang, uke 15

Prøveeksamen INF1050: Gjennomgang, uke 15 Prøveeksamen 2016 INF1050: Gjennomgang, uke 15 Overblikk Multiple choice Modellering Aktivitetsdiagram Sekvensdiagram Klassediagram Tilstandsdiagram Krav Ikke-funksjonelle krav og målbarhet Smidig metodikk

Detaljer

Prosjektrettet systemarbeid

Prosjektrettet systemarbeid Prosjektrettet systemarbeid Funksjonsmodellering Faglærer: Kjell Toft Hansen Funksjonsmodellering Fra prosjektets brukerkravdokument: Kap. 3.1 Krav til funksjoner Kravene til funksjoner beskriver hva bruker

Detaljer

Systemutvikling (Software Engineering) Professor Alf Inge Wang

Systemutvikling (Software Engineering) Professor Alf Inge Wang 1 Systemutvikling (Software Engineering) Professor Alf Inge Wang 2 Undervisningsmål og henvisning Målet med timen er: Få kunnskap om hva systemutvikling er Forstå hva en utviklingsprosess består av Få

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

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

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

Systemarkitektur. INF1050: Gjennomgang, uke 07

Systemarkitektur. INF1050: Gjennomgang, uke 07 Systemarkitektur INF1050: Gjennomgang, uke 07 Kompetansemål Systemarkitektur Hva og hvorfor? Arkitektoniske modeller Kjennetegn Fordeler og ulemper Arkitektoniske stiler Ulike typer: Pipe-and-Filter /

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