[alg] project planning

[Alarmnummer]

Ik ben een aantal boeken aan het doorbladeren over software architectuur en software methodologieen zoals agile development, test driven development, feature driven development, XP etc en ik zie hierin iedere keer mijn eigen onduidelijk over projectplanning bevestigd worden. Als iemand mij vraagt hoe lang iets gaat duren, dan moet ik eerlijk toegeven dat ik daar niet echt een goed antwoord op kan geven. Soms duurt iets langer en soms duur het korter. Meestal geef ik voor de grap dan mijn eigen tijdsregel:

neem de tijd die je denkt nodig te hebben, vermendigvuldig dit met drie en dan heb je nog te weinig.

Ik zie deze wazigheid ook terug in deze methodologieen. Ze willen zelfs steeds meer afstappen van een stugge document-driven methodologieen omdat veel documenten worden geschreven omwille van de methodologie en niet omwille van de programmeur. Daarnaast zijn de meeste documenten snel verouderd omdat als iets eenmaal is geimplementeerd, de documenten niet meer worden bijgewerkt (dus ook niet na refactoren zoals dat in principe overal wel moet gebeuren). Hierdoor steek je enorm veel werk in iets wat je later al bijna niet praktisch meer kan gebruiken en eigelijk alleen zorgt voor een verkeerd beeld.

Ik weet intussen van 2 matige oplossingen om het gat tussen code en model/document te verkleinen.
1) UML -> code en code->UML. Maar persoonlijk vind ik UML dat meteen te vertalen valt naar code net zo interessant als de code zelf en zie ook de meerwaarde hier niet van in. Alleen om het duidelijk te maken naar anderen (of jezelf) of om hogerop in je ontwerp te gebruiken vind ik UML een toegevoegde waarde hebben, maar niet als UML op hetzelfde abstractie nivo zit als je code.
2) MDA -> Model driven architecture. Aan de hand van modellen ga je code genereren. Het probleem aan deze modellen is dat je eigelijk vrij vast komt te zitten in de mogelijkheden van de code generatoren en van de beschikbare model-transformaties. Deze oplossing om het gat tussen code en documentatie te verkleinen vond ik zelf niet echt interesssant.

Een ander nadeel aan de stugge aanpakken is dat ze eigelijk te veel van te voren willen plannen en geen rekening houden met de veranderende natuur van software ontwikkeling. Het is een feit dat er altijd nieuwe requirements komen en dat je met de document-driven aanpak veel werk voor niets hebt gedaan. Verder valt van te voren ook niet altijd te bepalen hoe iets eruit moet komen te zien, omdat je daar eigelijk nog geen goed beeld van hebt.

Daarom zie je bij de bovengenoemde lichtere methodelogieen ook vaak dat niet te veel tijd in een ontwerp gestoken moet worden. Dit wil niet zeggen dat je maar een beetje ad-hoc alles in elkaar moet zetten (dit was het 1e waar ik aan moest denken), maar dat je een ontwerp zo op moet zetten dat veel interne structuren daaruit volgen, maar als het nodig is om het aan te passen, dat dit ook mogelijk moet zijn.

Zoals je ziet gaat het dus om vrijheid en het niet in de puntjes bepalen van alle details omdat dit gewoon niet mogelijk is. Maar als alles zo flexibel is, hoe maak je dan een planning? Hoe kan je een indicatie geven van hoe lang iets gaat duren? Als je ervaring hebt met een bepaald type product dan kan je aan de hand van die kennis wel een schatting doen, maar als je een volledig nieuw product ontwikkeld dan heb je geen referentie punten en een schatting doen is dan net zo trefzeker als bellen naar de tv-spelletjes waar altijd 5 minuten voor het einde van het programma de prijs wordt gewonnen.

Mijn vraag is dus hoe je moet gaan plannen?

[ Voor 19% gewijzigd door Alarmnummer op 19-08-2003 08:05 ]

[Reefer]

