Session 11: Introduktion til Systemudvikling

Præsentationer af emnet: "Session 11: Introduktion til Systemudvikling"— Præsentationens transcript:

1 Session 11: Introduktion til Systemudvikling
Krav Design Realisering Test

2 Hvad er systemudvikling?
Få en ide / Identificer behov find krav  design løsning  realiser ide  vedligehold løsningen UCN AK IT: Softwarekonstruktion

3 UCN AK IT: Softwarekonstruktion
Proces-tilgange Vandfaldsmodel: Et sekventielt gennemløb gennem hovedaktiviteterne. Iterativ model: Planlægning af aktiviteter sker successivt og tilpasset omstændighederne UCN AK IT: Softwarekonstruktion

4 Traditionel vandfald model
UCN AK IT: Softwarekonstruktion

5 IT-udviklingsprocesser
Klassisk opfattelse: Processen er plandreven: Er dokumenterbar Kan gentages Er forudsigelig Hviler på den antagelse at problemet er velforstået inden start at en præcis kravspecifikation foreligger/kan udarbejdes UCN AK IT: Softwarekonstruktion

6 IT-udviklingsprocesser
Brugerne ved ikke hvad de vil have, før de reelt har fået IT systemet. Analysis paralysis. Nye muligheder dukker op. Krav ændres. Brugernes/kundens prioriteter ændres. UCN AK IT: Softwarekonstruktion

7 IT-udviklingsprocesser
Moderne udviklingsprocesser er agile: Situationsbestemte Iterative og inkrementelle Eksperimenterende Udviklerne lærer, mens de udvikler Ofte opdages nye behov og muligheder undervejs UCN AK IT: Softwarekonstruktion

8 IT-udviklingsprocesser
Klassisk Agil …og specifikationen ændrer sig undervejs… Specifikation Specifikation Løsning Løsning UCN AK IT: Softwarekonstruktion

9 Unified process (UP)– metoden ?
UCN AK IT: Softwarekonstruktion

10 Udviklingsmodel, metode og notation
En udviklingsmodel er en samling af aktiviteter, der fører frem til det færdige IT system En metode er konkrete retningslinjer for, hvordan de enkelte aktiviteter skal udføres UP er både en udviklingsmodel og en metode En notation er et sprog til beskrivelse og visualisering Unified Modelling Language (UML) er en fælles standard for visualisering af modeller og understøttes af forskellige case-værktøjer UP og mange andre metoder benytter UML. UCN AK IT: Softwarekonstruktion

11 Discipliner, aktiviteter og produkter
Krav : Domænemodel: hvilke informationer skal håndteres i systemet (klasser) Use cases: hvilke funktioner skal der være i systemet Ikke-funktionelle krav: brugervenlighed, svartider, sikkerhed, vedligeholdelsesvenlighed… Design løsning: arkitektur database klassedesign (metoder og objektinteraktion) hvordan skal skærmbilleder se ud (GUI) Realiser Programmer og test Database UCN AK IT: Softwarekonstruktion

12 UCN AK IT: Softwarekonstruktion
Domænemodel Find entiteter/objekter, som systemet skal håndtere. Objekterne skal komme fra domænet – være fra brugerens verden. Beskriv deres sammenhæng (associeringer, aggregeringer, specialiseringer) Se tidligere lektioner. UCN AK IT: Softwarekonstruktion

13 Indhold af kravsspecifikation
En kravspecifikation skal indeholde flg.: Funktionelle krav til IT systemet (use cases) Information som IT systemet skal registrere (domænemodel) Ikke-funktionelle krav I det følgende drejer det sig om 1. og 2. – use cases og domænemodel UCN AK IT: Softwarekonstruktion

14 UCN AK IT: Softwarekonstruktion
Hvad er en use case? Use cases er beskrivelser af systemets funktionalitet set fra en brugers (kaldet aktør) perspektiv. Gennem use casen fortælles historien om hvordan en aktør bruger et system og herigennem illustreres de funktionelle krav. En use case kan defineres som en samling af relaterede succes og fejlscenarier, som beskriver hvordan en aktør bruger systemet til at opnå et bestemt mål. UCN AK IT: Softwarekonstruktion

15 Gode og dårlige use cases
Kriterier: Afsluttede; målet er nået; kaffepause Små beslægtede opgaver bundtes i én beskrivelse (CRUD) Gode eller dårlige? Administration af bøger Registrer bogens titel Udlån af bog Ret reservation Slet reservation Kontrol: Er alle opgaver med? Er alle aktørernes opgaver dækket? Er kritiske opgaver med? Kan alt data registreres, ændres, slettes (CRUD)? UCN AK IT: Softwarekonstruktion

16 Eksempel: Hændelsestabel fra et ordresystem
= Use case ”Rolle” der bruger systemet Step i use case Hændelse Aktivitet Step i brugen af IT systemet Aktør Kunde afgiver ordre Registrer ordre Registrere varer Registrere kunden Gemme ordren Udskrive ordreseddel og faktura Ekspedient Faktura sendt til kunden Overvåg ordre Sammenligne betalingsfrist med dags dato Genfremsende hvis overskredet (hændelse ”Tid til betaling”)….. System …… ……. UCN AK IT: Softwarekonstruktion

