Systemutvikling i henhold til "V-modellen"

1 Systemutvikling i henhold til "V-modellen" TTK4235 Tilpassede datasystemer Øyvind Stavdahl Sist revidert: 2015 Denne lysarkserien er en bearbeidet versjon av tilsvarende serie utviklet av 1.aman.II Geir Mathisen (2013), og utgjør pensumlitteraturen i denne fagbolken våren 2015. 2 Læringsmål systemutvikling m/v-modellen Etter å ha fullført dette emnet skal du ha grunnleggende kunnskap om 1. produkters livsløp 2. utviklingsprosjekters faser 3. V-modellen som verktøy i utviklingsprosjekter ha grunnleggende ferdigheter i å benytte V-modellen i egne prosjekter Hoveddelene i denne presentasjonen er organisert etter disse punktene/ perspektivene ha grunnleggende generell kompetanse i å kommunisere om utviklingsprosjekter med medarbeidere og "kunder" vurdere teknologiutvikling i et livsløpsperspektiv 1

3 Innhold Bærende tanke: behovet for systematikk Hvordan lage det riktige produktet? Hvordan lage produktet riktig? 1.Motivasjon V-modellens rolle i Samfunnet/næringslivet Emnet 2.Systemutvikling i et livsløpsperspektiv mere enn bare utvikling! 3.V-modellen som verktøy (systematikk) "Den pragmatiske V-modellen" (forenklet) 4.Sporbarhet 4 Motivasjon En tidligere student om V-modellen: Den 8. sep. 2014 kl. 23:25 skrev "LLM" <nn@gmail.com>: Ja du trenger ikke være redd for at det læres bort gammelt nytt! Er i Oslo på kurs i regi av norsk jernbaneskole frem til jul. I dag fikk vi utdelt en case-oppgave der et problem skulle løses via jernbaneverkets rammeverk for sikre prosesser. Det viste seg at denne prosessen fulgte V- modellen til punkt og prikke, og at hele caset egentlig gikk ut på å være "nazi" med kravspekken! Da var det utrolig nyttig å ha brukt modellen i masteren, og ikke minst de diskusjonene vi har hatt rundt dette med en god spec og sporbarhet. Det var gøy å ha mer kontroll på det enn "gamlegutta" som var på gruppa! 2

5 I dag Systemutvikling 6 Litt om Heisprosjektet - vårt case for å oppnå praktisk kunnskap og øvelse i dette stoffet 3

7 Stoffet er en del av en helhet Produktets livsløp Spesifikasjon-utvikling UML (verktøy for beskrivelse av systemet) V-modellen (metodikk) C (verktøy for implementasjon) 8 Konstruktørens to personligheter Dyrk begge! Kunstneren som: Får en glimrende ide som skal materialiseres Ser nye muligheter Ser nye/kreative løsninger Realisten som tenker Realiserbarhet Reproduserbarhet Validerbarhet Robusthet Økonomi 4

9 Holdninger Ikke spør Er produktet realiserbart, reproduserbart, validerbart, robust, økonomi i? Men spør Hvordan sikre at produktet er realiserbart, reproduserbart, validerbart, robust, økonomi i? Dette krever bevissthet og systematikk, f.eks. V-modellen 10 1. SYSTEMUTVIKLING I ET LIVSLØPSPERSPEKTIV 5

11 Produktets livsløp Ideunnfangelse Spesifikasjon-utvikling Produksjon Operativ tid Deponering/ resirkulering Dette handler om å se vår (ingeniørens) rolle i en større sammenheng. Hvilke aktiviteter inngår i de ulike fasene? Hvilke yrkesgrupper/stillingskategorier utfører dem? Osv. 12 Ideunnfangelsesfasen Ideunnfangelse Spesifikasjon-utvikling Produksjon Operativ tid Deponering/ resirkulering "Kunden" identifiserer et behov. "Kunden" kan være Bedriftens markedsavdeling (produktmulighet) Andre avdelinger ("intern kunde" med egne behov) Ekstern kunde 6

