Programma's ontwerpen: De speeltuin ontdekken

“Een gereedschap hoort thuis in een gereedschapskist”
                                                                        - Sam Rain

Programma’s zijn ‘vertaalde’ bestanden, welke door de computer gelezen kunnen worden. Uiteraard moet er dus een ‘bron’ zijn, waarvan de vertaling is afgeleid: de ‘broncode’. De broncode is geschreven in een taal dat een ander, speciaal programma begrijpt (en verantwoordelijk is voor de vertaling). De ‘broncode’ is een tekstbestand; het is leesbaar voor mensen en verschilt niet veel van andere documenten.

Om een programma te maken is er niet meer nodig dan twee onderdelen: een programma dat simpele tekstverwerking kan faciliteren en het programma dat verantwoordelijk is voor de vertaling ervan. Techneuten beginnen vaak met het meest minimale om effectief te leren ‘programmeren’.

Broncode is tekst, en het voordeel ervan is dat het gemakkelijk uit te wisselen is. Daarom hoeft het ‘wiel’ niet vaak opnieuw uitgevonden te worden. Programmeertalen bieden de mogelijkheid om reeds bestaande broncode te ‘importeren’ uit bibliotheken. Sommige bibliotheken worden zelfs standaard meegegeven met een programmeertaal, anderen zijn te downloaden of worden zelf gemaakt door de programmeur.

Vaak zijn er nog andere nuttige programma’s meegeleverd met een programmeertaal; sommigen kunnen beeldmateriaal (zoals iconen en foto’s) aan het programma koppelen, of de help-documentatie vereenvoudigen. Wanneer er een scala van dit soort programma’s bij elkaar gevoegd worden ontstaat er een geïntegreerde omgeving met als doel programma’s te fabriceren. Vooral in de industrie wordt er gekozen voor een standaard. Praktische voorbeelden zijn Visual Studio™ (Microsoft) en Eclipse™. Alle gemakken zijn dan voorzien binnen een structurele applicatie; ‘broncode’ wordt gecontroleerd op juistheid, bij veranderingen wordt er een nieuwe versie toegewezen en men kan zoeken binnen diverse bibliotheken naar eventuele functionaliteit.

Voor beginnelingen kan een omgeving voor programma’s behoorlijk intimiderend overkomen; vele opties en menu’s geven veelvoudig hetzelfde weer, maar toch net iets anders. Echter hebben deze geïntegreerde applicaties wel veel meer ‘lesmateriaal’ ter beschikking; video’s, stap-voor-stap documentatie en speciale opgerichte fora. Om programma’s te ontwerpen hoef je niet de hele dag met spijkers te slaan, maar is het zeker belangrijk om te weten waar het ontwerp wordt ‘geïmplementeerd’.

Omdat programma’s in zulke omgevingen vaak in versies beschikbaar worden gesteld, is praktische ervaring handig voor tussentijdse evaluatie. De functionaliteit testen is iets wat de uitvoerders in paniek doet maken, wanneer zij achterlopen op schema. Projecten op schema laten zich immers maar al te graag demonstreren. De bedoeling van evalueren voor consultants heeft niets met het bouwproces te maken, maar ligt op het vlak van projectmanagement. Niet zelden zullen er onvoorziene omstandigheden zijn, zoals ziekteverzuim, uitstroom of ‘ambitieuze’ planning. Weten wat de staat van bouw is, betekent de informatie hebben over potentiële vertraging.

Wees daarom bekend met de gele helm, waarschuwingsborden en de grote richtlijnen. Een architect is geen metselaar, maar zal wel bekend moeten zijn met inhoudelijke kennis over metselen. Daarnaast is het bouwen van prototypes of concepten een echte pré voor consultants die succes willen maken; je leert er advies mee te beargumenteren, constructies te begrijpen die anderen voor onmogelijk houden én een zeer handige vaardigheid die generiek van toepassing is.

Meer lezen over Informatie Technologie? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Ontwerpen