Het Functioneel Netwerk Ontwerp

Document Sample
Het Functioneel Netwerk Ontwerp Powered By Docstoc
					                        Het Functioneel Netwerk
                               Ontwerp

                           Een introductie, begrippen,
                        aandachtspunten en stappen om
                          tot een goed FNO te komen.




T. Vriese, ROC Rivor;
                               Opmerking vooraf
          Dit document is primair een dictaat / reader in de vorm van een
          PowerPointbestand.
          Vanwege de grote lappen tekst heeft het zeker niet de pretentie en
          voldoet het ook niet aan de voorwaarde, om als presentatie te fungeren.
          De keuze voor PowerPoint maakt het wel makkelijker om de inhoud
          klassikaal te behandelen.
          Deze reader is verre van compleet, maar verschaft echter wel algemene
          basiskennis en inzichten in de kenmerken en doel van een FNO en de
          faseringen die hier bij horen.
          Echter,…… geen enkel netwerk is hetzelfde.
          Dit houdt in dat, afhankelijk van de situatie en functie eisen die uit de
          analyse naar voren komen, in de praktijk kan worden besloten om
          aangepaste faseringen toe te passen.
          Daarbij is zeker ook nog van invloed welke projectmanagementmethode
          is toegepast (zie hiervoor de toelichting sheet op het eind van dit dictaat).
          Niettemin kan veilig worden gezegd dat de meeste van deze methoden
          op hoofdlijnen, dezelfde stapvolgorde zullen aanhouden.
 versie 0.3
T. Vriese, ROC Rivor;                                                                     2
                        Een Functioneel Ontwerp
In een aantal kerntaken van het beroepscompetentieprofiel ICT-beheerder, is
omschreven dat de kandidaat in staat moet zijn om een Functioneel Ontwerp en een
Technisch Ontwerp op te leveren van een Informatiesysteem.
Voor assessments op niveau 4 en 3 kunnen we de volgende informatiesystemen
onderscheiden.
• Ontwerp van een website.
• Ontwerp van een database.
• Ontwerp van een datanetwerk
                  datanetwerk.
Dit document zal enkel de aspecten van een Functioneel (Data)Netwerk Ontwerp
behandelen.
De principes en faseringen voor Functioneel Ontwerpen van bovengenoemde
informatiesystemen blijven in hoofdlijnen hetzelfde. Het verschil ligt in de uitwerking.
Wat wel in alle drie bovengenoemde gevallen geldt is:
Dat het ontwerpstartpunt niet is wat er technisch allemaal mogelijk is of wat voor
leuks er op de markt is, maar de vereisten vanuit de werkzaamheden van de
opdrachtgever.
versie wordt in vakjargon de Business Requirements genoemd.
Dit 0.3
T. Vriese, ROC Rivor;                                                                      3
                    Het ontwerp proces in hoofdlijnen
      Het Functioneel Netwerk Ontwerp is, evenals het hieruit voortvloeiende
      Technisch Ontwerp, een onderdeel van de Ontwikkel/Ontwerp fase uit een
      automatiseringsproject.

      Om het geheugen op te frissen zullen we eerst nog even kijken wat ook
      alweer de standaard fasering van een project is en welke plaats het FNO
      en het TO hier innemen.

      Indien je geroepen (!!!) voelt om je kennis over projecten op te poetsen, schroom
      dan niet het dictaat Projecten (weer) te bestuderen (is beschikbaar op de site).




 versie 0.3
T. Vriese, ROC Rivor;                                                                     4
                        Oriëntatie / analyse /   Ontwikkel / ontwerp   Bouw fase      Test fase         Acceptatie / implementatie /
                        definitie fase           fase                                                   oplever fase




                                                                           G                                                     G
                                                                           O                                                     O
                                                                           /                                                     /     Bouwfase
      Fasen met                      Oriëntatie/analyse/definitie                  Ontwikkel/ontwerp fase
                                                                           N                                                     N
      activiteiten                   fase                                  O                                                     O
                                                                           G                                                     G
                                                                           O                                                     O
                                                                                                  Go/
                                             Plan van       Planning           Functioneel        no    Technisch
