applicatiebeheer

Gebruik de 522 IT checklisten van ITpedia, met in totaal 22028 vragen.

Zoek in de omschrijvingenOmschrijvingAantal vragen
IT projectfaseringBestaat uit meerdere checklisten
Application Services Library (ASL)Bestaat uit meerdere checklisten
ContinuïteitBestaat uit meerdere checklisten
KwaliteitsattributenBestaat uit meerdere checklisten
Functies in de automatiseringBestaat uit meerdere checklisten
WebdesignBestaat uit meerdere checklisten
Of zoek naar een woord: Fulltekst

Laatst gebruikt: Rapportage acceptatietest op: 2017-02-25 17:12 Checklist
Toezenden van eerdere beoordelingen per e-mail.
E-mailadres:

The Economics of Application Management

Samenvatting van volledige publicatie van Machteld Meijer en Mark Smalley op ASL BiSL Foundation Market research shows that one third of IT budgets is spent on management of applications, and that this part is increasing. It is therefore not surprising that there is growing attention for the economic aspects of both demand management (business responsibility) and application management (technical responsibility). This article […]

ASL ondersteunt groot deel van de eisen van ISO 9001:2000

Voorwoord Enkele jaren geleden hebben we veel vergelijkingen gemaakt tussen ASL en diverse andere modellen, frameworks en standaarden. Een daarvan is hier geplaatst. In de tussentijd is er zowel een nieuwe versie van de ISO-9001 norm als van ASL op de markt gekomen. De hoofdlijnen zijn echter nog steeds van kracht. Een van de belangrijkste […]

Van Machteld Meijer op 5 april 2011 | Achtergronden, Analyses | Aanvullen?
Tags:, , ,
Checklisten: Geen

Elektronische consultant en kwaliteitstool

Dit artikel gaat over automatiseren en de kwaliteitszorg die goede automatisering van de organisatie vraagt. Daarbij wordt ITpedia geïntroduceerd als checklisten systeem dat de praktische verbinding legt tussen automatiseren en kwali­teitszorg. Gebruikers van ICT komen telkens knelpunten op hun weg tegen die vaak een nauwe relatie hebben met de geautomatiseerde delen van de organisatie. Naar […]

ASL 2 en ITIL v3 Hoe liggen de verhoudingen nu?

In 2009 is een nieuwe versie van ASL op de markt gekomen: ASL 2. In het boek waarin ASL2 wordt beschreven wordt summier ingegaan op de relatie tussen de ASL-processen en infrastructuurmanagement, maar niet op de relatie met ITIL. Eerder is al wel literatuur verschenen die ASL 1 vergelijkt met ITIL v2 en ITIL v3. In dit artikel […]

Van Machteld Meijer op 23 maart 2011 | Analyses, Methoden | Aanvullen?
Tags:, , , , ,
Checklisten: Geen

Challenges in Application Management

Samenvatting van volledige publicatie  Application Management (AM) is an IT domain that supports organizations by keeping their applications up and running, up to date and under control. AM consumes about a third of IT budgets. But what keeps AM people awake at night? This white paper summarizes the results of workshops in which representatives of the […]

Beheer

‘Beheer’ Omdat de ervaring leert dat het begrip ‘beheer’ rekbaar is wordt aangegeven wat wel en niet onder beheer en onder de drie beheerdomeinen functioneel beheer, applicatiebeheer en technisch beheer wordt verstaan. Zo’n 15 jaar geleden is het hele IT-beheerwerkveld door Looijen en Delen [Delen 1992] opgedeeld in drie aandachtsgebieden of beheerdomeinen, te weten functioneel beheer, […]

Economisch beheer van ICT

Samenvatting van volledige publicatie van Machteld Meijer en Mark Smalley op ASL BiSL Foundation Nederland moet de hoge uitgaven aan ICT beter benutten. Driekwart van ICT-budgetten wordt aan ICT-beheer besteed maar er is betrekkelijk weinig bekend over de dynamiek van ‘economisch beheer’. De bedrijfseconomische functie van beheer is vooral het bewerkstelligen dat het potentieel van gedane investeringen wordt benut. Verbetermogelijkheden worden vooral […]

Kosten van applicatiebeheer onder de loep

Samenvatting van volledige publicatie van Wil van der Drift en Mark Smalley op ASL BiSL Foundation De laatste jaren kijken veel organisaties kritischer dan voorheen naar hun kosten, ook voor de ICT-ondersteuning. Uiteraard moet ook naar de opbrengsten worden gekeken, maar de actuele trend is om de kosten onder de loep te nemen. Dit artikel verkent het gebied applicatiebeheer […]

Service-Oriented Application Management

