Samenvatting

Samenvatting Software engineering vragen opgelost

0 keer verkocht

Vak
Software engineering

Instelling
Universiteit Antwerpen (UA)

Alle vragen die aanbod kunnen komen tijdens de examens zijn opgelost in dit document. Pasop enkele dingen kunnen niet gerenderd zijn omdat dit gemaakt is via obsidian, dit geldt enkel voor pictogrammen dus aangeraden om het te studeren met de nodige slides van de leerkracht.

[Meer zien]

Voorbeeld 4 van de 52 pagina's

Bekijk voorbeeld

Geupload op 19 september 2024
Aantal pagina's 52
Geschreven in 2023/2024
Type Samenvatting

€9,49

In winkelwagen

Op verlanglijstje

100% tevredenheidsgarantie
Direct beschikbaar na je betaling
Lees online óf als PDF
Geen vaste maandelijkse kosten

SE Questions for every chapter
Questions of Software Engineering course, also answered in Dutch

Intro

Summary i
How does Software Engineering differ from programming?
Programmeren is de taak dat we uitvoeren om een product te kunnen verkrijgen. Terwijl
Software Engineering het gehele process is om tot aan het product te komen.
Bijvoorbeeld. het consulteren van wat het product moet omvatten (Requirements) met de
klant, de verschillende risico's dat kunnen voorkomen bij het maken van een bepaalde
feature, de kwaliteit van het product bij een tussentijdse en/of eindevaluatie, enz.
"Software Engineering is a state-of-the-art profession dedicated to designing, implementing
and modifying software on time and within budget so that it is of higher quality, more
affordable, maintainable and faster to build."
"Multi-person construction of multi-version programs "
"Software engineering is different from other engineering disciplines"
Why is programming only a small part of the cost of a “real” software project ?
Er is veel tijd nodig om te weten wat de klant wilt verkrijgen van het product. Dit moet duidelijk
zijn voor zowel klant als voor ons.
We moeten nagaan of sommige features risico's omvatten dat we moeten voor nakijken of
oppassen. (Na elke tussentijdse bespreking)
Daarnaast moet er tijdens elke tussentijdse bespreking ook een validatie/verificatie gedaan
worden, m.a.w. we gaan na of we het juiste maken en kijken na of we dit op een juiste manier

, doen. Indien dit niet zo is, moeten we dit weer opnieuw doen.
Er is daarnaast ook bij elke bespreking een check nodig of het nog nuttig is om verder aan het
project te werken, dit heeft ook een grondige bespreking nodig en kan ook wat tijd kosten
indien dit niet duidelijk is.
We hebben dan ook nog een plan nodig om aan te geven hoe we te werk gaan (development
plan).
Naast het documenteren, hebben we ook testing, dat apart gezien wordt van de
"implementatie".
En het programmeren komt dan na al deze stappen dat in slechte gevallen meerdere iteraties
moet overlopen worden.
Het programmeren kan ook lang duren maar dit is vergeleken het "plan" opstellen een
fractie van tijd.
Give a definition for “traceability”.
Traceability in context van software engineering kan in verschillende vlakken besproken:
Kunnen we nagaan wat de impact zou zijn van een bepaalde aanpassing op verschillende
components van het product?
Hoe kunnen we dit doen?
Relaties bijhouden:
Van component -> requirements dat de aanwezigheid veroorzaakte.
Van requirements volgens de impact van een component die is aangepast.
What is the difference between analysis and design?
Analysis: is de "What?", dus het modelleren en specificeren van de requirements .
Design:
Is de "How?", modelleren en specificeren van de oplossing.
System design (architecture) + detailed design (object design, formal spec).
Dus het verschil ligt dat de analyse specificeert wat we gaan maken en dat design zegt ons
vertelt hoe we dit gaan doen.
Explain verification and validation in simple terms.
Verification: maken we het juist?
Validation: maken we het juiste?
Why is the “waterfall” model unrealistic? Why is it still used?
Why is the “waterfall” model unrealistic?
Complete: realistisch kan een klant niet alle specificaties direct specificeren.
Idealistic: realistisch gaan we door meerdere iteraties (tools en organisatie belemmeren
dit)
Time: Een werkend product is alleen zichtbaar op het einde van de process, wat
problemen kan zorgen indien er iets fout is gelopen
Change: Onhandig en duur indien er aanpassingen moeten gemaakt worden aan de
requirements. Bijvoorbeeld process loopt fout op het einde of een requirement is fout
gedefinieerd en dit is in 1 van de latere stages van het process dan kan dit zorgen voor
veel problemen.
Why is it still used?