Ten eerste is mij geleerd dat je eigenlijk na de ontwerpfase geen nieuwe requirements zou moeten accepteren, omdat hierdoor je inderdaad veel werk voor niks kan hebben gedaan.
En als je geen idee hebt hoe het product eruit moet gaan zien , is het dan wel een goed idee om er zowiezo aan te beginnen ?
Planningen zijn in de projecten die ik voor school heb gedaan tot nu toe in elk geval altijd aan wijziging onderhevig vanaf dag 1. Dus planning zijn ook flexibel
En met goed risico-management zou je problemen met de planning moeten kunnen voorzien ( in theorie dan )

[Alarmnummer]

Reefer schreef op 18 augustus 2003 @ 14:42:
Ten eerste is mij geleerd dat je eigenlijk na de ontwerpfase geen nieuwe requirements zou moeten accepteren, omdat hierdoor je inderdaad veel werk voor niks kan hebben gedaan.

Tja.. helaas is de werkelijkheid niet altijd zo..

En als je geen idee hebt hoe het product eruit moet gaan zien , is het dan wel een goed idee om er zowiezo aan te beginnen ?

Dan zou er niet veel leuke software meer geschreven worden

Planningen zijn in de projecten die ik voor school heb gedaan tot nu toe in elk geval altijd aan wijziging onderhevig vanaf dag 1. Dus planning zijn ook flexibel
En met goed risico-management zou je problemen met de planning moeten kunnen voorzien ( in theorie dan )

Het probleem aan schoolvoorbeelden is dat de docent in ieder geval wel een redelijk beeld voor ogen heeft qua tijd en dat hij ook weet dat de opdracht in principe ook in die tijd afgerond kan worden. Meestal sturen ze de groepen ook wel aan als ze dreigen te verdrinken in de diepte.

Deze 'sturende' factor heb je dus niet in serieuze projecten.

[Verwijderd]

Jupz zoals Reefer zegt zo heb ik het ook geleerd
Kijk dan ook is naar de DSDM methode waarin zeker tijd zeer strak geplant staat en je de afgesproken deadline toch echt niet KAN overschrijden

[zoepercavia]

Bij incrementele methoden (met iteraties), is het volgens mij gebruikelijk om pas een definitieve planning te geven na een paar iteraties. Want dan pas heb je informatie over het project om goed te kunnen bepalen hoe lang het nog gaat duren. Bij XP meten ze 'project velocity' met behulp van het aantal user stories dat in een bepaalde tijd wordt geimplementeerd. Maar ook dit is dus pas als er al een aantal zijn gedaan.

Voor de klant is dit natuurlijk niet fijn, maar uit eigen ervaring weet ik dat een datum noemen weinig zin heeft. Het resulteert enkel in stress en overwerk (en dat komt nooit ten goede aan het project). Ook is het zo in de meerderheid van de gevallen dat de klant steeds meer wil waardoor een schatting op t=0 geen enkele zin heeft. Zoals ik al eerder zei: je hebt informatie nodig om een (educated) guess te kunnen maken.

En natuurlijk kan je altijd wel een hele grove schatting maken en deze zo langzamerhand verfijnen. Ik denk dat je wel met een redelijkheid een datum kan noemen als je op de helft van het project bent. Wanneer er deadlines (beurzen bijvoorbeeld) een rol gaan spelen dan is het misschien verstandig om heel duidelijk te bepalen wat er wel en niet geimplementeerd gaat worden. Haal je ook dat niet, dan is het gewoon zaak om toch nog minder te doen. Immers: haastige spoed is zelden goed

[Alarmnummer]

zoepercavia schreef op 18 August 2003 @ 14:49:
Bij incrementele methoden (met iteraties), is het volgens mij gebruikelijk om pas een definitieve planning te geven na een paar iteraties. Want dan pas heb je informatie over het project om goed te kunnen bepalen hoe lang het nog gaat duren.

Dit is ook mijn manier van werken (veel updates naar de users toe zodat je snel feedback krijgt en natuurlijk ook bugs die je nog niet te gevonden hebt met de unit tests)

