Inzichten in complexe software oplossingen via een gelaagd model

Auteur
Hans van den Hoogen
Datum

Inleiding

Toepassing van een gelaagd model helpt je om de diverse facetten van een software applicatie te beschrijven zodat het voor alle stakeholders begrijpelijk is. Dit voorkomt misverstanden en draagt bij tot een effectieve doorontwikkeling. In dit artikel beschrijf ik het 8-lagen-model aan de hand van een praktisch voorbeeld. Het is geschreven voor alle rollen, inclusief opdrachtgever, die bij een project betrokken zijn om zo de communicatie tussen deze rollen te verbeteren.

Door de overgang van waterval naar SCRUM methodiek voor software ontwikkeling wordt het toch al eeuwen oude verhaal van ‘de blinde mannen en de olifant’ weer actueel. Dit verhaal leert dat als je op de tast een gedeelte van het lichaam van de olifant onderzoekt, je je nogal kunt vergissen.

Software - Olifant

Om een applicatie effectief te ontwikkelen, te beheren of te optimaliseren is er een breed beeld van alle facetten noodzakelijk. Bij goede waterval-projecten worden deze facetten wel afzonderlijk vastgelegd.

Bij een SCRUM project is het effectief inzichtelijk maken van de verschillende aspecten zelfs nog belangrijker, omdat de uitbreiding van een systeem per user story plaatsvindt, tegelijkertijd door meerdere mensen wordt ontwikkeld én omdat documentatie geen prioriteit heeft.

Bundelen van de losse user story-beschrijvingen is als het samenvoegen van conclusies van de blinde mannen. Ook dit leidt niet tot het goed totaalbeeld van de olifant. Beter zou zijn om andere zintuigen te gebruiken, zoals reuk of gehoor. Inzicht in een applicatie wordt juist verhoogd als je vanuit meerdere dimensies kijkt.

Gebrek aan dit inzicht leidt tot problemen, zoals

  • misverstanden over gewenste functionaliteit omdat er geen goede afspraken zijn gemaakt over de gebruikte termen
  • vergeten van interface-koppelingen omdat de scope niet helder was
  • onvoldoende rekening gehouden met de non-functionele requirements omdat deze niet of te laat worden vastgesteld.

Opbouw van een gelaagd model

Door een applicatie te zien als een ui, opgebouwd uit een schil per dimensie, word je gestimuleerd om meerdere aspecten zoals de gebruikers, de scope en de USP’s van het systeem te bekijken. Hierdoor ontstaat er niet alleen een completer beeld, maar is deze ook beter scanbaar en onderhoudbaar. We lopen de verschillende lagen langs:

1) Over welke business gaat het systeem?

De termen die binnen een systeem worden gebruikt dienen eenduidig te worden gedefinieerd. Bij voorkeur door een uitwerking van een business/project-domeinmodel waarin ook de relaties tussen de termen worden weergeven. Ook een ordegrootte van het aantal objecten (zoals producten, klanten, vestigingen) geeft meestal snel inzicht in de business.
Daarnaast is er vaak behoefte aan een overzicht van de business rules.

Bij een luchtvaartwebsite geeft dit antwoorden op:

  • Wat is het verschil tussen een klant, passagier en een account?
  • Welke producten worden aangeboden via dit systeem?
  • Uit hoeveel vliegvelden kan een keuze worden gemaakt?
  • Wat bepaalt het aanbod aan producten: vliegveld, nationaliteit van bezoeker, status van een bezoeker?
  • Kan een bezoeker alle producten (vlucht, toegevoegde services zoals autohuur) samen afrekenen?

2) Wat moet het project en/of systeem bereiken?

Wat is het Business model waar het systeem een onderdeel van is. Wat zijn de normen, waarden en overtuigingen van de organisatie die de software inzet voor hun bedrijfsvoering. En hoe worden deze vertaald naar de USP’s van het systeem of een projectvisie? Verder dienen de business doelen te worden gekwantificeerd bijvoorbeeld in KPI’s.

Bij een luchtvaartwebsite geeft dit antwoorden op:

  • Wat is belangrijker voor de business: meer verkochte vliegtickets of per ticket meer aanvullende services?
  • Waarin onderscheid deze aanbieder zich in?: services, prijzen, betrouwbaarheid, kwaliteit of …?
  • Aan welke business doelen draagt het project bij: meer omzet, meer winst per transactie, minder backofficekosten en hoe: meer omzet per klant, producten met hoge winst promoten?
  • Kunnen we de bijdrage van project meten: bijvoorbeeld verhoging van het aantal aanvullende diensten bij een vliegticket?

3) Wie heeft er een rol binnen dit systeem?

Welke actoren (gebruikers, beheerders, redacteuren en management) hebben een rol binnen dit systeem. Gelden er specifieke rechten per rol en hoe vindt dan de autorisatie plaats?

En welke delen van de organisatie worden door het systeem geraakt?

Bij een luchtvaartwebsite geeft dit antwoorden op:

  • Zijn er specifieke klantgroepen te onderscheiden?
  • Wie beheert de content van de site?
  • Wie is verantwoordelijk voor de klachtenafhandeling?

4) Welke niet-functionele requirements gelden er voor het systeem?

