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