Ontwerp van informatiesystemen
H1: Wat is ‘Ontwerp van informatiesystemen’
Informatiesystemen
Informatiesystemen:
verzorgen invoer (input), verwerking, uitvoer (output) van informatie in functie
van informatiebehoeften van een gebruiker
- Soorten informatie
o Gestructureerd: getallen, tekstuele gegevens
o Semigestructureerd: e-mail, documenten
o Ongestructureerd: video, audio, afbeeldingen
- Soorten verwerking
o Aggregatie
o Selectie
o Sorteren
- Bestaat uit
IS = een socio-technisch systeem met manuele en automatische delen
o Hardware: incl. pc’s, servers, netwerken, ...
o Software: programma’s
o Bedrijfsprocessen/procedures (vb: The Antwerp Company)
o Mensen en andere
- Recente evoluties
o Content Management Systemen (CMS) zijn gericht op
semigestructureerde informatie
o Informatie IS het product, niet het bijproduct
Organisaties en IS
,Ontwerp van informatiesystemen
De organisatie bepaalt de bedrijfsprocessen, en dus de
informatiebehoeften van de gebruikers, en dus welke informatiesystemen
worden gebouwd
IS bouwen in een organisatie is een socio-technisch project met interne
impact (nieuwe bedrijfsprocessen, nieuwe hiërarchieën van
bevoegdheden, nieuwe taken, nieuwe machtsverhoudingen) en mogelijk
externe impact op de marktpositie
- Soorten IS
hangt af van hun plaats in de organisatie
o Transactie verwerkende systemen (Transaction Processing System -
TPS)
Een transactie is een atomair deel in een bedrijfsproces
Voorbeelden bij The Antwerp Company
Verkoop van een abonnement, aanwerving van een
medewerker
o Management Informatiesystemen (Management Information System
- MIS)
Ondersteunen gestructureerde beslissingen
Voorbeelden bij The Antwerp Company
Rapport van verkochte abonnementen per week,
elektronisch overzicht van nieuwe medewerkers
o Beslissingsondersteunende systemen (Decision Support Systems -
DSS)
Ondersteunen semigestructureerde beslissingen
Veelal op basis van kwantitatieve modellen en
sensitiviteitsanalyse
Voorbeelden bij The Antwerp Company
Berekenen van klantenprofielen, stockbeheer volgens
huidige en te verwachten verkopen
- Software engineering
o Ontstond eind ’60s in de software crisis
Programmeren was afhankelijk van individu (ad hoc)
Slecht gestructureerde programma’s (spaghetti-code)
Resultaat: slecht leesbaar en onderhoudbaar, veel fouten, te
laat
Software Engineering:
verwijst naar principes, methodologieën, methoden en technieken voor het
bouwen van kwalitatief hoogstaande informatiesystemen, is gericht op grote
systemen en streeft naar uniformiteit en standaardisatie ⇔ ad-hoc
Watervalmodel
ANALYSE – ONTWERP – IMPLEMENTATIE – TESTEN – ONDERHOUD
Analyse: weten hoe je wilt dat je huis eruitziet (niet-it’ers/ gebruikers)
Ontwerp: dat verslag vormt vertrekpunt van ontwerp (architect)
Implementatie: na goedkeuring, de programmeurs realiseren ontwerp (1ste stap
,Ontwerp van informatiesystemen
die door programmeurs wordt gedaan)
Testen: opdrachtgever en architect komen nakijken
Onderhoud: eens testfase afgerond is wordt IS in productie gebracht, alles wat na
die productie aan het systeem gebeurdt valt onder onderhoud
- Analyse (analist)
o Doel
vereisten volledig, consistent en ondubbelzinnig in kaart brengen in
de vereistenspecificatie = alles wat het IS moet kunnen, zeer niet
technisch
Wat moet het IS niet kunnen?: minstens even belangrijke
vraag want zo bespaar je geld en tijd
o Soorten vereisten
Functionele
Datavereisten
Procesvereisten: wordt neergeschreven in een use case
dat naam, scenario, stappenplan, … bevat
Niet-functionele
= beperkingen op de manier waarop het IS de functionele
vereisten realiseert
Performantie, onderhoudbaarheid, herbruikbaarheid,
beveiliging
o Belanghebbende
Interne mensen: budgetmanager, …
Externe mensen: klanten, gebruikers, …
- Ontwerp (ontwerper)
o Doel
de vraag ‘Hoe moet de software gestructureerd worden om
kwalitatief ’goed’ te zijn?’ beantwoorden
o Niveaus
Hoogniveau: welke software architectuur heb ik nodig
Laagniveau: gedetailleerd, beïnvloedt kwaliteit van IS
o Wicked design problem
alles heeft voor- en nadelen dus iemand nodig met voldoende kennis
over IS en over de vereisten zodat we best mogelijk ontwerp kunnen
opstellen
o Soorten
Gestructureerd
Object-georiënteerd
- Implementatie (programmeur)
o Doel
systeem zodanig programmeren in een taal dat software van hoge
kwaliteit ontstaat, denkwerk is al gebeurd nu enkel nog realisatie
Nuance: vaak is zowel denkwerk als praktijk nodig
- Testen
o Verificatie
werkt het systeem correct, de klassieke bugs oplossen
, Ontwerp van informatiesystemen
o Validatie
als het systeem correct werkt beantwoordt het dan ook aan de
informatiebehoefte van de eindgebruiker, lost het het probleem dat
er in de reële wereld was op
Voorbeeld: doel was om omzet te laten stijgen maar omzet
daalt
- Onderhoud
o Soorten
Perfectief: nieuwe vereisten door continue veranderende
wereld
Vroeger zag men dit als negatief en nu als positief
Adaptief: nieuwe hardware, besturingssysteem
Correctief: bugs
Preventief: software wordt steeds complexer (zie Lehman’s
laws) dus preventief investeren in het terug
leesbaar/begrijpbaar maken van software zodat je verslijting
tegengaat
o Lehman’s law
The law of continuing change:
een programma dat gebruikt wordt in de reële wereld moet
veranderen (evolueren), of het wordt minder en minder
bruikbaar
The law of increasing complexity:
de structuur van een programma dat evolueert wordt
complexer met de tijd, tenzij de nodige stappen worden
ondernomen om dit tegen te gaan
Software verslijt niet door gebruik maar door verandering want ze wordt
steeds moeilijker begrijpbaar waardoor je ze ook niet meer kan aanpassen
De combinatie van de 2 wetten zorgt voor het probleem dat software
steeds sneller verslijt wat het duurder maakt en daarom is preventief
onderhoud zo belangrijk
- Nuancering
lang niet alle projecten worden via het watermodel opgebouwd, het is
gewoon een goed basisvoorbeeld om zo andere moddelen makkelijker te
begrijpen
o Afhankelijk van
Verschillende fasen overlappen
Grote VS kleine software
Make or buy
Pakketten
o Andere modellen
Iteratief ontwikkelen
Methodologieën
H1: Wat is ‘Ontwerp van informatiesystemen’
Informatiesystemen
Informatiesystemen:
verzorgen invoer (input), verwerking, uitvoer (output) van informatie in functie
van informatiebehoeften van een gebruiker
- Soorten informatie
o Gestructureerd: getallen, tekstuele gegevens
o Semigestructureerd: e-mail, documenten
o Ongestructureerd: video, audio, afbeeldingen
- Soorten verwerking
o Aggregatie
o Selectie
o Sorteren
- Bestaat uit
IS = een socio-technisch systeem met manuele en automatische delen
o Hardware: incl. pc’s, servers, netwerken, ...
o Software: programma’s
o Bedrijfsprocessen/procedures (vb: The Antwerp Company)
o Mensen en andere
- Recente evoluties
o Content Management Systemen (CMS) zijn gericht op
semigestructureerde informatie
o Informatie IS het product, niet het bijproduct
Organisaties en IS
,Ontwerp van informatiesystemen
De organisatie bepaalt de bedrijfsprocessen, en dus de
informatiebehoeften van de gebruikers, en dus welke informatiesystemen
worden gebouwd
IS bouwen in een organisatie is een socio-technisch project met interne
impact (nieuwe bedrijfsprocessen, nieuwe hiërarchieën van
bevoegdheden, nieuwe taken, nieuwe machtsverhoudingen) en mogelijk
externe impact op de marktpositie
- Soorten IS
hangt af van hun plaats in de organisatie
o Transactie verwerkende systemen (Transaction Processing System -
TPS)
Een transactie is een atomair deel in een bedrijfsproces
Voorbeelden bij The Antwerp Company
Verkoop van een abonnement, aanwerving van een
medewerker
o Management Informatiesystemen (Management Information System
- MIS)
Ondersteunen gestructureerde beslissingen
Voorbeelden bij The Antwerp Company
Rapport van verkochte abonnementen per week,
elektronisch overzicht van nieuwe medewerkers
o Beslissingsondersteunende systemen (Decision Support Systems -
DSS)
Ondersteunen semigestructureerde beslissingen
Veelal op basis van kwantitatieve modellen en
sensitiviteitsanalyse
Voorbeelden bij The Antwerp Company
Berekenen van klantenprofielen, stockbeheer volgens
huidige en te verwachten verkopen
- Software engineering
o Ontstond eind ’60s in de software crisis
Programmeren was afhankelijk van individu (ad hoc)
Slecht gestructureerde programma’s (spaghetti-code)
Resultaat: slecht leesbaar en onderhoudbaar, veel fouten, te
laat
Software Engineering:
verwijst naar principes, methodologieën, methoden en technieken voor het
bouwen van kwalitatief hoogstaande informatiesystemen, is gericht op grote
systemen en streeft naar uniformiteit en standaardisatie ⇔ ad-hoc
Watervalmodel
ANALYSE – ONTWERP – IMPLEMENTATIE – TESTEN – ONDERHOUD
Analyse: weten hoe je wilt dat je huis eruitziet (niet-it’ers/ gebruikers)
Ontwerp: dat verslag vormt vertrekpunt van ontwerp (architect)
Implementatie: na goedkeuring, de programmeurs realiseren ontwerp (1ste stap
,Ontwerp van informatiesystemen
die door programmeurs wordt gedaan)
Testen: opdrachtgever en architect komen nakijken
Onderhoud: eens testfase afgerond is wordt IS in productie gebracht, alles wat na
die productie aan het systeem gebeurdt valt onder onderhoud
- Analyse (analist)
o Doel
vereisten volledig, consistent en ondubbelzinnig in kaart brengen in
de vereistenspecificatie = alles wat het IS moet kunnen, zeer niet
technisch
Wat moet het IS niet kunnen?: minstens even belangrijke
vraag want zo bespaar je geld en tijd
o Soorten vereisten
Functionele
Datavereisten
Procesvereisten: wordt neergeschreven in een use case
dat naam, scenario, stappenplan, … bevat
Niet-functionele
= beperkingen op de manier waarop het IS de functionele
vereisten realiseert
Performantie, onderhoudbaarheid, herbruikbaarheid,
beveiliging
o Belanghebbende
Interne mensen: budgetmanager, …
Externe mensen: klanten, gebruikers, …
- Ontwerp (ontwerper)
o Doel
de vraag ‘Hoe moet de software gestructureerd worden om
kwalitatief ’goed’ te zijn?’ beantwoorden
o Niveaus
Hoogniveau: welke software architectuur heb ik nodig
Laagniveau: gedetailleerd, beïnvloedt kwaliteit van IS
o Wicked design problem
alles heeft voor- en nadelen dus iemand nodig met voldoende kennis
over IS en over de vereisten zodat we best mogelijk ontwerp kunnen
opstellen
o Soorten
Gestructureerd
Object-georiënteerd
- Implementatie (programmeur)
o Doel
systeem zodanig programmeren in een taal dat software van hoge
kwaliteit ontstaat, denkwerk is al gebeurd nu enkel nog realisatie
Nuance: vaak is zowel denkwerk als praktijk nodig
- Testen
o Verificatie
werkt het systeem correct, de klassieke bugs oplossen
, Ontwerp van informatiesystemen
o Validatie
als het systeem correct werkt beantwoordt het dan ook aan de
informatiebehoefte van de eindgebruiker, lost het het probleem dat
er in de reële wereld was op
Voorbeeld: doel was om omzet te laten stijgen maar omzet
daalt
- Onderhoud
o Soorten
Perfectief: nieuwe vereisten door continue veranderende
wereld
Vroeger zag men dit als negatief en nu als positief
Adaptief: nieuwe hardware, besturingssysteem
Correctief: bugs
Preventief: software wordt steeds complexer (zie Lehman’s
laws) dus preventief investeren in het terug
leesbaar/begrijpbaar maken van software zodat je verslijting
tegengaat
o Lehman’s law
The law of continuing change:
een programma dat gebruikt wordt in de reële wereld moet
veranderen (evolueren), of het wordt minder en minder
bruikbaar
The law of increasing complexity:
de structuur van een programma dat evolueert wordt
complexer met de tijd, tenzij de nodige stappen worden
ondernomen om dit tegen te gaan
Software verslijt niet door gebruik maar door verandering want ze wordt
steeds moeilijker begrijpbaar waardoor je ze ook niet meer kan aanpassen
De combinatie van de 2 wetten zorgt voor het probleem dat software
steeds sneller verslijt wat het duurder maakt en daarom is preventief
onderhoud zo belangrijk
- Nuancering
lang niet alle projecten worden via het watermodel opgebouwd, het is
gewoon een goed basisvoorbeeld om zo andere moddelen makkelijker te
begrijpen
o Afhankelijk van
Verschillende fasen overlappen
Grote VS kleine software
Make or buy
Pakketten
o Andere modellen
Iteratief ontwikkelen
Methodologieën