Samenvatting van volledige publicatie. SOA and IT Management SOA is sexy Applications used to consist of several large programs that were difficult to modify and that were interconnected with batch-interfaces or by sharing data in common databases. These monolithic the eighties and nineties were generally more modular and distributed and made use of graphical user […]

Van Mark Smalley op 24 februari 2011 | Analyses, Oplossingen, White papers | Aanvullen?
Tags:, , ,
Checklisten: 3

Derde generatie applicatiebeheer

Samenvatting van volledige publicatie van Mark Smalley op ASL BiSL Foundation Inleiding Het toenemende belang van ICT voor de organisatie en de toenemende complexiteit van beheervraagstukken heeft de afgelopen decennia gezorgd voor een groei van het vak applicatiebeheer. In de jaren negentig maakten we de stap van de eerste generatie applicatiebeheer, dat erg reactief en operationeel was, naar […]

Van Mark Smalley op 14 februari 2011 | Achtergronden, Analyses, Methoden | Aanvullen?
Tags:,
Checklisten: 1

Beheerkosten en -baten in de greep

Samenvatting van volledige publicatie van Machteld Meijer en Mark Smalley op ASL BiSL Foundation Economische aspecten van beheer van applicaties onder de loep Uit rapporten en enquêtes onder IT-managers blijkt dat een derde van de IT-kosten wordt besteed  aan het beheer van applicaties, en dat aandeel wordt alleen maar groter. Niet verwonderlijk dat er groeiende aandacht is voor het […]

Van Mark Smalley op 11 februari 2011 | Analyses, Methoden | 1 aanvulling
Tags:, , , ,
Checklisten: 2

Applicatieonderhoud in de schijnwerpers

Samenvatting van volledige publicatie van Mark Smalley op ASL BiSL Foundation De belangstelling voor applicatiebeheer van het (financieel) management groeit omdat er steeds meer geld in omgaat. Met de recessie heeft het bedrijfsleven de budgetkranen dichtgedraaid tot het niveau van een karig straaltje. Vanwege tegenvallende inkomsten wordt fors in budgetten voor bestaande activiteiten geschrapt en […]

Van Mark Smalley op 6 februari 2011 | Analyses | Aanvullen?
Tags:, ,
Checklisten: 2

ITIL v3 en ASL, een Latrelatie

Samenvatting van volledige publicatie van Machteld Meijer en Mark Smalley op ASL BiSL Foundation   In de nieuwe versie van ITIL is vrij veel veranderd. Aspecten van applicatiebeheer komen in alle vijf kernboeken voor en de raakvlakken met ASL lijken nadrukkelijker aanwezig dan in de vorige versie. Toch zijn er op diverse gebieden verschillende opvattingen binnen ITIL en ASL over wat applicatiebeheer is en hoe dat wordt ingevuld. Dit artikel […]

Cloudy Application Management

Samenvatting van volledige publicatie van Mark Smalley op ASL BiSL Foundation Adoption of Cloud Computing – in particular Software as a Service – will confront the ‘business-facing’ Application Management function with changes that add extra complexity to the execution of approximately half of the processes that Application Management entails. ‘Business-facing’ refers not to the one-to-many […]


Versiebeheer in een maatwerk omgeving

1. Doel versiebeheer

Het doel van versie beheer is om op ieder moment de juiste versie van de programmatuur in de productieomgeving ter beschikking te hebben. en ook te houden voor herstel bij calamiteiten. Ten tweede is het bedoeld voor het bijhouden van de historie van programmatuur. Zodoende kan worden teruggevallen op voorgaande versies van de applicatie als zich calamiteiten voordoen.
Tenslotte is versiebeheer een middel is om alleen die programmatuur in productie te nemen die door de gebruikersorganisatie is geaccepteerd.

2. Inleiding versiebeheer

Het beheren van software is geen eenvoudige opgave. Door een strikte opzet van het versiebeheer kan veel ellende worden voorkomen. Dit artikel is bedoeld als voorbeeld voor het opzetten van het versiebeheer in een Oracle omgeving. Iedere organisatie zal een eigen invulling kennen en dient als aanvulling op de handboeken en procedures van het ontwikkelteam en systeembeheer te worden gezien.

3. Over te dragen van onderdelen

Als een applicatie gebruik maakt van aanvullende tools dan worden de onderdelen die daarvoor aan de clientzijde benodigd zijn gerekend tot onderdelen van de applicatie. Deze dienen ook in het versiebeheer van de applicatie meegenomen te worden.
In de database opgeslagen standaard routines gelden voor iedere applicatie en worden niet tot de applicatie gerekend

3.1 Onderdelen die geen gegevens bevatten

3.1.1 Rollen