, Het watervalmodel is populair bij het hogere management, omdat het zichtbaar is: het is
eenvoudig om de voortgang van projecten te controleren.
Het is een linear traject dus alles bouwt op elkaar dus het is makkelijk te weten in
welke stage we zitten van het project --> visibility
Omdat het opbouwend is, is er veel controle over het project, namelijk indien er geen
voortgang is in een bepaalde stage kunnen we niet verder naar het volgende stage.
Can you explain the difference between iterative development and incremental development?
Iterative development:
We itereren door een volgorde van stappen opnieuw en opnieuw om uiteindelijk een
eindresultaat te bekomen. We gaan gecontroleerd stukjes van het product opbouwen om
verbetering te verkrijgen.
+ "we get things wrong before we get them right."

Incremental development:
Hier splitsen we ons product in verschillende stukjes en gaan we stapgewijs te werk. We
streven naar product dat op elk moment bruikbaar is. We streven naar vroege en kleine
resultaten.
" always having a running version."
How do you decide to stop in the spiral model?
Extra uitleg in verband met de 4 fases van spiral model:
Determine objectives: waar we de requirements opbouwen en verschillende oplossingen
bekijken indien plan A faalt.
Daarna hebben we risk analyse, waarbij we de risico bekijken op de componenten op
basis van verschillende aspecten. Dit kan zowel risico's op basis van de requirements zijn
of risico's op basis van de budget.
Daarna maken we gebruik van de plan die we gemaakt hebben in de vorige twee stages
om iets te ontwerpen en te testen.
Als laatste doen we een evaluatie en kijken we of het een succes was of een faal. En
plannen we de volgende iteratie.
Het stoppen wordt bepaald door een risk analyse, we checken of het nog waard is of nog
verder te werken aan het project.

, How do you identify risk? How do you asses a risk? Which risks require action?
How do you identify risk?
Op basis van een "risk item checklist". Dit checklist is uniek voor bepaalde gevallen,
bijvoorbeeld andere programmeertalen.
How do you asses a risk?
Voor elke risk factor bepalen we een likelihood en de impact van de risk
3 point scale
low - medium - high
5 point scale
[impact] insignificant - minor - moderate - major - catastrophic
[likelihood] almost certain - likely - possible - unlikely - rare
Met deze projectie gaan we dan bepalen hoe belangrijk een risk is, dus hoe hoog zijn
impact is met zijn likelihood.
Which risks require action?
important risk factors: dus risks met hoge impact en medium tot hoge likelihood
What is Failure Mode and Effects Analysis (FMEA)?
Een stap voor stap aanpak om alle mogelijke fouten te detecteren in een bepaalt design, een
fabricageproces of assemblageproces, of een product of een service.
Failure mode: alle mogelijke fouten die voor kunnen komen die mogelijk de klant kan
storen. Deze fouten kunnen toekomstige fouten zijn of momentele fouten.
Effect Analysis: Is de analyse van de consequenties van deze fouten.
List the 6 principles of extreme programming.
Fine scale feedback
Dit is gerelateerd tot de feedback, regelmatige feedback en gedetailleerde feedback
wordt onder verwisseld tussen elkaar.
Continuous process
Heeft te maken met de constante progress. Dit zorgt voor "Continuous Integration" waarbij
elk probleem dat te gemoed komt, zo spoedig nodig opgelost wordt.
Shared understanding
Dit is verband dat de groep een zelfde visie hebben over het product en werken op een
gelijkaardige manier zodat er geen verwarring komt in notaties.
Programmer welfare
Dit heeft te maken met de snelheid dat een programmeur kan werken, we willen namelijk
dat hij geen burnout op loopt en dat de code nog steeds kwaliteit vol blijft. Dit heeft ook te
maken met de netheid van de code, waardoor het verstaan van de code beter wordt.
Coding
Dit heeft te maken met modelling van onze product dat dan later omgezet wordt naar
code. Daarnaast zoeken we hier ook naar alternatieve oplossingen.
Testing
Dit heeft te maken met het testen van de code:
Voor alle code bestaat er een Unit test (automated test om te checken of het juist is).
Alle code moeten deze Unit test slagen.

Dit zijn jouw voordelen als je samenvattingen koopt bij Stuvia:

Bewezen kwaliteit door reviews

Studenten hebben al meer dan 850.000 samenvattingen beoordeeld. Zo weet jij zeker dat je de beste keuze maakt!

In een paar klikken geregeld

Geen gedoe — betaal gewoon eenmalig met iDeal, Bancontact of creditcard en je bent klaar. Geen abonnement nodig.

Focus op de essentie

Studenten maken samenvattingen voor studenten. Dat betekent: actuele inhoud waar jij écht wat aan hebt. Geen overbodige details!

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 jasonliu1. Stuvia faciliteert de betaling aan de verkoper.

Zit ik meteen vast aan een abonnement?

Nee, je koopt alleen deze samenvatting voor €9,49. Je zit daarna nergens aan vast.

Is Stuvia te vertrouwen?

4,6 sterren op Google & Trustpilot (+1000 reviews)

Afgelopen 30 dagen zijn er 69252 samenvattingen verkocht

Opgericht in 2010, al 15 jaar dé plek om samenvattingen te kopen

Start met verkopen