H4 - Analysefase (Deel 1) Flashcards
De verschillende conceptuele lagen uitleggen: wat zijn de lagen, wat gebeurt er in elke laag
Workflowlaag: De workflowlaag bevat de activiteiten die plaatsvinden in de omgeving van het systeem
- Dit kunnen manuele of acties met de computersysteem zijn.
Functielaag: Bevat de functionaliteiten die het systeem aanbiedt ter ondersteuning van de workflow
- Dit zijn taken die met de software uitgevoerd moeten worden.
Eventlaag: Bevat de wijzigingen aan de domeinobjecten
Domeinlaag: Bevat de objecten die voorkomen in de omgeving van het systeem, en hun onderlinge samenhang.
Het lagenmodel in een overzichtelijk tekening weergeven.
tekening
Uitleggen wat een domeinmodel precies is
Een statische domeinmodel geeft de verschillende domeinobjecten (gegroepeerd in klassen), attributen, associaties weer binnen het probleemgebied en wordt gemodelleerd met een klassendiagram.
Dit zijn objecten uit realiteit en bestaan dus ook zonder de software (boek, lid, uitlening, reservering, …)
Een dynamische domeinmodel bestaat uit business events
Dit zijn events uit de reële wereld, die ook zouden optreden zonder software en zijn atomaire wijzigingen aan domeinobjecten
De doelstellingen van een vereistenanalyse beschrijven
- Het moet een duidelijke overeenstemming zijn tussen de opdrachtgever en uitvoerder (leverancier) over het te ontwikkelen systeem.
- Met de vereistenanalyse kan men vaagheden, onduidelijkheden of fouten in de specificaties zo vroeg mogelijk ontdekken.
Uitleggen waarom vereistenanalyse zo moeilijk is. Enkele redenen aangeven.
Het vereistenanalyse is een moeilijk proces want:
- Betrokkenen weten vaak niet precies wat ze willen
Betrokkenen hebben vaak geen besef van de kosten van een vereiste, en hebben soms onrealistische verwachtingen.
- Betrokkenen hebben eigen termen, waarbij zij heel wat impliciete kennis over het bedrijf en hun eigen manier van werken veronderstellen
Het verschil tussen functionele en niet-functionele vereisten uitleggen.
Functionele vereisten zijn diensten die het systeem moet leveren/de functies die het moet vervullen.
Niet functionele vereisten hebben vaak te maken met de beperkingen die aan een systeem opgelegd worden.
-> Grenzen waarbinnen de ontwerpers en programmeurs moeten werken.
Een voorbeeld geven van een aggregatie-associatie en een compositie-associatie en beknopt uitleggen wat de betekenis precies is
Aggregatie:
Een aggregatie geeft expliciet aan dat er tussen de klassen een ‘bestaat uit’ verband bestaat.
- Een land bestaat uit provincies, een boek uit een aantal hoofdstukken
Compositie:
Een compositie is een sterke aggregatie waarbij het geheel nadrukkelijk eigenaar is van de delen. Als het geheel wordt gekopieerd of verwijderd, worden de delen met het object mee gekopieerd of verwijderd.
- Een voorbeeld van een compositierelatie is die tussen een schaakbord en de
vlakken van een schaakbord, of tussen een persoon en zijn lichaamsdelen.
Het belang van prioriteiten voor vereisten uitleggen
Meestal zijn er meer functionele eisen dan het budget toelaat om te realiseren. Prioriteiten laten toe om te selecteren welke eisen eerst gerealiseerd moeten worden.
Als de functionele eisen wijzigen tijdens de ontwikkeling, helpen prioriteiten bij het
herdefiniëren van de scope van het project
Het MoSCoW-principe uitleggen.
MoSCoW principe is een manier om duidelijke prioriteiten te stellen voor de vereisten:
De afkorting van MoSCoW komt van de volgende vereisten:
- Must have – fundamentele vereisten voor het informatiesysteem, zonder deze is het systeem nutteloos.
- Should have – Verhogen de waarde van het systeem, maar ook zonder deze vereisten is het systeem bruikbaar.
- Could have – Vereisten met een beperkte waarde voor het systeem, kunnen zonder problemen uit het systeem weggelaten worden.
- Want to have but will not have this time around – Waardevolle vereisten die kunnen wachten. Worden pas ontwikkeld na de ontwikkeling van de andere eisen uit de andere categorieën.
Uitleggen wat een extends- en een includes-relatie tussen use-cases zijn, en wat hun betekenis is.
Extends-relatie:
Generalisatierelatie waarin een een use-case een algemene use-case uitbreidt door er acties aan toe te voegen.
- De use-case in kwestie omvat dan enig gedrag van de andere usecase.
Includes-relatie:
Generalisatierelatie waarin een use-case een andere usecase gebruikt, waarbij het gedrag van de algemene usecase eveneens als deel van de gespecialiseerde use-case wordt opgenomen.
Uitleggen hoe use-cases getest kunnen worden.
Het testen van use cases kan door middel van:
Verificatie:
Bevestigt dat het systeem correct of volgens de opgestelde specificaties ontwikkeld is;
Vindt plaats als er al werkende onderdelen zijn
Validatie:
Zorgt ervoor dat het systeem in ontwikkeling voldoet aan de behoeften van de klant/eindgebruiker. Vindt al vroeg in het ontwikkelingsproces plaats
