Bijlagen B bij hoofdstuk II over Informatieplanning:

Transcriptie

1 B: Systematisch bouwen van informatiesystemen SDM-fase : Informatieplanning Bijlagen B Bijlagen B bij hoofdstuk II over Informatieplanning: Bijlage IP - j) Checklist risico-analyse bij informatieplanningsproject Bij activiteit.7 van de SDM-informatieplanningsfase worden prioriteiten en verbanden bepaald voor de ontwikkeling van de verschillende informatiesystemen binnen een organisatie. Een van de hierbij te hanteren criteria is de kans op succes bij realisatie van een bepaald (deel)systeem. Proefondervindelijk zijn voor de bepaling van die kans op succes checklisten voor risico-analyse opgesteld. We geven hier een voorbeeld van zo'n checklist (uit: F. Pottjegort; 'Inleiding Technieken Informatiesystemen'): Nr. Aspect Waarde Risico- Risico- Totaal factor waarde Geschatte doorlooptijd van het project - mnd. -6 mnd. Aantal functionele deelgebieden dat betrokken is Aantal functionele deelgebieden dat gebruik maakt van de resultaten 6+ mnd Gaat het om een aanpassing of een nieuw informatieplan? In hoeverre zullen bestaande verantwoordelijkheden moeten wijzigen? 6 Lopen er andere projecten die afhanelijk zijn van dit project? 7 Wat zal de houding van 'de gebruikers' zijn? klein groot nieuw niet minimaal gemiddeld, veel tijd, weinig tijd positief interesse reserve negatief 8 Kent het project een definitieve deadline? 9 Zal er sprake zijn van deelprojecten en is de voortgang afhankelijk van de coördinatie hiertussen?, flexibel beetje sterk... Is de tijd voldoende om het project binnen de gestelde termijn te realiseren? ruim voldoende onvoldoende Wie werken er aan het project mee? Wat is de geografische spreiding van de werkgroepleden? Aantal functionarissen dat op piektijden > 8% is betrokken intern mix extern geen ± > - - > IP-bijlagen B blz.

2 B: Systematisch bouwen van informatiesystemen SDM-fase : Informatieplanning Bijlagen B Verhouding materie-deskundigen en IP-deskundigen in het project Hoe deskundig is het projectmanagement t.o.v. de materie van het project? goed slecht... 6 Hoe deskundig is het projectmanagement m.b.t. informatieplanning?... 7 Hoeveel ervaring heeft het projectmanagement met het leiden van projecten van deze soort/omvang? veel weinig... 8 Participeren 'de gebruikers' in de projectgroep? 9 Hoe deskundig zijn de IP-adviseurs op het te onderzoeken gebied? sterk Hoe deskundig zijn de materiedeskundigen op het te onderzoeken gebied? Hoe betrokken is het verantwoordelijke lijnmanagement bij het project? sterk Is de kans groot dat leden tussentijds muteren? Worden door de projectgroep standaardmethoden gehanteerd m.b.t. inventarisatie, analyse, rapportage, documentatie etc.? groot gemiddeld klein, enkele Zijn de probleem- en doelstelling voor alle leden voldoende scherp? mix Is het onderzoeksgebied nauwkeurig vastgelegd? 6 Is er voldoende afbakening met andere projecten? 7 Is er voldoende tijd gepland voor besluitvorming en afstemming? 8 Zijn de randvoorwaarden duidelijk? meeste sommige 9 Werken de randvoorwaarden beperkend genoeg? Toelichting checklist Door de in een bepaalde situatie geldende risicofactor te vermenigvuldigen met de risico-waarde van het betreffende aspect en vervolgens de totalen op te tellen, kom je op een risicoscore. Door deze score te delen door IP-bijlagen B blz.

3 B: Systematisch bouwen van informatiesystemen SDM-fase : Informatieplanning Bijlagen B de maximaal haalbare waarde, bereken je een risico-percentage. Is dit percentage hoger dan % dan dient het informatieplanningsproject níet te worden uitgevoerd. Je zult dan eerst op een of meerdere aspecten maatregelen te nemen om zo de risicoscore omlaag te brengen. Ligt het percentage daaronder, dan zou het project tegen een aanvaardbaar risico wèl kunnen worden uitgevoerd. De grenswaarden op grond waarvan men al of niet verder gaat met een project zal per organisatie vastgesteld en beoordeeld moeten worden. Dit is uiteraard ook afhankelijk van de wijze van beoordeling van de afzonderlijke aspecten. IP-bijlagen B blz.

