Oplossingen ontwerpen: De 5 zuilen van bedrijfsapplicaties

“If you can’t find out the real conditions, then you know who will prevail.”
                                                                                                            - Mei Yaochen

Wie als architect van oplossingen aan een ontwerp wilt beginnen leert al gauw een hoop filosofieën door elkaar. Volgens vele zelfgedeclareerde guru’s zijn er onbreekbare formules – en ik ben van mening dat deze ‘5 zuilen’ een ontwerpfilosofie is die de ‘Tao’ is voor ICT-oplossingen.

Een goed ontwerp vraagt om vijf strategieën vooraf in acht te nemen: de ‘snelheid’, de ‘functionaliteit’, de ‘vormgeving’, de ‘veiligheid’ en de ‘uitbreidingsmogelijkheden’. Verzuim in één van deze en kom te laat achter de pijnlijke resultaten. Beslis verkeerd in één van deze en dweil gegarandeerd met de kraan open. Het excuus is vaak ‘tijd’, maar de waarheid draait altijd uit op onwetendheid. Geen van deze ‘zuilen’ is vanzelfsprekend en ieder van hen is verbonden – wie dat gegeven onderschat, betaald de rekening achteraf. Een hoge rekening, wel te verstaan.

Snelheid, vaak aangeduid als ‘performance’ wordt altijd beloofd, maar zelden gehaald. Een ‘stress’-simulatie wordt vaak achteraf uitgevoerd, waarna de demonstratie veel minder ‘gelikt’ wordt. Dan moet men achteraf ineens compenseren door ‘spierkracht’ in de infrastructuur te plaatsen (wat een dure grap wordt). Ontwerpen voor snelheid is een kwestie van concessies doen en informatie doseren.

1.     Verwerken, uitwisselen en opslaan van informatie kosten snelheid

2.     Complexiteit, modulariteit en synchroniteit kosten snelheid

3.     Een infrastructuur, de omgeving en het platform bepalen de potentiële snelheid.

4.     Snel voor de ‘gebruiker’ en snel voor het systeem zijn twee verschillende begrippen.

De functionaliteit, oftewel de ‘features’, zijn het hart van een ontwerp; ze zijn het skelet van de ‘wensen’. Vaak worden functionele bouwstenen in overvloed gemaakt voor er echt sprake is van kennis over ‘hoe’ de functionaliteit gebruikt zal worden. Teveel functionaliteit die niet gebruikt wordt is als cholesterol voor de aders in een applicatie.

1.     ‘Less is more’, want ‘more’ kosten tijd, onderhoud en snelheid

2.     Gebruik ‘black boxing’, want details kosten flexibiliteit

3.     Vind het wiel niet opnieuw uit, tenzij het wiel vierkant is

4.     Vermijd ‘bottlenecks’ met simulaties, deze kosten snelheid.

De vormgeving is wat een gebruiker ziet. in bedrijfsoplossingen zijn het eigenlijk interactieve formulieren. Beschouw ze dan als zodanig. De vormgeving is cruciaal voor de productiviteit.

1.     Verdeel informatie in brokken – meer informatie kost snelheid

2.     Maak gebruik van ruimte; wat prettig oogt, werkt prettig

3.     Laat zien wat men wilt zien; onzinnige informatie is onzinnig

4.     Voorkom ‘dubbele’ invoer, maar forceer uniformiteit.

De veiligheid wordt vaak naar de infrastructuur geschoven; slechts 10% van de veiligheidslekken vinden er echter plaats buiten het ontwerp. Bescherm daarom op gepaste wijze het ontwerp tegen aanvallers van buiten én binnen.

1.     Alle informatie afkomstig van gebruikers wordt niet vanzelfsprekend vertrouwd – bewaak de ingangspoorten van het ontwerp.

2.     Gevoelige informatie mag niet zonder authenticatie ingezien of aangepast worden

