Samenvatting: Systeemanalyse en Databanken
Inleiding
Beleidsinformatica vormt de brug tussen bedrijfskunde en IT. Binnen systeemanalyse en
databanken kijken we niet naar de technische aspecten, maar wel naar bv. welk
informatiesysteem moet er gebouwd worden, wat zijn de vereisten,…
Analyse: het proces van het begrijpen en specifiëren in detail wat een informatiesysteem moet
doen →Zeer belangrijk voor een succesvol IS, een domein waar zowel kennis, ervaring als
technieken belangrijk zijn – (analyse = bedrijfsproblemen oplossen d.m.v. informatiesysteem)
Ontwerp: het proces van het specifiëren in detail hoe de componenten van het IS fysiek
geïmplementeerd moeten worden
Vaardigheden en kennis:
- Technische (programmeren, computers, netwerken, databanken, tools)
- Bedrijfskundige (organisatie, marketing, accounting, specifieke bedrijfskennis)
- Menselijke (communicatie, onderhandeling, empathie,..)
Systeemanalist:
Gaat de bedrijfskundige problematiek onderzoeken en probeert er oplossingen voor te vinden.
→deze kan oplossingen zoeken in de context van zowel klassieke als innovatieve
informatiesystemen.
→Verschil tussen klassieke en innovatieve informatiesystemen – moeilijkheidsgraad om
vereisten te bepalen:
- Klassieke – vereisten makkelijk te bepalen
o Want er zijn reeds veel systemen ontwikkeld
- Innovatieve – vereisten moeilijk te bepalen
o Want je bouwt een ‘nieuw’ systeem, waarvan er weinig vergelijkbare systemen
zijn
1
,Hoofdstuk 1: Levenscyclus van informatiesystemen
Hoe is de levenscyclus van informatiesystemen opgebouwd?
Stap 1) Projectplanningsfase (meestal allereerste stap)
o Er wordt een scope vastgelegd
▪ we kijken naar wat we willen bouwen
o Een eerste schatting van budget en timing waarmee het project kan worden gerealiseerd
o Schatting van de haalbaarheid (zowel technische als bedrijfskundige)
Stap 2) Analysefase
o De vereisten worden verzameld en gemodelleerd
Stap 3) Ontwerpfase
o Het ontwerp van verschillende aspecten wordt in beschouwing genomen
▪ Databank, gebruikersinterface, netwerkaspecten, systeeminterfaces,
toepassingsarchitectuur
▪ →wordt steeds technischer
Stap 4) Implementatiefase
o Het systeem wordt geprogrammeerd, getest (integratie-en acceptatietesten), data wordt
geconverteerd, gebruikers getraind, software geïnstalleerd
▪ Integratie-testen : alle verschillende modules samen testen → vaak blijken
dingen apart wel te werken maar in combinatie komen er weer errors naar boven
of werkt het systeem ineens trager dan verwacht
▪ Acceptatie-testen: Het systeem wordt gegeven aan een eindgebruiker. De
eindgebruiker moet bevestigen of het systeem werkt en/of er bepaalde zaken
ontbreken
➔Wanneer Acceptatie-test is goedgekeurd, kan informatiesysteem in productie
gaan
Stap 5) Onderhoudsfase (duurste fase)
o Deze fase omvat alle wijzigingen aan het informatiesysteem nadat het in productie werd
genomen
2
,2 Visies wat betreft Levenscycli van een informatiesysteem
o Predictieve levenscyclus:
• Gaat ervan uit dat men vooraf goed kan bepalen wat de vereisten zijn
• Wordt gebruikt indien de technologie goed gekend is, of er weinig risico’s zijn aan
de implementatie
• Nadeel: niet in staat om zich aan te passen aan digitale wereld – snelle
veranderingen – moeilijk om al in het begin alle vereisten concreet
ondubbelzinnig en volledig vast te leggen
o Bv. watervalmodel, gemodifieerd watervalmodel
o Adaptieve levenscyclus
• Pakt nadelen van predictieve aan → Gaat ervan uit dat vereisten onzeker zijn en
snel en voortdurend kunnen veranderen. – Meer realistische aanname
• Levenscyclus waar sprake is van iteratieve en incrementele ontwikkeling (=
herhaald uitvoeren van meerdere fasen in de cyclus)
o Bv. Spiraalmodel, UP, Extreme Programming, Agile, Scrum
→Men verschuift steeds meer naar deze adaptieve vormen van ontwikkeling:
→ Digitale economie – snelle verandering – zowel op economische vlak (vereisten in logistiek,…)
idem in technologie:
- Als prijs van project gebaseerd is op vereisten (bv. 16 schermen) en je begint te
programmeren en je hebt 18 schermen – klopt initiële prijs niet meer
- Stel je bouwt een technologie die je uiteindelijk niet gebruikt – schatting van tijd en prijs
kloppen dan niet meer
1.1. Predictieve levenscycli
Waterval ontwikkeld in 1970. Is een veel gebruikte levenscyclus voor het ontwikkelen van
informatiesystemen
→Gaat uit van een strikt sequentiële uitvoering van de levenscyclusfasen. Elke fase wordt
slechts één keer doorlopen
→Het watervalmodel is document-gebaseerd. → Elke fase wordt doorlopen en heeft als
eindresultaat een document dat formeel door alle stakeholders gehandtekend moet worden.
→waarna het resultaat bevroren wordt en er geen wijzigingen meer plaats kunnen vinden.
Elke fase heeft specifieke documenten:
- Einde Projectplanningsfase: document met scopebepaling, inschatting van
planning/budget en haalbaarheid
- Einde Analysefase: document met volledige/consistente/ondubbelzinnige verzameling
van vereisten + verschillende modellen
- Einde Ontwerpfase: Analysemodellen worden omgezet naar technische modellen en
fysiek ontwerp → documenten worden steeds technischer
- Einde Implementatiefase: dikwijls de duurste fase, dus financiële risico’s hier het
grootst, na de integratietesten zal de eindgebruiker acceptatietesten uitvoeren –
controleert of de functionaliteit corresponderen met de vereisten die vermeld waren in
document van analysefase
3
, Mogelijkse dat in de acceptatie-test gebruiker zegt: ‘Dit is niet wat ik heb gevraagd’ → Je kan dan
samen met de eindgebruiker terugkijken naar het analysedocument waar hij zijn handtekening
heeft ondergezet.. hoe kan het dan dat er iets fout is?
→Eindgebruikers begrijpen de documenten vanaf design-fase niet meer, ze worden te
technisch, dus ze lezen deze niet meer
Nadelen Watervalmodel:
- Hoeveelheden documentatie kunnen erg snel oplopen → duur en tijdrovend →formele
goedkeuringsproces vergt veel inspanning (handtekeningen van iedereen – structured
walkthrough)
- Laat weinig ruimte voor feedback om terug te koppelen naar documenten of resultaten
van voorgaande fases een die documenten goedgekeurd zijn en bevroren
o Stel bij wijziging van wetgeving – niet in staat om dingen aan te passen
o ➔watervalmodel geschikt voor statische / sterk gereglementeerde omgevingen
(banken,defensie…)
▪ Waarbij vereisten vanaf het begin mogelijk zijn om volledig consistent en
ondubbelzinnig in kaart te brengen
o Niet mogelijk om terug omhoog te klimmen in de waterval
o Niet mogelijk om digitale economie te volgen
- Relatief traag qua doorlooptijd door de strikt sequentiële aanpak
o Alle interviews, integratie van alle stakeholders
o Alle handtekeningen verzamelen
o een volgende fase kan pas gestart worden als de vorige volledig is afgerond
- Grote tijdspanne tussen periode wanneer eindgebruikers afhaken (einde analyse fase –
documenten worden te technisch) en het afronden van de project – waar ze er terug bij
komen →acceptatie-testen
- Problemen komen vaak voor op het einde van de levenscyclus, bij de acceptatie en
integratietesten → Daar waar al het geld en tijd op is, krijg je ineens te kampen met grote
problemen → Moeilijke dingen op het einde doen = te laat, →testen komt eigenlijk te laat
→Waarom dan toch zoveel gebruikt? → Iedereen weet op voorhand prijs en duur van het project
4
Inleiding
Beleidsinformatica vormt de brug tussen bedrijfskunde en IT. Binnen systeemanalyse en
databanken kijken we niet naar de technische aspecten, maar wel naar bv. welk
informatiesysteem moet er gebouwd worden, wat zijn de vereisten,…
Analyse: het proces van het begrijpen en specifiëren in detail wat een informatiesysteem moet
doen →Zeer belangrijk voor een succesvol IS, een domein waar zowel kennis, ervaring als
technieken belangrijk zijn – (analyse = bedrijfsproblemen oplossen d.m.v. informatiesysteem)
Ontwerp: het proces van het specifiëren in detail hoe de componenten van het IS fysiek
geïmplementeerd moeten worden
Vaardigheden en kennis:
- Technische (programmeren, computers, netwerken, databanken, tools)
- Bedrijfskundige (organisatie, marketing, accounting, specifieke bedrijfskennis)
- Menselijke (communicatie, onderhandeling, empathie,..)
Systeemanalist:
Gaat de bedrijfskundige problematiek onderzoeken en probeert er oplossingen voor te vinden.
→deze kan oplossingen zoeken in de context van zowel klassieke als innovatieve
informatiesystemen.
→Verschil tussen klassieke en innovatieve informatiesystemen – moeilijkheidsgraad om
vereisten te bepalen:
- Klassieke – vereisten makkelijk te bepalen
o Want er zijn reeds veel systemen ontwikkeld
- Innovatieve – vereisten moeilijk te bepalen
o Want je bouwt een ‘nieuw’ systeem, waarvan er weinig vergelijkbare systemen
zijn
1
,Hoofdstuk 1: Levenscyclus van informatiesystemen
Hoe is de levenscyclus van informatiesystemen opgebouwd?
Stap 1) Projectplanningsfase (meestal allereerste stap)
o Er wordt een scope vastgelegd
▪ we kijken naar wat we willen bouwen
o Een eerste schatting van budget en timing waarmee het project kan worden gerealiseerd
o Schatting van de haalbaarheid (zowel technische als bedrijfskundige)
Stap 2) Analysefase
o De vereisten worden verzameld en gemodelleerd
Stap 3) Ontwerpfase
o Het ontwerp van verschillende aspecten wordt in beschouwing genomen
▪ Databank, gebruikersinterface, netwerkaspecten, systeeminterfaces,
toepassingsarchitectuur
▪ →wordt steeds technischer
Stap 4) Implementatiefase
o Het systeem wordt geprogrammeerd, getest (integratie-en acceptatietesten), data wordt
geconverteerd, gebruikers getraind, software geïnstalleerd
▪ Integratie-testen : alle verschillende modules samen testen → vaak blijken
dingen apart wel te werken maar in combinatie komen er weer errors naar boven
of werkt het systeem ineens trager dan verwacht
▪ Acceptatie-testen: Het systeem wordt gegeven aan een eindgebruiker. De
eindgebruiker moet bevestigen of het systeem werkt en/of er bepaalde zaken
ontbreken
➔Wanneer Acceptatie-test is goedgekeurd, kan informatiesysteem in productie
gaan
Stap 5) Onderhoudsfase (duurste fase)
o Deze fase omvat alle wijzigingen aan het informatiesysteem nadat het in productie werd
genomen
2
,2 Visies wat betreft Levenscycli van een informatiesysteem
o Predictieve levenscyclus:
• Gaat ervan uit dat men vooraf goed kan bepalen wat de vereisten zijn
• Wordt gebruikt indien de technologie goed gekend is, of er weinig risico’s zijn aan
de implementatie
• Nadeel: niet in staat om zich aan te passen aan digitale wereld – snelle
veranderingen – moeilijk om al in het begin alle vereisten concreet
ondubbelzinnig en volledig vast te leggen
o Bv. watervalmodel, gemodifieerd watervalmodel
o Adaptieve levenscyclus
• Pakt nadelen van predictieve aan → Gaat ervan uit dat vereisten onzeker zijn en
snel en voortdurend kunnen veranderen. – Meer realistische aanname
• Levenscyclus waar sprake is van iteratieve en incrementele ontwikkeling (=
herhaald uitvoeren van meerdere fasen in de cyclus)
o Bv. Spiraalmodel, UP, Extreme Programming, Agile, Scrum
→Men verschuift steeds meer naar deze adaptieve vormen van ontwikkeling:
→ Digitale economie – snelle verandering – zowel op economische vlak (vereisten in logistiek,…)
idem in technologie:
- Als prijs van project gebaseerd is op vereisten (bv. 16 schermen) en je begint te
programmeren en je hebt 18 schermen – klopt initiële prijs niet meer
- Stel je bouwt een technologie die je uiteindelijk niet gebruikt – schatting van tijd en prijs
kloppen dan niet meer
1.1. Predictieve levenscycli
Waterval ontwikkeld in 1970. Is een veel gebruikte levenscyclus voor het ontwikkelen van
informatiesystemen
→Gaat uit van een strikt sequentiële uitvoering van de levenscyclusfasen. Elke fase wordt
slechts één keer doorlopen
→Het watervalmodel is document-gebaseerd. → Elke fase wordt doorlopen en heeft als
eindresultaat een document dat formeel door alle stakeholders gehandtekend moet worden.
→waarna het resultaat bevroren wordt en er geen wijzigingen meer plaats kunnen vinden.
Elke fase heeft specifieke documenten:
- Einde Projectplanningsfase: document met scopebepaling, inschatting van
planning/budget en haalbaarheid
- Einde Analysefase: document met volledige/consistente/ondubbelzinnige verzameling
van vereisten + verschillende modellen
- Einde Ontwerpfase: Analysemodellen worden omgezet naar technische modellen en
fysiek ontwerp → documenten worden steeds technischer
- Einde Implementatiefase: dikwijls de duurste fase, dus financiële risico’s hier het
grootst, na de integratietesten zal de eindgebruiker acceptatietesten uitvoeren –
controleert of de functionaliteit corresponderen met de vereisten die vermeld waren in
document van analysefase
3
, Mogelijkse dat in de acceptatie-test gebruiker zegt: ‘Dit is niet wat ik heb gevraagd’ → Je kan dan
samen met de eindgebruiker terugkijken naar het analysedocument waar hij zijn handtekening
heeft ondergezet.. hoe kan het dan dat er iets fout is?
→Eindgebruikers begrijpen de documenten vanaf design-fase niet meer, ze worden te
technisch, dus ze lezen deze niet meer
Nadelen Watervalmodel:
- Hoeveelheden documentatie kunnen erg snel oplopen → duur en tijdrovend →formele
goedkeuringsproces vergt veel inspanning (handtekeningen van iedereen – structured
walkthrough)
- Laat weinig ruimte voor feedback om terug te koppelen naar documenten of resultaten
van voorgaande fases een die documenten goedgekeurd zijn en bevroren
o Stel bij wijziging van wetgeving – niet in staat om dingen aan te passen
o ➔watervalmodel geschikt voor statische / sterk gereglementeerde omgevingen
(banken,defensie…)
▪ Waarbij vereisten vanaf het begin mogelijk zijn om volledig consistent en
ondubbelzinnig in kaart te brengen
o Niet mogelijk om terug omhoog te klimmen in de waterval
o Niet mogelijk om digitale economie te volgen
- Relatief traag qua doorlooptijd door de strikt sequentiële aanpak
o Alle interviews, integratie van alle stakeholders
o Alle handtekeningen verzamelen
o een volgende fase kan pas gestart worden als de vorige volledig is afgerond
- Grote tijdspanne tussen periode wanneer eindgebruikers afhaken (einde analyse fase –
documenten worden te technisch) en het afronden van de project – waar ze er terug bij
komen →acceptatie-testen
- Problemen komen vaak voor op het einde van de levenscyclus, bij de acceptatie en
integratietesten → Daar waar al het geld en tijd op is, krijg je ineens te kampen met grote
problemen → Moeilijke dingen op het einde doen = te laat, →testen komt eigenlijk te laat
→Waarom dan toch zoveel gebruikt? → Iedereen weet op voorhand prijs en duur van het project
4
