Resume
Software Analysis Samenvatting HoGent
- Cours
- Software Analysis
- Établissement
- Hogeschool Gent (HoGent)
Samenvatting van het vak Software Analysis, in het 1ste bachelor van het traject Toegepaste Informatica (TI)
[Montrer plus]
2 revues
Par: maerten1 • 10 mois de cela
Par: achilebatier • 10 mois de cela
Aperçu du contenu
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
Les avantages d'acheter des résumés chez Stuvia:
Qualité garantie par les avis des clients
Les clients de Stuvia ont évalués plus de 700 000 résumés. C'est comme ça que vous savez que vous achetez les meilleurs documents.
L’achat facile et rapide
Vous pouvez payer rapidement avec iDeal, carte de crédit ou Stuvia-crédit pour les résumés. Il n'y a pas d'adhésion nécessaire.
Focus sur l’essentiel
Vos camarades écrivent eux-mêmes les notes d’étude, c’est pourquoi les documents sont toujours fiables et à jour. Cela garantit que vous arrivez rapidement au coeur du matériel.
Foire aux questions
Qu'est-ce que j'obtiens en achetant ce document ?
Vous obtenez un PDF, disponible immédiatement après votre achat. Le document acheté est accessible à tout moment, n'importe où et indéfiniment via votre profil.
Garantie de remboursement : comment ça marche ?
Notre garantie de satisfaction garantit que vous trouverez toujours un document d'étude qui vous convient. Vous remplissez un formulaire et notre équipe du service client s'occupe du reste.
Auprès de qui est-ce que j'achète ce résumé ?
Stuvia est une place de marché. Alors, vous n'achetez donc pas ce document chez nous, mais auprès du vendeur TomDeBakker. Stuvia facilite les paiements au vendeur.
Est-ce que j'aurai un abonnement?
Non, vous n'achetez ce résumé que pour €5,49. Vous n'êtes lié à rien après votre achat.
Peut-on faire confiance à Stuvia ?
4.6 étoiles sur Google & Trustpilot (+1000 avis)
79202 résumés ont été vendus ces 30 derniers jours
Fondée en 2010, la référence pour acheter des résumés depuis déjà 14 ans