3.     Veiligheidsmaatregelen kosten snelheid; reguleer daarom de informatiekanalen waar de infrastructuur dit toelaat.

4.     Ontwerp een aantal ‘catastrofe’ scenario’s – zonder ‘reddingsplannen’ is de schade bij een lek onbeheersbaar.

Schaalbaarheid (of: scalability) is een andere benaming voor uitbreidingsmogelijkheden. Een ontwerp dat niet kan ‘schalen’ is niet flexibel. Deze zuil lijkt het gemakkelijkst, maar is de pees van Achilles in ontwerpen. Schalen staat gelijk aan snelheid maar ook aan onderhoud. Een ontwerp dat gelimiteerd is aan een bepaalde omgeving is niet schaalbaar. Een ontwerp dat niet parallel kan werken is niet schaalbaar.

1. Ga er vanuit dat alle informatie niet exclusief is voor een individueel ontwerp
2. Ontwerpen moeten parallel ‘naast’ elkaar kunnen werken, zonder de wetenschap van elkaar.
3. Cloud computing maakt de infrastructuur schaalbaar, niet het ontwerp.
4. Ontwerpen moeten beheerd kunnen worden vanuit een ander losgekoppeld ontwerp.

Hoe pak je het ontwerpen van een oplossing dan pragmatisch aan? Filosofisch klinkt het altijd ‘mooi’ – maar hoe doe je dat op de tekentafel?

Een industriële oplossing vereist een scheiding van ontwerp en informatie. Informatie dient daarom altijd thuis te horen in een database. Vanuit een database begint de informatiestroom en is, naast het ontwerp, een cruciaal orgaan. Een database ontwerp bepaalt al vanaf het begin de verwerkingssnelheid – vandaar dat een database ontwerper een aparte discipline is. Een vuistregel voor informatie uit databases is deze: informatie krijgen ‘kost’ minder verwerking dan informatie opslaan. De informatiestromen in kaart brengen is de eerste stap, de data modellen zijn de tweede stap. De derde stap is het advies vragen aan een ‘database expert’ – die kan je haarfijn uitleggen waar ‘views’, ‘indexes’ en ‘stored procedures’ voor zijn.

Een ‘Interaction Designer’ is een communicatie deskundige van formulieren en mensen. Een grafisch vormgever is niet hetzelfde als deze discipline – het gaat om de ‘logische’ opbouw van een formulier en de plaatsing van besturingselementen. De grootste valkuil voor de meeste ontwerpers zijn formulieren – wie als laatst aan deze begint, ontdekt de ‘vergeten’ informatie te laat en doet veel gedaan werk te niet. Bij grote ontwerpen waar meerdere ‘rollen’ gebruik maken van de grafische ‘schil’, is een Interaction Designer geen overbodige luxe.

Qua veiligheid gaat het met name om drie cruciale punten binnen het ontwerp: authenticatie, integriteit en distributiekanalen. Een gebruikersnaam en wachtwoord zijn niet voldoende ter bescherming; zaken als encryptie en database integriteit tegen aanvallen zijn geen zaken om ‘licht’ te nemen. Win daarom advies in van een veiligheidsconsultant. Vuistregel: aanvallen van ‘buitenaf’ zijn infrastructuur, aanvallen op de database via invoervelden en ‘controllers’, identiteitsdiefstallen bij authenticatie procedures. Voorkomen is beter dan genezen!
Functionaliteit is afhankelijk van de componenten; het is een goed plan om het ontwerp a la Scrum/Agile – in de vorm van ‘stories’ op te bouwen – en deze te modelleren als ‘black box’ in simplistische vormen, waarbij de informatie invoer, uitvoer en secundaire informatie duidelijk zijn:

Zodoende kun je functionaliteit ‘hergebruiken’.