Voor iedere rol binnen de applicatie wordt een script opgeleverd dat de rol genereert en de rechten aan de rol toekent. Een volgende versie van dit script bevat opnieuw het gehele script inclusief het aanmaken van de rol, ook als deze al bestaat. Bij de eerste oplevering van een applicatie mag de definitie van alle rolen in één script worden aangeleverd.
Het toekennen van rollen aan gebruikers is niet geautomatiseerd en kan alleen plaatsvinden met behulp van een Mutatie Autorisatie Formuler.

3.1.2 Synoniemen

Synoniemen worden niet overgedragen tussen de verschillende omgevingen. Aan de hand van de rechten van een gebruiker zullen synoniemen worden aangemaakt door systeembeheer. Dit gebeurt bij het aanmaken van nieuwe gebruikers of bij een wijziging in de applicatie

3.1.3 Schermen, rapporten, grafieken, library’s en SQL*script’s

Van een scherm wordt telkens de source files overgedragen. Op de doelomgeving wordt het uitvoerbare scherm gegenereerd vanuit de source file. Library’s die bij een specifiek rapport of scherm horen dienen samen met dit scherm of rapport opgeleverd te worden, ook als er geen wijzigingen zijn.

3.1.4 Referentieschermen

Schermen van dit type worden ook als source-file overgedragen maar in de doelomgeving niet gegenereerd.

3.1.5 Functies, procedures, packages, triggers, snapshots en views

Deze zijn opgeslagen in de database maar worden gegenereerd vanuit een SQL script. Hiervoor geldt dat de naam van het script overeen dient te komen met de modulenaam.
De betreffende module wordt altijd compleet aangeleverd in het script (CREATE OR REPLACE), hiermee wordt bereikt dat het script altijd de laatste versie van de module bevat.

3.1.6 Indexen niet bedoeld voor een foreign-key of primary-key

Het script voor een index bevat het CREATE statement van de index of een ALTER statement voor de index. Als de index wordt vervangen dan moet het DROP statement in het script zijn opgenomen.

3.2 Onderdelen die wel gegevens bevatten

Dit zijn:
Tabellen en bijbehorende foreign-keys, primary-keys en check-constraints
Sequences
Voor deze onderdelen geldt een andere werkwijze dan voor andere onderdelen omdat hierin gegevens opgeslagen zijn. Omdat deze onderdelen niet opnieuw gegenereerd kunnen worden dienen ze bijgewerkt te worden. Er is gekozen voor het opleveren van één script met daarin de CREATE of ALTER statements voor alle tabellen, sequences en indexen waarbij dit van toepassing is.

4. Versiebeheer

Het versienummer van een module wordt aangegeven met drie cijfers (bijvoorbeeld 1.1.1).
Het eerste cijfer is het releasenummer van de applicatie. Dit wijzigt zelden.
Het wordt bepaald door de eigenaar van de applicatie en staat voor de release van de software.
Het tweede cijfer is het versienummer van de module. Dit versienummer begint bij 1 en wordt opgehoogd telkens wanneer een module die al in productie is wordt aangepast.
Het derde cijfer is het testnummer. Dit cijfer begint bij 1 en wordt opgehoogd telkens wanneer de module opnieuw ter acceptatie wordt aangeboden. Bij wisseling van het tweede cijfer start dit opnieuw bij 1.

4.1 Onderdelen die geen gegevens bevatten

Elke keer dat een module wordt opgeleverd voor productie zal het versienummer van de module één hoger zijn dan de versie in productie. Wanneer de module meerdere malen ter acceptatie wordt aangeboden wordt het testnummer meerdere malen opgehoogd

4.2 Onderdelen die gegevens bevatten

Al deze onderdelen bij elkaar worden altijd als één module opgeleverd. Hiervoor geldt dat het versienummer bij elke oplevering ter acceptatie 1 hoger is dan de vorige oplevering. Wanneer een onderdeel wordt geaccepteerd zullen alle versies, hoger dan de huidige versie in productie, opeenvolgend in productie worden genomen.
De reden hiervoor is dat een database éénmalig wordt aangemaakt waarna er diverse wijzigingen plaatsvinden. Het is immers niet mogelijk om voor een bestaande database met gegevens een nieuw creatie script op te leveren. Gevolg is dat de huidige database aangepast dient te worden.

5. Identificatie source files en overige onderdelen

De bestandsnamen van de sources die opgeleverd worden dienen als volgt te worden opgebouwd:
<MODULENAAM>_<VERSIE>_<RELEASENUMMER>.<EXTENSIE>.

Hierin is <MODULENAAM>
de naam van de module

<VERSIE>
1 e en 2e positie versienummer applicatie opgevuld

3e en 4e positie versienummer module opgevuld

<RELEASENUMMER> 5e en 6e positie releasenummer module opgevuld

<EXTENSIE> de extensie die behoort bij dat type onderdeel.

