Best practices

De relatie tussen ITpedia en Inspector Online

Inspector Online is een reviewtool speciaal voor de ICT. Met Inspector is de kwaliteit van zowel automatiseringsprojecten als informatiesystemen te beoordelen. Een groot deel van de Inspector technologie is ondergebracht in ITpedia. Zo kan iedereen profiteren van de Public Domain versie. 

Fagan inspecties op programmacode, heeft dat nog nut?

Met het huidige gebruik van ontwikkeltools wordt het hard coderen van programmatuur een steeds kleiner wordend onderdeel van de realisatiefase. Veel van de businessrules zitten al in het tool en kunnen zo naar code gegenereerd worden. Het programmeerwerk komt vaak nog als de gebruikersinterface op maat gemaakt moet worden. Daarnaast zijn er nog veel bedrijven en ontwikkelaars die zweren bij het zelf coderen omdat je het resultaat dan zelf in de hand hebt. Tenslotte ontkom je in de meeste legacy systemen niet aan programmeerwerk.
Met behulp van Fagan inspecties zijn voor het testen al veel fouten uit de programmacode te halen.

Het gevaar van checklisten

ITpedia staat overvol met checklisten van velerlei aard. Deze checklisten kunnen je helpen bij het beoordelen van IT producten en IT organisaties. Omdat het kant en klare checklisten zijn kan je meteen aan de slag en dat scheelt veel tijd. Daarbij kunnen de checklisten je op punten wijzen waar je nog niet eerder aan hebt gedacht. Niet te min schuilt er een aantal gevaren aan het gebruik van checklisten. Voordat je lukraak begint met invullen wil ik je graag eerst op deze punten wijzen. [Klik op de titel voor het gehele artikel] 

Releases en change-management bij maatwerk applicaties

Op grote maatwerk informatiesystemen waarbij de informatiebehoeften vaak en onregelmatig wijzigen zal veel onderhoud plaatsvinden. Onderhoud op functies die soms al weer veranderen voordat de vorige wijziging in productie is genomen. Deze vorm van onder­houd doet zich met name voor als maatwerk applicaties regelgeving ondersteunen die door de politiek wordt bepaald. Uitvoerenden hebben vrijwel geen invloed op hoe de regelgeving met alle uitzonderingen eruit komt te zien en op welk moment deze regelge­ving van kracht wordt. De ervaring leert dat het geen zin heeft om tijd te rekken of de regelgeving onvolledig door te voeren. Wat wel werkt is de nieuwe regelgeving tijdelijk op een geïsoleerd (PC)systeem uit te voeren zodat tijd ontstaat om de nieuwe informatiebehoefte goed in het informatiesysteem in te bouwen.

Activiteiten bij een ICT uitwijktest

Organisaties die een uitwijkplan hebben doen er goed aan om dit plan regelmatig te testen. De omstandigheden veranderen telkens en voor je het weet sluit het plan niet meer aan op de omgeving waarin de uitwijk moet plaatsvinden bij een echte calamiteit. In totaal moeten er 18 stappen worden doorlopen voordat je kan zeggen dat het uitwijkplan op orde is. [Klik op de titel voor het gehele artikel]

Opleidingsplan en voorlichtingsplan, een blauwdruk

Er wordt een opleidings- en voorlichtingsplan voor gebruikers gemaakt bij een nieuw systeem of als een nieuwe release veel verschilt van het de vorige. Welke onderdelen moeten worden opgenomen?  [Klik op de titel voor het gehele artikel]

Kwaliteitsplan helpt het beheer in kaart te brengen

Het kwaliteitsplan voor beheer dient om aan te geven hoe informatiesystemen op een constant kwaliteitsniveau moeten worden gehouden. Als na de invoering van een systeem er geen aandacht meer aan wordt besteed zal dat systeem langzaam wegkwijnen.

Eisen aan applicaties

De kwaliteit van een applicatie wordt afgeleid van de mate waarin de applicatie aan de eisen voldoet. Tijdens de informatieanalyse en het ontwerp ligt de nadruk vooral bij de functionele eisen. Wat moet de applicatie allemaal kunnen. Er zijn echter ook algemene eisen die aan iedere applicatie gesteld kunnen worden maar wel per applicatie kunnen verschillen.

Alle SQL queries documenteren, fantasie of noodzaak

Vaak is de documentatie waarin de functionaliteit apart is beschreven is niet aanwezig. Deze informatie is in de meeste gevallen echter wel in het ontwerp terug te vinden. Daardoor is de status van de functionele beschrijving meestal wel actueel, de ontwikkelaars hebben het ontwerp immers nodig als uitgangspunt voor de bouw van de applicatie. De functionele beheerder heeft echter zelf gemaakte queries in beheer waarvan ook documentatie aanwezig hoort te zijn. [Klik op de titel voor het gehele artikel]

Testen terwijl het systeem in productie is

In vrijwel alle projecten en onderhoudssituaties vormt het testen van de opgeleverde programmatuur een probleem. De applicatie is reeds in gebruik en nu komt er een wijziging die de werking zal veranderen. De verandering wordt doorgevoerd terwijl het systeem in gebruik is. Slecht korte tijd (maximaal een weekend) zal het systeem zijn afgesloten om de wijziging door te voeren.

Sidebar