Skip navigation.
Home
Software-architectuur.nl de site van en voor software architecten!

Statische analyse tools

In een zeer lezenswaardig artikel "Practical guidelines for software static analysis"(*) van Bola Rotibi (www.mwdadvisors.com) wordt een lijst gegeven waarin de belangrijkste eisen staan die aan een static analyse tool gesteld worden, deze zijn:

  1. Gebruikersvriendelijkheid en uitbreidbaar, eenvoudig voor klanten en partners uit te breiden applicatie
  2. Automatiseerbaar, automatisering van rule checking
  3. Ondersteuning voor real-time testing, voor snelle terugkoppeling
  4. Goede basis set van metrieken en eenvoudig uitbreidbaar
  5. Simpele heldere gebruikersinterface
  6. Ondersteuning door meerdere views op de te ontwikkelen codebase/database structuur en afhankelijkheden
  7. Ondersteuning voor refactoring, refactoring scenario's kunnen opzetten zonder daarvoor de code al aan te hoeven passen
  8. Ondersteuning voor inpassing binnen workflow en build-time
  9. Uitgebreide rapportage mogelijkheden
  10. Mogelijk rapportage in combinatie met een andere context
  11. Uitbreidbaarheid in functionaliteit en licentie
  12. Team en community support
  13. Ondersteuning voor meten en uitgebreide weergave mogelijkheden voor trend analyse

(*) Dit artikel is niet te vinden op de aangegeven site.
 
Static code analyse op code niveau kan mogelijke problemen tijdens de implementatiefase aan het licht brengen. Het is belangrijk ook statische analyse tools in te zetten die op een hoger niveau en dus eerder in het proces (requirements, design) ondersteuning kunnen bieden. Uit onderzoek is gebleken dat het vroegtijdig ondervangen van mogelijke fouten kosteneffectiever is dan het oplossen van het probleem als het product inmiddels operationeel is. Het onderkennen of er fouten in een design zitten of dat het systeem conceptueel correct is opgezet wordt dus belangrijker en vormt in veel gevallen de basis van "forensische" software audits. Statische analyse is dus een voorwaarde voor dit soort audits.
 
Er zijn genoeg redenen om automatische static analysis tools te gebruiken, de belangrijkste zijn:

  1. Het helpt om een project te beschermen tegen slechte codeerpraktijken van minder goede ontwikkelaars en maakt uitwisseling van kennis en ervaring van en met de betere ontwikkelaars en industry review regels eenvoudiger.
  2. Ontwikkelorganisaties zijn veelal globale werldwijde omgevingen, dit maakt peer reviewing minder eenvoudig.
  3. Een statische analyse tool maakt het mogelijk om design modellen te valideren en interactie tussen software componenten en tussen software componenten en data sources te bekijken.

Statische analyse is slechts één onderdeel binnen een QA raamwerk. Echter een redelijk ingerichte statische analyse omgeving kan een reductie  met een factor 5 geven van het werkelijk aantal fouten binnen een gemiddelde organisatie.
 
Excuses die niet langer gelden!
Bij de introductie van statische analyse zijn er altijd excuses te verzinnen om het niet te doen:

  1. We hebben nu geen tijd, want het product moet de deur uit. Dit leidt tot een eindeloze cyclus van het releasen van bugs en patches tussen nieuwe functionaliteit door. Doordat er niet verbeterd wordt in de tussentijd stapelen de problemen zich op en zal het steeds moeilijker worden nieuwe functionaliteit toe te voegen.
  2. Ik heb nu geen tijd, ik moet nu coderen want het spul moet de deur uit. Grotere software complexiteit door het toepassen van de latest-and-greatest technologie in combinatie met complexe organisatorische structuren zorgt ervoor dat er geen ruimte meer zla bestaan voor deze houding.
  3. Tools zijn onpraktisch, kosten te veel tijd. Dit is zeker een excuus van het verleden. De meeste beschikbare tools zijn eenvoudig in te passen in bestaande ontwikkelomgevingen.
  4. Tools zijn te duur. Tool leveranciers leveren tegenwoordig betere tools voor een lagere prijs en soms zijn ze zelfs verkrijgbaar in de open source wereld. Daarnaast is het veelal mogelijk om de juiste modules aan te schaffen en uit te breiden naarmate de behoefte groeit.
  5. Tools ondersteunen de laatste technologie niet. Dit geldt nog in een beperkt aantal gevallen. De meeste serieuze tool ontwikkelaars doen hun uiterste best om bij te blijven.
  6. Er is geen ondersteuning door de leverancier en ik wil geen dure consultants. Ook dit is in de loop der tijd veranderd. Veel leveranciers zetten communities op waar kennis, ervaring en regels worden uitgewisseld.
  7. Wij zijn een te kleine organisatie en we maken geen complexe applicaties. Aangezien steeds meer bedrijven software nodig hebben om hun dagelijkse activiteiten te uit te voeren en zich te differentieren, software code kwaliteit wordt belangrijker om nieuwe businessmodellen te ondersteunen.