Implementatie van software

Laatst bijgewerkt op 1138 dagen geleden door Marcel Ziemerink

Bij het implementeren van software is een eerste belangrijke afweging die tussen:

De afweging hiertussen is complex en sterk afhankelijk van de gestelde eisen en wensen. Vaak zijn er in eerste instantie veel wensen die alleen met een maatwerkoplossing haalbaar zijn. Maar het loont de moeite om goed te bekijken of de kosten van maatwerk opwegen tegen die van de andere twee oplossingen. Het goed prioriteren van requirements is dus noodzaak.

Aanbesteden

Bij het laten bouwen, inkopen of inhuren van software is in een overheidscontext vaak sprake van een sterk gereglementeerd proces van aanbesteding. Overheden zijn bij grotere opdrachten gebonden aan de regels voor Europese aanbesteding. Het goed opstellen en uitvoeren van een aanbesteding is niet eenvoudig. Dat blijkt ook uit de diverse rechtszaken die softwareleveranciers hierover de laatste jaren tegen overheden hebben gevoerd. Een van de belangrijkste problemen is dat niet vaak alle requirements vooraf bekend (kunnen) zijn. Dit laatste komt vooral omdat gebruikerswensen vaak pas concreet worden als gebruikers tijdens het ontwikkeltraject een beter beeld van het eindresultaat beginnen te krijgen. Het is dus een noodzaak om voldoende flexibiliteit in het proces in te bouwen om hiermee om te kunnen gaan. Zie ook het Expertisecentrum Aanbesteden.

Softwareontwikkelproces

Het softwareontwikkelproces is het totale proces van het implementeren van software. Hierin komen in elk geval de volgende onderdelen terug (niet noodzakelijk in deze volgorde):

  • vaststellen van de eisen en wensen
  • analyse van het probleem en decompositie in deelproblemen
  • specificeren van de deeloplossingen
  • programmeren van de deeloplossingen
  • testen van de deeloplossingen
  • integreren van de deeloplossingen
  • integratietesten
  • gebruikerstesten en acceptatietesten
  • documenteren
  • onderhoud

Hiervoor zijn tal van softwareontwikkelmethoden. Sommigen hiervan hebben een waterval-karakter, waarbij de stappen van het vaststellen van eisen en wensen tot de acceptatietest elkaar lineair opvolgen. Andere gaan iteratief te werk, waarbij steeds voor een deel van de eisen en wensen een werkend deel van de oplossing wordt opgeleverd. De watervalaanpak is vaak minder geschikt in situaties waar de requirements moeilijk op voorhand helder te krijgen zijn. Denk aan situaties waarin de beoogde gebruikers zich nog geen voorstelling van het systeem kunnen maken. In zo'n geval is het iteratief werken een betere aanpak. Bij deze aanpak krijgt het systeem langzamerhand vorm.

Het beste is om in een iteratief proces te werken met een risicogedreven aanpak. Daarbij start u met die onderdelen waaraan de grootste risico's verbonden zijn, bijvoorbeeld door grote complexiteit, zware prestatie-eisen of hoge mate van gebruikersinteractie. Maak niet de fout eerst de gemakkelijke zaken te ontwikkelen en de probleemgevallen tot het laatst uit te stellen. Daar krijgt u gegarandeerd spijt van. Want aan het einde van de rit kunnen broodnodige middelen als geld, tijd en enthousiasme behoorlijk opgeraakt zijn.

Reageren is alleen mogelijk voor aangemelde gebruikers