,Theorie
Week 1
Kernactiviteiten Software Ontwikkelen:
® Dit is een vaste volgorde
® Ieder gebied heeft eigen problematiek en technieken
1. Specificeren wat de software moet oplossen
2. Ontwerpen hoe de software dat moet doen
3. Bouwen wat ontworpen is
4. Testen dat de software voldoet aan wat ontworpen is
5. Verifiëren dat de software het probleem oplost wat gespecificeerd is
Het V-model:
Software-systeem functies:
Hoofdfuncties
Voorbeeld:
Van functies bij Word
Subfuncties
Hoofdfunctie: documenten maken
Subfuncties: een document openen, letters en symbolen typen in het Subsubfuncties
document, lettergrootte veranderen, lettertype veranderen ect.
Ontwikkelmethode
Hoe worden de kernactiviteiten gebruikt om de softwarefuncties te bouwen?
1. Lineair, analytisch
Requirements Denken
Lineair: Waterval
1. Eerst alle benodigde functies bepalen en Ontwerp Denken
specificeren
2. Daarna een totaal ontwerp maken Software Denken + doen
3. Vervolgens het gehele ontwerp
programmeren Testen Doen
4. Testen
5. Tot slot het gehele software systeem laten
Verifiëren
accepteren/implementeren
Doen
Analytisch: Activiteiten 1 & 2 uitvoeren door beredeneren
Let op: de kosten per defect nemen toe naar maten je veder in het software ontwikkelproces
komt (een defect tijdens het opstellen van requirements kost minder dan tijdens de testfase)
, 2. Experimenteel, incrementeel, iteratief
Iteratief:
1. Eerst enkele (belangrijke) functies Requirements Denken
bepalen en specificeren Iteratie: verbeter
2. Daarna een deelontwerp maken
3. Vervolgens het deelontwerp
Ontwerp Iteratie en increment
Denken
programmeren
4. Testen Software Denken + doen
5. Beoordelen of het resultaat gewenst is
5.1 Zo nee, ga terug naar 1 (iteratie) Testen Doen
5.2 Zo ja, voeg nieuwe functie toe
(iteratie, increment) Verifiëren
Doen
Experimenteel: activiteiten 1 en 2 uitvoeren
door: Prototyping: trail and error
3. Een Combinatie van de twee is ook mogelijk
In de praktijk:
In deze module gaan we dieper in op de eerste stap van de lineaire module (= eerst alle benodigde
functies bepalen en specificeren) dit wordt ook wel Requirements Management genoemd.
Waarom Requirements Management?
Om bij het gewenste resultaat te komen en
misverstanden te voorkomen
Het proces om bij de gewenste requirements te komen
werkt Top-down (zie afbeelding)
Zo moet je eerst duidelijk voor welke situatie je
requirements opstelt, vervolgens moet je duidelijk krijgen
waar je product aan moet gaan voldoen (op
(non-)functioneel gebied). Om vervolgens pas de
software specificaties/ technische requirements op te
stellen
Het requirements-proces in vogelvlucht:
Work Product Requirements
Conception Scoping investigation determimation Definition Construction
Er is een goals Buc's opstellen PUC's Requirements developer
idee/opdracht constraints opstellen opstellen
business event list
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 pien21x. 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.