De 5 zuilen vragen een ‘omschakeling’, maar het resultaat wordt merkbaar bij een tevreden klant als een opvolgend project, waar je niet bezig bent met het ‘lijmen’ van een ontwerp, maar naar een nieuwe fase van ontwerp ‘volwassenheid’.

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

©SamRain
Bedrijsapplicaties

Mobile Apps die we allemaal wensen (maar nooit krijgen)

“De menselijke geest is ziek en gezond, door elkaar geschud.”
                                                                                    - Sam Rain

Kijk je wel eens op je telefoon en beeld je dan een icoontje in dat instantly ‘iets’ te voorschijn tovert, waar je echt naar snakt? Mijn app-ideeën zullen nooit gerealiseerd worden, maar vond het toch leuk om ze maar eens te delen.

1.     De vallende piano

Stel; je irriteert je mateloos aan een persoon die de “hint” niet begrijpt; een snelle ‘touch’ en floeps, bam, klets. Een vallende piano op die ‘toevallige’ GPS-coördinaten...

2.     De ‘Mute’ Button

Eigenlijk was je hem/haar al een minuut of vijf kwijt, en zo sociaal dat je bent, blijf je op de automatische knik-en-uhhu modus. Alleen dat gekwetter stoort wel door je belangrijke gedachten heen (zoals de rest van je agenda). Bliep. Rust!

3.     De Hologram Stand-In

Een meeting waar je verplicht bij moet zijn van de Amerikaanse manager, of een verplichte bruiloft. Zou een hologram dan niet een ideale plaatsvervanger zijn, zodat je op tijd kan besteden aan ahum belangrijke zaken? Bzzzzmmm!

4.     De Bob

Slokje op? In plaats van de tommy de BobBob; hop in je carkit en de app navigeert jou en vrienden naar huis en neemt de besturing over. Stoeltje achterover en snurken maar! Wel blijven updaten, want zonder nieuwe kaarten rijd je BobBob de sloot in een nieuwbouwwijk. Brrroemm!

5.     De Karma App

Een simpel programmaatje dat je hart uitleest en een actuele balans geeft van je goede en slechte daden. Met een scan functie om de Karma van een ander te meten – ook van Dommy Teleshopping verkopers.

6.     De Tijdstopper

Gewoon de pauzeknop van de wereld – even een huahaawww schreeuw als je boos bent of een groot aantal practical jokes wilt uithalen met je collega’s. Ach, de rust voor al die deadlines! Tik, tok, ti...

7.     De Pookamon

Net zoals de gekke bal, maar nu als app, je gevaarlijke huisdieren op zak. Geen kennel of kattenasiel, extra treinkaartje of speciaal hokje. Eventueel beamen en verzenden naar je vrienden om de diertjes uit te laten.

8.     De Apocalypso Button

Als de Heer komt uit de hemel en iedereen verteld dat het dit keer écht voorbij is, een app die alle mensen die je nog moeten vergeven een blauw schermpje geeft met een ‘ok’ knop en de vriendelijke mededeling dat het om een vergeving gaat. Tja, de hemel heeft nu eenmaal een hoop criteria!

9.     De geest uit de phone

Een app die met behulp van Touch ‘gewreven’ moet worden en een geest te voorschijn haalt voor 3 wensen naar keuze. Nadeel is wel dat je de wetenschap hebt dat er een machtige geest in je telefoon woont, die na 3 wensen de rest van je leven kan afpersen! No secret is safe!

©SamRain
App-ideeen

 

Applicaties ontwerpen: Een begin in interaction design

“De kracht zit in de motor, maar de aanschaf in de vriendelijkheid.”
                                                                                                - Sam Rain

Programma’s voor mensen worden beoordeelt op het uiterlijk. Feit.
Programma’s voor mensen moeten voor mensen vanzelfsprekend zijn. Feit.
Programma’s voor mensen moeten voor mensen interactief zijn. Feit.
Een programma voor mensen wordt vanuit dit oogpunt ontworpen. Feit?
Interaction Design, oftewel Actiebewust Ontwerpen (en dus niet ‘interactief’ ontwerpen) is niet een nieuw fenomeen. Visuele vormgevers maken vaak briljante kunstwaardige websites en ook applicatie ontwerpers gebruiken steeds meer typografie en dynamische effecten, maar is het ook echt actiebewust?

