[Disc] Invloed ontwikkelmethode op kwaliteit software?

[kasper_vk]

Bij software kun je verschillende kwaliteitsaspecten onderscheiden, waaronder:

• Correctness, reliability & rubustness
• Reusability
• Repairability
• Evolvability
• Understandability
• Verifiability

Er zijn wel meer kwaliteitsaspecten te noemen; de bovenstaande aspecten zijn voornamelijk van technische aard.
Ik wil, voor een presentatie, de mate onderzoeken waarin de gehanteerde ontwikkelmethode invloed heeft op de verschillend kwaliteitsaspecten.

Voorbeeld:
Bij extreme programming (XP) wordt er gewerkt met pair programming, wat de duidelijkheid en de repairability van de code vervoorderd. Tevens maakt de methode regelmatig ruimte voor refactoring. Maar doordat er bij XP steeds kort vooruit wordt geplant, en er dus een grotere kans bestaat dat lange termijn veranderingen niet voorzien worden, kan de evolvability van de gemaakte software, denk ik, lager uitvallen.

Wat denken / weten jullie over het verband van specifieke ontwikkelmethode(n) op de verschillende bovenstaande kwaliteitaspecten?

[Alarmnummer]

Kijk ook even naar Unit testing, Test Driven Development, Model Driven Architecture (door gebruik te maken van gestandariseerde transformatoren krijg je natuurlijk minder fouten).

Ik gebruik zelf unit testen om mijn code te testen op correctheid. Hierdoor kan ik afzonderlijke subsystemen ontwikkelen en testen zonder dat hiervoor een volledige applicatie gemaakt hoeft te zijn. Verder heb ik mijn unit testen (en ook andere testen zoals functionele) gekoppeld aan mijn buildscript waardoor ik alle testen meerdere keren per dag uitvoer.

Verder zou je ook kunnen kijken naar design patterns. Design patterns verhogen de kwaliteit van je code omdat je 'macro stenen' gebruikt, waarvan de voors en tegen goed beschreven zijn. Hierdoor kan je de juiste steen voor het probleem kiezen en hierdoor zal de kwaliteit van je software uiteraard beter worden.

[Bobco]

Lijkt me een lastig onderwerp, ook al omdat de verschillende aspecten niet of moeilijk te kwantificeren zijn. "Klassieke' methodes, zoals SDM, gaan uit van een watervalmodel waarbij je pas aan de volgende fase mag beginnen als de vorige is afgerond. Dit dwingt je in principe om alles goed te ontwerpen voordat je code gaat schrijven. Deze benadering is lastig als er naderhand nog wijzgingen nodig zijn in het ointwerp.

Modernere methodes zijn meer 'agile'. Vaak staan ze toe om voor verschillende onderdelen van een project in een verschillende fase te zitten. Iteratief ontwikkelen is ook mogelijk, waarbij je met een kleine kern van functionaliteit begint en deze steeds verder uitbouwt.

XP is redelijk extreem vanwege de mogelijkheid om al heel snel aan het ontwikkelen te gaan, waarbij je wel de nodige refactorings nodig hebt om tot het gewenste eindresultaat te komen.

Zelf heb ik geen favoriete benadering. Bezint eer ge begint is een gezond principe, trajecten waarin meteen code wordt geschreven duren vaak langer dan trajecten waarbij eerst een basisontwerp wordt gemaakt. Het probleem blijft meestal dat je niet alle problemen ziet op het moment dat je begint. Je methode moet dus soepel om kunnen gaan met tussentijdse wijzigingen.

Voor wat betreft 'evolvability' en XP denk ik juist dat de meeste slimme programmeurs rekening houden met het gegeven dat er gemakkelijk gerefactored moet kunnen worden. In XP trajecten zie je vaak een beweging waarbij er in de loop van het project toch gemeenschappelijke functionaliteit wordt ontdekt in de verschillende stories, het project als geheel moet dan de gewenste refactoring uitvoeren en de gemeenschappelijke functionaliteit 'naar buiten halen'. Eigenlijk is dit gewoon de moderne variant op het ontdekken van gemeenschappelijke subroutines/programma's dat al bestond in de tijd dat er nog in Fortran en Cobol werd geschreven.

Een belangrijk aspect dat moet worden meegenomen is de mate waarin de gebruikte tools de gewenste manier van werken ondersteunen. Refactoring kan heel bewerkelijk zijn als je met een 'platte' text editor werkt. Als je in Java programmeeert is dat echter weer heel makkelijk met tools als IntelliJ of Eclipse. Ik zou dus ook de tooling meenemen als een aspect dat de kwaltieit sterk kan beinvloeden.

[kasper_vk]

Het verschijnsel unit testing ken ik i.d.d. van XP; wanneer je je software goed modulair opzet (OO?) kan ik me voorstellen dat dit de foutgevoeligheid van de software omlaag brengt en, doordat de fouten de modules steeds getest worden, tevens de modules betrouwbaarder zijn te hergebruiken.

Je hebt het over Test Driven Development en Model Driven Architecture . Die termen ken ik niet en ga ik dus nu opzoeken.
Het klinkt echter als 2 technieken; van welke ontwikkelmethoden maken zij dan o.a. deel uit? Of kun je desgewenst gebruiken i.c.m. een willekeurige ontwikkelmethode?

[Alarmnummer]

kasper_vk schreef op 29 januari 2004 @ 11:57:
Het verschijnsel unit testing ken ik i.d.d. van XP; wanneer je je software goed modulair opzet (OO?) kan ik me voorstellen dat dit de foutgevoeligheid van de software omlaag brengt en, doordat de fouten de modules steeds getest worden, tevens de modules betrouwbaarder zijn te hergebruiken.

