Liam Debels
VIVES Hogeschool
Analyis & Design
,1. Inleiding................................................................................................................ 3
1.1. Inhoud van de cursus ..................................................................................... 3
1.2. Wat is systeemanalyse ................................................................................... 3
1.3. Belang van systeemanalyse ............................................................................ 4
1.4. De fasen in softwareontwikkeling .................................................................... 5
1.5. Het waterval model ........................................................................................ 5
1.6. Iteratieve ontwikkeling: Scrum ........................................................................ 6
1.7. Waterval, Scrum en de relatie met de opdrachtgever ........................................ 7
1.8. Object georiënteerd werken: werken met objecten en klassen ........................... 7
1.9. OOA en OOP.................................................................................................. 9
1.10. UML - Unified Modeling Language ................................................................... 9
1.11. Opdrachten en oefeningen ........................................................................... 10
2. Vooronderzoek .....................................................................................................10
2.1. Doel van het vooronderzoek .......................................................................... 13
2.2. Analyse van de huidige situatie ..................................................................... 14
2.3. Beschrijving van de behoeften (gewenste situatie) .......................................... 14
2.4. Korte beschrijving van de oplossingsalternatieven .......................................... 17
2.5. Selectie van de beste oplossing .................................................................... 17
2.6. Evaluatie van de oplossing ............................................................................ 18
2.7. Verificatie van het vooronderzoek .................................................................. 19
2.8. Technieken voor het vooronderzoek ............................................................... 20
2.9. Het gebruik van activiteitendiagrammen ........................................................ 20
2.10. Samenvatting van het vooronderzoek ............................................................ 21
3. Analyse- of specificatiefase...................................................................................26
3.1. Inleiding ...................................................................................................... 26
3.2. Conceptuele lagen ....................................................................................... 27
3.3. Statische systeemstructuur (domeinmodel) .................................................. 27
3.4. Vaststellen van de vereisten .......................................................................... 31
3.5. Modelleren met use-cases ........................................................................... 39
3.6. Dynamische systeemstructuur (business events) ........................................... 40
3.7. Verificatie van de analysefase ....................................................................... 44
3.8. Rapid prototyping ........................................................................................ 49
3.9. Een analyse moet een levend document zijn .................................................. 49
3.10. Samenvatting van de analysefase.................................................................. 49
4. Realisatiefase ......................................................................................................51
4.1. Inleiding ...................................................................................................... 51
4.2. De watervalaanpak ...................................................................................... 51
4.3. Het V-model ................................................................................................ 51
4.4. De iteratieve aanpak..................................................................................... 53
4.5. Agile en Scrum ............................................................................................ 53
4.6. Mix and match ............................................................................................. 55
,Cursus
1. Inleiding
1.1. Inhoud van de cursus
Analysefase – Behoeften van de opdrachtgever geanalyseerd en wordt de huidige situatie precies en duidelijk
in kaart gebracht.
- Goed gefundeerd ontwerp vorm uiteindelijk de basis
Software van hoge kwaliteit kan NIET ontwikkeld worden zonder analyse
Objectgeoriënteerde analysetechnieken
- Merode-methode
o KU Leuven
- De technieken die er deel van uitmaken zijn het belangrijkste
o Vereistenanalyse
o Domeinanalyse
Andere methodes gebruiken gelijkaardige technieken, als je die van Merode kent is dat makkelijker
werken met die andere later
Ontwikkelen = iteratief proces
1.2. Wat is systeemanalyse
Systeem – Een geautomatiseerd informaticasysteem
- Informatici helpen ontwikkelen, implementatie, onderhoud
- Software én hardware
Systeemanalyse – verzamelnaam voor een reeks technieken en methodes om de informatiebehoefte van de
gebruiker ondubbelzinnig in kaart te brengen (analyse) en om het informatiesysteem op hoog (logisch) niveau te
gaan ontwerpen (ontwerp)
Doel Kost Info Omgang Beveiliging
DOBIK systeemanalyse
Doel: Aan de informaticabehoefte van de gebruiker voldoen
Domeinanalyse – Uiteenrafelen en structureren van het probleem, zodat je het goed genoeg begrijpt om er een
informatiesysteem voor te onwikkelen.
Probleemdomein – domein
Vereistenanalyse – Verwachtingen van opdrachtgevers en eindgebruikers van het systeem
Beschrijving probleemdomein (domeinanalyse) + vereistenanalyse = analyse
- Analyse = WAT
Ontwerp – Conceptuele voorstelling van de oplossing zonder details
- Hoe de oplossing logisch gestructureerd is
HOE
Liam Debels VIVES Hogeschool Pagina 3 van 58
, Ontwikkeling van informatiesysteem = 2 partijen
- Opdrachtgever en/of eindgebruiker
- Informaticateam
Communicatiestoornissen mogelijk
Gebruikers weten niet wat ze willen
Informatici luisteren niet
Complexe vragen
Onhaalbaar
Oplossing voor die communicatiestoornissen
- Systeemanalist die de behoeften van de opdrachtgever en eindegebruikers probeert te achterhalen
o Dat vertalen naar exacte technische specificaties waarmee de programmeur aan de slag kan
Eventueel derde partij is het management of de financier
- Programmeren is duur
o Verantwoorde wijze gebeuren
Systeemanalist moet ervoor zorgen dat hij het management voorziet van de nodig info om deze controle
mogelijk te maken (worden de middelen op een verantwoorde wijze uitgegeven?).
Analist krijg probleem aangeleverd
- Onderzoek doen naar de behoeften en structuur van het probleemdomein
o Interviews, lectuur van bedrijfsdocumenten, observaties,….
Teksten zijn niet overzichtelijk, dubbelzinnig, onvolledig
o Modellen
Goede analyses = modelgedreven
- Geven visueel beeld van een probleem of een oplossingsvoorstel
- Vereenvoudiging van de realiteit vanuit een bepaald perspectief
Modellen – Gebaseerd op ondubbelzinnige definities van symbolen en hun betekenis. Teksten bevatten heel
wat vaagheden en dubbelzinnigheden.
- Een model vergt bepaalde implementatiedetails die op het ogenblik of vanuit dat perspectief niet
relevant zijn.
- Elk model toont 1 aspect van de realiteit
Modellen alleen zijn niet voldoende, moeten aangevuld worden met teksten om het systeem volledig te
beschrijven.
Vaardigheden van een analist, Analytisch denken, abstractie maken, synthetisch denken, communiceren,
schriftelijk rapporteren, presenteren, vergaderen, kennis van.
1.3. Belang van systeemanalyse
Een goed informatiesyeem
- Bruikbaar
- Betrouwbaar BOBGOF
- Gebruiksvriendelijk
- Onderhoudbaar → grootste kost
- Flexibel
Informatiesystemen die dat allemaal zijn zijn eerder zeldzaam
Men heeft een goed maar nutteloos systeem gebouwd
Veel IT-projecten zijn te duur en te laat klaar
Levens in handen van software maar dikwijls onvoldoende betrouwbaar
Belang van analyse
Trial-and-errormethode = niet effectief
Goede analyse en ontwerp noodzakelijk → succes softwareproject verhogen
Liam Debels VIVES Hogeschool Pagina 4 van 58
VIVES Hogeschool
Analyis & Design
,1. Inleiding................................................................................................................ 3
1.1. Inhoud van de cursus ..................................................................................... 3
1.2. Wat is systeemanalyse ................................................................................... 3
1.3. Belang van systeemanalyse ............................................................................ 4
1.4. De fasen in softwareontwikkeling .................................................................... 5
1.5. Het waterval model ........................................................................................ 5
1.6. Iteratieve ontwikkeling: Scrum ........................................................................ 6
1.7. Waterval, Scrum en de relatie met de opdrachtgever ........................................ 7
1.8. Object georiënteerd werken: werken met objecten en klassen ........................... 7
1.9. OOA en OOP.................................................................................................. 9
1.10. UML - Unified Modeling Language ................................................................... 9
1.11. Opdrachten en oefeningen ........................................................................... 10
2. Vooronderzoek .....................................................................................................10
2.1. Doel van het vooronderzoek .......................................................................... 13
2.2. Analyse van de huidige situatie ..................................................................... 14
2.3. Beschrijving van de behoeften (gewenste situatie) .......................................... 14
2.4. Korte beschrijving van de oplossingsalternatieven .......................................... 17
2.5. Selectie van de beste oplossing .................................................................... 17
2.6. Evaluatie van de oplossing ............................................................................ 18
2.7. Verificatie van het vooronderzoek .................................................................. 19
2.8. Technieken voor het vooronderzoek ............................................................... 20
2.9. Het gebruik van activiteitendiagrammen ........................................................ 20
2.10. Samenvatting van het vooronderzoek ............................................................ 21
3. Analyse- of specificatiefase...................................................................................26
3.1. Inleiding ...................................................................................................... 26
3.2. Conceptuele lagen ....................................................................................... 27
3.3. Statische systeemstructuur (domeinmodel) .................................................. 27
3.4. Vaststellen van de vereisten .......................................................................... 31
3.5. Modelleren met use-cases ........................................................................... 39
3.6. Dynamische systeemstructuur (business events) ........................................... 40
3.7. Verificatie van de analysefase ....................................................................... 44
3.8. Rapid prototyping ........................................................................................ 49
3.9. Een analyse moet een levend document zijn .................................................. 49
3.10. Samenvatting van de analysefase.................................................................. 49
4. Realisatiefase ......................................................................................................51
4.1. Inleiding ...................................................................................................... 51
4.2. De watervalaanpak ...................................................................................... 51
4.3. Het V-model ................................................................................................ 51
4.4. De iteratieve aanpak..................................................................................... 53
4.5. Agile en Scrum ............................................................................................ 53
4.6. Mix and match ............................................................................................. 55
,Cursus
1. Inleiding
1.1. Inhoud van de cursus
Analysefase – Behoeften van de opdrachtgever geanalyseerd en wordt de huidige situatie precies en duidelijk
in kaart gebracht.
- Goed gefundeerd ontwerp vorm uiteindelijk de basis
Software van hoge kwaliteit kan NIET ontwikkeld worden zonder analyse
Objectgeoriënteerde analysetechnieken
- Merode-methode
o KU Leuven
- De technieken die er deel van uitmaken zijn het belangrijkste
o Vereistenanalyse
o Domeinanalyse
Andere methodes gebruiken gelijkaardige technieken, als je die van Merode kent is dat makkelijker
werken met die andere later
Ontwikkelen = iteratief proces
1.2. Wat is systeemanalyse
Systeem – Een geautomatiseerd informaticasysteem
- Informatici helpen ontwikkelen, implementatie, onderhoud
- Software én hardware
Systeemanalyse – verzamelnaam voor een reeks technieken en methodes om de informatiebehoefte van de
gebruiker ondubbelzinnig in kaart te brengen (analyse) en om het informatiesysteem op hoog (logisch) niveau te
gaan ontwerpen (ontwerp)
Doel Kost Info Omgang Beveiliging
DOBIK systeemanalyse
Doel: Aan de informaticabehoefte van de gebruiker voldoen
Domeinanalyse – Uiteenrafelen en structureren van het probleem, zodat je het goed genoeg begrijpt om er een
informatiesysteem voor te onwikkelen.
Probleemdomein – domein
Vereistenanalyse – Verwachtingen van opdrachtgevers en eindgebruikers van het systeem
Beschrijving probleemdomein (domeinanalyse) + vereistenanalyse = analyse
- Analyse = WAT
Ontwerp – Conceptuele voorstelling van de oplossing zonder details
- Hoe de oplossing logisch gestructureerd is
HOE
Liam Debels VIVES Hogeschool Pagina 3 van 58
, Ontwikkeling van informatiesysteem = 2 partijen
- Opdrachtgever en/of eindgebruiker
- Informaticateam
Communicatiestoornissen mogelijk
Gebruikers weten niet wat ze willen
Informatici luisteren niet
Complexe vragen
Onhaalbaar
Oplossing voor die communicatiestoornissen
- Systeemanalist die de behoeften van de opdrachtgever en eindegebruikers probeert te achterhalen
o Dat vertalen naar exacte technische specificaties waarmee de programmeur aan de slag kan
Eventueel derde partij is het management of de financier
- Programmeren is duur
o Verantwoorde wijze gebeuren
Systeemanalist moet ervoor zorgen dat hij het management voorziet van de nodig info om deze controle
mogelijk te maken (worden de middelen op een verantwoorde wijze uitgegeven?).
Analist krijg probleem aangeleverd
- Onderzoek doen naar de behoeften en structuur van het probleemdomein
o Interviews, lectuur van bedrijfsdocumenten, observaties,….
Teksten zijn niet overzichtelijk, dubbelzinnig, onvolledig
o Modellen
Goede analyses = modelgedreven
- Geven visueel beeld van een probleem of een oplossingsvoorstel
- Vereenvoudiging van de realiteit vanuit een bepaald perspectief
Modellen – Gebaseerd op ondubbelzinnige definities van symbolen en hun betekenis. Teksten bevatten heel
wat vaagheden en dubbelzinnigheden.
- Een model vergt bepaalde implementatiedetails die op het ogenblik of vanuit dat perspectief niet
relevant zijn.
- Elk model toont 1 aspect van de realiteit
Modellen alleen zijn niet voldoende, moeten aangevuld worden met teksten om het systeem volledig te
beschrijven.
Vaardigheden van een analist, Analytisch denken, abstractie maken, synthetisch denken, communiceren,
schriftelijk rapporteren, presenteren, vergaderen, kennis van.
1.3. Belang van systeemanalyse
Een goed informatiesyeem
- Bruikbaar
- Betrouwbaar BOBGOF
- Gebruiksvriendelijk
- Onderhoudbaar → grootste kost
- Flexibel
Informatiesystemen die dat allemaal zijn zijn eerder zeldzaam
Men heeft een goed maar nutteloos systeem gebouwd
Veel IT-projecten zijn te duur en te laat klaar
Levens in handen van software maar dikwijls onvoldoende betrouwbaar
Belang van analyse
Trial-and-errormethode = niet effectief
Goede analyse en ontwerp noodzakelijk → succes softwareproject verhogen
Liam Debels VIVES Hogeschool Pagina 4 van 58