Tien jaar geleden had ik een aangeboren hekel aan het woord ‘marketing’; in mijn belevingswereld was het een pseudo-wetenschap voor tetterende wijven, die een dosis Xanax of Diazepam gemist hadden. Gelukkig ontdekte ik een flink aantal jaar later het ondernemerschap – en het praktische nut van marketing. Maar ‘interaction design’ als jargon bleef uit, want interaction designers die ik tegenkwam, waren derde rangs vormgevers in mijn opinie. Muggenziften vond ik het (en dat was het toen ook!), maar ik begrijp vandaag de dag wat actiebewust ontwerpen inhoudt.

Een ervaren marketing expert, gevreesd als geadoreerd, kwam destijds over als een tetterend kakwijf – maar ze blijkt achteraf een groot leermeester te zijn geweest (nou ja, inspiratie) voor mijn concept in het actiebewust ontwerpen. “Call for Action, Call for Action”, riep ze hard en luid in ieder overleg. Het kwam er op neer dat informatie een bepaalde plek krijgt, wanneer deze moeten ‘bewegen’ tot handelen. “Wat is mijn keuze, Mijn Keuze?”, tetterde ze bij elk voorstel. Hoewel ik haar toen het liefst wilde verdrinken in een bak vol zoutzuur, zijn deze twee uitspraken het fundament geworden om actiebewust te ontwerpen. Zo zie je dat je van ieder mens iets kunt leren, ongeacht de hoeveelheid bloed dat ze laten koken in je halsslagader.

Wanneer we een applicatie ontwerpen voor mensen, dan moeten we verder denken dan de zandbak; conservatievelingen mengen alles door elkaar als een groen, slijmerig mengsel waarna ze ingrediënten toevoegen om de smaak te compenseren. Het Sam Rain concept voor actiebewust ontwerpen vraagt om de Gordon Ramsay aanpak; ken je basis, je ingrediënten en lever een smaaksensatie waar mensen voor willen betalen.

Het is daarom belangrijk om informatie op te dienen als een enkel gerecht, verdeeld in 4 delen:

-       inhoudelijke informatie: de ‘content’ waar de boodschap in verwerkt is;

-       visuele opmaak: de plaats, de kleuren, het lettertype en plaatjes;

-       de presentatie: wanneer de informatie wordt voorgeschoteld en hoe (bijv. d.m.v. speciale effecten)

-       de interactie: dat de informatie gekoppeld is aan een reactie.

Het laatste deel, de interactie, is hoe de applicatie moet communiceren alsof het in dialoog gaat met de eindgebruiker. Een persbericht kan bijvoorbeeld dienen als mededeling, maar een typische interactie is een knop om de informatie te delen op Facebook. Een interessant artikel kan een opinie peilen, zoals een abonnement op artikelen van dezelfde schrijver of een ‘fan worden’. Hoewel de meeste voorbeelden vanzelfsprekend lijken, zou het je verbazen hoe vaak deze handelingen als laatste wordt toegevoegd aan een ontwerp. Bij het actiebewust ontwerpen is de gewenste handeling een onderdeel van het motorisch geheel.

Informatie wordt ook beter opgeslagen in het menselijk brein als een keuze mogelijkheid zich voordoet; daarnaast zijn mensen altijd aan het handelen, bewust of onderbewust. Wanneer applicatie ontwerpers hierop inspelen, stimuleert het innovatie. Kijk eens naar programma’s van nu en 10 jaar terug; dit komt allemaal door een renaissance van de presentatie!

