1 / 40

Session 11: Introduktion til Systemudvikling

Session 11: Introduktion til Systemudvikling. Krav Design Realisering Test. Hvad er systemudvikling?. Få en ide / Identificer behov find krav  design løsning  realiser ide  vedligehold løsningen. Proces-tilgange.

reese-norman
Télécharger la présentation

Session 11: Introduktion til Systemudvikling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Session 11: Introduktion til Systemudvikling Krav Design Realisering Test

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

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

  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 UCN AK IT: Softwarekonstruktion 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.

  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 …og specifikationen ændrer sig undervejs… Specifikation Specifikation Løsning Løsning Klassisk Agil UCN AK IT: Softwarekonstruktion

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

  10. Udviklingsmodel, metode og notation UCN AK IT: Softwarekonstruktion • 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 • UnifiedModelling 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.

  11. Discipliner, aktiviteter og produkter UCN AK IT: Softwarekonstruktion • Krav : • Domænemodel: hvilke informationer skal håndteres i systemet (klasser) • Usecases: 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

  12. 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 UCN AK IT: Softwarekonstruktion 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. – usecases og domænemodel

  14. Hvad er en use case? UCN AK IT: Softwarekonstruktion 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 usecase 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.

  15. Gode og dårlige use cases • Kriterier: • Afsluttede; målet er nået; kaffepause • Små beslægtede opgaver bundtes i én beskrivelse (CRUD) • 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 Gode eller dårlige? • Administration af bøger • Registrer bogens titel • Udlån af bog • Ret reservation • Slet reservation

  16. Eksempel: Hændelsestabel fra et ordresystem = Use case ”Rolle” der bruger systemet Step i use case 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 Samles i use casen: Håndter vare - CRUD Samles i use casen: Håndter kunde - CRUD • 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 UCN AK IT: Softwarekonstruktion

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

  20. Opsummering: Find aktører UCN AK IT: Softwarekonstruktion • 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

  21. Opsummering: Find use cases UCN AK IT: Softwarekonstruktion • 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 usecasen skal give aktøren en observerbar nytteværdi (kaffe pause testen: fortjener aktøren at holde kaffepause efter usecasen 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.

  22. Beskrivelsesformater for use cases UCN AK IT: Softwarekonstruktion • Overordnede tekstuelle beskrivelser i en kort summeret form (kunderettet) • brief: tekstuel beskrivelse af happydays scenariet • casual: variationer af happydays scenarier • Detaljerede beskrivelser i en “expanded” form - fullydressed • 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 fullydressed med tilhørende SSD og kontrakter

  23. Use case beskrivelse:Kort- eller oversigtsform (brief) • ”Steps” fra hændelsestabellen samt mockup’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: Briefuse case beskrivelse 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. Hændelsestabel giver input til beskrivelse af use case: UCN AK IT: Softwarekonstruktion

  25. Prioritering af usecases UCN AK IT: Softwarekonstruktion • 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 ”fullydressed” beskrivelser.

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

  27. Use case: Registrer Ordre MockUP’s fra test: 1. Start på registrering af varer 2. Respons på vare nr 1231 Flow of events i fullydressed beskrivelse : • Usecasen 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. UCN AK IT: Softwarekonstruktion

  28. Fullydressed 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. Design UCN AK IT: Softwarekonstruktion • Design løsning: • arkitektur • database • klassedesign (metoder og objektinteraktion) • hvordan skal skærmbilleder se ud (GUI)

  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 Application Server Backend Database Server Mobile Client New Dedicated Client Database Access Layer DB UCN AK IT: Softwarekonstruktion

  32. 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. Klassedesign • Designklassediagram: • Metoder på klasser og objektinteraktion fastlægges. • Controllere tilføjes. • Data access klasser. UCN AK IT: Softwarekonstruktion

  34. 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. 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. Test model Krav Accepttest Arkitektur Integrationstest Test afklasser Design Test afmetoder Design 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. 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

More Related