Voor de klant is dit natuurlijk niet fijn, maar uit eigen ervaring weet ik dat een datum noemen weinig zin heeft. Het resulteert enkel in stress en overwerk (en dat komt nooit ten goede aan het project). Ook is het zo in de meerderheid van de gevallen dat de klant steeds meer wil waardoor een schatting op t=0 geen enkele zin heeft. Zoals ik al eerder zei: je hebt informatie nodig om een (educated) guess te kunnen maken.

Het probleem is als je niet kan zeggen hoe lang iets gaat duren (en dus hoeveel iets gaat kosten) er ook meteen een stuk interesse verdwijnt. Ik kan me goed voorstellen dat een klant geen zin heeft om geld te steken in een project waarvan niet bepaald kan worden hoeveel geld het uiteindelijk gaat kosten. Maar aan de andere kant vind ik een uit de duim gezogen tijdsbepaling ook niet kunnen.

En natuurlijk kan je altijd wel een hele grove schatting maken en deze zo langzamerhand verfijnen.

Ik denk dat ik het al knap van mezelf vind als ik er maar 100% naast zit. Maar dit is voor een klant totaal onacceptabel.

[ Voor 3% gewijzigd door Alarmnummer op 18-08-2003 15:02 ]

[Scare360]

Use case driven, dus een use case uitwerken, implementeren, testen etc en de tijdsduur noteren. Door statistische gegevens bij te houden en vooraf de use case op complexiteit in te schatten wordt je "schatting" steeds nauwkeuriger. Werkt prima overigens.

[Pooh]

Alarmnummer schreef op 18 August 2003 @ 15:01:
Ik denk dat ik het al knap van mezelf vind als ik er maar 100% naast zit. Maar dit is voor een klant totaal onacceptabel.

Volgens mij moet je nooit op die manier jezelf vastpinnen op een datum. Je kunt beter grove schattingen geven, die in de loop van het project steeds verfijnder worden. Dus bij het eerste gesprek zeg je bijv. "dat kost tussen de 6 maanden en de 2 jaar", nadat de lijst met features is opgesteld zeg je "tussen de 12 en 18 maanden", en na de ontwerpfase zeg je "tussen de 14 en 16 maanden". Hierdoor schep je geen irreele verwachtingen, en kun je ook elke keer aangeven wanneer je met een verfijndere schatting kunt komen.

[zoepercavia]

Ik denk dat het ook maar net is hoe een klant gewend is te werken met leveranciers. Misschien een beetje flauw, maar software maken is niet hetzelfde als een machine bouwen, met goedgedefinieerde fases (analyse, ontwerp, produktie, testen) die elkaar sequentieel opvolgen. Dit moet je je klant denk ik goed duidelijk maken. Ik weet niet meer precies waar het stond, maar het gebruik van een waterval methode voor software ontwikkeling stond in de top 10 van redenen voor mislukking van software projecten.

Ik snap dan ook niet waarom bij sommige opleidingen dat soort methodes nog gegeven worden. Tuurlijk is XP of RUP (of een combinatie) of Scrum (enz.) geen panacee voor projecten om te slagen. Maar ik krijg niet de indruk dat er veel aandacht aan besteed wordt op opleidingen (ik kom niet uit het wereldje, dus misschien is het veranderd?).

Daarnast vind ik dat irreele verwachtingen scheppen veel erger dan beginnen met een ruime schatting.

Use case driven, dus een use case uitwerken, implementeren, testen etc en de tijdsduur noteren. Door statistische gegevens bij te houden en vooraf de use case op complexiteit in te schatten wordt je "schatting" steeds nauwkeuriger. Werkt prima overigens.

Das natuurlijk hetzelfde als de term project velocity

offtopic:
Alarmnummer, je woont toch in Groningen? Ik ook, mag ik misschien weten waar je woont? Vind ik leuk

[ Voor 6% gewijzigd door zoepercavia op 18-08-2003 15:50 ]

[Alarmnummer]

zoepercavia schreef op 18 August 2003 @ 15:46:
Ik denk dat het ook maar net is hoe een klant gewend is te werken met leveranciers. Misschien een beetje flauw, maar software maken is niet hetzelfde als een machine bouwen, met goedgedefinieerde fases (analyse, ontwerp, produktie, testen) die elkaar sequentieel opvolgen. Dit moet je je klant denk ik goed duidelijk maken.

