Onze trainingen zijn gecertificeerd en worden zeer goed gewaardeerd!

Informatie ASL

  • Wat is ASL?
  • Trainingslocaties


    Referenties


    Frans de Torbal Ministerie van VROM
    De Prince2 Foundation training is naar volle tevredenheid geweest. De theorie is goed overgebracht en met goede voorbeelden toegelicht.

    A. Vonk Oracle Nederland BV
    PRINCE2 Practitioner is een goede training. Het is een goede voorbereiding op het examen en de trainer heeft veel parate kennis.

    Overzicht referenties

    Klanten van ITMG


    SVUtilities
    Kwantum
    SevenTrees
    Gemeente Amsterdam
    CIBG
    DutchTrain
    ICT
    Zuidzorg
    De Nederlandse Zorg Autoriteit
    Overzicht klanten

    Visie op leren


  • Blended Learning
  • Praktijkgericht
  • Duurzaam
  • Social Return
  • Home » Training » Informatie » Best Practices » ASL Best Practice

    ASL BEST PRACTICE

    Doel ASL
    Application Services Library (ASL) heeft als doel het vak applicatiemanagement te professionaliseren. Dit wordt bereikt door het bieden van een framework waarin de verschillende processen van applicatiemanagement tot elkaar in relatie gebracht worden. Daarnaast dient het framework als kapstok om ontwikkelde best practices te categoriseren. Naast het framework omvat ASL een uniforme woordenlijst. Door het gebruik van standaard terminologie kunnen bij het applicatiemanagement betrokken partijen beter met elkaar communiceren.

    Filosofie ASL
    In het beheer van informatiesystemen kunnen drie deelgebieden onderkend worden:

    Functioneel beheer: het management namens de systeemeigenaar aan de gebruikerszijde van de informatiesystemen;
    Applicatiebeheer: management van het beheer, het onderhoud en de vernieuwing van applicaties (applicatieprogrammatuur en de databasestructuren) op een bedrijfsmatig verantwoorde manier;
    Technisch beheer: het beheer van de technische infrastructuren (rekencentrum-, netwerk- en werkplekbeheer).

    Waar ITIL (Information Technology Infrastructure Library) een algemeen aanvaarde standaard is geworden om het technisch beheer rondom informatiesystemen in te richten, biedt de Application Services Library een framework voor het inrichten van applicatiebeheer.

    Het ASL Framework

    Het ASL-framework is afgebeeld in figuur 1. De bollen en het blok in het midden staan elk voor een cluster van processen. Er worden drie niveaus onderscheiden: het uitvoerende, het sturende en het richtinggevende niveau.

    ASL is een procesmodel. Dit houdt in dat de werkzaamheden in een bedrijf beschreven worden aan de hand van processen die niet noodzakelijkerwijs hoeven samen te vallen met afdelingen of personen met een bepaalde functie. Een proces omvat werkzaamheden die volgens het ASL-model bij elkaar horen. In de praktijk kan een afdeling meerdere processen uitvoeren en een proces kan door meerdere afdelingen uitgevoerd worden. ASL kent de volgende processen:

    Uitvoerend: Beheerprocessen

    Er zijn vijf beheerprocessen in ASL. Deze processen zijn belangrijk omdat ze het gebruik van de applicaties ondersteunen met zo weinig mogelijk middelen en zo weinig mogelijk applicatie-onderbrekingen. Al deze processen zijn ook gedefinieerd in ITIL maar omdat ze hier vanuit applicatiebeheer gedetailleerd zijn, kunnen de processen enigszins afwijken. De volgende beheerprocessen zijn te onderscheiden:

    incidentbeheer
    configuratiebeheer
    beschikbaarheidsbeheer
    capaciteitsbeheer
    continuïteitsbeheer

    Uitvoerend: Onderhouds- en vernieuwingsprocessen

    Men schat dat zo’n 80% van het werk binnen applicatiebeheer te maken heeft met onderhouds- en vernieuwingsprocessen. Omdat de bedrijfsprocessen die door applicaties ondersteund worden continu veranderen, moeten de applicaties meeveranderen. Voor elke verandering zullen de onderhouds- en vernieuwingsprocessen doorlopen moeten worden. In ITIL zijn deze processen niet terug te vinden. Het gaat om de volgende processen:

    uitwerkingsanalyse
    ontwerp
    realisatie
    test
    implementatie

    Uitvoerend: Verbindende processen

    De verbindende processen verbinden de hierboven genoemde beheersprocessen met de onderhouds- en vernieuwingsprocessen. Er zijn twee verbindende processen. Wijzigingsbeheer bepaalt de inhoud van releases en aan welke releases onderhouds- en vernieuwingsprocessen mogen werken. Programmabeheer en distributie controleert de status van applicatiecomponenten en bepaalt welke applicatiecomponenten door de beheersprocessen gebruikt mogen worden. Het gaat om de volgende processen:
    wijzigingsbeheer
    programmabeheer en distributie
    Sturende processen

    Sturing is noodzakelijk om de hierboven genoemde processen optimaal te doen verlopen. Hierbij zijn vier aspecten van belang, te weten de oplevertijd, kosten, kwaliteit voor de medewerker en de kwaliteit voor de klant. Dit leidt tot de volgende processen:

    planning en control
    kostenmanagement
    kwaliteitsmanagement
    service level management

    Elk proces kent drie soorten activiteiten. Ten eerste moet een plan opgesteld worden of afspraken gemaakt worden: een resource planning, budgettering, kwaliteitsplan of SLA. Vervolgens moet dit plan of deze afspraken bewaakt worden. Tot slot moet er regelmatig gereviewed worden. De review leidt zo nodig tot een wijziging van het plan of de afspraken.

    Richtinggevend: ACM en OCM processen

    De ACM-processen (Applications Cycle Management) zorgen voor een lange termijn strategie met betrekking tot de applicatie. Hierbij zijn drie zaken van belang: de technologische ontwikkelingen, de ontwikkelingen bij de gebruikers- of klantorganisatie en ontwikkelingen in de omgeving van gebruikers- of klantorganisatie (bijvoorbeeld bij bedrijven waarmee de gebruikersorganisatie samenwerkt). De zaken leiden tot een strategie met betrekking tot de toekomst van de applicatie, de bijbehorende benodigde onderhoudsacties en een strategie met betrekking tot de applicatieportfolio.

    De OCM-processen (Organization Cycle Management) zorgen voor een lange termijn strategie met betrekking tot de ICT-organisatie waarbinnen het applicatiebeheer plaats vindt. Hierbij zijn de volgende zaken van belang: marktontwikkelingen, de gewenste benadering van de gebruikers- of klantorganisatie, de gewenste kennis en vaardigheden binnen de ICT-organisatie en de gewenste technologische middelen voor de ICT-organisatie. Deze zaken leiden tot een bepaling van de te leveren diensten op lange termijn.

    Gedetailleerde beschrijving van de uitvoerende processen

    Beheerprocessen

    Incidentbeheer
    Tijdens gebruik van applicaties kunnen storingen, vragen of wensen ontstaan. Deze worden als incident gemeld bij een helpdesk of servicedesk wat onderdeel is van het proces incidentbeheer. Dit proces streeft een handhaving van de dienstverlening na opdat voldaan wordt aan de afgesproken service levels. Ingewikkelde incidenten of vaak optredende incidenten worden als probleem doorgezet naar Kwaliteitsmanagement. Naast het reageren op incidenten wordt er ook pro-actief gehandeld, bijvoorbeeld door het communiceren van ontwikkelingen rond een bepaalde applicatie.

    Configuratiebeheer
    De applicaties en onderdelen daarvan en de afgesproken diensten en service levels moeten geadministreerd worden. Dit is de taak van configuratiebeheer. Ook wanneer iets op dit vlak wijzigt, moet er geadministreerd worden. De administratie wordt de CMDB (Configuratie Management DataBase) genoemd.

    Beschikbaarheidsbeheer
    Het is belangrijk dat een applicatie de afgesproken en gewenste functionaliteit kan bieden op de afgesproken tijden. Beschikbaarheidsbeheer zorgt hiervoor door het meten en rapporteren van beschikbaarheidsniveaus, het analyseren van eventuele tekortkomingen in de applicatie of het beheer, het initiëren van verbeteringen en het betrokken zijn bij nieuwe wijzigingen. Deze activiteiten en maatregelen worden in een beschikbaarheidplan vastgelegd.

    Capaciteitsbeheer
    De middelen die een applicatie gebruikt zoals geheugenruimte, diskruimte en cpu-vermogen moeten optimaal ingezet. Het moment, de hoeveelheid en de kosten zijn hierbij belangrijke aspecten. Capaciteitsbeheer verricht metingen ten aanzien van de gevraagde en beschikbare capaciteit, analyseert de metingen, rapporteert hierover en neemt zo nodig maatregelen. Mogelijke maatregelen zijn het verschuiven of opdelen van verwerkingen, vergroten van de capaciteit en het optimaliseren van de prestaties. Deze activiteiten en maatregelen worden in een capaciteitsplan vastgelegd.

    Continuïteitsbeheer
    Alle maatregelen die moeten garanderen dat de applicaties en de dienstverlening ook op langere termijn kunnen blijven functioneren, vallen onder continuïteitsbeheer. Er dient tegen diverse bedreigingen beveiligd te worden. Het gaat om bedreigingen zoals: virussen, hackers, fraude, brand, overstroming. Ook dient men rekening te houden met het wegvallen van leveranciers van wie men afhankelijk is. Aangezien het om dure maatregelen gaat, zal men het risico tegen de kosten moeten afwegen. Deze activiteiten en maatregelen worden in een continuïteitsplan vastgelegd.

    Onderhoud en Vernieuwing

    Uitwerkingsanalyse
    Onderhoud van een applicatie begint altijd met het analyseren van de uitwerking van de gewenste wijzigingen. Het gaat daarbij om de inspanning die benodigd is om de wijziging te realiseren en de consequenties voor gebruikers(organisatie) en beheerders. Hiervoor is nodig dat duidelijk wordt welke onderdelen van de applicatie gewijzigd moeten worden en door wie de betrokken applicatie(releases) gebruikt worden. Op basis van deze informatie wordt ook bepaald wat de beste oplossingsrichting is voor de wijziging. Ook wordt nu al in kaart gebracht hoe er getest moet gaan worden. Tijdens deze fase is er veel overleg met Technisch en Functioneel beheer.

    Ontwerp
    Tijdens deze fase worden de gewenste wijzigingen in overleg met Functioneel Beheer uitgewerkt en eenduidig gespecificeerd. Onderdeel van deze specificatie is onder andere een functionele beschrijving van de te verwerken informatie, de gewenste bewerkingen en de gewenste output in de nieuwe situatie. Ook aan samenhang en volgorde dient aandacht besteed te worden. Voor het specificeren maakt men veelal gebruik van een functioneel ontwerp. Verder wordt er ook uitgewerkt hoe er na realisatie getest dient te worden.

    Realisatie
    Tijdens de realisatie wordt de functionele specificatie uit de vorige fase technisch uitgewerkt tot een technisch ontwerp. Vervolgens wordt er nader uitgewerkt en gebouwd. Het resultaat is een change package, de gewijzigde programmaonderdelen en databestanden. Ook ondergaan de gewijzigde delen een eerste test: de unit-test waarbij de delen afzonderlijk van elkaar getest worden. Een belangrijk aspect hierbij is het voorkomen van het opnieuw optreden van fouten die reeds bij eerdere releases eruit zijn gehaald.

    Test
    Om te voorkomen dat de wijzigingen tot fouten in de applicatie leiden en om te borgen dat de gewenste functionaliteit in de nieuwe release verwerkt is, moet er getest worden. Onderdeel van het proces testen zijn de volgende soort testen:
    technische systeemtest (m.b.t. opgestelde specificaties en onderhoudbaarheid van de software)
    functionele systeemtest (m.b.t. afgesproken functionaliteit en kwaliteit)
    (ondersteuning van de) productietest door Technisch Beheer (m.b.t. exploiteerbaarheid)
    Zo mogelijk worden deze testen zo opgezet dat ze herbruikbaar zijn bij elke nieuwe release. Op die manier kan er efficiënt gewerkt worden. Om het testen nog meer gestructureerd aan te pakken zijn methoden ontwikkeld zoals TMAP en TestFrame. Deze methoden vallen niet onder ASL.

    Implementatie
    Anders dan het woord implementatie suggereert gaat het bij het proces implementatie niet om de daadwerkelijk implementatie van de nieuwe release in de productie omgeving. Deze actie wordt namelijk uitgevoerd door Technisch beheer in samenwerking met Functioneel beheer die de gebruikersondersteuning voor zijn rekening neemt. Wel ondersteunt dit proces Technisch beheer en Functioneel Beheer hierbij. Daarnaast sluit dit proces de release en de opdracht af na ontvangst van een verklaring van acceptatie opdrachtdecharge vanuit Functioneel beheer.

    Verbindende processen

    Wijzigingsbeheer
    Diverse processen dienen wijzigingsverzoeken in bij wijzigingsbeheer. Deze wijzigingen worden vervolgens geregistreerd, geclusterd en ingepland in releases. Dit gebeurt in overleg met processen zoals service level management, functioneel beheer, planning en control en impactanalyse. Vervolgens bewaakt dit proces uitvoering van het maken van een nieuwe release in de onderhoud en vernieuwingsprocessen.

    Programmabeheer en distributie
    Dit proces moet voorkomen dat er ongeautoriseerde wijzigingen plaatsvinden. Wanneer in het onderhouds- en vernieuwingsproces bepaalde applicatie onderdelen gewijzigd dienen te worden dan zal dat onderdeel eerst door dit proces ter beschikking gesteld moeten worden. Wanneer de applicatie in productie genomen moet worden dan zal dit proces voor de distributie zorgen zodat de juiste applicatie onderdelen operationeel gemaakt worden. Daarbij let dit proces onder andere op interferenties en overlappingen tussen verschillende parallel lopende releases.