DSDM: geschikt voor database-upgrade?

[pven]

Voor mijn werk moet ik een plan schrijven om databases te upgraden (van Oracle8i naar 9i). Om het wat beheersbaar te maken (het gaat om 200 databases) wil ik er een bewezen methode voor gebruiken en nu zit ik aan DSDM te denken.

quote: http://www.dsdm.nl/nl/dsdm/toepasbaarheid.asp

DSDM is goed toe te passen voor de ontwikkeling van alle mogelijke systemen. De meerwaarde van DSDM wordt echter ten volle benut bij de ontwikkeling van systemen met bepaalde kenmerken. Te noemen zijn goed visualiseerbare functionaliteit, via bijvoorbeeld schermen en rapporten. Prototypes kunnen middels deze zichtbare resultaten eenvoudig en goed geëvalueerd worden. Verder is het belangrijk dat de uiteindelijke gebruikersgroepen voor het systeem helder zijn. Dan kunnen de juiste gebruikersvertegenwoordigers worden gekozen om zorg te dragen voor de juiste prioriteiten en voor juiste aansluiting bij de huidige behoeften. Deze vertegenwoordigers, in DSDM ambassadeurs genaamd, zijn de ambassadeurs van het project in de doelorganisatie en de ambassadeurs van de doelorganisatie in het project. Tenslotte, wanneer het de ontwikkeling van een groot en complex systeem betreft, moet dit opdeelbaar zijn in kleinere en goed overzichtelijke delen die door onafhankelijke teams in kortetijd ontwikkeld en getest kunnen worden.

Om te voorkomen dat ik straks een methode voorstel die achteraf niet goed blijkt te zijn, wil ik graag weten of hier mensen zijn met DSDM-ervaring en dan uiteraard het liefst met betrekking tot een database-upgrade.

_{Uiteraard heb ik gezocht (search en Google), maar dan kom ik niet bij berichten uit waar ik iets aan heb.}

[Boss]

Wat ik over die methode lees op hun website is het vooral geschikt voor de ontwikkeling van nieuwe applicaties. In jou geval gaat het erom dat je een plan moet maken / voorstel moet doen om een migratie uit te voeren. Een migratie gaat in dit geval (upgrade van db servers) volledig buiten de gebruikers om, als het goed gaat zal er weinig voor ze veranderen.

Dus... een plan schrijven (plan van aanpak) heeft weinig te maken met DSDM.

Of ik zie niet helemaal goed wat je wilt doen

[Baarsjes]

DSDM is inderdaad meer voor ontwikkeling van nieuwe produkten, het is speciaal gericht op intensieve samenwerking met de gebruikers. Veel prototypes opleveren en samen de uiteindelijke gebruiker een goed product op te leveren.

Voor een database upgrade lijkt me dit dus nogal lastig, aangezien dit niet direct met je gebruikers te realiseren is. Ook staat je resultaat al vast (upgrade naar 9) terwijl bij DSDM juist je resultaat flexibel is en je tijd vast staat.

Verwacht wel dat er nog mensen voorbij gaan komen die gaan zeggen dat dit prima met DSDM kan, zal ongetwijfeld kunnen maar voor mij is het niet de eerste methode waar ik aan zou denken.

Verder heb ik niet zoveel ervaring met project aanpakken, alleen Prince 2 een beetje, en wat ik me daarvan kan herinerren komt dat dichter in de buurt voor wat jij ermee wilt doen. Wellicht dat je daar verder op kan zoeken.

[mkleinman]

Naar mijn weten biedt Oracle uitstekende upgrade functionaliteit wanneer je een database van 8.x naar 9.x wil upgraden. In mijn geval ( Okay maar 2 databases ) was het een kwestie van 9.2 cd erin, de Universal installer starten en gaan met die banaan

In inderdaad DSDM is meer voor het ontwikkelen van software applicaties. ( maar dat was al meerdere malen gezegd ) .

Kijk anders eens op http://technet.oracle.com of op http://metalink.oracle.com De laatste mits je hier toegang tot hebt.Hier staat zeer veel infol, ook over upgraden van databases.

[ Voor 40% gewijzigd door mkleinman op 04-10-2004 07:40 ]

[pven]

De technische kennis is geen probleem, maar we willen dit min-of-meer volgens een bewezen methode proberen te doen. De gebruikers moeten overigens testen (en dus accoord geven), anders wordt er niet ge-upgrade.

Iemand enig idee of Prince2 beter geschikt is? Dat lijkt veel meer op (kleine) projecten gericht te zijn.

_{Uiteraard wordt het op te stellen plan nog door enkele mensen gereviewed.}

[ Voor 13% gewijzigd door pven op 04-10-2004 17:42 ]

[Verwijderd]

DSDM e.d. doe je niet zo maar hoor, organisaties zijn vaak jaren bezig om het goed geimplementeerd te krijgen. Maar anyway hier wat van mijn persoonlijke ervaringen:

DSDM staat voor Dynamic System Development Methodology en is een ontwikkelmethodiek methodiek welke beschrijft hoe je bijvoorbeeld je projectgroepen inricht (wie, welke rollen wanneer uitvoert). Hier worden ook deliverables in beschreven als prototypen, development plan, timeboxplannen etc.
je kunt hier alles natuurlijk zo ombuigen dat het op jouw project van toepassing is.
het is echter neit een manier die je zo maar even toepast, de duurste kosten zijn doorgaan die van Ignorance. je zult van iedereen hoogste input moeten verwachten, ook van de mensen buiten je team, en geloof mij het is vaak heel moeilijk dit tot hun leiding gevenden door te laten dringen.

Wat je nog zult ontbreken is een stukje borging. maak plannen hoe er gereviewed moet worden en zorg dat iedereen zich hier aan houdt. Hoe er met externe (buiten jouw project) gecommuniceerd moet worden, hoe changerequests afgehandelt moeten worden etc. En zorg dat er van alles planningen bijgehouden worden, die per wijziging door gecommuniceerd worden, afgestemd en gecommitteerd(change requests) met de stackholders. etc. Communicatie en borging dus. Je zou hiervoor eens (naast DSDM) naar CMM kunnen kijken, dit is echter alleen een framework dat nog nadere invulling behoeft.

Onthoud dat je enige doel is dat je het voor elkaar krijgt dat niemand van de opdrachtgevers en stackholders straks met konijnen uit de hoed geconfronteerd wordt als je moet vertellen dat het project 3 maanden uitloopt en een 100.000 euro meer gaat kosten dan dat zij dachten. het gaat er om dat je ze van alles op de hoogte houdt en jij zeker bent dat je al je input van de juiste personen in de organisatie hebt gehad.