2de bach HI
Systeemanalyse
Theorie : slides + notities samengevoegd / examenvragen
Q 152
uickprinter Koningstraat 13 2000 Antwerpen www.quickprinter.be
6.00 EUR
Nieuw!!! Online samenvattingen kopen via www.quickprintershop.be
2e bach HIB
Systeemanalyse: 2014 (2e Sem.) Jan Verelst
Examen: - 10/20 theorie - 10/20 oefeningen: gestructureerd en object-georiënteerd Cursus: Deze tekst bevat alle theorie, in de les gegeven door Jan Verelst. Dit is geen samenvatting; alles wat hij zei is samengevoegd met de slides, en is zeker en vast voldoende om te slagen op het theoriedeel van het examen. De oefeningen worden apart gegeven door Philip Huysmans (in 2014 althans) en staan hier niet bij. Een aanrader om de lessen te volgen in ieder geval! Het boek kan je gebruiken als achtergrondinformatie indien je iets niet volledig begrijpt. Ikzelf heb een 16/20 gehaald op dit vak, en theorie volledig aan de hand van deze cursus gestudeerd. Achteraan deze cursus heb ik examenvragen van vorige jaren toegevoegd. Ook doorheen de cursus staan er belangrijke tips/vragen m.b.t. het examen. Bereid deze vragen zeker voor, op examens van professor Verelst komen vragen van vorige jaren namelijk vrijwel altijd (deels) terug!
1
Hoofdstuk 1: de wereld van de informatiesystemen analist The World of the Information Systems Analyst De leerdoelen: De rol van de systeemanalist in het bedrijfsleven kunnen uitleggen De rol van de informatiesystemen in het bedrijfsleven kunnen uitleggen Soorten taken van de systeemanalist kunnen uitleggen. Kennis en vaardigheden van de analist kunnen uitleggen De analist is meer bedrijfskundig probleemoplosser dan programmeur: Hij is toegewijd om d.m.v. informatiesystemen programma’s beter te laten werken. Hij begrijpt bedrijfskundige problemen en zoekt oplossingen d.m.v. informatiesystemen -> systemen die info verzamelen om taken te verrichten (hoog IT-gehalte) Hij leidt de implementatie van deze oplossingen, maar bouwt niet zelf. Voorbeeld 1: probleem met onbetaalde facturen (hoge verwijl-intresten: 15 à 20%) Er werd gevraagd aan een externe consultant om probleem op te lossen. Bij elke factuur moesten er steeds 13 handtekeningen gezet worden. De consultant digitaliseerde dit, maar het probleem was niet opgelost. Tweede poging dan: er moesten nog maar 5 handtekeningen gezet worden, dat zou het probleem oplossen. Dit betekende dat de organisatie moest aangepast worden -> dit zorgde voor een verandering in de evenwichten, verantwoordelijkheid (zoiets van mensen afpakken, is niet evident) -> je krijgt organisatorische en psychologische factoren die meespelen, wat het heel lastig maakt. Uiteindelijk kwam het in orde om maar 5 handtekeningen te zetten. Moraal van het verhaal: Het bedrijfskundige probleem oplossen met IT lukte niet -> bedrijfskundige problemen. Voorbeeld 2: Internetbetalen was in 1996 heel inefficiënt. Er was een idee om het op te lossen, wat bedrijfskundig niet helemaal nieuw was -> in de bedrijfswereld wordt er clearing toegepast. Een post-graduaat wilde een soort clearing house voor internetbetalen op de markt toepassen.
2
Hoe probleem oplossen – Problem Solving: 1. Onderzoeken en begrijpen van het probleem
Belanghebbenden, welke markten, welke invloed op andere processen
2. Nagaan of de voordelen voor het oplossen de kosten overstijgen 3. Beschrijf de benodigdheden om het probleem op te lossen
Wat men nodig heeft: welke input(gegevens), welke processen en welke output men wil
4. Geef mogelijke oplossingen
Hoe men het zal aanpakken
5. Beslis wat het beste alternatief is en raad het aan
Minste risico’s & meeste voordelen OOK andere factoren: strookt het met bedrijfsdoelen, mogelijk met reeds bestaande IS, mogelijk in bestaande corporate covernance,…
6. Beschrijf de details van de gekozen oplossing
Alle delen van IS, databases, user interfaces, netwerken, processen,…
7. Implementeer de oplossing
Nu pas de eerste stap van programmeren
8. Controleer of je het gewenste resultaat verkrijgt Waarom niet ineens programmeren? Wel goed: indien men aan de gebruikers al wil laten zien hoe het er ongeveer uit zal zien en de technische haalbaarheid te controleren Niet goed: verkwist tijd en geld, want misverstanden omtrent vereisten o Hierdoor: men gaat over budget en lost het probleem niet volledig op. Ontwikkelen van een informatiesysteem om: Programma’s te schrijven Bedrijfsproblemen op te lossen Informatiesystemen (IS): Een collectie van met elkaar verbonden componenten die informatie verzamelen, verwerken, opslaan en als output aanbieden nodig om bedrijfstaken te vervullen. Vb: personeelsbetaling systeem. Verzamelt info over personeel en zijn werk, verwerkt en slaat die informatie op en produceert dan loon en betalingsrapporten. Functional decomposition: Een systeem in onderdelen verdelen gebaseerd op subsystemen die verder onderverdeeld zijn in kleinere subsystemen. Geeft de analist de mogelijkheid zich te focussen op 1 onderdeel van het systeem.
3
Soorten IS met grote interactie: Customer relationship management(CRM) system: ondersteunt marketing, verkoop en service na verkoop bestaande uit directe en indirecte interactie met de klanten. (grote evolutie o.b.v. het gebruik van internet) Supply chain management(SCM) system: integreert foutloos productontwikkeling, productaanwinst, productie, en inventarisbeheer. (sterk ontwikkeld d.m.v. internet en zo gemakkelijkere verbinding met CRM van andere bedrijven.) interactie met leveranciers. Accounting and Financial management(AFM) system: registreert boekhoudingsinformatie nodig voor ontwikkelen van financiële verklaringen en andere rapporten die door investeerders en leverancieren(schuldeisers) worden gebruikt. contant geldbeheer, voorspellen cash flow en effectenbeheer. Interactie met investeerders. Human resource management(HRM) system: ondersteunt op werknemerbetrekking hebbende taken zoals loonlijst, voordelen, het aannemen en opleiding. Interactie met werknemers.
4
Soorten IS met weinig of geen interactie Manufacturing management system: controleert interne productieprocessen die grondstoffen in afgewerkte goederen veranderen. Knowledge management system(KMS): Een systeem dat de opslag van en toegang tot documenten van alle delen van de organisatie ondersteunt. Collaboration support system(CSS): staat geografisch verdeeld personeel toe samen te werken aan projecten een taken. Business intelligence system: ondersteunt strategische planning en het maken van bedrijfsleiders beslissingen. Analist als systeemontwikkelaar: Analyse: volledig begrijpen en beschrijven wat het systeem zou moeten doen, zowel ervaring als kennis (beetje) als techniek (SA) zijn belangrijk en het is een kritische succesfactor in de ontwikkeling van een IS. Ontwerp: specificeren in detail hoe de vele componenten fysisch geïmplementeerd moeten worden. Implementatie: begeleiden (soms zelf doen). zowel een gestructureerde als object georiënteerde aanpak. => !!! GOED KENNEN VAN DE VEREISTEN = KRITISCHE SUCCESFACTOR !!! Vaardigheden en kennis: Technisch: programmeren, computers, netwerken, databanken, tools, technieken,… Bedrijfs: organisatie, management, marketing, accounting,… Industriële sectorm specifiek bedrijf… -> uitstekend geplaatst als HIBer! Menselijk: communicatie, onderhandeling, empathie, rol van de leider, manager, leraar, vertrouwenspersoon, medewerker… Voorkennis: Ideaal TEW/HI! Typische Jobtitels: - Systeemanalist: een beroepsprofessional die analyse en design technieken gebruikt om bedrijfsproblemen op te lossen met IT. - Andere titels: analist/programmeur, business systems analyst, business consultant (dicht tegen analist aan), systeemontwerper, software engineer, systeem architect, web developer… De analist en IS planning: Ad hoc projecten: ad hoc = specifiek voor een geval of situatie IS strategisch plan: Het plan dat de technologie en de toepassingen bepaalt, dat de IS functie het strategisch plan van de organisatie moet ondersteunen. Verband met: o ICT governance: het met de benodigde autoriteit ontwikkelen, beheersen of beheren van beleid alsmede het pro-actief beïnvloeden en toezicht houden op een juiste uitvoering van dit beleid door één persoon (de CIO).
5
Balanced scorecard: een veel gebruikte techniek voor strategisch management en het behalen van langetermijndoelstellingen binnen organisaties. Het wordt met name gebruikt als evaluatiehulpmiddel voor managers die complexe doelstellingen hebben. Het idee achter de balanced scorecard is dat een manager niet alleen is af te rekenen op financiële resultaten, maar dat ook andere prestaties worden meegenomen in de jaarlijkse beoordeling. Business process re-engineering (BPR) (speciaal project): een techniek die de aard van het gedane werk in een proces wil veranderen met objectieve of radicale verbetering. o
CONCLUSIE ANALIST: Analyse = bedrijfsproblemen oplossen dmv informatiesystemen Verzorgt analyse, eventueel ontwerp en implementatie. Het is een combinatie van bedrijfsen technische vaardigheden. Perfect: TEW/HI-profiel!
6
Hoofdstuk 2: Benaderingen van systeemontwikkeling Approaches to System Development Levenscyclus van een informatiesysteem IS ontwikkeling is een project: Project: geplande onderneming dat een begin- en einddatum heeft dat een gewenst (robuust, betrouwbaar,onderhoudbaar,performant,…) resultaat of product produceert. Idee: Succes vereist een gedetailleerd, systematisch plan van taken = project Kan zeer klein tot zeer groot zijn. 2 Keuzes/Visies voor Systems Development Life Cycle (SDLC): = het gehele proces van bouwen, opstellen, gebruiken en updaten van IS
1. Predictive approach: veronderstelt dat het ontwikkelingsproject vooraf kan worden gepland en georganiseerd en dat het nieuwe informatiesysteem volgens het plan kan worden ontwikkeld. (vereisten goed gedefinieerd en onderzocht + laag technisch risico) Watervalmodel Gemodifieerd watervalmodel 2. Adaptive approach: flexibeler, veronderstellend dat het project niet volledig vooraf kan worden gepland maar het moet worden gewijzigd naargelang het vordert. (onzekere noden en eisen + hoog technisch risico) Spiraalmodel Iteratieve Ontwikkeling Incrementele Ontwikkeling Recente evoluties: UP, XP, Agile modeling en Scrum
7
IS ontwikkelingsfases: Levenscyclus kent een aantal fasen!!
1. Project planningsfase: om het bereik van het nieuwe systeem te identificeren. Zorg ervoor dat het project uitvoerbaar is en ontwikkel een programma, een middelplan, en een begroting voor de rest van het project. (hoofdstuk 3) Definieer het probleem: verstaan wat we moeten oplossen Maak een projectschema: met de gegeven middelen een schema opmaken. Bevestig haalbaarheid van het project o.b.v. wat men reeds weet. Bekijk de beschikbare middelen (‘staff the project’): de training en beschikbaarheid. Launch the project: is de mogelijkheid er te starten 2. Analyse fase: begrijp en documenteer de bedrijfsnoden in detail en de proceseisen van het nieuwe systeem. (hoofdstuk 4) Verzamel info Definieer systeemeisen: in detail wat het systeem moet kunnen. Geef voorrang aan eisen (Prioritize): geef de belangrijkste duidelijk aan. Maak prototype voor de haalbaarheid en ontdekking: bewijs dat de voorgestelde technologie doet wat we verwachten + de gebruiker begrijpt zo de volledige werking en gaat hiermee akkoord. Ontwikkel en evalueer alternatieven: beste manier om het systeem te creëren. Overzicht v/d eisen met management: gaan we verder met het voorgestelde systeem o.b.v. alle voorgaande info. Fundamenteel 2 zaken: 1. Verzamel vereisten 2. Bouw modellen van de vereisten -> want het verzamelen van de vereisten kan onvolledig zijn, zo elimineer je de fouten!
8
3. Ontwerp fase: ontwerp het oplossingssysteem gebaseerd op de gedefinieerde vereisten en beslissingen ontwikkeld in de analyse fase. (hoofdstuk 9) Ontwerp en integreer het netwerk: specificeer in detail hoe de verschillende onderdelen van het systeem zullen communiceren met elkaar via de onderneming. Ontwerp de toepassingsopmaak en de software: specificeer in detail hoe elke activiteit in uw systeem uitgevoerd wordt door personeel en pc Ontwerp de gebruikersinterface: hoe alle gebruikers zullen interageren met het systeem Ontwerp systeem interface: hoe het systeem zal samenwerken met andere systemen binnen en buiten de onderneming. Ontwerp en integreer de database: specificeer waar alle info nodig zal worden opgeslagen en hoe. Prototype maken van deze ontwerp details: zodat men elke beslissing in het voorgaande duidelijk kan begrijpen en goedkeuren. Ontwerp en integreer de controlemechanismen: specificeer hoe men controleert of het systeem correct functioneert en de data veilig is. Bv. Smartphones: user interfaces zijn complexe dingen geworden. Hier SQL voorkomen (relationele databank) 4. Implementatiefase: bouwen, testen en installeren van een vertrouwbaar IS met getrainde gebruikers om van de voorziene voordelen te genieten. (H16) Bouw software componenten, verbeter en test, zet data om (bv, Word -> pdf), train en documenteer + installeer het systeem/zet systeem in productie! “Train and document”: Deze fase vermindert vaak de hoeveelheid problemen in de acceptatie-testen Testen van software, zoals acceptatietesten: Was dit wat je wilde? Vaak is dit niet het geval. Andere voorbeelden: unit testen, integratietesten Eerste 4 fases: 25% van de kosten <-> laatste fase: 75% van de kosten! Men begint hier pas echt te programmeren: dat is de duurste activiteit! 5. Onderhoudsfase: om het systeem productief te laten blijven werken in het begin en tijdens de levensjaren van het systeem. (H16) Behoud en verbeter het systeem + ondersteun gebruikers
9
PREDICTIEVE LEVENSCYCLUS: 1. Predictive 1 - Watervalmodel: Planningsfase -> Analyse fase -> Ontwerpfase -> Implementatiefase Kenmerken: Men bevriest de vereisten voor ontwerp. Ontwerp bevriezen voor implementatie. Men kan nooit terugkeren naar de voorgaande fase. Nadelen: niet realistisch (vereisten nooit volledig, consistent en ondubbelzinnig van de eerste keer) + niet efficiënt ( taken kunnen nooit in parallel uitgevoerd worden) +duurt zeer lang + geen interactie eindg. Dit komt eigenlijk uit de burgerlijke bouwkunde en grote projecten. Men denkt na over planning, budget en kost. Vb. van de handtekeningen: als er niet wordt gehandtekend, is het project afgelopen. Hoofdprobleem: de acceptatietesten leiden frequent tot problemen. Analisten: wanneer de analysefase af is, beginnen die aan een ander project. Sterk punt/voordeel: het is tamelijk duidelijk qua projectmanagement (duidelijk beeld) + predictief: het gaat ervan uit dat je de vereisten kent Als je als ontwerper iets niet snapt: zelf gaan interpreteren want mensen uit voorgaande fase zijn niet meer beschikbaar. 2 Problemen: a) Analysis Paralysis: het blijft aanslepen als je toch niet goed weet wat je moet doen. Het watervalmodel kan niet om met onzekerheid, dan blokkeert het. Je krijgt nooit iets concreet te zien dan. b) Scope-creep: langzaam naar een groter formaat. Budget en tijd dreigen toch toe te nemen. Het zou kunnen dat de scope blijft groeien. Als je weet wat je wil zou dit het goedkoopste model zijn -> de andere modellen zijn enkel nuttig als er ook effectief verandering is. (HCO 3 – 3.3.2014) 2. Predictive 2 - Gemodifieerd watervalmodel: er is nog steeds een verplichte voorafgaande kennis aan het begin van elke fase, alleen kan men nu wel enkele onhaalbare vereisten aanpassen en enkele bijvoegen. De ontwerpers kunnen al beginnen ontwerpen voor de analyse volledig klaar is. Er zullen wel enkele in de vuilbak belanden, maar dit kan de analisten helpen begrijpen. Er moet steeds voorafgaande analyse blijven, want anders te veel weggooien. Gemodifieerd watervalmodel: legt extra voorwaarden op aan het projectmanagement. Alles moet worden opgevolgd, correct met elkaar integreren… Is iedereen nog wel met het juiste bezig? Het projectmanagement moet ook de integratie bekijken. Groot voordeel: kortere doorlooptijd 10
2 soorten prototyping (inleidend werkmodel dat sommige aspecten van het systeem toont): 1. Throw-away of discovery prototyping: voorbeelden na ontwerp weggooien (bestaat veel) Voorbeeld: houten prototype -> het gaat niet op in het finale product! Nuttig bijvoorbeeld als er onzekerheid is over de vereisten van het systeem -> het kan zo beter in kaart gebracht worden. Het vliegt daarna wel de vuilbak in! Opgelet: er bestaat amper software om van die soorten schermen te maken. 2. Evolutionaire prototyping: voorbeeld bestaat al en wordt steeds aangepast na feedback. Je blijft als het ware het prototype aanpassen totdat je op het einde van de rit het finale product hebt. o Nadeel: 1) systeem dat al vaak aangepast is; continue verandering = slechte cohesie; kapotte structuur (Wet van Lehman) 2) Het punt is dat de eindgebruiker op het einde van de rit moet zien wat hij gevraagd heeft -> probleem want het prototype is eigenlijk niet af! Zaken zoals beveiliging, performantie,… zijn niet meegenomen. Dit is een moeilijk moment want de eindgebruiker denkt dat het wél af is -> je moet er toch nog in slagen van het af te werken. Het is raar want het bouwen van wat die persoon wil zien, kost minder dan de rest dat nog moet gebeuren. -> evolutionaire prototyping heb je dus eigenlijk niet in 2014! Beide zijn belangrijk bij adaptieve levenscycli Opm: 80’s prototyping wordt vaak uitgelegd in analogie met ingenieurswetenschappen, maar het is toch niet helemaal hetzelfde als engineering!
11
Er zijn verschillende varianten op het idee van prototypes maken!! ADAPTIEVE LEVENSCYCLUS: 1. Adaptive 1 - Spiraalmodel: het overloopt telkens weer de cirkel van de ontwikkelingsactiviteiten tot het project volledig is. Elk onderdeel wordt om de beurt behandeld (bij elke nieuwe iteratie gaat men de grootste risicofactor eruit halen) (duid hierbij aan op geprint blad wat op slide 14 van notities staat!) Barry Beam kwam reeds in 1988 met het idee dat het waterval- en iteratief model misschien niet top waren. In model: evaluate alternatives, identify, resolve risk… Je moet steeds proberen gaan voor de grootste risico’s eerst! Het is één van de eerste configureerbare procesmodellen: het ziet er steeds anders uit. 2. Adaptive 2 - Iteratieve ontwikkeling: de activiteiten analyse, ontwerp en implementatie, worden telkens 1 maal gedaan en dan telkens opnieuw herhaald. (herhalen van ontwikkelingsactiviteiten) Soort iteraties: i. Belangrijkste functionaliteit eerst, optionele laatst ii. Subsysteem per subsysteem iii. Eerst meest complexe, riskante delen: indien falen van deze dan moet men de andere niet eerst maken = minder geld en tijd -> als je input niet hebt, kan je beslissing niet maken. Je moet met de funderingen beginnen. Er zijn koppelingen. Voordelen: Meer eindgebruikersbetrokkenheid(= wijzigende eisen incorporeren + hogere acceptatiekans) + er wordt vroeger getest + parallellisme (bij implementatie moet je je systeem steeds al integreren) Nadelen: iteraties hebben opstartkosten en vereisen meer coördinatie Men wil tamelijk snel naar de implementatie. Op het einde van de implementatie vraagt men dan feedback. Op basis van de feedback past men de analyse aan. Zo blijft het doorgaan. Probleem bij iteratie: wanneer stopt het? Eindgebruiker moet zeggen wat het eindpunt is. In termen van projectmanagement is dit veel ingewikkelder dan het watervalmodel! Integratietesten: hoe kan je de verschillende stukken software aan elkaar plaatsen? Men maakt leren mogelijk, een voortschrijdend inzicht. Nadeel: je nodigt de verandering eigenlijk wel uit. Je weet niet wanneer het stopt, wat het eindpunt is.
12
