Skip to content

Latest commit

 

History

History
251 lines (168 loc) · 13.7 KB

File metadata and controls

251 lines (168 loc) · 13.7 KB

Architectuur ScanMe toepassing

  • Verwachtingen voor elke paragraaf staan cursief gedrukt. Laat ze staan zolang dit document in ontwerpfase is maar denk eraan ze allemaal te verwijderen tegen versie 1.0
  • Gelieve de structuur van dit document niet te wijzigen, om zo het nalezen ervan te vergemakkelijken
  • Alle afbeeldingen moeten als fysisch bestand beschikbaar worden gemaakt in de img folder (urls dus niet toegelaten)
Opdracht voor ICT Architecture

2019 - 2020

Voornaam Naam


Samenvatting

  • Lees de Wikipedia pagina om te begrijpen wat een samenvatting is
  • De bedoeling van deze paragraaf is om alle inhoud van dit document samen te vatten in maximaal een 100-tal leestekens.
  • Je volgt best deze structuur:
    • 1 of 2 korte zinnen rond de probleemstelling
    • 1 korte zin over de architectuur stijl je wil volgen
    • 3 tot 7 zinnen over de uitwerking (views)
    • 1 zin om te bespreken in hoeverre het voorstel/werk wel degelijk een antwoord biedt op de vooropgestelde probleemstelling
  • Probeer de nieuwsgierigheid van de stakeholders te beantwoorden
  • Vermijd schrijftaal
  • Een samenvatting schrijf je al laatst
  • _Een samenvatting bevat steeds originele tekst, geschreven in je eigen woorden (dus niets letterlijk gekopieerd)

Probleemstelling

De aanwezigheid van studenten tijdens de les wordt momenteel semi-automatisch afgenomen via Digitap. Voor examens gebeurt alles nog op papier, d.m.v. aftekenlijsten. Het idee bestaat om tijdens de examens en andere evenementen (zoals het stage-event of bedrijfsbezoek) de aanwezigheden te registreren door het inscannen van de studentenkaart.

Voorbeeld studentenkaart

Het inscannen zelf zou kunnen plaatsvinden door middel van 1. een smartphone van een lector of begeleider of 2. een barcode scanner zoals hieronder afgebeeld:

Voorbeeld barcode scanner

De bedoeling is om een workflow te bedenken alsook een applicatie voor het opnemen en opvolgen van de absenties. Hieronder wordt twee scenario's uitgewerkt:

Scenario 1: Tijdens het examen

Vóór de aanvang van het examen en dus ook vóór de eerste student het examenlokaal binnentreedt, wordt de registratie voorbereid door een lector (in feite mag elk personeelslid van AP dit doen) door in een WebUntis-gekoppelde agenda van de applicatie eenvoudigweg het examen te kiezen. Daarop vraagt de applicatie de lector het lokaal te bevestigen. De applicatie tracht daarop verbinding te maken met één of meerdere alleenstaande barcode scanners. Er is ook de mogelijkheid om met de smartphone de registratie te doen, maar uiteraard moet het systeem zo ontworpen worden dat enkel personeelsleden en geen studenten hun smartphone kunnen gebruiken bij het registreren.

Tijdens het betreden van het examenlokaal dienen de studenten hun studentenkaart in te scannen ofwel bij een alleenstaande barcode scanner ofwel bij de lector die klaarstaat met zijn smartphone. Onmiddellijk tijdens het scannen moet de applicatie een popup tonen ter bevestiging dat een student zich heeft ingeschreven. De applicatie moet controleren of de student wel degelijk op dat examen verwacht wordt en moet een fout weergeven indien dit niet zo is, waarop de toezichter kan kiezen om de student te weigeren of toch toe te staan.

Op elke ogenblik tijdens het examen kan de lector:

  • een lijst opvragen met alle geregistreerde studenten
  • opzoeken of een student in deze lijst staat door een deel van de naam van die student op te geven
  • in één oogopslag zien hoeveel studenten er geregistreerd zijn voor dit examen en hoeveel nog niet aanwezig zijn
  • een opmerking toe te voegen voor een bepaalde student. Daarbij neemt de AP-vertegenwoordiger de kaart van de student, scant deze en voegt in de applicatie de opmerking toe
  • Extra informatie op te vragen van een student door ofwel door te klikken op een student ofwel door de studentenkaart in te scannen

Na het afwerken van hun examenopdracht kan de lector een student uitschrijven nadat er gecontroleerd werd dat de student de opdracht correct indiende. Totdat de volgende student zich komt afmelden, moet deze actie eenvoudig ongedaan kunnen worden gemaakt.

Telkens wanneer een student in de applicatie vermeld staat, moet er van deze student de volgende informatie getoond worden:

  • Foto
  • Voornaam + Naam (in die volgorde)
  • Student nummer
  • Opleiding

Naast een aanwezigheidslijst, wil men in de toekomst ook (tegelijkertijd) andere lijsten kunnen hanteren zoals lijsten "ziek gemeld", "Zaal A", "aanwezig maar neemt niet deel", "te laat", …