4 B: Systematisch bouwen van informatiesystemen SDM-fase : Informatieplanning Bijlagen B Bijlage IP - k) A-schema-techniek (uit ISAC) We hebben hiervoor al gezien hoe we voor het beschrijven van systemen de SADT-techniek kunnen gebruiken. We geven hier nu ook een korte beschrijving van hoe de zogenaamde A-schema's (bekend uit de uit Zweden afkomstige systeemontwikkelingsmethode ISAC) gebruikt kunnen worden. We geven hier eerst een overzicht van de in A-schema's gebruikte symbolen: symbool betekenis fysieke verzameling (b.v. personen en/of materiële grootheden) gegevensverzameling bestaande uit berichten (b.v. documenten of telefonische berichten) samengestelde verzameling, bestaande uit zowel fysieke grootheden als gegevens (berichten) stroom van fysieke grootheden (aangegeven door dikke lijnen in een A-schema) stroom van berichten (aangegeven door dunne lijnen in een A-schema) beslissingen c.q. activiteiten Betekenis van de symbolen in een A-schema. Een voordeel van A-schema's (t.o.v. SADT-schema's) is, dat er via aparte symbolen wèl expliciete mogelijkheden voor het aangeven van voorraden/magazijnen/opslag zijn. Een nadeel kan echter zijn, dat net daarom méér symbolen van elkaar onderscheiden moeten worden en de schema's daardoor moeizamer te begrijpen zijn IP-bijlagen B blz.

5 B: Systematisch bouwen van informatiesystemen SDM-fase : Informatieplanning Bijlagen B We geven nu een wat uitgebreider voorbeeld van deze (ISAC-) A-schema-techniek voor een aangetroffen situatie van een technische onderhoudsdienst (ietwat aangepaste versie van het schema uit: Bemelmans; Bestuurlijke informatiesystemen en automatisering): actuele storingsgegevens monteurs (werkuren) fysieke machines gegevens machines plannen gegevens servicemonteurs voorraadmelding voorraad onderdelen afhandelen magazijn uitgeleverde onderdelen uitvoeren service aanvraag onderdelenuitlevering werkmonteur opdracht servicerapport besteladvies gerepareerde of onderhouden machine Globaal A-schema voor een technische onderhoudsdienst. N.B. Zonder nadere aanduiding lopen 'stromen' van boven naar beneden. indien verbindingen horizontaal of van beneden naar boven lopen, moeten richtingspijlen worden gebruikt. IP-bijlagen B blz.

6 B: Systematisch bouwen van informatiesystemen SDM-fase : Informatieplanning Bijlagen B Bijlage IP - l) Client/server-architectuur Door het opkomen van nieuwe netwerk-technologiën zijn ook nieuwe mogelijkheden ontstaan voor het gebruiken (en 'dus' het maken) van software. Voorheen hadden we de keuze uit extremen: enerzijds het werken via een stand alone pc, waarbij alle rekenkracht en alle gegevens lokaal (òp of ònder je bureau) aanwezig waren en anderzijds werken via een mainframe-computer waarbij alleen een 'domme terminal' (toetsenbord+beeldscherm; zonder enige rekenkracht) op je bureau stond. Bij zo'n mainframe/domme-terminal-situatie werden bij wijze van spreken alle toetsaanslagcodes via een verbindingslijn naar de centrale computer gestuurd om daar verwerkt te worden; voor de beelschermpresentatie moesten daarna de te tonen tekens via de verbindingslijn naar die domme terminal terug gestuurd worden om daar op het beeldscherm te worden afgebeeld. Via de zogenaamde C/S-(client/server-) architectuur is het nu mogelijk om het geheel van uit te voeren taken te splitsen. In onderstaande figuur zijn de eerder genoemde extremen, samen met een aantal mogelijkheden die de C/S-architectuur biedt, schetsmatig aangegeven. client/server-architectuur Frontend stand alone pc client client client 'domme terminal' presentatie toepassing data presentatie presentatie presentatie n e t w e r k - v e r b i n d i n g presentatie Backend (client-deel) (server-deel) data data data data server server server mainframe N.B. Let erop dat de woorden 'client' en 'server' processen aanduiden, die op een bepaalde machine/computer worden uitgevoerd. Een 'client-proces' vraagt aan een 'server-proces' om een bepaalde opdracht uit te voeren en het server-proces geeft later het verkregen resultaat terug naar de client. Met die woorden 'client' en 'server' kun je dus eigenlijk géén machines aanduiden; in feite kan een client-proces en een server-proces op eenzelfde machine aanwezig zijn. Bij de linker C/S-implementatie wordt de machine waarop het 'server'-proces draait, slechts gebruikt voor de opslag van data (dit kan handig zijn om b.v. vanaf allerlei plekken in een bedrijf toegang te hebben tot centraal opgeslagen bedrijfsgegevens). De rechter C/S-implementatie kan bijvoorbeeld gebruikt worden bij gespecialiseerde grafische werkstations, die afbeeldingen tonen die verkregen worden via sen die op een 'server lopen'. De middelste C/S-implementatie kan zich voordoen bij bijvoorbeeld het gebruik van een client die SQLopdrachten naar een SQL-server stuurt en waarbij die SQL-server op een centrale database werkt en tot slot de verkregen resultaten terugstuurt naar de client. Qua concept lijkt de client/server-architectuur nauw aan te sluiten bij zowel (een aantal) behoeften binnen organisaties (die deels gecentraliseerd en deels gedecentraliseerd zijn) alsook bij de wens van veel gebruikers om op een flexibele manier hun eigen werkomgeving te kunnen bepalen. Een probleem is echter dat het onderhoud van een C/S-constellatie in de praktijk hoge onderhouds- en ondersteuningskosten met zich meebrengt (zeker als je de collegiale steun mee telt, waarbij goedwillende collega's over het probleem gaan 'mee denken'). IP-bijlagen B blz. 6