Gisteren heb ik voor een potentiële klant een presentatie gegeven over het gebruik van Dependency Structure Matrices bij het analyseren van software applicaties. De presentatie geeft een korte introductie in de mogelijke toepassingen.

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.

Op InfoQ is zojuist een zeer interessante video verschenen van Amit Uttam en Derek Longmuir waarin verschillende strategieen worden besproken die van toepassing zijn op bestaande systemen. 

Naast dat de beide heren een definitie geven voor een legacy systeem geven ze ook een aantal interessante migratie mogelijkheden. Sommige doe je waarschijnlijk al onbewust, sommigen liggen minder voor de hand.

Veel succesvolle softwarebedrijven hebben een ding gemeen, Het geheim achter hun succes heet visie. Visie drijft de ontwikkeling van een softwareapplicatie of een software productlijn. Het omzetten van visie in een product is geen rocket-sience je hoeft ook niet de beste programmeurs van de wereld te hebben om het te realiseren.

In verschillende projecten en omgevingen heb ik zowel de waarde als het gemis van een visie mogen ervaren. Als er een visie is dan is het maken van een model en een softwarearchitectuur veel eenvoudiger. Hoewel misschien niet alles aan het begin klip-en-klaar is vallen puzzelstukjes vanzelf op de juiste plek omdat alles logisch lijkt en ook is. Gebeurt dit niet dan is dit een teken aan de wand. Het product wil niet af komen, enthousiasme is tanende, kosten lopen op. Onderhoud wordt een blok aan het been.

In het artikel Scoping and Requirements Woes van Frank Buschmann (Gang of Four) in IEEE Software November/December 2009  worden weer een aantal punten naar voren gebracht waardoor softwareapplicaties de mist in gaan. De belangrijkste redenen zijn:

1. scope van de applicatie, veel applicatieontwikkelingen worden gestart zonder voldoende de scope van de te ontwikkelen applicatie te bepalen;
2. onvoldoende rekening te houden of niet definieren van vage niet-functionele eisen.

Na wat geharrewar over zaken die meer te maken hebben met de Belastingdienst met name inzake de afgifte van de juiste VAR verklaring is het dan eindelijk zo ver. Ik ga starten met een grote opdracht. Voor een bedrijf (ik noem bewust geen namen) ga ik een redelijk omvangrijke analyse uitvoeren.

Deze klant wil meer inzicht krijgen in de huidige applicatie die bestaat uit verschillende technologien en programmeertalen:

De presentatie van Dan North (Thoughtworks) op QCon die op de InfoQ website beschikbaar is is zeer de moeite van het bekijken waard. Dan is een goede spreker en vertelt over veel voorkomende problemen en gebeurtenissen bij het ontwikkelen Java software.

www.infoq.com/presentations/north-pimp-my-architecture

Het laatste deel van de presentatie sprak mij persoonlijk het meeste aan.

Er zijn veel verschillende vormen van aanpak om object oriented modellen te maken. Velen hiervan schalen slecht wanneer applicaties groter en complexer worden. Context mapping is een aanpak die de softwarearchitect helpt om de verschillende vormen van complexiteit die zij tegenkomen binnen software projecten te tackelen. Context mapping biedt een mogelijkheid om overzicht over en tussen systemen en systeemcontexten te verkrijgen.