Gaat er op technisch vlak iets misloopt met de scanner (zowel alleenstaande scanner of fototoestel van de smartphone), moet dit ook duidelijk zijn zowel voor de lector of toezichthouder als voor de student zodat deze opnieuw kan scannen. Bovendien moet er de mogelijkheid bestaan om het studentennummer (of eventueel naam) manueel in te geven.

Scenario 2: Tijdens een Evenement

Tijdens een evenement moet er op gelijkaardige wijze als tijdens het examen afwezigheden kunnen worden afgenomen, opmerkingen toegevoegd en informatie opgevraagd. Een aantal verschillen:

  • Hierbij is het gebruikelijk dat de student zichzelf uitschrijft uit de aanwezigheidslijst
  • Op verplaatsing zal de begeleider eerder de smartphone gebruiken, bij een lokaal evenement zoals het stage-event is een alleenstaande scanner logischer
  • Het zou leuk zijn mocht (=nice to have) een derde persoon (standhouder tijdens stage-event, bedrijfsverantwoordelijke tijdens bedrijfsbezoek) ook de student kunnen registreren (bijvoorbeeld voor interview, deelnemen aan specifieke workshop, etc…)

Definities: Objecten, Actoren en Activiteiten

  • In deze paragraaf definieer je alle (=30-50) actoren, objecten en acties die in de architectuur worden vernoemd
  • De bedoeling van de definities is om alles dubbelzinnigheid uit de architectuur te halen
  • Enkel termen die als dubbelzinnig kunnen worden opgevat, horen hier thuis
  • In de rest van dit document mag je geen enkele actie, actor of object bespreken dat hier niet gedefinieerd staat!
  • Wanneer je een definitie later in de tekst gebruikt, zet je deze vetgedrukt zodat het voor de lezer duidelijk is dat het om een voorgedefinieerde term bestaat

Dit zijn de objecten die centraal staan in de toepassing:

  • Scanner - Een alleenstaande barcode-scanner van het merk […]
  • […]

Dit zijn de actoren die een rol hebben in de toepassing:

  • Begeleider - Een AP medewerker
  • […]

Hier volgen de definities van de relevante activiteiten:

  • Scannen - Het ofwel automatisch uitlezen van een barcode ofwel het manueel invoeren van het studentennummer
  • […]

Doelstelling

Functionele Vereisten

  • Hier geef je een genummerde lijst van de vereisten die beschrijven hoe de applicatie moet functioneren
  • Met andere woorden, hier som je op wat er moet gebeuren en niet hoe het moet gebeuren
  • Onder deze paragraaf mag je dus niet verwijzen naar enige technologie. Zo hoort het woord "databank" eerder thuis onder de technische vereisten
  • Het is jouw taak om op basis van de probleemstelling een set van vereisten te extraheren
  • Voorbeeld: "17. De eindgebruiker kan tijdens het raadplegen van de lijst van historische commentaren deze sorteren volgens hun relevantie; zie nota […] voor het correct berekenen van relevantie"

Scenario's

  • Het aaneenrijgen van de functionele vereisten tot complete scenario's

Technische Vereisten

Accessibility

  • Doornummeren!
  • Beantwoord hier de vraag: Wie kan er aan het systeem?

Availability

  • Beantwoord hier de vraag: Wanneer en onder welke voorwaarden wordt het systeem beschikbaar?

Configurability

  • Welke parametrisatie heeft de gebruiker zelf in de hand. Welke ‘Settings’ moeten er worden voorzien?

Extensibility

  • In hoeverre kan het systeem in de toekomst worden uitgebreid met nieuwe modules?

Performance

  • Wat zijn de vereisten op het vlak van respons-snelheid van het systeem?

Maintainability

  • Hoe wordt ervoor gezorgd dat het systeem functioneel en up-to-date blijft ook na de lancering?

Scalability

  • Hoe wordt er voorzien op een grotere groep gebruikers?

Security

  • Hoe wordt ervoor gezorgd dat de veiligheid en privacy van de gebruiker gegarandeerd blijft?

Supportability

  • Hoe wordt ervoor gezorgd dat de gebruiker geholpen wordt indien er iets mis gaat of indien de gebruiker niet begrijpt wat er moet gebeuren?

Testability

  • Hoe kan het systeem getest worden, wat voor soort testen zijn hier relevant?

Usability

  • Hoe wordt er gegarandeerd dat het systeem gemakkelijk is in gebruik?

Risico-analyse

  • Denk na over wat er kan fout lopeniets fout loopt
  • Volg instructies in slides
  • Focus op project-specifieke risico's
  • Voeg minstens 5 risico's toe

Architectuur

  • Zie details voor afzonderlijke views onder h3 titels hieronder
  • Verwijs naar de bovenstaande vereisten via hun nummers

