Wat is de kwaliteit van de software?

In mijn praktijk als deskundige wordt die vraag nogal eens gesteld. En dan meestal niet in die vragende vorm, maar in een conflictsituatie in een stellende, kwalificerende vorm: “De software is van slechte kwaliteit“, meestal als onderdeel van een groter dispuut.

In voorgaande blogs heb ik geschreven over de rol van testen op (technische) correctheid en op (functionele) geschiktheid. Toch is er meer af te leiden over de kwaliteit van de software zelf als er inzicht is in de broncode. In deze blog aanwijzingen die ik gebruik bij het (technisch) inspecteren van de broncode van software om iets zinvols te kunnen zeggen over de kwaliteit van de programmatuur. Daarbij maak ik onderscheid in de verschillende lagen van software (database, databenadering, business logica, schermopbouw en -afhandeling) en het productieproces van de applicatie.

In mijn werkzame leven heb ik met vele programmeeromgevingen en -talen gewerkt, maar de laatste jaren toch vooral in een Microsoft georiënteerde omgeving met als database MS SQL Server en .NET (C#, VB.Net) als programmeertaal en Visual Studio als programmeeromgeving. Allemaal moderne gereedschappen voor de hedendaagse IT’er. De toelichting die ik hieronder geef is dan ook vooral geënt op deze omgeving, maar niet beperkt daartoe. Ook andere omgevingen (Java, Oracle, MySQL, Progress, PHP, Eclipse) laten zich prima hiermee vergelijken.

In deze blog aspecten van kwaliteit van het eindresultaat teruggebracht tot twee basiselementen: de database en de programmatuur.

Database

Bij het inspecteren van een database opbouw let ik op:

• Gebruik van naamgevingsconventie voor objecten in de database (tabellen, views, queries, velden, functies, etc.)
  Voor de Microsoft omgeving is er een naamgeving die door Microsoft wordt geadviseerd, maar in feite ben ik tevreden met een consistente naamgeving
• Normalisatie
  Gebruik van een genormaliseerd datamodel is niet per se nodig, zeker niet voor gegevens die gebruikt worden voor reporting of historie
• Primairy keys
  Iedere tabel hoort een primairy key te hebben met unique index. Mijn voorkeur is een enkelvoudig betekenisloos veld als primary key.
• Referentiële integriteit
  Databases kunnen zelf de referentiële integriteit bewaken, dat komt de kwaliteit van de opgeslagen gegevens ten goede en bespaar je programmeertijd
• Views, queries en stored procedures
  Gebruik van views, queries en stored procedures voor het opvragen en bijwerken van gegevens, deze onderdelen laten het werk over aan de database in plaats de programmatuur

Los daarvan geeft het bekijken van de definitie van sorteervolgorde, codepage, gebruik van audit velden, instellen van databae files, gebruik van logging, gebruik van security principles, instellen van back-up, enz. een indruk van de database kennis van de softwareontwikkelaar.

Programmatuur

Met alleen een database ben je er niet, er dient ook programmacode geschreven te worden. Hier kijk ik zowel naar de algemene structuur (data access laag, business rules laag, info objecten, user interfacing) en naar de technische vorm van de programmaonderdelen.

• Als eerste weer aandacht voor naamgevingsconventie
  Een goede, structurele naamgeving biedt veel houvast wanneer de programmatuur aangepast moet worden (en dat moet het in de loop van de levensduur van programmatuur altijd)
• Omvang routines
  Ik hou ervan dat routines (procedures, functies, etc.) een beperkte omvang hebben, bijvoorbeeld maximaal 100 of regels of code. Alleen dan is de routine makkelijker te begrijpen
• Beperkte nesting
  Geen 5 niveaus van if/then/else structuren die in elkaar grijpen, maar maximaal 2-3 niveaus. Refactoring tools bieden mogelijkheden programmatuur snel te herstructureren als het aantal niveaus te groot wordt
• Code comments
  Begrijpelijk code comments die uitleggen waarom iets gebeurt, niet wat er gebeurt, want dit laatste is zo uit de (goed gestructureerde?) code te lezen

Bovenstaande onderwerpen hebben te maken met het eindresultaat: een applicatie. Op zich zeker belangrijk, maar er kan ook veel geleerd worden over kwaliteit door te kijken naar de wijze waarop de programmatuur (technisch) gemaakt wordt en de wijze waarop het proces van maken wordt beheerd.

Meer over het proces van software ontwikkelen in een volgende blog.