Verder zorgt unit testen imho er ook voor dat je dus testbare code gaat schrijven, en dat komt het ontwerp meestal ook ten goede. Je moet dus redelijk eenvoudig objecten kunnen opzetten, ipv een wirwar van aanroepen af te gaan om misschien iets in de goeie toestand te krijgen. Verder moet je ook dummy object plaatsen (bv een dummy server die bv altijd faalt zodat je kan testen of de client zijn fouten ook goed afhandelt). Hierdoor ga je toch sneller werken met interfaces en mbv polymorfisme mogelijk maken om van implementatie wisselen.

Je hebt het over Test Driven Development en Model Driven Architecture . Die termen ken ik niet en ga ik dus nu opzoeken.
Het klinkt echter als 2 technieken; van welke ontwikkelmethoden maken zij dan o.a. deel uit? Of kun je desgewenst gebruiken i.c.m. een willekeurige ontwikkelmethode?

Hmmz... ik zie ze regelmatig staan in het agile/xp hoekje, maar je kan ze in principe overal toepassen. Je zou gerust MDA en TDD kunnen combineren met de waterval methode.

[ Voor 12% gewijzigd door Alarmnummer op 29-01-2004 12:05 ]

[kasper_vk]

Bobco schreef op 29 januari 2004 @ 11:52:

... een heleboel wijze dingen...

Je noemt een paar sterke dingen, o.a. de keuze voor een incrementele of waterval methode, de (keuze voor de) gebruikte tools, 'bezind eer ge begint' (uiteraard), fatsoenlijke programmeurstechnieken zoals decompositie / 'naar buiten trekken van code'.

Het komt op mij (tot nu toe) over alsof de methode an sich niet veel invloed heeft op de kwaliteit, behalve de keuze waterval of incrementeel.
Het zijn kenenlijk meer de toegpaste technieken en tools die de kwaliteit bepalen.

Wat me wel opvalt is dat de klassieke methoden, zoals SDM, geen formele testfase of testfasen hebben, terwijl bij XP of een andere iteratieve methoden vaak al expliciet testen en (tijd maken voor) bugfix'en opgenomen is.

[ Voor 3% gewijzigd door kasper_vk op 29-01-2004 12:11 ]

[Alarmnummer]

kasper_vk schreef op 29 januari 2004 @ 12:08:
[...]
Wat me wel opvalt is dat de klassieke methoden, zoals SDM, geen formele testfase of testfasen hebben, terwijl bij XP of een andere iteratieve methoden vaak al expliciet testen en (tijd maken voor) bugfix'en opgenomen is.

Ik geloof dat Kent Beck (een van de grootouders van XP) heeft gezegd: no feature without testing. Dus meteen testen als je een feature erin plaats. Bij TDD ga je zelfs nog verder door eerst de tests te schrijven en daarna de code. Hierdoor ga je beter nadenken over wat je code exact moet doen.

Verder heb je ook continuous integration, waarbij je een code server hebt draaien die de hele tijd tests loopt uit te voeren. Alle developers halen en sturen dan hun source naar deze server.

[ Voor 15% gewijzigd door Alarmnummer op 29-01-2004 12:14 ]

[Bobco]

kasper_vk schreef op 29 januari 2004 @ 12:08:
[...]
Het komt op mij (tot nu toe) over alsof de methode an sich niet veel invloed heeft op de kwaliteit, behalve de keuze waterval of incrementeel.
Het zijn kenenlijk meer de toegpaste technieken en tools die de kwaliteit bepalen.

Wat me wel opvalt is dat de klassieke methoden, zoals SDM, geen formele testfase of testfasen hebben, terwijl bij XP of een andere iteratieve methoden vaak al expliciet testen en (tijd maken voor) bugfix'en opgenomen is.

Mja, een ontwikkelmethode is meestal ook meer bedoeld als manier om een project in de hand te houden dan een manier om betere software te bouwen. Goede software is uiteraard alles wat aan de requirements voldoet, maar sommige oplossingen zijn duidelijk beter dan andere.

Mijn persoonlijke kijk op het toepassen van dit soort methodes is dat je er wel mee moet kunnen omgaan en dat je in de gaten moet houden dat het volgen van een methode een middel is en geen doel. Ik heb vaak genoeg projecten gezien met keurige projectdossiers, maar slecht werkende software.

Een interessant punt is dat het voor projectleiders vaak noodzakelijk is om inzicht te hebben in de mate waarin het project klaar is. Gegeven een situatie waarin de requirements veranderen is dat vaak lastig. XP heeft daar met het gebruik van use cases wel iets op gevonden omdat je kunt stellen dat een bepaalde use case goed geimplementeerd is en dus af is. Probleem is vaak dat er gedurende een project uses cases bij komen of verdwijnen waardoor je 'percentage gereed' cijfer weer wordt beinvloed.

[EfBe]

Verreweg het meest belangrijke aspect is of er een 1:1 of iig zeer solide koppeling bestaat tussen theoretisch ontwerp en gebouwde functionaliteit, dus dat je met ontwerp in de hand al kijkende naar de code kunt terugvinden waar welke functionaliteit is geimplementeerd en vice versa, dus dat je een stuk code hebt en kunt terugvinden welke functionaliteit het beschrijft (want dat is code, beschrijving van functionaliteit in een programmeertaal).

Elke methodiek die die koppeling bewerkstelligd is goed. Daarom is elke methodiek die op Fowler's ideeen voortborduurt in theorie minder, omdat je in veel situaties een vertaalslag moet maken tussen process oriented ontwerpen en object oriented implementaties en vice versa. De vertaalslag levert onherroepelijk problemen op, die overigens ook erkend worden. Wees daar dus op beducht.