DSDM & OOP

[Verwijderd]

Binnen de software-ontwikkel afdeling binnen ons bedrijf beginnen we steeds serieuzere applicaties te ontwikkelen ter ondersteuningen van ons bedrijf.

Momenteel ben ik bezig met het bestuderen van DSDM en heb een vraag hierover die op de volgend quote slaat.

delivering re-usable components. Projects may be required to produce re-usable components. Such components must be exactly right. DSDM may not be the appropriate method of choice where large scale re-usable components with exact correctness are to be built. However DSDM will be very suitable if the re-usable components are highly modular and can be built incrementally without prejudicing the rest of the application.

Wij ontwikkelen alles Object Orientated en gebruiken steeds meer UML voordat we beginnen met programmeren. Mijn vraag is of DSDM wel geschikt is als je het te programmeren gedeelte in DSDM eerst in UML wilt beschrijven en op het einde van de rit een goed Object Orientated programma hebt, inclusief re-usable components.

[Glimi]

DSDM heeft eigenlijk niet zo veel met programmeren te maken, maar eerder met project management. Het schrijft wel een incrementele ontwikkeling voor, maar dat kan net zo goed met OO als niet.

DSDM is karaktistieker gericht op communicatie naar de klant dmv workshops en demo's ed. Hierover kun je meer vinden op www.dsdm.nl (zowaar )

[Verwijderd]

Dat het inderdaad geen programmeervraag is oke. Maar dit was volgens mij de beste plaats om het te vragen.

Het lijkt mij juist dat dit niet goed samen gaat met OOP/UML. Met UML leg je al vast wat er wel en niet in komt. Er aan de hand van UML maak je je klasse's (genereer je ze bijna).

[LordLarry]

Dat bedoelt Glimi niet. Hij bedoelt dat het bij DSDM niet uit maakt of je UML gebruikt of niet. Beide is gewoon goed mogelijk. Ik ben het met hem eens.

Waarom jij vind dat het niet kan is mij niet helemaal duidelijk. De resultaten van een workshop kan je juist heel goed in de verschillende UML diagrammen vastleggen, maar hoe en of je dat doet valt niet onder DSDM.

[CubicQ]

Je kan UML op 3 verschillende manieren gebruiken [1]:
1) 'schetsen', dus om binnen de developers groep abstract tot een globaal beeld te komen van hoe de applicatie eruit moet komen te zien.
2) 'blauwdruk', dan gaat het al iets verder. Dan worden ook alle details ingevuld: zo moet deze private variabele in een class heten enzo.
3) 'programmeren', mbv bijv. Executable UML of een andere Action Semantic-implementatie (zie UML 1.5) kan je implementatie-onafhankelijk aangeven wat je applicatie precies moet doen.

Bij 3 haal je je UML door een tool heen en heb je je programma, bij 2 heb je een programmeur nodig die de UML diagrammen omzet in code en bij 1 heb je developers nodig die aan de hand van de UML diagrammen de software bouwen.

Bij Agile methodologies zul je denk ik vaker UML op manier 1 gebruiken, terwijl in zwaardere methodes versie 2 of 3 meer gebruikt worden.

Vergeet niet: UML is slecht een manier (taal) om software artifacts te beschrijven, hoe je dat doet of met welk doel etc. wordt niet door UML vastgelegd.

[1] http://martinfowler.com/bliki/UmlMode.html

[ Voor 5% gewijzigd door CubicQ op 03-06-2003 13:43 ]

[Verwijderd]

Ok thanks allemaal. UML is dus helemaal te gebruiken zonder problemen als je de DSDM project methode gebruikt.

Ik had mijn twijfels omdat je met UML al veel vast legt en vanuit daar gaat programmeren. Met DSDM kun je tijdens elke stap reeds gedane zaken weer veranderen.

[CubicQ]

argh, moest edit zijn... sorry

[ Voor 97% gewijzigd door CubicQ op 03-06-2003 13:42 ]

[Croga]

En als je het idee hebt dat UML en DSDM elkaar mischien in de weg zitten, kun je ook nog altijd kijken of je DSDM door RUP vervangt. Het idee er achter is vergelijkbaar: Door regelmatige demo's/prototypes de wensen van de klant helderder krijgen. De manier waarop de prototypes gemaakt worden is echter helemaal anders.

Kijk eens op www.rational.com voor meer informatie hier over.

[Kwai_gon_jinn]

hmmz.. DSDM werkt wel fijn met OOP programmeringen.. kun je in rapportages de klant tonen wat je wil..

op school worden we met DSDM ingestouwd, maar persoonlijk en ook uit m'n stage blijkt dat ik MOSCOW prettiger vindt werken..

je steld dan op wat erin moet komen, wat erin kan komen maar niet noodzakelijk is en wat erin mag komen ter vermakkelijking/ versiering e.d.

zo maak je toch het basis product die je langzamerhand uitwerkt naar de wensen van je klant. dat lijkt met OOP wel handig aangezien je toch al heel veel basis spul al eerder gemaakt hebt uit andere producten..

maar om veel prog moeite besparen is DSDM handiger omdat je alvorens begint met proggen eerst alle failbacks, must and don'ts al op papier hebt voor de klant.. (soort offerte)
tiss alleen wel veel papier werk. scheelt veel programmeer werk.

het is maar net wat voor klant je hebt en wat je product word (of levert)

[Verwijderd]

Kwai_gon_jinn schreef op 03 June 2003 @ 13:49:
op school worden we met DSDM ingestouwd, maar persoonlijk en ook uit m'n stage blijkt dat ik MOSCOW prettiger vindt werken..

je steld dan op wat erin moet komen, wat erin kan komen maar niet noodzakelijk is en wat erin mag komen ter vermakkelijking/ versiering e.d.

beetje offtopic maar,
MoSCoW heeft te maken met de requirements analyse van een software ontwikkel traject en is dus niet echt een methode.

MoSCoW kan je gebruiken om je (functionele en niet-functionele) requirements een prioriteit mee te geven ongeacht de methode die je gebruikt lijkt mij.

[ Voor 3% gewijzigd door Verwijderd op 03-06-2003 13:59 ]

[Verwijderd]

MoSCoW is een onderdeel van DSDM toch?

[Verwijderd]

MoSCoW kan bij elke software ontwikkelmethode worden toegepast, dus ook bij DSDM.

Het is zoals gezegd bedoeld om je requirements een bepaalde prioriteit te geven.

Must haves
o
Should haves
Could haves
o
Would haves

[ Voor 9% gewijzigd door Verwijderd op 03-06-2003 14:36 ]

[Gert]

TS heeft wel een punt te pakken. Wanneer je producten moet realiseren die voor meerdere dingen gebruikt moet kunnen worden kan het zijn dat DSDM in de weg zit.
Je kijkt naar het probleem en daar zoek je een oplossing voor. Dat deze ook nog voor andere dingen moet werken is mooi meegenomen maar dat kan geen prioriteit zijn. De tijd staat vast, de functionaliteit moet daar maar aan aanpassen.

Natuurlijk kan je het altijd een beetje naar eigen inzicht aanpassen.

UML kan je natuurlijk best pas maken nadat de functionele eisen bekend zijn. Er komt een moment dat er geen stap meer terug mogelijk is als het gaat om het aanpassen / toevoegen van functionaliteit.