Big Design Up Front
Big Design Up Front (BDUF) is een softwareontwikkelingsmethode waarbij het ontwerp van het programma af moet zijn voordat de implementatiefase wordt gestart. Bij de methodologie van Big Design Up Front staat vooraan dat het "big" design voor de realisatiefase plaatsvindt (dat wil zeggen voor het programmeren en testen). Het is daarom niet vreemd dat het in verband wordt gebracht met de bekende watervalmethode in de softwareontwikkeling.
De discussie tussen de voor- en tegenstanders van BDUF is fel, maar de meeste mensen geloven dat een compromis tussen BDUF en de extremere varianten binnen flexibele softwareontwikkeling (Rapid Application Development, de Agile-beweging) de beste oplossing biedt voor de meeste problemen omtrent de softwareontwikkeling. Waar Extreme Programming ervan uitgaat dat het meeste van het ontwerpen plaatsvindt tijdens het programmeren, gaat BDUF er dus van uit dat de ontwerpfase reeds is afgerond voor men met de realisatiefase begint.
Argumenten voor Big Design Up Front bewerken
Voorstanders van BDUF vinden dat het besteden van tijd aan de planning een waardevolle investering is, ze kunnen meerdere studies aanhalen waarin de conclusie getrokken werd dat er minder tijd en energie gestoken was in het repareren van een bug in de beginfases van de levenscyclus van een software product dan wanneer dezelfde bug later gevonden wordt en hersteld moet worden. (Het is makkelijker een bug binnen de project requirements (project eisen) te verhelpen in de requirements fase, omdat het verhelpen van deze bug tijdens de implementatiefase inhoudt dat er in ieder geval iets uit de implementatie en het ontwerp, wat al af was, geschrapt moet worden).
Joel Spolsky, een populaire online commentator op softwareontwikkeling, heeft sterke argumenten voor Big Design Up Front.
Vertaald: "Regelmatig heeft het van tevoren uitdenken van bepaalde zaken ons later veel ellende bespaard. … [over het maken een bepaalde specificatiewijziging] … Het maken van deze wijziging in de specificaties kostte ons slechts een uur of twee. Als we deze wijziging later in de code hadden moeten maken, dan had dat ons weken extra gekost. Ik kan niet beschrijven hoe erg ik geloof in Big Design Up Front, hetgeen de voorstanders van Extreme Programming (XP) als minderwaardig (anathema) beschouwen. Ik heb consistent tijd bespaard en betere producten gemaakt met gebruik van BDUF en ik ben er trots op dat ik het gebruik, wat de XP fanatici ook beweren. Ze hebben gewoon ongelijk op dit punt, daar kan ik niet duidelijk genoeg in zijn.“
Hoewel sommigen hier tegenin brengen dat hetgeen Joel beschouwt als Big Design Up Front niet lijkt op het BDUF dat door de aanhangers van XP en andere agile (flexibele) software ontwikkelmethodieken wordt bekritiseerd.
Argumenten tegen Big Design Up Front bewerken
Critici (met name degenen met een agile (flexibele) softwareontwikkeling achtergrond) beweren dat BDUF niet flexibel is ten opzichte van de projecteisen, dat de voorstanders “dinosaurussen” zijn die zich vast blijven houden aan een verouderde en onbewezen methodiek. Ze nemen aan dat BDUF-softwareontwerpers een “kristallen bol” hebben en problemen kunnen voorzien zonder uitgebreid gebruik te maken van prototypes en ten minste wat onderzoek te verrichten naar de implementatie.
Bij de BDUF worden de projecteisen in de beginfase het liefst bevroren, zodat de functionaliteiten vast staan. Hierdoor kan men in theorie de verschillende fases uit het watervalmodel achter elkaar doorlopen, zonder de noodzaak om eerder gedane stappen te moeten herhalen. Deze theorie wijkt echter af van de praktijk, waar blijkt dat de projecteisen op elk moment aan verandering onderhevig zijn, nieuwe inzichten en vereisten kunnen verder in het traject pas aan het licht komen. Bij een flexibele software ontwikkelmethode is hier goed op in te springen, omdat het geen probleem is om terug te gaan naar eerder gedane fases uit het project, hierdoor is de aansluiting van deze methode bij de wensen van de opdrachtgever(s) veel beter.
Verder laat een flexibele software ontwikkelmethode toe om sneller te reageren op onverwachte problemen en wijzigingen. Dit komt voornamelijk doordat de communicatie met de eindgebruikers doorgaans veel hechter is en testen niet een fase is aan het einde van het project, maar constant wordt uitgevoerd tijdens het project.
Tevens wordt op deze blog een interessante vergelijking gemaakt met de Rubiks kubus en BDUF.
Waarom Design Up Front gebruiken? bewerken
Het is altijd zo dat er enig ontwerp van tevoren aanwezig moet zijn. Vooral wanneer het gaat om grote projecten aangaande Enterprise systemen. Het moet van tevoren duidelijk zijn wat de functionele eisen zijn. Denk hierbij aan welke diensten het project in moet voorzien of hoeveel machines daarbij nodig zijn om deze te ondersteunen. Het is onmogelijk om een nieuw project voor te stellen aan bijvoorbeeld een Raad van Bestuur waar een groot prijskaartje aanhangt en vervolgens te zeggen dat men maar de code in moet duiken om te begrijpen of de eisen dus daadwerkelijk gehaald worden.
Vooral voor grote projecten wordt het 'grote' ontwerp vooraf als een van de belangrijkste eisen gezien.
Zie ook bewerken
Bronnen bewerken
- Dit artikel of een eerdere versie ervan is een (gedeeltelijke) vertaling van het artikel Big Design Up Front op de Engelstalige Wikipedia, dat onder de licentie Creative Commons Naamsvermelding/Gelijk delen valt. Zie de bewerkingsgeschiedenis aldaar. Automatisch zijn dus ook de bronnen van dat artikel gebruikt.