Business View

  • Deze eerste view geeft visueel weer wat de meerwaarde is van jouw applicatie
  • Bevat geen verwijzingen naar IT systemen_
  • Moet de belangrijkste activiteiten weergeven van jouw applicatie
  • Moet de visie van de opdrachtgever weerspiegelen
  • De business view moet gerelateerd kunnen worden aan de vereisten (verwijs naar de nummering!)

Functionele View

  • Introductie van actoren
  • Omschrijving van scenario’s, wie doet wat
  • Moet compatibel zijn met Business View
  • Moet geëxtraheerd kunnen worden uit de functionele analyse
  • Moet alle vereisten omvatten
  • Deelsystemen mogen getoond worden maar denk zo functioneel mogelijk, i.e. vanuit standpunt van niet-technisch geschoolde eindgebruiker
  • Door de pijlen in de functionele view te volgen moet elk scenario doorlopen kunnen worden

Informatie View

  • Welke informatie moet er tijdelijk of permanent worden bewaard?
  • Wat zijn de informatiestromen?
  • Wat zijn de datatypes
  • Wat zijn de entiteiten, attributen en relaties met bijhorende kardinaliteiten
  • Zijn er regels waaraan de gegevens moeten voldoen (bijv. Bereik.Einde > Bereik.Begin)?
  • Alle objecten en actoren zouden moeten terug te vinden zijn in de Informatie view of bijhorende tekst
  • De informatie view moet alle informatie bevatten om de toepassing te laten functioneren, maar niet méér dan dat
  • De Informatie-blokken in de informatie flow moeten ook ergens in het entiteitendiagram terug te vinden zijn

Applicatie View

  • Kern van de architectuur
  • Beschrijf grondig al de interfaces, ook met mogelijke externe toepassingen
  • Beschrijf de werking zodat geen enkele vereiste onbeantwoord blijft
  • Orden front-end versus backend
  • Laat alle structuur zien die nodig is om aan de vereisten te voldoen, ook bestaande onderdelen
  • Indien er van bestaande/gedeelde onderdelen wordt gebruik gemaakt: laat zien dat je grondig bent ingewerkt in de bestaande technologieën
  • Alle scenario's moeten compatibel zijn met de applicatie view
  • Voor alle acties moet het duidelijk zijn wie deze uitvoert en in welke onderdeel van de toepassing (op schermpje van barcode scanner, in applicaties hoofdscherm, in web-versie settings scherm, …)
  • Alle afhankelijke applicaties en verbonden applicaties (WebUntis, barcode-app, …) moeten zichtbaar worden gemaakt in de applicatie view
  • Alle overdracht van informatie in de informatie view moet terug te vinden zijn als een verbinding in de applicatie view
  • Voor alle onderdelen van de toepassing waar code voor nodig is moet duidelijk worden gemaakt in welke programmeertaal (of talen) het geschreven moet worden
  • De interfaces tussen jouw applicatie en de buitenwereld moeten duidelijk uitgebeeld worden
  • Beschrijf of illustreer de onderdelen van het bestaand systeem die dienen verwijderd te worden om overgang duidelijk te maken

Infrastructuur View

  • Infrastructuur view beschrijft de interactie met de betrokken hardware systemen
  • Het moet duidelijk zijn waarvoor elke infrastructuur component nodig is
  • Protocol vernoemen
  • Security, DMZ en firewalls toevoegen
  • Bestaande van nieuwe componenten scheiden indien van toepassing
  • Backup systemen toevoegen
  • Alle nodige apparatuur bij eindgebruiker ook toevoegen
  • Van elk onderdel van de toepassing moet het duidelijk worden op welke hardware die draait
  • Voor elke verbinding op de infrastructuur view moet een protocol gegeven worden

Architectuurstijlen en -patronen

  • Beschrijf hier, in 100-500 woorden (je eigen woorden!), de architectuur stijl(en) die gebruikt gaan worden voor dit project
  • Dit is belangrijk om te kunnen communiceren met andere architecten
  • Wordt ook in de samenvatting vermeld
  • Je vindt een lijst van mogelijke stijlen terug op deze Wikipedia pagina
  • Zoek op wat deze stijlen betekenen, wat de voor- en nadelen zijn en of jouw project aan de voorwaarde voldoet voor die stijl
  • Beschrijf hier waarom je denkt dat de gekozen architectuurstijlen hier van toepassing zijn

Proof-of concept

  • Hier moet je de opdrachtgever kunnen overtuigen dat het plan wel eens écht zou kunnen werken
  • Vertrek vanuit de risico-analyse

Referenties

  • Wees fair en verwijs naar andermans werk als je dat gebruikt. Als jij origineel werk creëert zou je dat ook willen, toch! Maar, a.u.b. geen referenties naar het werk van een collega, of naar de dia's van de lector of iets dergelijks. Enkel verwijzen naar gepubliceerd materiaal, liefst peer-reviewed
Referentie
1 Naam1 V, Naam2 V, …NaamN V (YYYY) Titel artikel/Boek. Blad/Uitgever. (Uitgave:) p###-###.