Application Services Library (ASL) procesmodel

ArchiMate-modellen > GGI > Views > Application Services Library (ASL) procesmodel
Application Services Library (ASL) procesmodel
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. (BusinessProcess) Application Services Library (ASL) procesmodel BusinessProcess Richtinggevende processengroep De OCM-processen (Organization Cycle Management) zorgen voor een lange termijn strategie met betrekking tot de ICT-organisatie waarbinnen het applicatiebeheer plaatsvindt. 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. (BusinessProcess) Organization Cycle Management 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). Deze 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. (BusinessProcess) Application Cycle Management processen BusinessProcess Sturende processengroep 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: * contractmanagement * planning en control * kwaliteitsmanagement * financieelmanagement * leveranciersmanagement 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. Hierna zal er worden geëvalueerd en bijgeleerd. (BusinessProcess) Sturende processen Overkoepelend proces voor de uitvoerende processen van de GGI-Services platformbeheerder. (BusinessProcess) Uitvoerende processengroep 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. (BusinessProcess) Beheerprocessen 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. (BusinessProcess) Continuïteitsbeheer 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. (BusinessProcess) Configuratiebeheer De middelen die een applicatie gebruikt zoals geheugenruimte, diskruimte en CPU-vermogen moeten optimaal worden 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. (BusinessProcess) Capaciteitsbeheer Tijdens gebruik van applicaties kunnen storingen, vragen of wensen ontstaan. Deze worden als incident gemeld bij een helpdesk of servicedesk die 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 proactief gehandeld, bijvoorbeeld door het communiceren van ontwikkelingen rond een bepaalde applicatie. (BusinessProcess) Incidentbeheer 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 beschikbaarheidsplan vastgelegd. (BusinessProcess) Beschikbaarheids- beheer 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. (BusinessProcess) Verbindende processen Diverse processen dienen wijzigingsverzoeken in bij wijzigingenbeheer. Deze wijzigingen worden vervolgens geregistreerd, geclusterd, geprioriteerd 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 onderhouds- en vernieuwingsprocessen. (BusinessProcess) Wijzigingenbeheer 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 vrijgaven. (BusinessProcess) Programmabeheer en distributie 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. (BusinessProcess) Onderhoud en Vernieuwing 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(vrijgaven) 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. (BusinessProcess) Impactanalyse 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. (BusinessProcess) Ontwerp 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. (BusinessProcess) Implementatie 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. (BusinessProcess) Realisatie 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 (met betrekking tot opgestelde specificaties en onderhoudbaarheid van de software) * functionele systeemtest (met betrekking tot afgesproken functionaliteit en kwaliteit) * (ondersteuning van de) productietest door Technisch Beheer (met betrekking tot 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. (BusinessProcess) Test Deze svg is op 06-04-2024 16:23:05 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 06-04-2024 16:23:05 CEST
Klik hier om deze view op ware grootte te tonen.
Klik hier om de technische details van deze view te tonen.
Legenda




   
ArchiMate-view Application Services Library (ASL) procesmodel
Elementtype  : ArchiMateView
Element-id  : GGI/id-9ca62e57-c0a4-497f-a819-e52573095723
ArchiMate-model  : GGI
Label  : Application Services Library (ASL) procesmodel
ArchiMate-gezichtspunt  : Introductory
Object ID  : 9ca62e57-c0a4-497f-a819-e52573095723
Publiceren  : GEMMA Online en redactie
Elementen  : 
Relaties  : (Er is niets om te tonen.)

De GEMeentelijke ModelArchitectuur met een verzameling samenhangende kaders, richtlijnen, referentiemodellen en standaarden die gemeenten helpt bij het inrichten van hun IT-omgeving en processen.

Overgenomen van "https://www.gemmaonline.nl/index.php?title=GGI/id-9ca62e57-c0a4-497f-a819-e52573095723&oldid=797093"
Deze pagina is het laatst bewerkt op 14 apr 2021 om 14:18.