Naast de eerder gegeven voorbeelden, hoort ook de ‘visuele terugkoppeling’ in het gebied van interactie. Hoewel applicaties niet primair de doelen nastreeft volgens de Turing-theorie, mogen applicaties altijd zo menselijk mogelijk zijn – op hun fouten na.

Meer lezen hierover? Klik hier voor de inhoudsopgave voor alle artikelen!

©SamRain
Interaction Design

Programma's ontwerpen: Een applicatie ontwerpen

“Doe uw plicht en laat het verder aan de goden over”
                                                                        - Corneille

Applicaties zetten een gebruiker centraal; door informatie op een bepaalde manier weer te geven en besturingselementen toe te voegen geeft een applicatie de mogelijkheid tot interactie. Zo koppelen ze verwerking aan iedere ‘beslissing’ die de gebruiker maakt en geven de status terug nadat het proces voltooid is. Applicaties maken gebruiken van de kernprogrammatuur: een collectie van services waar de applicatie toegang tot heeft.

Een applicatie bestaat uit 3 onderdelen:

-       formulieren: de visuele weergave van informatie

-       besturingselementen: knoppen en invoervelden

-       koppelingen aan services: de mechaniek naar daadwerkelijke verwerking

Een applicatie bestaat dus uit een aantal taken bedoeld om een ‘proces’ te voltooien; een medewerker zal bijvoorbeeld klantgegevens moeten invoeren, zodat deze kan worden opgeslagen in de centrale database, waarop een buitendienst medewerker weer deze informatie kan gebruiken. Een applicatie hoeft niet zeer complex te zijn om een applicatie genoemd te worden. Het proces van de invoerende medewerker is al voldoende om het programma te classificeren als applicatie.

Bij het ontwerpen van formulieren is het belangrijk om het proces te begrijpen: welke informatie wordt er verwacht van de gebruiker en welke beslissingen zal deze moeten nemen binnen de applicatie? Als we het eerdere voorbeeld nemen, zullen we moeten weten welke klantgegevens er opgeslagen moeten worden, welke gegevens op juistheid gecontroleerd moeten zijn en hoe de beslissingen worden teruggekoppeld aan de gebruiker. Door het proces in een stroomdiagram te plaatsen krijgen we daar duidelijkheid in:

Het proces maakt meteen duidelijk dat er 2 formulieren nodig zijn: een formulier voor de invoer en één voor de bevestiging. De mechaniek is onzichtbaar voor de gebruiker; daarom werkt de bevestiging als een visueel hulpmiddel om de voltooiing te bevestigen.

Omdat gegevens gebruikt worden voor diverse doeleinden, word er uitgegaan van een data model. (Zie hier)  In het geval van dit voorbeeld is het er een van het type ‘debiteur’, en zullen we het formulier moeten voorzien van minimaal de invoervelden die aan dat model voldoen. De opmaak staat echter in zijn geheel vrij, het ontwerp voor de interactie is natuurlijk wel belangrijk voor de effectiviteit van de applicatie. Naast de invoervelden moeten er ook andere besturingselementen aanwezig zijn; een ‘opslaan’ knop, zodat de gebruiker bepaald of de ingevoerde informatie ook daadwerkelijk opgeslagen mag worden. Visueel mag er van alles gedaan worden met het formulier; plaatjes, video’s of muziek het kan allemaal, zo lang er voor ieder besturingselement maar beschreven is welke service zij aanroepen. Net zoals een service, kan een applicatie ook ontworpen worden in stroomdiagrammen voor ieder formulier.

Wanneer een applicatie veel formulieren bevat, kan een ‘keuze menu’ een meerwaarde hebben: deze menu’s zijn eigenlijk een applicatie om applicaties te starten, maar wekken het gevoel op alsof ze besturingselementen zijn.

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

©SamRain
Applicatie ontwerpen

Programm's Begrijpen: Denken in Pseudocode

