Samenvatting
Software Analysis Samenvatting HoGent
- Vak
- Instelling
Samenvatting van het vak Software Analysis, in het 1ste bachelor van het traject Toegepaste Informatica (TI)
[Meer zien]Voorbeeld 10 van de 33 pagina's
Voorbeeld 10 van de 33 pagina's
In winkelwagen
In winkelwagen
2 beoordelingen
Door: maerten1 • 10 maanden geleden
Door: achilebatier • 10 maanden geleden
Verkoper
Volgen
TomDeBakker
Ontvangen beoordelingen
Voorbeeld van de inhoud
Software AnalysisTom De Bakker
23/12/2023
1
,Inhoudstafel
Software Analysis 4
Andere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Hoofdstuk 1: Inleiding 5
Hoofdstuk 2: Software-ontwikkelingsproces 6
2.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Hoe verloopt een project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Projectleider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Analist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.3 Ontwerper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.4 Programmeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.5 Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Methodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 Waterval methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2 Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1 Voordelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6 Voorbeelden van fouten bij softwareprojecten (oefeningen) . . . . . . . . . . . . . . . . . . . . . . . 8
2.6.1 Year 1990 bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6.2 Leap-year bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6.3 Interface misuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.4 Late and over budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.5 On-time delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.6 Unnecessary complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Hoofdstuk 3: Behoeftenanalyse 10
3.1 Vereisten/behoeften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Verschillende soorten actors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Hoe lezen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3 Use case: Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Activity diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1 Bouwstenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2 Stappenplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Testscenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Hoofdstuk 4: Domeinmodel 18
4.1 Doel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Onderdelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Conceptuele klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2 Associaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3 Generalisatie/specialisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.4 Aggregatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5 Compositie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.5 Associatieklasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Stappenplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1 Identificeren van de kandidaatsklassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2 Selecteren van de conceptuele klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.3 Associaties leggen en/of aanpassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.4 Attributen toevoegen, verplaatsen en/of schrappen . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.5 Optimalisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Oefeningen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Hoofdstuk 5: System Sequence Diagram (SSD) & Operation Contract (OC) 27
5.1 Doel van systeem sequentiediagram (SSD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2 Onderdelen van systeemsequentiediagram (SSD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2
, 5.2.1 Deelnemer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.2 Levenslijn per deelnemer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.3 Systeemoperatie(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.4 Antwoord op een systeemoperatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.5 Herhaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.6 Externe use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3 Stappenplan om een systeemsequentiediagram (SSD) op te stellen . . . . . . . . . . . . . . . . . . 30
5.4 Doel van Operation Contract (OC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5 Onderdelen van een Operation Contract (OC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.1 Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.2 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.3 Cross references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.4 Precondities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5.5 Postcondities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.6 Stappenplan om een Operation Contract (OC) op te stellen . . . . . . . . . . . . . . . . . . . . . . 32
3
, SOFTWARE ANALYSIS
Software Analysis
Andere
• Op Chamilo onder Documenten , staan oefeningen voor in werkcolleges (geen modeloplossingen)
• Leerpad (Per hoofdstuk theorie):
∘ Theorie slides
∘ Begeleidende tekst: extra uitleg/aanvullende nota’s bij de slides.
■ Geen één op één uitleg van de slides. Alles staat wel uitgelegd in de tekst, maar op een andere
manier/volgorde
∘ Uitgewerkte oefeningen (slides) stap voor stap met modeloplossing
• Alles wordt ook beschouwd als te kennen leerstof
∘ Het is mogelijk dat er één of twee extra pdf’s op Chamilo worden gezet dat we niet konden zien in
de les. Deze zijn ook leerstof
Evaluatie
• 85% - Schriftelijk examen gesloten boek
∘ Theorie vragen:
■ Bespreek agile, …
■ Meerkeuze schemas
■ Er komen ook theorie vragen uit H6, dat dus ook leren
■ …
∘ Alle mogelijke schema’s worden gevraagd en moeten kunnen getekend wordent
• 15% - Ontwerp taak
∘ Opdracht staat onder Documenten/UI Taak
∘ Groepjes van 4
■ Module Cursusgroepen op Chamilo
∘ Een mockup maken van hoe een website er moet uitzien. Enkel mockup, niks echt maken in html/css
∘ Je moet de taak indienen, anders ben je gebuisd (wordt gezien als afwezig) voor het volledige vak
∘ Er wordt alleen gekeken naar de laatste indiening, je kan dus zeker op voorhand al eens indienen
∘ Indienen bij Opdrachten
■ Je kan ook controleren als teamgenoten al hebben ingediend
■ Altijd namen + klasgroep erbij
2de kans is nieuwe taak + examen opnieuw
4
, HOOFDSTUK 1: INLEIDING
Hoofdstuk 1: Inleiding
Nothing of note
5
, HOOFDSTUK 2: SOFTWARE-ONTWIKKELINGSPROCES
Hoofdstuk 2: Software-ontwikkelingsproces
2.1 Inleiding
Elk software-ontwikkelingsproces bestaat uit drie basiselementen:
• Scope (features, functionality)
• Resources (kost, budget)
• Schedule (tijd)
Binnen die 3 moet er een goeie afweging worden gemaakt. Een product moet voldoende functionaliteit hebben,
maar dient toch binnen een bepaalde tijd/kost geleverd worden.
Van alle functionaliteiten dient een analyse gemaakt te worden. Zodat er gefocused kan worden op wat voor de
klant de meeste waarde heeft binnen diens budget/tijd.
De scope van het project bevat dan alle te realiseren functionaliteiten.
2.2 Hoe verloopt een project
Eenmaal de scope, middelen (resources) en budget vastliggen, kunnen we nog niet onmiddelijk beginnen on-
twikkelen.
Om het project de meeste kansen op slagen te geven is het nodig om minstens volgende stappen uit te werken:
• (Requirements/vereisten verzamelen)
• Analyse
• Ontwerp
• Programeren
• Testen
• Integratie
∘ Dit is slechts van toepassing als we functionaliteit toevoegen aan reeds bestaande software.
• (Onderhoud)
Dingen tussen haakjes heb ik toegevoegd uit de les, stond niet in begeleidende tekst
2.3 Rollen
Een team dat het project uitwerkt bestaat uit:
• Analist
• Ontwerper
• Programmeur
• Tester
• Projectleider
De volgende behoren niet rechtsreeks tot het team maar spelen wel een belangrijke rol:
• Klant/opdrachtgever
• Managment/business
2.3.1 Projectleider
• Deze persoon leidt het project.
• Beslist of het project wordt verder gezet of niet.
• Verzorgt juiste communicatie naar het team + klant + management
2.3.2 Analist
• Deze persoon zorgt voor de correcte vertaling van de eisen(requirements) van de klant, waaraan het
eindproduct moet voldoen.
∘ Als de analist de eisen niet goed capteert, zal dit in latere fasen in het project leiden tot fouten alleen
maar groter worden.
6
,2.4 Methodes HOOFDSTUK 2: SOFTWARE-ONTWIKKELINGSPROCES
∘ Moet zorgen dat ontwerpers aan slag kunnen met de eisen.
■ AKA niet-technologisch communiceren met de klant, maar wel met de ontwerpers.
Voorbeeld van het belangrijkste schema, en dus communicatiemiddel, is het domeinmodel.
2.3.3 Ontwerper
• Zet de niet technische stukken die gebruikt worden om met de klant te communiceren, om naar diepgaan-
dere documenten die de programmeurs kunnen gebruiken.
Voorbeeld van zo een document, is een sequence diagram met bijhorende operation contracts.
2.3.4 Programmeur
• Zet de documenten van de analist en ontwerper om in code met klassen en methoden om het product met
alle functionaliteiten te verwezenlijken.
2.3.5 Tester
• Moet de fouten vinden in een programma, voor de release van het programma.
Vanuit de analyse, is het voornaamste document dat de tester kan gebruiken het activity diagram. Omdat
dit alle mogelijke wegen beschrijft die het programma kan volgen bij het uitvoeren van de functionaliteiten.
2.4 Methodes
2.4.1 Waterval methode
• Bedoelt om projecten in één keer af te werken
• Je doet alles in opeenvolgende volgorde, je begint eerst bij de analyse, dan ontwerp enz.
• Je doet elke blok in één keer, je kan niet terug.
∘ Dit is niet optimaal, de kans dat het project voldoet aan de eisen van de klant is klein.
Dit leidt tot hoge kosten als het project alsnog aangepast zou moeten worden.
Voor kleine projecten van maximum 3 maanden, kan de waterval methode voor projecten echter wel nog goed
werken.
2.4.1.1 Nadeel De klant is eigenlijk niet meer betrokken bij het project, slechts in het begin. Maar eenmaal
die eerste klant/requirements stap is afgerond, check je niet meer met de klant.
Daarom dat het bij korte/kleine projecten wel goed werkt, omdat in 3 maanden tijd de klant niet echt van
gedacht zal veranderen. Maar bij langere projecten is het beter om voor de Agile manier te gaan.
2.4.2 Agile
Agile werd ontwikkelt om het grootste probleem van de waterval methode, gebrekkige communicatie met de
klant, weg te werken.
Agile deelt een project op in kleinere stukken (=iteraties), hierdoor kan er makkelijk ingespeeld worden op
wijziginen doorheen het project.
Per iteratie worden er doelen (=milestones) vastgelegd die het product moet kunnen op het einde van de iteratie.
De feedbackloop proberen we zo kort mogelijk te houden, 2-6 weken.
Agile is gebouwd rond 2 pijlers:
• Iteratief
∘ We zullen het software-ontwikkelingsproces een aantal keer herhalen om zo het project in kleinere
stukken af te werken.
∘ Voor elk stuk van het project, worden de functionaliteiten steeds ontwikkelt op de volgende manier:
■ Analyse
■ Ontwerp
■ Implementatie
■ Testen
■ Integratie
7
,2.5 UML HOOFDSTUK 2: SOFTWARE-ONTWIKKELINGSPROCES
Aangezien we steeds in kleine stukjes werken die worden geintegreerd in de rest van het project.
Kunnen we eventuele probelemen veel gemakkelijker oplossen.
∘
• Incrementeel
∘ We zullen een project stap per stap(per iteratie) uitbreiden met nieuwe functionaliteiten, in plaats
van alles in één keer te ontwikkelen.
■ Dit zorgt ervoor dat de klant snel werkbare software heeft en zo ook betere feedback kan geven.
□ Dit in tegenstelling tot de watervalmethode, waar de klant pas feedback kan geven wanneer
het product is afgewerkt.
Als er bij de Waterfall aanpak een probleem optreedt, dan moet je helemaal opnieuw beginnen.
Bij Agile werk je in stapjes, dus je kan direct ingrijpen vanaf dat het misloopt.
2.5 UML
Unified Modeling Language
• Een modelleertaal om objectgeoriënteerde analyses en ontwerpen voor een informatiesysteem te kunnen
maken.
• UML zelf is geen methode, maar een notatiewijze die bij verschillende methodes (zoals Iteratief-
Incrementeel) kan worden gebruikt.
2.5.1 Voordelen
UML is een model dat we zullen gebruiken om de werkelijkheid te modelleren, te abstraheren tot wat we strikt
nodig hebben.
• Communicatie
• Visualisatie
• Transformatie = UML vergemakkelijkt de overgang van:
∘ Analyse ⇒ ontwerp
∘ Ontwerp ⇒ programmeren
∘ Programemren ⇒ testen
2.6 Voorbeelden van fouten bij softwareprojecten (oefeningen)
Bepaal per voorbeeld welke rol(len) het meeste in de fout zijn gegaan:
De rollen die in fout kunnen zijn:
• Klant
• Analist
• Ontwerper
• Programmeur
• Tester
• Project leider
2.6.1 Year 1990 bug
In 1992, Mary from Winona, Minnesota, received an invitation to attend a kindergarten. Mary was 104 at the
time.
In fout:
• Ontwerper
∘ De leeftijd in de databank die ontworpen is door de ontwerper, berekend de leeftijd op basis van de
laatste 2 cijfers van het jaartal. Dit is een foute beslissing van de ontwerper.
• Tester
∘ De tester had moeten testen wat er gebeurt als mensen ouder zijn dan 100 jaar
2.6.2 Leap-year bug
A supermarket was fined $1000 for having meat around 1 day too long, on February 29, 1988. The computer
program printing the expiration date on the meat labels did not take into account that 1988 was a leap year.
8
,2.6 Voorbeelden van fouten bij softwareprojectenHOOFDSTUK
(oefeningen) 2: SOFTWARE-ONTWIKKELINGSPROCES
In fout:
• Programmeur
∘ Moet ervoor zorgen dat de berekening van de houdsbaarheids datum altijd klopt, ook als er schrikkel-
jaren zijn
• Tester
∘ Had moeten testen met schrikkeljaren
2.6.3 Interface misuse
On April 10, 1990, in London, an underground train left the station without its driver. The driver had taped
the button that started the train, relying on the system that prevented the train from moving when doors were
open. The train operator had left his train to close a door which was stuck. When the door was finally shut,
the train simply left.
In fout:
• Klant
∘ De klant is koning, dus ookal is die in fout mag je die nooit de schuld geven.
• (Analist)
∘ Had moeten aangeven aan de klant dat de veiligsheid procedure niet zo veilig is.
• Tester
2.6.4 Late and over budget
In 2002, the Swanick Air Traffic Control system covers all the enroute air traffic over England and Wales. The
system was delivered substantially over budget (cost £623 million, originally planned at £350 million) and 6
years late. Two major upgrades of the system were delivered after training of the traffic controllers had started.
In fout:
• Project leider
∘ Heeft de kosten & looptijd van project niet goed ingeschat
• Programmeur
∘ “Er waren nog 2 major upgrades nodig” wat betekent dat er nog redelijk wat bugs waren
2.6.5 On-time delivery
After 18 months of development, a $200-million system was delivered to a health insurance company in Wisconsin
in 1984. However, the system did not work correctly: $60 million in overpayments were issued. The system
took 3 years to fix.
In fout:
• Analist
• Ontwerper
• Programmeur
• Tester
Aangezien er geen specifieke details gekend zijn waarom het systeem niet correct werkte kunnen we hier niet
een bepaalde rol verantwoordelijk maken
2.6.6 Unnecessary complexity
The C-17 cargo plane by McDonnell Douglas ran $500 million over budget because of problems with its avionics
software. The C-17 included 19 onboard computers, 80 microprocessors, and 6 different programming languages.
In fout:
• Klant
∘ Systeem is te complex, maar klant is koning dus hij kan niet in fout zijn
• Ontwerper
∘ Aangezien alles te complex gemaakt werd, b.v. door 6 verschillende programmeertalen, kunnen we
er vanuit gaat het systeem niet goed ontworpen werd.
9
, HOOFDSTUK 3: BEHOEFTENANALYSE
Hoofdstuk 3: Behoeftenanalyse
Figure 1: Use cases te kennen leerstof
3.1 Vereisten/behoeften
Vereisten zijn de behoeften van de klant waaraan het project moet voldoen.
Deze kunnen opgedeeld worden in twee categorieën:
• Functionele vereisten
∘ Functionele vereisten zijn de eisen die beschrijven wat het programma moet kunnen. I.e. welke
functionaliteiten beschikbaar zullen zijn op het systeem.
• Niet-functionele vereisten
∘ Niet-functionele vereisten beschrijven daarentegen hoe het systeem die functionele vereisten moet
uitvoeren of hoe ze er moeten uitzien. Deze vereisten hebben geen invloed op het functionele ontwerp
van het systeem zelf.
Voorbeeld auto:
• Functionele vereisten:
∘ Gas geven
∘ Schakelen
∘ Richting aangeven
∘…
• Niet-functionele vereisten
∘ HOE gas geven (met pedaal of knop op stuur)
∘ Automatische of manuele versnellingsbak
∘ Kleur van richtingaanwijzer
∘…
3.2 Use case
Een use case is een tekstuele beschrijving van een taak voor een bepaalde partij. Het beschrijft het gebruik (=
de interactie tussen actor en systeem) van het systeem om een bepaald doel te verwezenlijken.
Hierin is het belangrijk dat alle acties die het systeem moet uitvoeren om een taak te realiseren duidelijk
beschreven worden. Een use case beschijft alleen maar wat het systeem moet doen, niet hoe het dit moet
uitvoeren.
Dit is een document dat begrijpbaar moet zijn voor alle belanghebbende partijen. Het is met andere woorden
geen technisch document om communicatie met de klant te vereenvoudigen. De use case zelf is een contract
tussen de belanghebbende partijen en het ontwikkelteam.
3.2.1 Verschillende soorten actors
Primary actor Dit is de actor die het verhaal (use case) zal starten en dus als doel heeft om de functionaliteit
te verwezenlijken.
Supporting actor Om zijn doel te bereiken, heeft de primary actor soms nood aan een andere actor die
een bepaald subdoel verwezenlijkt om het totale doel te bereiken. Die andere actor wordt de supporting actor
10
Voordelen van het kopen van samenvattingen bij Stuvia op een rij:
√ Verzekerd van kwaliteit door reviews
Stuvia-klanten hebben meer dan 700.000 samenvattingen beoordeeld. Zo weet je zeker dat je de beste documenten koopt!
Snel en makkelijk kopen
Je betaalt supersnel en eenmalig met iDeal, Bancontact of creditcard voor de samenvatting. Zonder lidmaatschap.
Focus op de essentie
Samenvattingen worden geschreven voor en door anderen. Daarom zijn de samenvattingen altijd betrouwbaar en actueel. Zo kom je snel tot de kern!
Veelgestelde vragen
Wat krijg ik als ik dit document koop?
Je krijgt een PDF, die direct beschikbaar is na je aankoop. Het gekochte document is altijd, overal en oneindig toegankelijk via je profiel.
Tevredenheidsgarantie: hoe werkt dat?
Onze tevredenheidsgarantie zorgt ervoor dat je altijd een studiedocument vindt dat goed bij je past. Je vult een formulier in en onze klantenservice regelt de rest.
Van wie koop ik deze samenvatting?
Stuvia is een marktplaats, je koop dit document dus niet van ons, maar van verkoper TomDeBakker. Stuvia faciliteert de betaling aan de verkoper.
Zit ik meteen vast aan een abonnement?
Nee, je koopt alleen deze samenvatting voor $5.97. Je zit daarna nergens aan vast.
Is Stuvia te vertrouwen?
4,6 sterren op Google & Trustpilot (+1000 reviews)
Afgelopen 30 dagen zijn er 80467 samenvattingen verkocht
Opgericht in 2010, al 14 jaar dé plek om samenvattingen te kopen
Laatst bekeken door jou
