Samenvatting Systeemanalyse

Eline Opsommer 2e jaar Toegepaste ICT-Apps&Gamification




Systeemanalyse
1 Inleiding (pg 4)

1.1 Inhoud van de cursus (pg 4)

1.2 Wat is systeemanalyse (pg 6)
1.2.1 Definitie (pg 6)
- Systeemanalyse = verzamelnaam voor reeks technieken & methodes om:
o Informatiebehoefte van gebruiker weer te geven -> analyse/WAT
o Informatiesysteem op hoog (logisch) niveau te gaan ontwerpen -> ontwerp/HOE
- Verschil tussen analyse & ontwerp:
o ANALYSE:
 Domeinanalyse: structureren van probleem & bedrijfsobjecten en bedrijfsregels
beschrijven -> via klassendiagram




 Vereistenanalyse: beschrijven welke functies er in software moeten komen -> via use-
case diagram




o ONTWERP: conceptuele voorstelling van oplossing
 Zonder implementatiedetails beschrijven hoe oplossing logisch gestructureerd is, hoe
oplossing zal uitzien

1.2.2 Analist als brugfunctie (pg 8)
- Opdrachtgever heeft probleem, hij kent zijn bedrijf goed & weet wat hij wil, maar hij heeft te weinig
technische kennis om informatiesysteem te bouwen -> opdrachtgever kent probleem maar kan niet
oplossen
- Informatici hebben technische middelen & kennis om goeie informatiesystemen te bouwen, maar ze weten
niet wat opdrachtgever precies wil & weten niet hoe bedrijf in elkaar zit -> programmeur zou probleem
kunnen oplossen, maar hij begrijpt probleem niet
 communicatiekloof



1

,Eline Opsommer 2e jaar Toegepaste ICT-Apps&Gamification



- systeemanalist moet behoeften van opdrachtgever & eindgebruikers vertalen naar exacte technische
specificaties voor programmeur -> soort tolk tussen de 2
- management/financier van project moet kijken of de te investeren middelen op verantwoorde wijze
worden uitgegeven




1.2.3 Analysemodellen (pg 10)
- Als analist probleem krijgt, moet hij onderzoek doen naar behoeften van klant & structuur van
probleemdomein -> resultaat: verzameling teksten (interviewrapporten, samenvattingen, ..)
o Nadeel teksten: niet overzichtelijk, dubbelzinnig (vb. klant: iemand die al bestelling heeft geplaatst
of potentiële klant) & onvolledig
- Goede analyses zijn model-driven = ideeën weergeven in visuele modellen
- Vb. statische structuur van probleemdomein van eenvoudige bibliotheek:




- Vb. toestandsdiagram van toestandsveranderingen van 1 exemplaar:




- Voordelen modellen:
o Ondubbelzinnig
o Visueel (-> overzichtelijk)
o Duidelijk: verbergt implementatiedetails
o Goed communicatiemiddel door overzichtelijkheid & ondubbelzinnigheid
o Ontwerpfouten worden sneller ontdekt
 Moeten wel aangevuld worden met tekstuele beschrijving

1.2.4 Vaardigheden van een analist (pg 13)
- Analytisch vermogen
- Abstract denkvermogen


2

, Eline Opsommer 2e jaar Toegepaste ICT-Apps&Gamification



- Synthetisch vermogen
- Communicatief vaardig
- Interviewtechnieken
- Schriftelijke rapportering
- Vergadertechnieken
- Kennis van en interesse voor nieuwe informatietechnologieën


1.3 Belang van systeemanalyse (pg 14)
1.3.1 Kenmerken van een goed informatiesysteem (pg 14)
- Goede software is:
o Bruikbaar: voldoen aan functionele & niet-functionele eisen van gebruiker
o Betrouwbaar: geen fouten
o Gebruiksvriendelijk: makkelijk te bedienen zonder dat gebruiker interne implementatie kent
o Onderhoudbaar: kleine fouten verbeteren & aanpassingen doorvoeren zonder dat programma
onbetrouwbaar wordt
o Flexibel/aanpasbaar): software makkelijk kunnen aanpassen, zonder inspanning kunnen
integreren in andere systemen
o Efficiënt: kost voor ontwikkeling & onderhoud moet juist zijn voor kwaliteit van software &
concurrentiële voordeel ervan

1.3.2 Ideaal versus realiteit (pg 15)
- Gevolgen van slechte analyse/ontwerp:
o Gedemotiveerde informatici & hoge kosten
o Nutteloze, maar dure producten
o Veel beloven & weinig veel te laat & veel te duur geven
o Levens komen in gevaar & geld gaat verloren

1.3.3 Belang van analyse neemt toe (pg 16)
- Nood aan goede analyse:
o Softwareontwikkeling wordt gestuurd door klant & niet door technologie
o Complexiteit van software is gestegen
o Kosten van software zijn groter geworden:
 Ontwikkelen is duur door stijgende loonkost & toegenomen complexiteit
 Slecht functionerende software is duur (vb. gevolgen van slecht functionerend
vliegtuignavigatiesysteem)
 Kost van niet-flexibele systemen (vb. als dure software na enkele jaren niet meer gebruikt
wordt omdat aanpassen van software aan veranderende behoeften onmogelijk is)


1.4 De fasen in softwareontwikkeling (pg 20)
- Procesmodel beschrijft in welke fasen men te werk moet gaan bij ontwikkelen & welke taken in elke fase
vervuld moet worden
- Watervalmodel: na elke fase wordt mijlpaaldocument (gestructureerd rapport) afgeleverd die door
management geëvalueerd wordt




- Alternatief: iteratieve modellen -> ontwikkelwerk in stukken breken

1.4.1 Vooronderzoek (pg 20)
 Heeft het zin om te beginnen aan dat project?
- Taken:
o Onderzoeken wat bedrijfsstructuur & huidige manier van werken is
o Randvoorwaarden onderzoeken (uiterste leverdatum, maximale kosten,..)
o Wensen van klant globaal onderzoeken



3