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

of 14 /14
Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers

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

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

Software Engineering les 1

Algemene inleiding enRequirements Engineering

Stijn Hoppenbrouwers

Page 2: Software Engineering les 1 Algemene inleiding en Requirements 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

Page 3: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

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?

Page 4: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

4

Page 5: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

5

Page 6: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

6

Page 7: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

7

Page 8: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

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

Page 9: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

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

Page 10: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

10

WHAT-HOW

• WHAT – HOW onderscheid: vaak lastig

• Kabouter-metafoor: flauw maar handig

• WHAT voor HOW?

Page 11: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

11

WHY and WHAT

• “Probleembeschrijving” maakt dit expliciet. Dit is een soort negatief ingestoken beschrijving van het “why”

• WHY voor WHAT?

Page 12: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

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

Page 13: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

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?

Page 14: Software Engineering les 1 Algemene inleiding en Requirements Engineering Stijn Hoppenbrouwers.

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)