Sharing IT Best Practices with youVersioning Introduction Version management is an essential aspect of the DevOps deployment pipeline. Many DevOps teams realize too late that every object needs to have a (correct) version. This article gives a list of objects to be versioned and explains why to version these objects. Versioning Definitions Object In this article, an object is defined… lees verder »
Waterfall vs Agile, Introduction This article describes the arguments when to use waterfall or an incremental and interative approach. Waterfall vs Agile, Definitions Increment The Agile way of working consists of building increments rather than a complete product or service. Each increment has an added value. The architecture of the product / service has to… lees verder »
Planning The Deliverables, Introduction This article describes some of the most important deliverables of a DevOps planning. Planning The Deliverables, Definitions Funnel A funnel is a metaphor used to indicate a selection pathway. The graphical representation is a funnel. There are more ideas than can be realized. As an idea gets more shape and the business… lees verder »
Versiebeheer van programmasources is sinds de introductie van computers altijd een aandachtspunt geweest. Kort gezegd gaat het om deze vraag: Wat moeten we doen als er een bug ontstaat in een programma dat toevallig onderdeel is van een andere change. Er zijn dus al twee versies van het programma en nu komt er een derde… lees verder »
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 onderhoud 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 regelgeving 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.
Een probleem in de informatieverwerking kan vele oorzaken hebben. De neiging bestaat om een probleem gelijk op te lossen. Misschien is het echter verstandig om het probleem eerst maar eens te onderzoeken. Aan de hand van de probleemanalyse kan een probleem worden geclassificeerd. Deze classificatie kan dan worden gebruikt voor de keuze van een standaard plan van aanpak per klasse door applicatiebeheer. Voordeel van deze werkwijze is dat na de classificatie niet lang nagedacht hoeft te worden over hoe het probleem eens aangepakt moet worden. Ook de onzekerheid of de aanpak voor een bepaald type probleem wel juist is wordt hiermee weggenomen. [Klik op de titel voor het gehele artikel]
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.
De programmamodules die worden gebouwd dienen tijdens de bouw goed gedocumenteerd te worden. Deze documentatie heeft niet allen betrekking op de inhoud en de opzet van het programma maar heeft ook betrekking op het gebruik. Meer specifiek gaat het om de gebruikersdocumentatie, d.w.z. de handleiding en de productiedocumentatie in de vorm van een moduledossier. [Klik op de titel voor het gehele artikel]
Gebruik de 522 IT checklisten van ITpedia, met in totaal 22028 vragen. |
| |||||||||||||||||||||||||||
| |||||||||||||||||||||||||||