13 Utviklingsfasen Ideunnfangelse Spesifikasjon-utvikling Produksjon Operativ tid Deponering/ resirkulering Dette er "vår" (dvs. ingeniørenes) fase fremfor noen. Spesifikasjon av produktets (ønskede) egenskaper: Markedsavdeling/kunde er sentral => lage det riktige produktet! Utvikling av et produkt med de spesifiserte egenskapene: => lage produktet riktig! 14 Produksjonsfasen Ideunnfangelse Spesifikasjon-utvikling Produksjon Operativ tid Deponering/ resirkulering Her skal produktet (masse-)produseres. Viktige aktører: Egen produksjonsavdeling, underleverandører, osv. NB: I utviklingsfasen må det tilrettelegges for en effektiv produksjon! 7

15 Den operative fasen Ideunnfangelse Spesifikasjon-utvikling Produksjon Operativ tid Deponering/ resirkulering Her skal produktet selges, driftes og vedlikeholdes. Viktige aktører: Markedsavdeling, forhandlere, serviceingeniører osv. NB: I utviklingsfasen må det tilrettelegges for effektivt service, vedlikehold, oppgraderinger osv.! 16 Den siste fasen Ideunnfangelse Spesifikasjon-utvikling Produksjon Operativ tid Deponering/ resirkulering Her skal produktet tas ut av bruk og "avhendes". Gammel løsning: deponi ("søppeldynge") Moderne løsning: resirkulering Både etiske, juridiske og bedriftsøkonomiske forhold spiller inn! NB: I utviklingsfasen må det tilrettelegges for effektiv innsamling og resirkulering! 8

17 Én av mange mulige modeller: 2. V-MODELLEN SOM VERKTØY 18 V-modellens plass i livsløpet Ideunnfangelse Spesifikasjon-utvikling Produksjon Operativ tid Deponering/ resirkulering En modell som hjelper oss å utvikle det riktige systemet på "den riktige måten" Merk overlapp Med produksjonsfasen! Dette handler om testing av det helt ferdige produktet Det handler om systematikk som sikrer at alle krav oppfylles og at dette kan dokumenteres. 9

19 V-modellens prinsipp Idé Ferdig produkt Systemnivå Spesifisere Modularisere Implementere Teste Verifisere Modulnivå 20 Analyse - arkitekturmodell Analyse Testkriterier "Oppgaveteksten" Arkitekturmodell 10

21 Analyse/arkitekturmodell: Modularisering (splitt og hersk) Splitter oppgaven i enklere blokker lettere oppgaver å løse, lettere å teste, muliggjør parallelt arbeid, mere fleksibelt produkt, lettere gjenbruk, enklere prosess ved endringer, lettere vedlikehold, forlenger levetiden(?) 22 Analyse/arkitekturmodell Eksempel: styresystem for en kran Modulene utgjør funksjonelle blokker (hva betyr det?) Fokus på hva modulene skal gjøre, ikke hvordan. 11

23 Designmodell Designmodell (større detaljering) 24 Design, funksjonelt diagram, modulorientert Spennings måling Definere: Grensesnittene (meldinger, timing, sekvenser.) Funksjonalitetene (ikke implementasjonsdetaljer!) Først her: Fordeling av funksjonalitet mellom HW og SW 12

25 Modulutvikling Ferdigstilte og testede moduler Modulutvikling Først her blir det virkelig "bygget " noe (moduler)! 26 Sammenstillingstest (system integration) Test av flere / alle testede moduler i et system Hvordan fungerer logikken i modulene sammen? Hvordan er interaksjonen (grensesnittet) mellom modulene (meldinger, timing, sekvenser)? 13

27 FAT (Factory Acceptance Test) FAT er en test som utføres i forbindelse med overtakelse / (del-)godkjennelse av et produkt. FAT innbefatter ofte et antall på forhånd avtalte deltester, ofte avtalt ved avtaleinngåelse. FAT utføres i kontrollerte omgivelser på utviklers hjemmebane (derav "factory"). FAT bør alltid lykkes! (Hvorfor?) * Vi kjører "FAT" som del av godkjenning/poengkriterium i Heisprosjektet 28 SAT (Site Acceptance Test) I den grad SAT benyttes vil det være for å endelig godkjenne produktet. SAT utføres for å etterprøve at produktet oppfyller sine spesifikasjoner når det står i sine normale arbeidsomgivelser (derav "site"). Deltester avtalt på forhånd, eller at produktet skal fungere Som forventet ved normal bruk. SAT krever erfarne testfolk som kjenner bruk og mulige feil 14

