Software complexiteit kost geld


By Han van Roosmalen - Posted on 16 March 2010

Gisteren heb ik bij een groot Internet bedrijf in Rotterdam een presentatie gegeven over software complexiteit. De belangrijkste conclusies zijn:

  • wacht met coderen totdat je de complexiteit van het te realiseren systeem voldoende begrepen hebt;
  • monitor de toename van de software complexiteit gedurende de applicatie life cycle d.m.v. geschikte metrieken, dependency graphs en/of dependency structure matrices.

Aan het einde van de workshop waren de deelnemers overtuigd van het nut van het verkrijgen van meer inzicht in de complexiteit van hun eigen applicatie. Een onderzoek wordt op gezet om te kijken welke metrieken in Visual Studio geschikt zijn voor deze doeleinden.

Wat is software complexiteit?

Software complexiteit is opgebouwd uit twee verschillende soorten complexiteit:

  • algoritmische complexiteit en
  • structurele complexiteit.

Algoritmische complexiteit heeft betrekking op complexiteit die aanwezig is door bijvoorbeeld het wiskundig/natuurkundig/financieel ingewikkelde algoritme. Hier is weinig aan te doen. Als een domein complex is, dan zal de oplossing ook niet eenvoudig. Om hier iets tegen te doen is nadenken en isoleren essentieel.

Complexiteit in de structuur is wel goed aan te pakken. Een complex algoritme in een slecht gestructureerde oplossing maakt de complexiteit veel groter. Structurele complexiteit ontstaat vanzelf als er geen maatregelen worden genomen.

Redenen voor het ontstaan van software complexiteit

Er zijn veel redenen waardoor de complexiteit toeneemt, ik beperk mij tot een aantal belangrijke:

  • vage requirements,
  • te veel programmeurs (projectleden),
  • onvoldoende separation of concerns,
  • geen domeinmodel,
  • geen visie.

Door het toenemen van de complexiteit lopen een aantal zaken serieus gevaar, zoals:

  • begrijpbaarheid,
  • analyseerbaarheid en
  • hergebruik.

Complexe systemen zijn moeilijker te begrijpen en hergebruik van onderdelen zijn moeilijker te isoleren en daardoor te hergebruiken.

Een goed domeinmodel is essentieel voor het reduceren complexiteit

De afgelopen maanden heb ik regelmatig een discussie gevoerd met ontwikkelaars over het nut van een goed domeinmodel. Bij een van mijn klanten is tijdens de analyses d.m.v. een Dependency Structure Matrix naar voren gekomen dat hoewel er een domeinmodel aanwezig was in de middle layer deze niet helemaal correct bleek te zijn. Door 5 minuten extra te besteden aan het model kwamen we tot de conclusie dat een van de classes een niet correcte naam heeft. Dit is inmiddels aangepast en daardoor kon de functionaliteit verder groeien zonder dat de complexiteit significant is toegenomen.

Geen visie stuurt programmeurs het bos in

Na een aantal ontwikkelteams gesproken te hebben en uitvoerige analyse van systemen heb uitgevoerd kan ik managers niet voldoende op het hart drukken dat het hebben van een visie waarin duidelijk geformuleerd wordt waar er met een applicatie in de toekomst naar toe gewerkt moet worden essentieel is voor de complexiteit van het systeem. Geef de architect en programmeurs voldoende inzichten in welke kant het op moet gaan. Wordt dit niet gedaan, dan bestaat de kans dat zij zelf hele slimme (technische) oplossingen verzinnen die misschien nooit gebruikt gaan worden. Slimme oplossingen zijn mooi, maar kunnen leiden tot een grotere complexiteit, waardoor de wel noodzakelijke functies moeilijker dan nodig te realiseren zijn.

Software complexiteit reduceert kans op hergebruik

Hoewel hergebruik misschien niet het belangrijkste doel is tijdens het realiseren van product a is het wel prettig als op zijn minst een deel van de software kan worden hergebruikt tijdens de realisatie van product b. In een complex systeem is het veel moeilijker mogelijk herbruikbare onderdelen te herkennen en te isoleren. Modularisatie is hier het keyword.

Meten van software complexiteit

Een eerste manier om inzicht te krijgen in de mogelijke complexiteit is het bestuderen van het aantal coderegels. Met name analyse tools die de verhouding coderegels/commentaarregels zijn interessant. Maar andere meterieken geven meer inzicht in de complexiteit. Een bekende is de McCabe Cyclomatic Complexity metrics. Een aantal gratis tools en in sommige IDEs is deze metriek beschikbaar, eventueel als plug-in, zoals de Eclipse Metrics plug-in.

Sommige metrieken geven inzicht in locale complexiteit, anderen geven een meer globaal inzicht.

Dependency graphs helpen om inzicht te krijgen in de structuur van de applicatie. Het grote probleem is dat graphs goed werken voor kleine applicaties of applicatiedelen, maar niet schalen als de applicatie groter wordt.

Dependency Structure Matrix kunnen grotere applicaties aan

De manier waarop een Dependency Structure Matrix maakt het mogelijk om van grotere systemen de structurele complexiteit eenvoudiger te visualiseren. Hierdoor is het makkelijker totaaloverzichten en details te analyseren.

Metrieken en matrix leveren het gewenste inzicht

De combinatie van het gebruik van metrieken en matrixen leveren een goed inzicht in hoe de architectuur van een applicatie is gestructureerd en waar de probleemgebieden zich bevinden.

Dus als het inzicht ontbreekt: neem even de tijd om na te denken en een plan te bedenken om dit te verbeteren.

Taal/Language