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

Post on 13-May-2015

237 views 2 download

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

Software Engineering les 1

Algemene inleiding enRequirements Engineering

Stijn Hoppenbrouwers

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• http://www.theprocessfactory.com/

• 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)