Op te leveren
                                             Aanpak         (voorlopig)        Ontwerp            go    Ontwerp
tussenproducten

                                                     Overeenkomst                                                Evt.
                                                     (voorlopig)                                                 Prototype

                                                                                            Contract              Start Implementatieplan
                                                                                            definitief            Start Testplan

                                                                        Communicatieplan + uitvoering

 versie 0.3
T. Vriese, ROC Rivor;                                                                                                                         5
                        Oriëntatie / analyse /   Ontwikkel / ontwerp       Bouw fase       Test fase    Implementatie / Acceptatie /
                        definitie fase           fase                                                   Oplever fase




                                                              G                        G




                                                                                                                          Ontbinding Projectteam
                                                                                                                         Décharge. Einde Project.
                                                              O                        O
                                   Bouw fase                  /                        /
      Fasen met                                                        Test fase           Implementatie /                                           Onderh.
                                                              N                        N
      activiteiten                                            O                        O   Acceptatie /                                              & Beheer
                                                              G                        G   opleverfase
                                                              O                        O
                                         Handleidingen                    Test               Demo’s /                                               SLA Log
Op te leveren
                                         en te testen                     rapport            Instructies, etc.                                          bestan
tussenproducten
                                         Product(en)                                                                                                    den
                                          Testplan en                                             Acceptatie /
                                       Implementatieplan                                          evaluatie rapport




 versie 0.3
T. Vriese, ROC Rivor;                                                                                                                                        6
                   Het ontwerp proces in hoofdlijnen
      Nu we de fasen van een project weer op het netvlies hebben, gaan we in
      zoomen op de stappen van het Ontwerp proces.


    1. Analyse
    2. Ontwerp
    3. Bouw / realisatie
    4. Test: Integratie- en
       systeemtest
    5. Implementatie en
       oplevering
    6. Onderhoud en beheer


 versie 0.3
T. Vriese, ROC Rivor;                                                          7
                   Het ontwerp proces in hoofdlijnen
      Nu we de fasen van een project weer op het netvlies hebben, gaan we in
      zoomen op de stappen van het Ontwerp proces.


    1. Analyse
                                   • Business requirements
    2. Ontwerp
                                   • Applicaties; passend bij functies
    3. Bouw / realisatie
    4. Test: Integratie- en        • Datastromen; informatiestromen
       systeemtest
                                   • Netwerk; logisch ontwerp
    5. Implementatie en
       oplevering                  • Technologie; fysiek ontwerp
    6. Onderhoud en beheer

 versie 0.3
T. Vriese, ROC Rivor;                                                          8
                  Het Functioneel Netwerk Ontwerp
          Voordat we vorig genoemde stappen doorlopen om tot een FNO te
          komen, gaan we eerst bekijken:

            • Wat eigenlijk de definitie van een FNO is,
            • Wat het doel van een FNO is,
            • Wat de eisen zijn waaraan een goed FNO dient te voldoen
              en
            • Wat de valkuilen bij een FNO zijn




 versie 0.3
T. Vriese, ROC Rivor;                                                     9
                              Definitie FNO
        Definitie:
        Een FNO is het ontwerp voor het netwerk vanuit functionele eisen. Een
        FNO legt aan een niet-technisch onderlegd persoon uit welke functionele
        eisen aan het netwerk worden gesteld en daarbij welke gevolgen dat heeft
        voor het ontwerp.

        Dat betekent niet dat het FNO geen technische taal mag bevatten. Als uit
        de benodigde functionaliteit (eisen), direct technische eisen of
        randvoorwaarden naar voren komen, horen deze zeker in het FNO thuis.
        In een FNO moet zonodig de conclusie kunnen worden getrokken dat een
        netwerk (nog) niet te realiseren is omdat bijvoorbeeld de bandbreedte niet
        voldoet.
        Als namelijk zou worden vastgehouden dat een FNO geen techniek mag
        bevatten, kon in deze fase deze conclusie nog niet worden getrokken.

 versie 0.3