Mijn probleem is dat ze dan erg terughoudend zijn.

Ik snap dan ook niet waarom bij sommige opleidingen dat soort methodes nog gegeven worden. Tuurlijk is XP of RUP (of een combinatie) of Scrum (enz.) geen panacee voor projecten om te slagen. Maar ik krijg niet de indruk dat er veel aandacht aan besteed wordt op opleidingen (ik kom niet uit het wereldje, dus misschien is het veranderd?).

Vanuit de hanze hoogeschool wordt er echt heel weinig aan gedaan en ze zijn nu eindelijk eens begonnen met design patterns, en een heel klein beetje XP. Het probleem is dat veel docenten niet echt gemotiveerd zijn (of goed in hun vak). en imho te weinig tijd besteden om up to date te blijven. Daarnaast is het voor een school financieel gezien het beste om veel mensen af te laten studeren (ze krijgen pas betaald na afstuderen) en hoe lager het nivo dan is, hoe meer mensen afstuderen, hoe meer geld ze binnen krijgen. Het feit dat een afgestuurde hts`er totaal niet praktisch inzetbaar is, is voor een school schijnbaar niet interessant meer.

Voor de RuG geldt trouwens hetzelfde. Ik geloof dat ze nu voor het eerst zijn begonnen met design patterns. Ik denk dat dit al genoeg zegt over de opleiding.

Alarmnummer, je woont toch in Groningen? Ik ook, mag ik misschien weten waar je woont? Vind ik leuk

Ik woon tegen het noorderplantsoen aan (noorderhaven). Een groot wit gebouw met daarop de tekst 'melkfabriek' En dat klopt ook redelijk, want bij ons in huis wordt er flink wat op losgemolken *denkt even aan zijn irritante buurman en zijn vriendin*

[ Voor 5% gewijzigd door Alarmnummer op 18-08-2003 16:00 ]

[mjax]

Ik mag zeggen dat ik een zeer ruime ervaring op het gebied van projectmanagement van maatwerk softwaredevelopment projecten heb, zowel vanuit de ontwikkelende kant als vanuit de managende kant. En laat ik meteen een boud statement erin gooien: klanten hebben geen boodschap aan projectmanagement methoden!

Een klant wil een product volgens zijn specs op dag X afgeleverd krijgen. Dag X zul je dus al vrij snel moeten kunnen noemen. Kun je het niet berekenen (volgens een bepaalde methode) dan zul je dus goed moeten kunnen bluffen/gokken. Klanten zijn ook een held in het interpreteren van specs in hun voordeel.

Hoe moet je hier als ontwikkelteam dan mee omgaan?

Ten eerste door veiligheidsmarges in te bouwen. Schat de ontwikkeltijden voor features ruimer in dan je in eerste instantie nodig acht. Die regel van Alarmnummer (3x wat je denkt nodig te hebben) is zo gek nog niet.

Ten tweede door verwachtingsmanagement. Het belang van "Perceptionmanagement" is omgekeerd evenredig aan de inzichten die een klant over het eindproduct heeft. Dus hoe minder helder dat beeld, hoe belangrijker het management van verwachtingen wordt. Dat is een taak die bij de projectmanager en (bij sommige toko's) de accountmanager ligt.

Ik ben zeer gecharmeerd van de zgn. 'agile' ontwikkelmethodes, maar in de praktijk zijn ze niet altijd strikt inzetbaar. Je kunt natuurlijk ook de passende onderdelen van verschillende methodes nemen en die combineren om voor een specifiek project tot een acceptabele methode te komen. Bijvoorbeeld use cases combineren met de unittesten van XP en de timeboxing van DSDM.

Moraal van dit verhaal: uiteindelijk is softwareontwikkeling en bijbehorend projectmanagement vanuit het perspectief van een klant een noodzakelijk kwaad om tot een eindproduct te komen.

[Alarmnummer]

Voor mensen die echt ervaren zijn met project managment (en dan doel ik echt op de technische kant en niet zozeer de economische/sociale):

wat voor scholing hebben jullie hiervoor gevolgd?

[ Voor 28% gewijzigd door Alarmnummer op 18-08-2003 17:09 ]

[mjax]

Alarmnummer schreef op 18 augustus 2003 @ 17:00:
Voor mensen die echt ervaren zijn met project managment (en dan doel ik echt op de technische kant en niet zozeer de economische/sociale):

wat voor scholing hebben jullie hiervoor gevolgd?

Zelf heb ik HIO gedaan en een paar aanvullende management trainingen. Aangezien het alweer een tijd geleden is dat ik de HIO volgde, heb ik destijds alleen SDM als methode meegekregen. XP, SDSM e.a. heb ik in vervolgtrainingen geleerd.

[Verwijderd]

UML vind ik op zich wel wat(zodat je van te voren een beetje weet wat de structuur van je prog. wordt, en kunt communiceren naar je klanten etc.) , maar ik denk dat UML niet door mensen gemaakt moet worden. Het beste lijkt me om gegeven een aantal beperkingen, daaruit te bepalen waar bepaalde instantievariabelen moeten komen.

Overigens vraag ik me af of het nog praktisch is om 200 klassen in een UML diagram te zetten(als je het tenminste over een groot project hebt). Een andere methode die wel (alleen) voordelen biedt ken ik alleen niet.

Er is wel een functionele modeleringstaal alá UML, maar daar heb ik me niet in verdiept. In The Haskell Cafe Archive kun je daar wel wat vinden erover.

[Verwijderd]

UML heeft niks met project planning te maken, het is alleen een manier van modelleren.

Over project planning: Lees ees het boek van Tom Gilb: Principles of SE Managent

[Alarmnummer]

Ik ben gisteravond al begonnen in:

Planning Extreme Programming van Kent Beck en Martin Fowler.

[Alarmnummer]

Wat voor software gebruiken jullie trouwens om te plannen? MS-Project is al 1 ding dat ik ben tegengekomen, maar er schijnen nogal wat it`ers te zijn die problemen hebben met die manier van denken.

