1 Hoofdstuk 2: softwareontwikkelingsproces
= kader dat vastlegt hoe een softwareproject wordt aangepakt
= Een methode om de activiteiten in verband met creatie, oplevering en onderhoud van
softwareproblemen te organiseren
Elk ontwikkelingsproces bevat volgende onderdelen:
1. Requirements of vereisten verzamelen door te luisteren naar de opdrachtgever
2. Requirements analyseren
3. Een ontwerp of plan maken
4. Implementeren: het ontwerp uitvoeren
5. Testen en controleren
Er zijn 2 methoden:
- Waterval
Analyse/ontwerp fout? Niet omkeerbaar, dus project is ook niet correct
Deze methode is slechter dan de agile-methode
Enkel voor kleine projecten
- Agile
Iteratief-incrementele softwareontwikkelingsmethode
Wendbaar/flexibel
Iteratief = je werkt in stappen, na elke stap lever je
werkende software op, je krijgt feedback van de
gebruiker.
Incrementeel = bij elke stap bouw je verder aan je
software.
,1.1 Het Agile Manifesto
Het is het document waarin agile softwareontwikkeling is gedefinieerd en bevat de
belangrijkste principes van agile werken.
Deze principes zijn:
BELANGRIJKER BELANGRIJK
Individuen en interacties Processen en tools
Werkende software Uitgebreide documentatie
Samenwerking met de klant Contractonderhandelingen
Antwoorden op wijzigingen Volgen van een plan
Belangrijkste principes achter het Agile Manifesto
- Hoogste prioriteit: klant tevredenheid
- Accepteren dat gebruikerseisen en wensen veranderen, ook later in het project
- Lever geregeld werkende software op
- Business en ontwikkelaars werken dagelijks samen, “face-to-face” communicatie binnen
het team
- Werkende software is de eerste meting van vooruitgang
1.2 Iteratief-incrementele ontwikkeling
Think big, develop small: werk in iteraties
Een iteratie bevat steeds dezelfde activiteiten
De tijdsbesteding aan iedere activiteit kan gaandeweg tijdens het project veranderen
Iteraties duren meestal 2 tot 6 weken, dit is niet strikt
1.3 Risico: agile vs. waterval
Projectrisico is het risico dat het project niet op tijd klaar zal zijn, niet binnen het budget en
niet met de juiste scope.
Er is een groter projectrisico wanneer je gebruik maakt van de watervalmethode omdat je
minder feedback krijgt.
1.4 OOA/D
De analyse en ontwerpstappen in meer detail
OOAnalyse binnen iteratief-incrementeel:
- De opdrachtgever formuleert een probleem
- Analist noteert het verhaal en de eisen
- Analist vertaalt het verhaal naar use cases
- Ontwerper stelt aan de hand van use case(s) scenario’s en testen op
- Ontwerper stelt aan de hand van use case(s) het domeinmodel op
- Vervolgens wordt het systeem sequentie diagram (SSD) opgesteld
- Opstellen van de nodige operation contracts (OC)
Samenvatting Analyse I 1
, 1.5 UML
= unified modelig 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
Voordelen:
- Communicatie
- Visualisatie
- Transformatie = UML vergemakkelijkt de overgang
Analyse ontwerp
Ontwerp programmeren
Programmeren testen
2 Hoofdstuk 3: use cases
2.1 Functionele vereisten vs. niet-functionele vereisten
Functionele vereisten (functional requirements)
- Mapt de inputs van het programma op de outputs
- Beschrijft wat het systeem moet kunnen
- Vergelijk met: auto
Niet-functionele vereisten (non-functional requirements)
- Betreft alle andere beperkingen/vereisten
Bijvoorbeeld:
Het systeem moet snel werken
Het systeem moet mooi zijn
…
- Vergelijk met: gele sportauto met rode wielen
2.2 Use cases
Een use case omvat alle manieren waarop het systeem gebruikt kan worden om een
bepaald doel voor een bepaalde gebruiker te behalen
Een complete set use cases geeft je alle zinvolle manieren om het systeem te gebruiken en
illustreert de waarde die dit zal opleveren
Actor + systeem + doel
Opgelet! Een use case definieert niet hoe het systeem het implementeert
Nut van de use cases:
- Modelleert de functionele vereisten
- Eenheid van planning:
Identificeren
Schat ontwikkeltijd in
- Vormen de basis voor
functionele testen
- Vormen de basis voor
verdere ontwikkelingen
2.3 Use case diagram
Overzicht van alle rollen
Samenvatting Analyse I 2
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller jaspergoegebeur. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $3.74. You're not tied to anything after your purchase.