T. Vriese, ROC Rivor;                                                                10
                                  Doel FNO
        Een FNO heeft een tweeledig doel:
        1. Het moet een gedetailleerde basis zijn voor de volgende fase van een
           netwerkontwerp; het Technisch Ontwerp (TO)
        2. Het moet “leesbaar” (begrijpelijk) zijn voor de opdrachtgever.


      Het is voor een opdrachtgever van belang om te weten in hoeverre het
      netwerkontwerp tegemoet komt aan zijn ICT-wensen en welke (fysieke)
      veranderingen gepaard gaan met de invoering van het netwerk.

      Het FNO kan daarom ook gezien worden als een overeenkomst met
      de opdrachtgever.




 versie 0.3
T. Vriese, ROC Rivor;                                                             11
                        Eisen aan een goed FNO
        1. Een FNO kan als goed worden bestempeld wanneer de opdrachtgever
           een heldere voorstelling kan maken van de toekomstige ICT omgeving
           en zijn plan van eisen daarin herkent. Hij moet in het FNO feitelijk een
           blauwdruk van zijn toekomstig netwerk kunnen lezen.
        2. Een technisch ontwerper moet aan de hand van het FNO in staat zijn
           een netwerk te ontwerpen dat exact voldoet aan de specificaties.

         Het is lastig om een standaard format voor een FNO te geven. Veel
         hangt af van de situatie en wensen van de klant. Er zijn geen twee
         identieke netwerken en dus ook geen twee gelijke functionele
         ontwerpen.
         De basis is een programma van eisen dat een ruwe schets geeft van de
         uitgangspunten die aan het netwerk worden gesteld.



 versie 0.3
T. Vriese, ROC Rivor;                                                                 12
                               Toelichtingen
      Als er te veel rekening wordt gehouden met het gegeven dat een niet-
      technisch onderlegd persoon het FNO moet kunnen begrijpen, kan het te
      weinig technische details bevatten om later een bruikbaar uitgangspunt voor
      de realisatie van het netwerk te zijn.
      Het gaat voor de opdrachtgever over functies en niet over de techniek.
      Daarom is er een verschil tussen een Functioneel Ontwerp (het wat, welke
      functionaliteit) en een Technisch Ontwerp (het waarmee, met welke
      apparatuur.)
      In een FNO kan bijvoorbeeld wel staan: “Er moet een verbinding over een
      TCP/IP connectie met een minimale bandbreedte van 10 Megabit/s
      beschikbaar zijn, omdat er maximaal x transacties tegelijkertijd op de
      database moet kunnen worden uitgevoerd die ieder y bandbreedte
      vragen.”
      (merk op dat deze doelstelling grotendeels SMART is weergegeven,                               )
                                                                         hè wat was dat ook al weer???


      In het FNO hoort echter niet te staan dat “hiervoor de HP server AB1234 of
      de Cisco Router XY987 geschikt voor is.”
 versie 0.3
T. Vriese, ROC Rivor;                                                                                    13
                               Valkuilen FNO
        Valkuil 1: Sluitpost
        Wat nog vaak voorkomt is dat bij een groot automatiseringstraject het
        netwerk ontwerptechnisch als sluitpost wordt gezien. Het hele
        automatiseringstraject (bijvoorbeeld invoering van een ERP systeem met
        dito database) wordt met zorg doorlopen en aan het eind wordt ineens nog
        bedacht dat er een (aangepast) netwerk nodig is om de applicatie te
        gebruiken. Op het laatste moment moet er dan nog een netwerk komen.
        Vaak is het hieruit voortvloeiend netwerkontwerp niet goed doordacht
        omdat er nauwelijks met beheer rekening is gehouden. Niet alleen
        ontstaan er dan functionele problemen, maar heeft dit vaak hogere kosten
        tot gevolg dan oorspronkelijk aan de klant is voorgespiegeld.
        Er zouden veel minder automatiseringsprojecten mislukken als eerder en
        beter aandacht zou worden geschonken aan het ontwerp van het netwerk.



 versie 0.3
