Big Design Up Front

Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken

Big Design Up Front (BDUF) is de (regelmatig bekritiseerde) software ontwikkelingsmethode 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 uit gaat dat het meeste van het ontwerpen plaatsvindt tijdens het programmeren, gaat BDUF er dus vanuit 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 waar 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 inhoud 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 beschouwd als Big Design Up Front niet lijkt op het BDUF wat 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 software ontwerpers een “kristallen bol” hebben en problemen kunnen voorzien zonder uitgebreide gebruik te maken van prototypes en tenminste 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 wensen van de opdrachtgever(s) veel beter.

Verder is een flexibele software ontwikkelmethode sneller in staat te reageren op onverwachte problemen en wijzigingen, dit komt grotendeels 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]

Deze tekst is een vertaling van het Engelse artikel. Automatisch zijn dus ook de bronnen van dat artikel gebruikt.