Vaak wordt bij software-ontwikkeling gezegd dat er documentatie van het gemaakte programma of het systeem ontbreekt. Vooral technische documentatie is doorgaans afwezig. In dit artikel geef ik aan waarom het technisch ontwerp juist in de prullenbak thuishoort.
De namen functioneel en technisch ontwerp komen oorspronkelijk uit de System Development Methodology (SDM). Deze ontwikkelmethodiek is beter bekend als de watervalmethode. SDM is verouderd en de meeste software-ontwikkeling gaat nu iteratief met als methodiek bijvoorbeeld RUP of Scrum. Hierbij is afstand genomen van het idee dat in één keer een totaal ontwerp gemaakt en uitgewerkt kan worden. Oorspronkelijk bevatte het technisch ontwerp vaak procedurenamen en beschrijvingen, detailschermen, datamodellen en datacomponenten. Dit was tot in detail beschrevenl. Welke documentatie wordt gemaakt is nauw verbonden met de gekozen ontwikkelmethodiek. Voor RUP wordt er bijvoorbeeld gewerkt met een software-architectuur document en analyse en design models. Binnen Scrum bestaat er geen technisch ontwerp of vergelijkbaar document.
Naar de prullenbak
De eerste reden waarom het technisch ontwerp in de prullenbak zou horen te verdwijnen is dat het document niet past binnen de huidige methodieken. Als er gekozen wordt voor Scrum is er eigenlijk geen technisch ontwerp. In de praktijk worden er wel vaak documenten gemaakt met een technische inslag. Dit wil ik geen technisch ontwerp noemen omdat het niet de volledigheid en vorm van het vroegere technisch ontwerp kent. De ontwerpdocumenten worden gebruikt in de discussies en bewijzen vooral hun nut tijdens ontwerpen en ontwikkelen.
De tweede reden waarom het technisch ontwerp in de prullenbak hoort te verdwijnen is, omdat het document moeilijk te onderhouden is. Er staan zoveel details in een technisch ontwerp dat het nagenoeg altijd moet wijzigen als de software wijzigt. Soms wordt het document zelfs vanuit commentaar in de code of vanuit metadata in het databasemodel gegenereerd. Vaak is dit een eenmalige actie en wordt het document later slecht bijgehouden. Nieuwe ontwikkelaars weten niet van het bestaan van het document, of hebben er geen vertrouwen in, met als gevolg dat het niet gebruikt wordt. Er wordt liever in de code gekeken. Het document wordt dus later in het software- ontwikkeltraject niet gebruikt, maar alleen tijdens het ontwerpen zelf.
Technische documentatie niet nuttig?
Technische documentatie is zeker nuttig omdat het een abstractie is van de code. Deze abstractie helpt de ontwikkelaar bij aanpassingen of bij de analyse van problemen. De veelgemaakte fout is echter dat er teveel naar de details wordt gekeken. De systeemstructuur of kernprincipes worden dan vaak vergeten. Maar documentatie op architectuurniveau is juist wel belangrijk om te hebben. Software-architectuur gaat over de essentie van de gemaakte software en verandert ook niet zo snel. Een architectuuraanpassing kost veel meer moeite en zal niet snel doorgevoerd worden. Het beschrijven van de architectuur helpt ontwikkelaars enorm bij het begrijpen en uitbreiden van de gemaakte software.
Buiten de architectuur is er tijdens het ontwerpen ook behoefte aan meer technisch detail. Het maken van klasse en sequence diagrammen is niet ongebruikelijk en ook zeer nuttig in de ontwerpfase. Ook hier helpt de abstractie in de discussies. Het bewaren van dergelijke modellen is niet zo nuttig. De diagrammen worden immers niet bijgehouden en verder zijn er vaak alleen maar delen tot in dat detail beschreven. De diagrammen worden namelijk voor een bepaald project gemaakt. Zeker als de diagrammen ouder worden, verliezen ze hun waarde.
Als eenmaal keuze is gemaakt om de diagrammen niet te onderhouden, dan worden ook de kwaliteitseisen met betrekking tot het model anders. Het maakt niet meer uit dat ze niet met een duur tool zijn gemaakt, maar gewoon met potlood en papier. Ook een whiteboard diagram voldoet prima. Een foto hiervan kan eenvoudig later nog worden gebruikt. Tijdens het ontwerpen helpen de diagrammen je op een andere manier na te denken over de te maken oplossing. Tijdens ontwikkeling helpen ze vervolgens met het uitzetten van de richting en grote lijnen, maar daarna kunnen de diagrammen gewoon naar de prullenbak.
Als ik afga op de reacties zie ik terug wat ik ook vaak in mijn werk hoor. Er zijn mensen die een voorkeur hebben voor meer documentatie en er zijn mensen die een voorkeur hebben voor minder documentatie. Verder was er vroeger behoefte aan gedetailleerdere documentatie dan tegenwoordig.
Zoals Ad correct aangeeft is vooral het gezonde verstand bepalend voor het wel of niet maken van een document en voor het detailniveau.
Het is belangrijk om te zien dat ik wel degelijk waarde hecht aan functionele documentatie en architectuurdocumentatie. Dit vind ik de kern waarop softwareonderhoud zich zal baseren. Als je goed weet WAT een systeem moet doen, dan is het HOE eenvoudiger te begrijpen en bepalen.
Technische documentatie noem ik niet allemaal technisch ontwerp (zie reden 1 van mijn betoog). Technische documentatie is niet geschreven vanuit volledigheid standpunt (zoals dat vroeger wel gebeurde) Deze technische documtatie is meer de kers op de pudding. Het is handig om te hebben, maar het is niet iets wat bijgehouden moet worden. Het bijhouden kost onnodig veel tijd en geld en zal niet te rechtvaardigen zijn. Het niet hebben van de technische documentatie is niet echt een probleem tijdens onderhoud. Als de code immers niet te begrijpen is zonder de documentatie, dan is er toch iets anders mis.
ps. Niet gemeld maar het gaat in dit geval over mission critical systemen bij overheidsbedrijven en financiele wereld. Er zijn dus wel degelijk strenge eisen aan, maar het gaat nog steeds niet over flight control of dergelijke systemen met superstrenge eisen.
Er zit zeker wat in. Als documentatie toch niet gebruikt wordt, waarom dan maken.
Veel documentatie is verouderd. Het moeten maken van documentatie levert vaak geen goede documentatie op.
Functioneel beheerders, die door de veelheid aan applicaties, applicaties niet kennen.
En toch krijg ik het gevoel van IT-ers, die moeilijk ontwerpen kunnen maken/lezen en alles meteen willen bouwen.
Schrijf AUB nog wel wat op, want de generatie na ons, zal dan zeker ons werk weggooien.
Ik ben het heel erg eens met die mijnheer PaVaKe. Om het scynisme nog wat meer op te voeren. Wel eens van het woord “pragmatisch” gehoord? Dat is een duur klinkende term voor de EMP-methode (En maar proberen). Er is een prachtig ontwerp, de deadline nadert in dus zegt de projecleider ineens: “Jongens we staan onder druk, kunnen we nou niet gewoon pragmatisch….”. En zo gaan mensen dan gehaast maar wat aanklooien en de praktijk van alle dag wijst gewoon uit dat je dan naderhand met onderhoud e.d. in de problemen komt. Ik erger me altijd groen en geel en projectleiders die er dergelijke argumentatie op na houden. Achter duur klinkende terminologie proberen te verbergen dat je erg voor het maar wat aan rommelen bent.
Prachtig, dit ontslaat mij voor het maken van een technisch ontwerp voor het afstuderen :)))))
Prachtig, dit ontslaat mij voor het maken van een technisch ontwerp voor het afstuderen :)))))
“Er staan zoveel details in een technisch ontwerp dat het nagenoeg altijd moet wijzigen als de software wijzigt.”
Ja, dat is wel heel vervelend en ongemakkelijk. Vooral als dat ontwerp is gebaseerd op een gedocumenteerd FO. Dat moet dan ook maar in de prullenbak wat dat moet steeds worden gewijzigd op basis van de gewijzigde gedocumenteerde requirements op basis van de gewijzigde beschreven behoefte aan ondersteunende functionaliteit van de gebruiker.
Weet je wat? Gooi die gebruiker ook maar in de prullenbak, sluit het systeem af en ga wat nuttigs doen.
Natuurlijk chargeer ik, maar de stelligheid waarmee in dit artikel het beheer van wijzigingen omver wordt gehaald, gaat mij een stap te ver. Natuurlijk, de schrijver preekt voor eigen parochie. Hij is architect en de architectuur is wel belangrijk. De architectuur verandert nauwelijks, omdat het de werking en logica (“de essentie”)van een systeem of software vastlegt. Ja, ik moet nog zien of die essentie aan de praat gehouden kan worden als we niet meer bijhouden wat de software precies moet doen.
Ik zou zover willen gaan dat generieke zaken niet steeds opnieuw beschreven (of ontworpen) en gedocumenteerd hoeven worden (mits je kunt verwijzen naar de gekozen standaarden), maar in geval van maatwerk moet je dat wel.
Met wiskunde kregen wij vroeger een extra punt als de bewerking was uitgeschreven. Een goed, maar gegokt antwoord was minder waard omdat niet gecontroleerd kon worden of de juiste bewerking was gebruikt. Als je straks je essentiële functionaliteit niet meer kunt controleren op de juiste werking, is je software feitelijk waardeloos.
Ik denk dat het goed is dat je eerst het verschil tussen een ontwerp en documentatie vastlegt. Een ontwerp doe je van te voren om jezelf of anderen te helpen met het ontwikkelen van een systeem. Net als een architect doet voor een huis. Een programmeur mag van een ontwerp afwijken als dat nodig is! Jij hebt je werk gedaan dus het is NIET jouw probleem als er van af wordt geweken. Het ontwerp is er dus te helpen bij de realisatie.
Documentatie doe je achteraf, om mensen inzicht te laten krijgen in hoe je iets hebt gemaakt. Hier zijn gelukkig veel tools voor in veel ontwikkelomgevingen. Niemand haalt het in zijn hoofd om met de hand alle veranderingen in het product te achterhalen om te kijken wat hij moet veranderen natuurlijk.
Documentatie én ontwerpen zijn dus twee totaal verschillende dingen, en beiden kunnen gebeuren zonder al teveel inspanning als je het zo bekijkt.
Het idee is wel dat je aan de hand van je technisch en functioneel ontwerp testen kan ontwerpen (zie bijv. V-model) omdat je vooraf bepaald hoe het systeem moet werken zonder naar de realisatie te hebben gekeken. Dit is waar deze twee ontwerpen dan juist nóg sterker uit komen. Technische en functionele ontwerpen passen ook prima in Scrum e.d. Je moet dan wel per sprint/fase/iteratie een nieuw ontwerp maken van het onderdeel dat jij gaat realiseren. Is het onderdeel van een groot systeem, dan kan je het beste een algemeen functioneel en technisch ontwerp maken aan de hand van alle Musts in een project om zo rekening te houden met de komende sprints/iteraties/fases of andere delen van een bepaalde methodiek.
Ik hoop dat dit je visie veranderd op het technisch ontwerp, maar ik begrijp ook dat het in veel bedrijven wordt overgeslagen omdat naar functionaliteit wordt gewerkt en niet naar traceerbaarheid, testbaarheid en uitbreidbaarheid, wat ik eveneens als valkuilen heb ervaren bij verschillende organisaties welke ik heb geadviseerd in mijn beroep.
Mooi artikel, zit inderdaad nu ook te overwegen om er van af te stappen en door te gaan op scrum.
(But they call me Gérard!)