T. Vriese, ROC Rivor;                                                              14
                            Valkuilen FNO
        Valkuil 2: Te weinig communicatie naar gebruikers
        Wat te vaak wordt onderbelicht is dat de invoering van een
        informatiesysteem voor een groot aantal werknemers een ingrijpende
        verandering in hun werkzaamheden betekent. Bepaalde taken of functies
        kunnen verdwijnen (zit ik daar dan ook bij?). Dat kan betekenen dat er
        weerstand is binnen een organisatie bij het invoeren van een systeem en
        een systeem waar weerstand tegen bestaat wordt doorgaans niet gebruikt
        Het is essentieel voor het slagen van het project dat vanaf het begin
        duidelijk wordt welk systeem in aantocht is, voor welke doelgroep en vooral
        ook het waarom.
        Om een systeem geaccepteerd te krijgen dient een communicatieplan en
        implementatieplan te worden opgesteld.
        Een ander argument om in een vroeg stadium toekomstige gebruikers te
        betrekken, is dat deze vaak het beste weten wat voor werk ze doen en
        welke functionaliteit ze het meest gebruiken. Ook zijn ze beter in staat om
        de volgorde van sommige stappen binnen hun werkproces te bepalen.
 versie 0.3
T. Vriese, ROC Rivor;                                                                 15
                           Documenteren
       In ieder project vormt het documenteren een onderdeel van alle fasen.
       Het is gedurende de gehele loop van het project een continu proces.
       Zo ook in de ontwerpfase. Hierbij dient bij iedere stap te worden
       vastgelegd wat de eisen voor deze stap zijn, welke gevolgtrekkingen
       daaruit mogelijk zijn en tot welke conclusies dit leidt.
       Bijna ieder besluit heeft ook ongewenste gevolgen. Een aantal zaken
       wordt onmogelijk. Dit zal ook naar alle belanghebbenden duidelijk
       moeten worden gecommuniceerd.
       Ook later wanneer het netwerk is gerealiseerd, zal moeten kunnen
       worden teruggevonden waarom voor bepaalde (on)mogelijkheden is
       gekozen.
       Documenteren is daarom een continu proces.



 versie 0.3
T. Vriese, ROC Rivor;                                                          16
                    Het ontwerp proces in hoofdlijnen
      Oké, nu we begrijpen wat een FNO inhoudt, gaan we weer terug naar de
      stappen van het ontwerp proces.

    1. Analyse
                                                                      • Business requirements

                              Technisch Ontwerp Functioneel Ontwerp
    2. Ontwerp
                                                                      • Applicaties; passend bij functies
    3. Bouw / realisatie
    4. Test: Integratie- en                                           • Datastromen; informatiestromen
       systeemtest
                                                                      • Netwerk; logisch ontwerp
    5. Implementatie en
       oplevering                                                     • Technologie; fysiek ontwerp
    6. Onderhoud en beheer


      Leuk, maar hoe gaan we nu te werk en hoe vertalen we de functionele
      eisen van de opdrachtgever in een concreet ontwerp???
 versie 0.3