29 Pragmatisk V-modell Produktkrav -spesifikasjon (=modul) 30 Den "Pragmatiske V-modell" har: Færre nivåer Produktkravdokument med akseptansekrav Spesifikasjon med akseptansekrav (færre nivåer) Sporbarhet i spesifikasjonen (opp og ned). FAT og SAT er uavhengig av antall nivåer (dvs. fortsatt like relevant). 15

31 3. SPORBARHET 32 Om sporbarhet Produktkrav 16

33 Sporbarhet Hvordan sikre at kundens ønsker blir realisert? Hvordan sikre at det vi lager i modulene er en oppfylling av kundens ønsker? Sporbarhetsmetodikk gjør det mulig å følge kravene på forskjellig nivå. Toppnivået for sporbarheten bør være et systematisert dokument på et nivå hvor kunden vil kjenne igjen sine krav (Produktkravdokumentet). Hvert krav her skal også være koblet til akseptansekriteriene (høyre side av V'en). 34 Eksempel på sporbarhetsmatrise, (søkbar wordfil e.l. K.I.S.S.) Krav ref Produktkrav Akseptansekrav Test ref PK-11 Systemet skal styre servomotorene, med utslag fra 0,2 mrad/sek til 0,3 rad/sek, samt kunne holde systemet i ro Kjøring av servomotorene, med utslag fra 0,2 mrad/sek til 0,3 rad/sek, samt kunne holde systemet i ro TPK-11 Spek ref Spesifikasjon Impl ref Akseptansekrav Test ref PK-11.1 Servostyring av en likestrømsmotor, 24V, 0 50A, 8 bits oppløsning DSW-14A DHW-9 Måling av strøm over en 0,1 ohms motstand, 0 50A, 8 b oppløsning + Testbeskrivelse TPK-11.1 PK-11.2 PK-11.1.1 Servostyring av motoren i hastigheter fra 1 til 100 o/sek etter 1:100 gir, basert på tacho måling Strømmåling med 10 bits oppløsning, område 0 50A, min 20 målinger / sek DSW-14A.1 DHW-9 DSW-14A.2 DHW-9 Måling med ekstern omdreiningsteller på gearaksel koblet til motor + Testbeskrivelse Send in en 50 HZ sinussignal, ta ut måleverdier og plott disse + Testbeskrivelse TPK-11.2 TPK-11.1.1 PK-11.1.1.1 <HW for strømmåling> DHW-9. TPK-11.1.1.1 PK-11.1.1.2 <SW for strømmåling> DSW-14A.2. TPK-11.1.1.2 17

35 Toveis sporbarhet! Spesifikasjonsmatrisen har referanse til implementasjon / designdokument Spesifikasjonsmatrisen har rader for alle akseptansekrav 36 Kommentarer til sporbarhet Detaljer som ikke står i spesifikasjonsmatrisen er opp til implementørens beste skjønn å avgjøre (jfr."kunstneren"). (Ideelt sett:) Alle deler av der ferdige systemet skal kunne refereres til ett eller flere punkt i spesifikasjonsmatrisen, og vice versa. Dette er ikke "én-til-én"-referanser! Hvert krav kan implementeres via flere deler av systemet, Hver del av systemet kan implementere flere krav 18

37 Brukererfaring Erfaring fra en førstegangsbruker: V-modellen har blitt brukt i utviklingen av en MP3-spiller. Å utarbeide kravdokumenter og tekniske krav virket noe tungvint i starten, og en har følelsen av å ikke komme i gang med selve utviklingen av MP3-spilleren. V-modellen viste seg likevel å være en god metode fordi den lettet arbeidet i implementerings- og testfasen av oppgaven. V-modellen gir oversikt over arbeidet, og en har kontroll på hvilke krav som skal oppnås for å få et godkjent system. 38 Oppsummering - Hva gir bruk av V-modellen? Verktøy for systematisk produktfremtaking Felles utviklingsmetodikk, letter kommunikasjonen internt Produkter spesifisert i korte etterprøvbare punkter Avtalte, utvetydige akseptansekrav (Metodikk for å) sikre at kundens krav blir implementert En sporbarhet mellom arbeidsmoduler ("Work Breakdown Structure") 19