17 Use case diagram – første version for ordrestyring
Er en grafisk model over systemets funktionalitet og kommunikationen med dets aktører Omfatter: Use cases Aktører Associeringer mellem use cases og aktører Systemafgrænsning (ikke vist) UCN AK IT: Softwarekonstruktion

18 Udvidelse af use case diagrammet for ordrestyring
Afvigelser fra et normalt flow i forretningsscenariet, fx Annuller ordre Registrer returvare osv… Vedligeholdelse af varebeholdning Registrer vare Find vare Ændre vareoplysninger Slet vare Vedligeholdese af kundekartotek Registrer kunde osv Samles i use casen: Håndter vare - CRUD Samles i use casen: Håndter kunde - CRUD UCN AK IT: Softwarekonstruktion

19 Udvidet use case diagram for ordrestyring
UCN AK IT: Softwarekonstruktion

20 Opsummering: Find aktører
Tag udgangspunkt i hvem/hvad der bruger systemet og hvilken rolle de spiller? – Generaliser. Ud over de aktører der deltager i forretningsprocessen kan der være andre, fx systemadministrator, leder. Brug en tidsaktør til tidsafhængige funktioner. Aktørerne navngives, og beskrives ud fra et forretningsperspektiv. Eksempel: Navn: Ekspedient Opgave: Er ansvarlig for at modtage og registrere ordrer fra kunder, samt vedligeholdelse af kundekartotek UCN AK IT: Softwarekonstruktion

21 Opsummering: Find use cases
Forretningskritiske use cases findes ved at kortlægge hændelser i forretningsområdet, der initierer aktiviteter, som skal understøttes af IT. Herudover kan man kigges på de primære aktører og deres formål med at bruge systemet. Ud over de forretningskritiske use cases vil der typisk være use cases for afvigelser i forretningsprocessen samt til vedligeholdelse. Fokus i afgrænsningen af use-cases skal være, at use casen skal give aktøren en observerbar nytteværdi (kaffe pause testen: fortjener aktøren at holde kaffepause efter use casen er afsluttet?). En hyppig fejl er at use cases fastlægges på et for lavt niveau, fx er Udskriv bekræftelse som regel en del af noget andet. UCN AK IT: Softwarekonstruktion

22 Beskrivelsesformater for use cases
Overordnede tekstuelle beskrivelser i en kort summeret form (kunderettet) brief: tekstuel beskrivelse af happy days scenariet casual: variationer af happy days scenarier Detaljerede beskrivelser i en “expanded” form - fully dressed Trinene i use casen og variationer heraf beskrives i detaljer En grafisk visning af interaktionen i use casen i et systemsekvensdiagram – SSD (udviklerrettet) Alle use cases beskrives brief og/eller causal. Kun de kritiske beskrives fully dressed med tilhørende SSD og kontrakter UCN AK IT: Softwarekonstruktion

23 Use case beskrivelse: Kort- eller oversigtsform (brief)
”Steps” fra hændelsestabellen samt mock up’s af skærmbilleder giver input til use case beskrivelserne. Template for brief beskrivelse : Use case: Navn på use casen Beskrivelse: En overordnet men komplet beskrivelse af hvem der initierer use casen, de forventede systemhandlinger og responsen herpå, der tilføjer værdi for aktøren. UCN AK IT: Softwarekonstruktion

24 Eksempel: Brief use case beskrivelse
Hændelsestabel giver input til beskrivelse af use case: Hændelse Aktivitet Step i brugen af IT systemet Aktør Kunde afgiver ordre Registrer ordre Registrere varer Registrere kunden Gemme ordren Udskrive ordreseddel og faktura Ekspedient Brief beskrivelse, Use case: Registrer Ordre En kunde henvender sig for at afgive en ordre. Ekspedienten bruger systemet til at oprette en ny ordre, tilføje varer til ordren, registrere kundeoplysninger, gemme ordren og udskrive ordreseddel og faktura. Undervejs viser systemet detaljer om varerne, deltotal og total. UCN AK IT: Softwarekonstruktion

25 Prioritering af use cases
Systemet designes, implementeres og testes igennem et antal iterationer jf. UP modellen. De højest prioriterede use-case analyseres, designes og kodes i de første iterationer (så må man formode at resten også kan laves). Trin i udvikling af use-cases: Use-cases identificeres og de vises i et UML use-case diagram. Dernæst beskrives de på brief eller casual form. På dette grundlag prioriteres use-cases (ud fra arkitekturmæssig vigtighed, risici og forretningsværdi), og derefter analyseres de vigtigste med henblik på design ved prototyper og ”fully dressed” beskrivelser. UCN AK IT: Softwarekonstruktion