T. Vriese, ROC Rivor;                                                                                       17
                        Business requirements
    Het ontwerpproces is een zogenaamd top-down benadering. Dit houdt in dat
    van ietwat abstracte begrippen, via steeds meer concretere invullingen, wordt
    afgedaald tot een uiteindelijk tastbaar resultaat.
    Bij de top-down benadering worden de eisen van de opdrachtgever centraal
    gesteld.
    Wij als ICT’ers neigen wel eens te vergeten dat ICT voor een opdrachtgever
    niet een doel is, maar hooguit een middel om zijn bedrijfsprocessen efficiënter
    en uiteindelijk ook effectiever te maken en daardoor een positieve bijdrage te
    leveren om bedrijfsdoelstellingen te halen.
    Nogmaals: Onthoudt dus dat het ontwerpstartpunt niet datgene is wat er
    technisch allemaal mogelijk is of wat voor leuks er op de markt is,
    maar de vereisten (Business Requirements) vanuit de werkzaamheden
    van de opdrachtgever.



 versie 0.3
T. Vriese, ROC Rivor;                                                            18
             Invulling Business requirements
        Maar hoe gaan we nu de Business requirements invullen?
        Om dit te waarborgen wordt o.a. gebruikt gemaakt van een zogenaamde
        BE matrix.
        Hierbij worden in een tabel horizontaal de Business requirements, dus de
        functionele eisen, ingevuld en verticaal alle componenten of technische
        voorzieningen die deel uit kunnen gaan maken van het informatiesysteem
        (in ons geval dus een datanetwerk).
        Vervolgens wordt in de matrix een beoordeling gegeven voor ieder
        component.
        Conclusie voortvloeiend uit de BE-matrix:
        Elke technische voorziening die niet bijdraagt aan een van de
        doelstellingen op de bovenste rij (zie volgende sheet), is blijkbaar niet
        belangrijk genoeg om te worden gerealiseerd.

 versie 0.3
T. Vriese, ROC Rivor;                                                               19
             Invulling Business requirements

Leveren deze componenten
                  een bijdrage aan



Kleurenlaserprinters

DVD ROM server

Internet verbinding

Custom applicatie

Bestandsdeling

Corporate database

Mainframeverbinding
 versie 0.3
T. Vriese, ROC Rivor;                          20
                        Invulling Applicaties
        Er kan niet vaak genoeg op worden gehamerd; de functionaliteit staat
        centraal in het ontwerp.
        Dit vindt dus zijn weerslag in de benodigde applicaties.

          Want:
          1. Uit de eisen van de opdrachtgever,
          2. De interviews met de toekomstige gebruikers (communicatie en
             daardoor acceptatie)
          3. En de professionaliteit van de functioneel ontwerper,


        volgt een voorstel voor de software die later op het netwerk beschikbaar
        zal zijn.

 versie 0.3
T. Vriese, ROC Rivor;                                                              21
                        Netwerk datastromen
          Het aanbieden van functionaliteit in de vorm van applicaties, heeft
          datastromen tot gevolg.
          Deze zullen in kaart moeten worden gebracht
          Daarbij moet niet alleen naar het gemiddelde dataverkeer worden
          gekeken, maar ook naar piekbelasting. Vrijwel ieder netwerk is in
          staat de gemiddelde datastroom van een dag te verwerken
          Cruciaal is echter de vraag of dit ook lukt als iedereen om half
          negen binnenkomt en zijn of haar computer aanzet.

          Of dat er voldoende tijd is om de voorgenomen back-up van de server
          te maken in de tijd die daarvoor is gereserveerd.

          Ook deze inventarisatie kan het beste in een matrix worden uitgevoerd.


 versie 0.3
T. Vriese, ROC Rivor;                                                              22
                        Netwerk datastromen
                         Benodigde     System      System        Eisen      Eisen mail
                         bandbreedte   resources   resources     database   server
    Applicatie                         server      werkstation   server


    Programma 1

    Programma 2

    Programma 3

    Programma 4

    Programma 5

    Programma 6




 versie 0.3
T. Vriese, ROC Rivor;                                                                    23
                           Netwerk concept

          Wanneer alle voorgaande stappen goed zijn ingevuld en alle verkregen
          informatie is gecontroleerd, op volledigheid, betrouwbaarheid, relevantie
          en actualiteit, kan worden gestart met de laatste stap van het FNO.

          Dit wordt het conceptdiagram met bijbehorende omschrijving en
          beargumenteerde toelichting.
          In een conceptdiagram wordt het netwerk getekend als een logische
          structuur (zie eenvoudige voorbeelden op volgende sheets)




 versie 0.3
