ASL-beheermethodiek
Uit Wikipedia, de vrije encyclopedie
ASL (Application Services Library) is een procesraamwerk, ondersteund door Best Practices, dat de processen van het beheer, onderhoud en vernieuwing van informatiesystemen en applicaties beschrijft. Het biedt een handvat bij het verbeteren van organisaties, die applicatiebeheer uitvoeren. Door gebruik van best-practices en diagnose-instrumenten, zoals zelfevaluaties, kan men pragmatisch aan de slag met het verbeteren van het applicatiebeheer.
ASL beschrijft de processen op uitvoerend (operationeel), sturend (tactisch) en richtinggevend (strategisch) niveau. Het kent zes clusters, met daarin processen.
ITIL is als beheermethodiek sterk gericht op het beheren van IT-infrastructuren, ASL legt de nadruk op applicatiebeheer, op de processen rond het beheren en onderhouden van software en de gegevensbanken. De ITIL processen zijn voor een groot deel binnen ASL terug te vinden, met name in de hoek van de beheer-processen en de tactische processen. Eigen voor ASL is de nadruk op de ontwikkelcyclus (onderhoud / vernieuwing).
ASL is een Nederlandse standaard in het publieke domein, beschikbaar voor iedere organisatie, en wordt beheerd door een stichting, die wordt ondersteund door een aantal grote ICT-bedrijven.
Inhoud |
[bewerk] De omgeving van ASL
Men onderscheidt in de ICT drie vormen van beheer (beheerdomeinen). Technisch Beheer is het meest bekend, richt zich op het beheer van de IT-infrastructuur en heeft ITIL als standaard. De IT-infrastructuur is een basis waarop applicaties kunnen draaien. Deze applicaties worden beheerd door Applicatie Beheer. Onder dit beheer wordt verstaan het aanpassen van de applicatie naar aanleiding van geconstateerde fouten in de applicatie of veranderende technische of functionele eisen. Het gaat nadrukkelijk om bestaande applicaties en niet om nieuwbouw van applicaties. ASL is hiervoor de standaard. ASL is nieuwer dan en deels geïnspireerd op ITIL. De applicaties worden gebruikt door de gebruikersorganisatie. Deze organisatie zal aan moeten geven aan welke eisen die applicatie moet voldoen en controleren of na een eventuele aanpassing deze applicatie inderdaad voldoet. Dit proces noemt men Functioneel Beheer en heeft als standaard BiSL.
[bewerk] ASL-processen
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:
[bewerk] Beheersprocessen
Er zijn vijf beheersprocessen 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 beheersprocessen zijn te onderscheiden:
[bewerk] 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:
[bewerk] 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:
[bewerk] Sturende processen
Sturing is noodzakelijk om de hierboven genoemde processen optimaal te doen verlopen. Hierbij zijn vier aspecten van belang oplevertijd, kosten, kwaliteit voor de medewerker en kwaliteit voor de klant. Dit leidt tot de volgende processen:
Elk proces kent drie soorten activiteiten. Ten eerste moet er 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.
[bewerk] 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.
[bewerk] De processen in detail
[bewerk] Beheerprocessen
[bewerk] 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.
[bewerk] 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.
[bewerk] 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.
[bewerk] 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.
[bewerk] 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.
[bewerk] Onderhoud en Vernieuwing
[bewerk] impactanalyse
Onderhoud van een applicatie begint altijd met het analyseren van de impact 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.
[bewerk] 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.
[bewerk] 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.
[bewerk] 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.
[bewerk] 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.
[bewerk] Verbindende processen
[bewerk] 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.
[bewerk] programmabeheer en distributie
Dit proces moet voorkomen dat er ongeautoriseerde wijzigingen plaatsvinden. Wanneer in het Onderhoud 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..
[bewerk] Verdere informatie
- Remko van der Pols - ASL, een framework voor applicatiebeheer, 2001, ISBN 904400266X
- Yvette Backer, Remko van der Pols - ASL, a management guide, 2003, ISBN 90-77212-04-3
- Peter Janssen - Applicatiebeheer volgens ASL, 2005, ISBN 90-430-0883-4