26 Use case beskrivelse: ”Fully dressed”
Detaljering af use cases i step (flow of events): Aktørhandling < - > Systemsvar. Tilføjelse af aktører samt pre- og post betingelser. Brief-beskrivelser bruges som udgangspunkt for ”fully dressed” beskrivelser. UCN AK IT: Softwarekonstruktion

27 Use case: Registrer Ordre
Mock UP’s fra test: 1. Start på registrering af varer Flow of events i fully dressed beskrivelse : Use casen starter med at en kunde henvender sig telefonisk for bestille varer. Ekspedienten påbegynder en ny ordre. Systemet opretter en ny ordre. Ekspedienten angiver id på de ønskede varer. Systemet returnerer varebeskrivelse, pris, deltotal , samt løbende total. Ekspedienten tilføjer det ønskede antal varer. Systemet tilføjer varen. Trin 4-7 gentages indtil alle varer er tilføjet. Ekspedienten angiver leveringsoplysninger. Systemet validerer oplysningerne og registrer kunden. Ekspedienten afslutter orden. Systemet gemmer ordren. Ekspedienten beder om en ordreseddel og faktura. Systemet udskriver en bekræftelse. 2. Respons på vare nr 1231 UCN AK IT: Softwarekonstruktion

28 Fully dressed af use casen: Registrer ordre
UCN AK IT: Softwarekonstruktion

29 Domænemodel vs. use cases
I systemudviklingskredse diskuteres: ”Model før krav” (skandinavisk skole). ”Use cases før model” (amerikansk skole). De udvikles ”hånd-i-hånd”. (og skal noget komme først, så hælder denne forelæser til ”model-før-krav”). ? UCN AK IT: Softwarekonstruktion

30 UCN AK IT: Softwarekonstruktion
Design Design løsning: arkitektur database klassedesign (metoder og objektinteraktion) hvordan skal skærmbilleder se ud (GUI) UCN AK IT: Softwarekonstruktion

31 N-tier (multi-tier) Architecture
Database access layer: All code to access database is here. Makes it possible to change data store. Web server accesses application layer – not the database directly. Easier maintenance: No business logic in the web server (or other clients). Application server: All (almost) business logic is re-used. New client may be added without code duplication. Client accessing web services Browser Client Internet Dedicated Client Web Server DB Database Server Application Server Database Access Layer Backend Mobile Client New Dedicated Client UCN AK IT: Softwarekonstruktion

32 UCN AK IT: Softwarekonstruktion
Databasedesign Tabeller designes ud fra domænemodellen En tabel pr. objekt Customer (Bank)Account Meget mere i næste fag:-) 1- n associeringen fra Customer til BankAccount implementeres i databasen ved at inkludere custNo som fremmednøgle i Account. UCN AK IT: Softwarekonstruktion

33 UCN AK IT: Softwarekonstruktion
Klassedesign Designklassediagram: Metoder på klasser og objektinteraktion fastlægges. Controllere tilføjes. Data access klasser. UCN AK IT: Softwarekonstruktion

34 UCN AK IT: Softwarekonstruktion
Om test Test udføres altid i henhold til specifikationer. En test kan aldrig påvise korrekthed - kun tilstedeværelse af fejl! En succesfuld test finder fejl!!! Udvikleren skal ikke teste sig selv. Et system er færdigtestet, når hyppigheden af fejl er reduceret til et forretningsmæssigt acceptabelt niveau!! UCN AK IT: Softwarekonstruktion

35 UCN AK IT: Softwarekonstruktion
Testmodel En samling af Test-cases Test-procedurer Eksekverbare komponenter, som tester Omfatter typer af test: Modultest eller unit-test (klasseniveau) Integrationstest Systemtest Accepttest UCN AK IT: Softwarekonstruktion

36 UCN AK IT: Softwarekonstruktion
Test model Krav Accepttest Arkitektur Integrationstest Design Test af klasser Design metoder Test af metoder Kodning UCN AK IT: Softwarekonstruktion

37 Modultest (unit-test)
Alle en klasses metoder skal testes Black-box test ud fra specifikation (pre- og post-betingelser) White-box test udfra kendskab til intern struktur: test grænsetilfælde og normaltilfælde UCN AK IT: Softwarekonstruktion

38 Integrations- og systemtest
Integrationstest skal finde fejl i måden moduler spiller sammen på og udføres efter hvert build. (Design by Contract er vigtigt.) Systemtest skal finde fejl i systemet som helhed og udføres i slutningen af hvert gennemløb af implementationsprocessen UCN AK IT: Softwarekonstruktion

39 UCN AK IT: Softwarekonstruktion
Test-cases Test-cases findes udfra use-case modellen Hver test-case tester et scenarium for en use-case En test-case skal specificere input, forventet output og evt. betingelser for testen Husk også belastningstest!!! UCN AK IT: Softwarekonstruktion

40 Test-procedurer og komponenter
Test-procedurer specificerer, hvordan en test gennemføres kan være manuelle eller - bedre - automatiske Test-komponenter - eller drivere automatisering af testprocedurer Tilstræb design af test-procedurer og -komponenter, så der er så meget genbrug som muligt UCN AK IT: Softwarekonstruktion