T. Vriese, ROC Rivor;                                                                 24
                        Netwerk concept




 versie 0.3
T. Vriese, ROC Rivor;                     25
                        Netwerk concept




 versie 0.3
T. Vriese, ROC Rivor;                     26
                         Overgang FNO naar TO
          Langzaam maar zeker komen we nu in een grijs gebied. Een vast
          discussiepunt is altijd waar het FNO ophoudt en het Technisch Ontwerp
          (TO) begint. Bijvoorbeeld:
          • moet het IPnummerplan nu in het FNO komen of in het TO.
                  Zelf ben ik van mening dat dit in het TO behoort, tenzij er vanuit de functionele
                  eisen, argumenten naar voren komen om deze toch in het FNO op te nemen.
          • en de plattegrond? Uit oogpunt van functionaliteit is het van belang
             om inzicht te krijgen in de ruimtebeslag van servers en rest van de
             infrastructuur. Vaak zie je dat wordt volstaan met een globale plattegrond.
          In het latere TO komt dan een nadere invulling van de plattegrond.


          Wat in ieder geval voor ogen moet worden gehouden is dat bij het
          opzetten van een Functioneel Ontwerp enkele technische keuzes
          moeten worden gemaakt die, omdat ze rechtstreeks uit de gewenste
          functionaliteit volgen, in het FNO moeten worden uitgewerkt.
 versie 0.3
T. Vriese, ROC Rivor;                                                                                 27
                        Technische keuzes
          Om maar wat te noemen;
          • Gaan we bekabelen? Waarmee, UTP of glasvezel, welke topologie kiezen
            we dan en gaan we voor 100MB/s of 1GB/s? Wat zijn de consequenties?
          • Hoe is de fysieke constructie van het gebouw? Kunnen er kabelgoten
            worden gebruikt, is er een systeemvloer of systeemplafond? Of is het een
            pand dat op de monumentenlijst staat, dus niet overal kunnen zomaar
            doorgangen worden gemaakt?
          • Of gaan we voor draadloos? Relatief goedkoop, alleen…., zijn de
            systeemwanden van metaal? Is het een pand met veel gecoat glas? Is er
            veel elektronische apparatuur die storingen kan veroorzaken? Zitten we
            in de binnenstad, waar het “gonst” van de draadloze netwerken en het
            dringen is op alle kanalen? Hoe zit het met de veiligheid?
          • Is er eigenlijk wel een internetverbinding met de benodigde bandbreedte
             leverbaar op dit adres?
          • Hoe zit het met………etc.?
 versie 0.3
T. Vriese, ROC Rivor;                                                                 28
                                  Uiteindelijk
          Uiteindelijk komt het er op neer dat het FNO een weergave is van
          geformuleerde doelstellingen.
          En zoals we ongetwijfeld nog weten dienen doelstellingen SMART te zijn
          geformuleerd. Let daar dus op bij de oplevering van een FNO;
          • Zijn alle gevraagde aspecten Specifiek en niet multi-interpretabel
            omschreven.
          • Zijn alle aspecten in het FNO in Meetbare grootheden omschreven.
          • Is er of wordt er voldoende gecommuniceerd zodat er draagvlak wordt
             gecreëerd en het informatiesysteem Acceptabel is bij de toekomstige
             gebruiker.
          • Is datgene wat uiteindelijk moet worden opgeleverd Realiseerbaar met
            beschikbare menskracht en middelen en met aanvaardbare inspanning.
          • Is de planning en het projectplan dermate realistisch dat alles binnen de
            afgesproken Tijd kan worden uitgevoerd.

 versie 0.3
T. Vriese, ROC Rivor;                                                                   29

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:120
posted:3/2/2012
language:Dutch
pages:29