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.
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.
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 jasonliu1. Stuvia facilite les paiements au vendeur.
Est-ce que j'aurai un abonnement?
Non, vous n'achetez ce résumé que pour €9,49. Vous n'êtes lié à rien après votre achat.