[mbravenboer]

Wikipedia heeft aardig wat project planning bronnen. Zie bijvoorbeeld Project management software.

[alienfruit]

Ik doe de project planningen gewoon op papier

[mjax]

MS Project is persoonlijk mijn favoriet, maar als dat niet voorhanden is, doe ik het gewoon in Excel. Eis is in elk geval dat er automatisch totalen berekent kunnen worden van subtaken, deelprojecten en het totale project. Op papier vind ik dat wat bewerkelijk.

[CubicQ]

Alarmnummer schreef op 18 August 2003 @ 14:35:
[..]
Ik weet intussen van 2 matige oplossingen om het gat tussen code en model/document te verkleinen.
1) UML -> code en code->UML. Maar persoonlijk vind ik UML dat meteen te vertalen valt naar code net zo interessant als de code zelf en zie ook de meerwaarde hier niet van in. Alleen om het duidelijk te maken naar anderen (of jezelf) of om hogerop in je ontwerp te gebruiken vind ik UML een toegevoegde waarde hebben, maar niet als UML op hetzelfde abstractie nivo zit als je code.
2) MDA -> Model driven architecture. Aan de hand van modellen ga je code genereren. Het probleem aan deze modellen is dat je eigelijk vrij vast komt te zitten in de mogelijkheden van de code generatoren en van de beschikbare model-transformaties. Deze oplossing om het gat tussen code en documentatie te verkleinen vond ik zelf niet echt interesssant.
[...]

Om even op MDA in te gaan. MDA is niet echt alleen bedoeld voor code-generatie (dat is alleen een bij-product), en al helemaal niet om het gat tussen code en documentatie te dichten. Het gaat erom dat je verschillende modellen maakt door transformaties. In een normale top-down project begin je met een Platform Independent Model (PIM) waar je onafhankelijk van je middleware technologie (ok, OMG praat algemener over 'platform', maar in de praktijk betekent platform in MDA middleware) je applicatie modelleert. Daarna transformeer je dat model naar een Platform Specific Model (PSM) waarbij je abstractie-niveau lager komt te liggen en je keuzes wat betreft het platform maakt. Tenslotte maak je een Platform Specific Implementation (PSI): je code.

