Stijn Hoppenbrouwers Software Engineering les 1 Algemene inleiding en Requirements Engineering.

Presentatie over: "Stijn Hoppenbrouwers Software Engineering les 1 Algemene inleiding en Requirements Engineering."— Transcript van de presentatie:

1 Stijn Hoppenbrouwers Software Engineering les 1 Algemene inleiding en Requirements Engineering

2 Overzicht 12 weken (effectief, dus vakantie niet meegerekend)
Onderwerpen (zoals nu voorzien, dus ruwweg): Requirements engineering en analyse Technisch ontwerp Implementatie (middels Cordys tool) Testen Documentatie Invoeren Evaluatie proces/produkt Rapid prototyping

3 Overzicht - 2 4 weken RE engineering 4 weken Tool & implementatie
4 weken Testen en invoeren/documenteren (en eindevaluatie) per week 6 uur: 3 lesuren plus evenveel zelfwerkzaamheid; twee groepen van 4?

4

5

6

7

8 Denken voor je doet: waarom eigenlijk?
Waarom niet gewoon “lekker bouwen”? Discussie: Complexiteit van software Kwaliteit van software Complexiteit en kwaliteit: proces versus produkt Complexiteit en kwaliteit: techniek versus mens/organisatie Stakeholder inbreng: wie weet wat het beste? Voorspelbaarheid (en de beperkingen daarvan) Kosten van en problemen met late wijzigingen Maar ook: wijzigingen tijdens het project

9 Requirements Engineering
System engineering WHY (probleem, situatie) WHAT (hoe de oplossing er voor de werker/gebruiker uit ziet; “black box”) HOW (concrete, technische oplossing; “white box”) Zo stap-voor-stap nadenken is logisch, maar soms werkt het qua volgorde toch wat anders Logica en werkvolgorde: bezie ze apart, en respecteer beide

10 WHAT-HOW WHAT – HOW onderscheid: vaak lastig
Kabouter-metafoor: flauw maar handig WHAT voor HOW?

11 WHY and WHAT “Probleembeschrijving” maakt dit expliciet. Dit is een soort negatief ingestoken beschrijving van het “why” WHY voor WHAT?

12 Functionele en non-functionele requirements
Functioneel: “wat het systeem voor de gebruikers doet” (Concreet: “wat het systeem tegen de gebruiker zegt, en wat de gebruiker tegen het systeem zegt”) Non-functioneel: “niet wat de gebruiker er aan heeft, maar randbepalingen daarop”: Security, dependability, availability, usability, learnability, … Misleidend: “non-functionale requirements” hebben wel degelijk te maken met functionaliteit, alleen op een wat minder directe manier Non-functionals zijn lastig! Ze hebben vaak forse technische gevolgen

13 Opdrachten week 1 Onderwerp
Wat voor systeem wil je gaan bouwen? Welk probleem lost het op? (probleemstelling) Wat is de bredere context? Voor wie bouw je het systeem? (stakeholder analyse) Rollen benoemen maar ook concrete personen Gebruikers Managers Anderen? Aanpak: ga eens met diverse mensen praten; beschouw je eigen groep evt. als stakeholders Kun je leuke systemen bedenken? Kun je die ook aan een realistische toepassingsomgeving hangen?

14 Soort van systeem? Implementatie: Cordys Process Factory
Hou het klein en overzichtelijk: Liever een beperkte maar goede applicatie dan een hoop plannen zonder werkend systeem Je kunt ook klein beginnen en later uitbreiden, maar zorg dat je minstens een functionele kern hebt die echt werkt Denk aan applicaties voor gebruik door scholieren,, leraren, of de schooladministratie (maar uitzonderingen zijn bespreekbaar)