(bv. HEFAFR50_030203.FMB voor versie 3.2.3 van HEFAFR50.FMB of HEFADN12_012303.FMB voor versie 1.23.3 voor HEFADN12.FMB). Sources files dienen op de machine van de betreffende omgeving bewaard te worden in een aparte directory. Dit dient ook voor de productieomgeving zo te zijn. Doel hiervan is dat op de back-up van een willekeurige machine zowel de sources als de uitvoerbare bestanden staan.
De versienummers opgenomen in de bestandsnaam zullen in de uiteindelijke omgeving verwijderd worden door systeembeheer.

Verder dient het versienummer in schermen zichtbaar te zijn in de titelbalk, bij rapporten op het schutblad of, indien er geen schutblad is, onderaan de pagina.
Voor schermen kan dit bijvoorbeeld gebeuren door de windowtitle van het eerste blok aan te vullen met het versienummer.

Bij modules in de database, zoals triggers, procedures (niet in een package), functies (niet in een packages) en packages, dient het versienummer in de code te worden opgenomen, dit mag bonvenaan of onderaan de code. Dit bij voorkeur voortschrijdend zodat ook wijzigingen in het verleden zichtbaar zijn.

5.1 Uitzondering voor tabellen en sequences.

 De modulenaam voor het script dat tabellen en sequences oplevert heeft als naam
<applikatie afkorting>
. De extensie van dit bestand is .TAB. In dit bestand dienen alle statements ten aanzien van tabellen, sequences, foreign-keys, primary-keys en check-constraints te staan.

Bijvoorbeeld: HEF_010101.TAB

5.2 Uitzondering voor eerste oplevering

Voor de eerste oplevering van een applicatie voor acceptatie is het toegestaan om naast het script dat de tabellen en sequences oplevert ook voor de procedures, functies, triggers en grants één script op te nemen dat dit alles genereert. Dit komt overeen met de methode waarop Oracle Designer de scripts genereert.

Bijvoorbeeld (voor de applicatie IMI):
IMI_010101.SQL wat aanroept:
IMI_010101.TAB (voor de tabellen en sequences)
IMI_010101.TRG (voor database triggers)|
IMI_010101.FNC (voor functies)|
IMI_010101.PRC (voor procedures)
IMI_010101.RGR (voor rollen)|
IMI_010101.VW (voor views)

Indien modules die in één van deze script zitten opnieuw worden opgeleverd dienen ze opgeleverd te worden conform het hoofdstuk Versiebeheer en het hoofdstuk Identificatie source-files.

6. Formulieren

Voor de overdracht van ontwikkeling naar acceptatie en uiteindelijk naar productie dient de juiste procedure gebruikt te worden. Per modulegroep die opgeleverd gaat worden dient een Applicatie Changemanagement Formulier of een Problem Management Formulier ingevuld te worden. Op een bijlage dient aangegeven te worden welke modules worden opgeleverd en welke versies deze modules hebben.
Met één formulier is het mogelijk het gehele traject van één versie van één of meerdere modules te bestrijken van oplevering ter acceptatie tot in productiename. Ook als er meerdere malen een oplevering plaatsvindt.

6.1 Changemanagement

Een applicatie changemangament formulier wordt gebruikt wanneer een applicatie nieuw wordt opgeleverd of wanneer nieuwe functionaliteit wordt toegevoegd. Tevens wordt dit formulier gebruikt wanneer functionaliteit verwijderd dient te worden.

6.2 Problemmanagement

Een problem management formulier wordt gebruikt wanneer in bestaande functionaliteit problemen zijn ontdekt die opgelost dienen te worden.

7. Overdracht

Zeer belangrijk voor een goed versiebeheer is dat de drie omgevingen strikt gescheiden blijven:

Ontwikkeling: Hier werkt de ontwikkelaar aan de applicatie.
Acceptatie: Deze omgeving is alleen toegankelijk voor testers van de gebruikersorganisatie en is bedoeld voor het accepteren van opgeleverd programmatuur.
Oplevering voor deze omgevingen worden uitgevoerd door systeembeheer.
Productie: Dit is de omgeving waarin de eindgebruikers werken.
Oplevering voor deze omgevingen worden uitgevoerd door systeembeheer.

De stappen die programmatuur ondergaat is als volgt:

Ontwikkeling (Actie: ontwikkelaar)
Overdracht ontwikkeling – acceptatie (Actie: systeembeheer)
Acceptatie (Actie: gebruikersorganisatie)
Overdracht acceptatie – productie (Actie: systeembeheer)
In productiename

Het is in alle gevallen uitgesloten dat programmatuur rechtstreeks vanuit ontwikkeling naar productie gaat.


-- Printbare PDF-versie --