Denk hierbij aan specifieke eisen aan niet-functionele eigenschappen zoals toegankelijkheid, security, performance, beheerbaarheid en analytics.

Bij een luchtvaartwebsite geeft dit antwoorden op:

  • Hoe toegankelijk moet de website zijn, om aan wetgeving te voldoen of niet te veel omzet te missen van bezoekers die nog hogere toegankelijkheid wensen?
  • Hoe snel en hoe vaak dient content te worden gewijzigd?
  • Hoeveel bezoekers worden verwacht?

5) Wat is de scope van het project en het globale technisch ontwerp?

We beschrijven hier de systeemgrenzen voor het project, met extra aandacht voor interfaces met externe systemen. Ook wordt in deze laag een globaal technisch opzet van het systeem beschreven.

Bij een luchtvaartwebsite geeft dit antwoorden op:

  • Welke systemen zijn buiten scope en dient de werking/ interfacing als gegeven worden beschouwd?
  • Welk systeem wordt ingezet als content management systeem?

6) Wat zijn de functionaliteiten van het systeem en bijhorende processen, benodigde interfaces en beheer inspanning?

Beschrijving van de happy en unhappy flows van functionaliteiten, de interfaces met andere systemen, de uitgangspunten(precondities) voor de functionaliteit, en de vrijheid om door functioneel beheer of redacteur is aan te passen.

Bij een luchtvaartwebsite geeft dit antwoorden op, per functionaliteit:

  • Wat is er bekend van een bezoeker als deze start met het zoeken naar een vlucht?
  • Wat zijn de stappen bij het boeken van een vlucht?
  • Wat dient er te gebeuren als het boeking-systeem niet beschikbaar is?

7) Wat is het interactie ontwerp van het systeem?

Beschrijving van de interactie via de user interface: overzicht van de schermen, scherm-flows, schermbeschrijvingen, de weergave van content en interactie methodieken.

Bij een luchtvaartwebsite geeft dit antwoorden op:

  • Hoe worden de belangrijkste userflows ondersteund?
  • Wat ziet de bezoeker nadat hij een ticket geboekt heeft?

8) Hoe ziet de user interface van het systeem eruit?

Visual design van de user interface op basis van een style guide: Een opsomming van elementen en uitwerkingen van enkele schermen.

Bij een luchtvaartwebsite geeft dit antwoorden op:

  • Hoe zien primaire en secundaire buttons er uit?
  • Wat zijn de richtlijnen voor gebruik van fotografie binnen de website?

Toepassing bij een uitbreiding

Een gelaagd model is een methode om alle dimensies van software te beschrijven. Ongeacht de projectmethodiek, fase van een project of levenscyclus van de software wordt aanbevolen om al deze lagen van een software te beschrijven en bij te houden. Hierdoor heeft iedereen die betrokken bij ontwikkeling of beheer een compleet beeld, en kan zijn acties gespiegeld worden aan dit beeld.

De lagen kunnen gezien worden als schillen van een ui, met als kern het business domein en de waarde. De opvolgende schillen dienen te passen op onderliggende schillen. Aangeraden wordt om bij toevoeging van een functionaliteit dan ook in deze volgorde te werken: Software - ui

Wanneer bij een luchtvaartwebsite een extra kortingsmethodiek wordt toegevoegd, kunnen de volgende vragen per laag relevant zijn:

Business Domein

  • Wat zijn de business rules voor de kortingen in termen van het business domein?
  • Zijn er afhankelijkheden met reeds bestaande kortingsmethodieken?

Business Waarde

  • Past deze kortingsmethodiek bij de USP’s van het product en de waarden van de organisatie?
  • Hoe gaat deze methodiek bijdragen aan de business doelstellingen?

Rollen

  • Op welke bestaande of nieuwe doelgroepen is de kortingsmethodiek gericht?
  • Wie gaat de regels van de korting beheren?

Niet-functionele requirements

  • Heeft de kortingsmethodiek aanleiding tot aanvullende maatregelen voor de performance, omdat piekbelasting verwacht kan worden?

Scope en onderdelen

  • In welk systeem worden de regels beheerd?
  • In welk systeem worden de regels toegepast?
  • Welke systemen dienen te worden aangepast, zoals betalingssysteem of facturen?

Functionele flows

  • Hoe worden de business rules van de kortingen bewaakt?
  • Dienen de bestaande unhappy flows te worden aangepast of uitgebreid?

Interactie Ontwerp

  • Kan de kortingsmethodiek gebaseerd worden op bestaande schermflows en interactie patronen?
  • Dient er door verschuiving van doelgroep of USP’s interactie patronen worden aanpast?

Visual Design

  • Kan voor deze toevoeging van kortingen gebruikt worden van de reeds bestaande style guide?
  • Geeft verschuiving van de doelgroep aanleiding tot bijstelling van het visual design?

Conclusie

Een laagsgewijze beschouwing en vastlegging van een systeem is beter onderhoudbaar en helpt:

  • Bij het rekening houden van alle dimensies bij een (verdere) ontwikkeling van een systeem
  • Bij de communicatie tussen de verschillende rollen van een project
  • Als een snelle introductie voor personen die op een later moment betrokken raken bij de ontwikkeling van het systeem.

Tags

Kwaliteit Scrum