“De meeste tekenaars beginnen met een ruwe schets”
                                                                        - Sam Rain

Programma’s bestaan uit componenten die invloed uitoefenen op informatie met behulp van operatoren, condities en lussen. Hoe deze invloeden worden uitgewerkt in detail wordt bepaald door de ‘omgeving’; de beschikbare programmeertaal, de informatievoorziening en de distributie en uitwisseling naar andere systemen. Voordat de uitwerking kan beginnen is er een oplossing nodig die de verwerking in grote lijnen kan beargumenteren; een ‘ruwe’ schets van de mechaniek zonder vastgekoppeld te zijn aan de omgevingslimieten: de pseudo-code.

Pseudo-code is niet uitvoerbaar; het is een abstracte methode om de oplossing in theorie te maken. Gelukkig hoeft dit niet zoals de grote nauwkeurige meesters als lange, complexe en onleesbare formules. Het doel van pseudo-code is dat het begrijpelijk is voor iedereen die de basis begrijpt van informatieverwerking.

Een praktisch voorbeeld: Karel wilt zijn telefoontjes registreren en koppelen aan zijn debiteurenbestand. Als hij een debiteur aan de telefoon krijgt, wilt hij de geschiedenis op kunnen vragen aan de hand van de naam, postcode of klantnummer van de debiteur.

Eerst moeten de informatiebronnen in kaart gebracht worden. Debiteuren hebben contactgegevens, ieder telefoontje is een nieuwe registratie en alle registraties horen bij een debiteur.

Vervolgens kijken we naar de structuur voor de informatie. Elke registratie heeft een datum- en tijdsnotering nodig, tezamen met een omschrijving. De debiteurgegevens hebben altijd een uniek klantnummer nodig.

Pas dan kijken we naar de mechaniek van de oplossing. De informatie moet opgevraagd, aangepast, opgeslagen of verwijderd kunnen worden. Daarnaast moet er een zoekmechanisme zijn die juiste gegevens afbeeld. In programma’s zijn er twee delen waar de mechaniek zich afspeelt; de gebruikerskant en de kern. Soms hebben programma’s geen gebruikers nodig, ze voeren zonder vertraging of tussenkomst van een gebruiker de taken uit en heten een ‘service’ (achtergrondproces). Een programma dat de gebruiker centraal stelt is wel interactief en wordt een applicatie genoemd. In dit voorbeeld gaat het om een applicatie, er zul dus rekening gehouden worden met de gebruikerskant.

Voor de gebruiker zijn er 3 ‘schermen’ nodig. Schermen zijn in dit geval zelfstandige formulieren welke informatie weergeven. Het eerste scherm gaat om de registratie, het tweede is een zoekscherm en het derde scherm beheerd de debiteurgegevens. Het ontwerp van ieder scherm valt al onder pseudo code: 

 De ‘kern’ van een applicatie handelt de functionaliteit af van alle schermen. Ongeacht de invulling qua taal of omgeving kan het volgende al worden ‘geschetst’ voor de kern:

Procedure Nieuw-knop (vereist debiteurnummer, omschrijving):

·      nieuwe registratie maken met huidige tijd en datum

·      vereiste debiteurnummer, omschrijving aan registratie toevoegen

·      gegevens opslaan van registratie

·      velden leegmaken

·      eventuele bevestiging dat de gegevens zijn opgeslagen.

Voor iedere functionaliteit zal er dus een ‘eigen’ procedure moeten komen. Soms kunnen bepaalde procedures opnieuw gebruikt worden binnen een applicatie, bijvoorbeeld om een structuur beschikbaar te maken. Computers denken overigens nooit verder dan hun processor lang is, gegevens in een structuur moeten heel expliciet bewaard worden of zelf ‘teruggegeven’ worden. Echter heeft pseudo code het voordeel dat een aantal puntjes op de i gemist mogen worden.