MDA legt niet vast hoe die transformaties moeten verlopen. Het is best mogelijk om ze compleet ad-hoc handmatig te doen, of half met een tool (a la skeleton generatie van Rose), of compleet (toekomstmuziek). In de praktijk wordt MDA in het bedrijfsleven alleen gezien als code-generatoren, maar dit is dus niet waar (en als je er zo over denkt dan is je 1) eigenlijk hetzelfde, omdat in de praktijk een MDA model een verzameling UML diagrammen is).

Het is overigens zo dat als je een goede code generator gebruikt dat je zelf je model-transformaties moet kunnen definieeren, dus je zit niet echt vast aan je code generator. Ik zou misschien wel zo ver kunnen gaan om te beweren dat het een essentiele eis van een bruikbare code generator is. En ja, deze aanpak betekent dat het maken van je transformatie specificaties een belangrijk iets wordt. Een stukje implementatie verschuift naar een hoger abstractieniveau.

Eigenlijk brengt MDA niet echt iets nieuws: het abstract beginnen en dmv refinement steeds concreter worden was al een best-practice. En het code-generatie gedeelte bestond in de praktijk ook al: het automatisch genereren van proxies, stubs en skeletons bestaat al een tijdje. Met MDA wordt het allemaal alleen wat concreter vastgelegd, en krijg je wat meer UML profiles die je kunt gebruiken om je applicaties abstracter te beschrijven (maar ook UML 2.0 zelf brengt hier verbetering in).

[Alarmnummer]

CubicQ schreef op 20 August 2003 @ 11:53:
[...]


Om even op MDA in te gaan. MDA is niet echt alleen bedoeld voor code-generatie (dat is alleen een bij-product)

Codegenerators (of Model generators) zijn een essentieel onderdeel aan MDA.

The MDA process may look suspiciously much like traditional development. However, there is a crucial difference. Traditionally, the transformations from model to model, or from model to code, are done mainly by hand. Many tools can generate some code from a model, but that usually goes no further than the generation of some template code, where most of the work still has to be filled in by hand.

In contrast, MDA transformations are always executed by tools

uit
Addison Wesley - MDA Explained. The Model Driven Architecture

en al helemaal niet om het gat tussen code en documentatie te dichten. Het gaat erom dat je verschillende modellen maakt door transformaties.

Ik wil niet zeggen dat dat het meest belangrijke onderdeel is aan MDA, maar het is zeker geen onbelangrijk onderdeel.

Een MDA-model zit op een hoger abstractie nivo zoals dat bij papieren documentatie van een systeem ook het geval is. Een nadeel aan een passief onderdeel als papieren documentatie is, dat als code eenmaal is geschreven de documenten niet meer worden bij gewerkt. Een MDA-model is een actief onderdeel in je ontwerp en iedere wijziging in het model zal ook leiden tot een wijzing in de code (andersom kan trouwens in sommige gevallen ook)

MDA legt niet vast hoe die transformaties moeten verlopen. Het is best mogelijk om ze compleet ad-hoc handmatig te doen, of half met een tool (a la skeleton generatie van Rose), of compleet (toekomstmuziek). In de praktijk wordt MDA in het bedrijfsleven alleen gezien als code-generatoren, maar dit is dus niet waar (en als je er zo over denkt dan is je 1) eigenlijk hetzelfde, omdat in de praktijk een MDA model een verzameling UML diagrammen is).

Het is overigens zo dat als je een goede code generator gebruikt dat je zelf je model-transformaties moet kunnen definieeren, dus je zit niet echt vast aan je code generator. Ik zou misschien wel zo ver kunnen gaan om te beweren dat het een essentiele eis van een bruikbare code generator is. En ja, deze aanpak betekent dat het maken van je transformatie specificaties een belangrijk iets wordt. Een stukje implementatie verschuift naar een hoger abstractieniveau.