Aan de hand van ‘de wensen’ om de applicatie te maken, laat de pseudocode duidelijk zien dat het hier niet gaat om een hele complexe applicatie. Het gaat met name om het beheer van gegevens en het maken van relaties. Een voor de hand liggende keuze om de applicatie te bouwen is met behulp van een database technologie. Deze ondersteunen simpele formulieren en hebben een ingebouwde programmeertaal om de procedures tot leven te wekken.

De reden waarom een database technologie vooral gekozen wordt ligt aan de noodzaak om informatie te koppelen, de gegevens van de debiteur horen bij iedere registratie, ze hebben een ‘relatie’. Deze relatie werkt technisch gezien als een ‘sleutel’. Met behulp van een unieke waarde in beide gegevensbronnen kan een database de relatie vinden. Er is wel een valkuil: soms kan een debiteurnummer omstreden zijn als sleutel, en computers zijn zeer strenge wezens. Gelukkig mag je als ontwerper de vrije keuze maken; de relatie is alleen interessant voor de computer. Veel ontwerpers voegen daarom een relatie toe door een handig truukje: ze voegen ‘informatie’ toe dat iets verteld over de informatie, beter bekend als ‘meta-data’. Omdat het gaat om unieke nummering wordt in de industrie voor sleutels de afkorting ‘ID’ gebruikt, welke staat voor Identifier, vrij vertaald als identificatie. Een ‘gegevensbron’, dus een tabel in de database, gebruikt de ‘ID’ om iedere verzameling van gegevens te identificeren. Deze ‘primaire sleutel’ legt dus niet automagisch een relatie vast. Vaak zijn er gegevens die als ‘ouder’-informatie dienst doen, zoals in het geval van het voorbeeld zijn dit de debiteuren. De informatie die een relatie moeten hebben met deze gegevens hebben dus de informatie nodig van de ‘ouder’-bron. Echter zijn deze ook uniek, ze hebben ook een ‘primaire sleutel’ nodig voor het geval ze dienst moeten doen als ‘ouder’-bron. Dezelfde truuk wordt daarom toegepast; de structuur krijgt extra informatie: de ‘foreign key’ (vrij vertaald: de buitenlandse sleutel). Deze sleutel is de ‘primaire sleutel’ van de relatie; dankzij deze sleutel kan een computer de relatie vinden. Even ter illustratie:

Tabel: debiteuren                                        

ID	KLANT	DEBITEURNR
11	Jaap	200117
12	Mien	200118
13	Hans	201302

Tabel: registraties

ID	DATUM	OMSCHRIJVING	DEBITEUR-ID
1	22-11	Klacht levering	12   (Relatie met Mien)
2	23-11	Bevestiging	11    (Relatie met Jaap)
3	23-11	Order Ontvangen	11

De ‘relaties’ in kaart brengen vallen ook onder pseudo-code; vaak werkt een database specialist verbeteringen uit om de snelheid te bevorderen of zal de structuur ‘optimaliseren’.  Echter biedt de pseudocode de mogelijkheid om gegevensstructuren vorm te geven: niet alle gegevens zijn nodig voor de formulieren. De gegevens horen dus in een structuur thuis; het ‘data-model’ bevat de gietvorm van hoe deze beschikbaar moeten zijn:

Data-Model ‘Registratie’

-       DATUM -       KLANT -       DEBITEURNR -       OMSCHRIJVING

De pseudocode brengt de primaire mechaniek, structuren en formulieren als ontwerp. Voordat er een projectplan gemaakt wordt kan de complexiteit voorzien worden en een goede schatting wat betreft de tijd die het gaat kosten om daadwerkelijk de applicatie te bouwen. Daarnaast helpt de ‘pseudo-code’ om een oplossing preventief te testen op ‘veiligheidsfouten’, toekomstige wensen en schetst het een duidelijk beeld voor de ‘uitvoerders’ van de applicatie bouw.

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

©SamRain
Pseudo-code