Eigenlijk brengt MDA niet echt iets nieuws: het abstract beginnen en dmv refinement steeds concreter worden was al een best-practice. En het code-generatie gedeelte bestond in de praktijk ook al: het automatisch genereren van proxies, stubs en skeletons bestaat al een tijdje. Met MDA wordt het allemaal alleen wat concreter vastgelegd, en krijg je wat meer UML profiles die je kunt gebruiken om je applicaties abstracter te beschrijven (maar ook UML 2.0 zelf brengt hier verbetering in).

Ik heb er in de praktijk eigelijk nog helemaal niets mee gedaan, en heb alleen het boek gelezen zodat ik in ieder geval lichtelijk weet wat de term MDA eigelijk inhoud. En verder ging in in mijn 1e reply om de klassieke document driven aanpakken die gebruikt worden, en hoe MDA hierin een uitzondering vormde door de documenten een actief onderdeel te laten zijn binnen het ontwerp proces.

Mijn 'veroordeling' van MDA is denk ik ook iets uit zijn context getrokken.

[ Voor 7% gewijzigd door Alarmnummer op 20-08-2003 12:22 ]

[CubicQ]

Alarmnummer schreef op 20 August 2003 @ 12:12:
[...]

Codegenerators (of Model generators) zijn een essentieel onderdeel aan MDA.

uit
Addison Wesley - MDA Explained. The Model Driven Architecture

En omdat iets in een boek staat is het waar? Ik kan ook wel documenten aanwijzen waarin staat dat het geen essentieel onderdeel van MDA is, mijn eigen afstudeerverslag bijvoorbeeld Of iets toegankelijker, de MDA Guide van OMG. Maar het is wel zo dat je in de praktijk tools voor je transformaties wil gebruiken, met de hand is gewoon niet praktisch. Net als dat je in de praktijk ook een IDE wilt gebruiken of iig een compiler bij programmeren, maar dat betekent niet dat wetenschappelijk gezien programmeren zonder compiler ook wel kan: handmatig omzetten van bijvoorbeeld C-code in op-codes is best mogelijk. (nu is die vergelijking misschien een beetje flauw, maar wel vrij relevant, in het verleden was het soms gewoon beter om met de hand asm te schrijven doordat CPU power duur was en compilers relatief slecht, dezelfde situatie heb je nu: modelcompilers leveren in z'n algemeen nu nog geen code op die te vergelijken is met handmatig geschreven code)

Het probleem is dat nu eigenlijk nog niemand echt een goed idee heeft van wat MDA nou is, ook OMG niet. Dus iedereen heeft zijn eigen interpretatie, ook ik.

[...]
En verder ging in in mijn 1e reply om de klassieke document driven aanpakken die gebruikt worden, en hoe MDA hierin een uitzondering vormde door de documenten een actief onderdeel te laten zijn binnen het ontwerp proces.

Ah, ok, duidelijk. Maar dat is toch eigenlijk het geval binnen elke aanpak die round-trip-engineering gebruikt?

[Alarmnummer]

CubicQ schreef op 20 augustus 2003 @ 13:06:
[...]


En omdat iets in een boek staat is het waar?

yep

Ik kan ook wel documenten aanwijzen waarin staat dat het geen essentieel onderdeel van MDA is, mijn eigen afstudeerverslag bijvoorbeeld

Ik hoop dat die niet in boekvorm beschikbaar is

Het probleem is dat nu eigenlijk nog niemand echt een goed idee heeft van wat MDA nou is, ook OMG niet. Dus iedereen heeft zijn eigen interpretatie, ook ik.

Het beeld dat ik van het addison en wesley boek heb, is hetzelfde als jij hierboven hebt beschreven. Ik kan me voorstellen dat in de 'details' er een groot verschil van mening kan ontstaan, maar in grote lijnen valt er toch niet zoveel anders te intepreteren?

Ah, ok, duidelijk. Maar dat is toch eigenlijk het geval binnen elke aanpak die round-trip-engineering gebruikt?

Yep.. maar hoeveel andere round-trip technieken zijn er nog meer?