[VB] Ontwikkelmethodiek voor kleine projecten *

[Verwijderd]

Voor me stage bedrijf moet ik een advies schrijven voor een ontwikkel methode die ze hier kunnen gaan gebruiken.

Ze hanteren op dit moment geen enkele methode en ze ontwikkelen in VB.

Ze ontwikkelen relatief kleine applicaties, dus een Iteratieve of Incrementele methode is niet zo heel noodzakkelijk. Daarom kwam ik terug op een oude vertrouwde waterval methode, SDM.

Omdat ze in VB ontwikkelen, want (bijna) OO is, wou ik als Techniek UML hanteren. Nu ben ik er nog niet helemaal uit of dit haalbaar is.

Graag zou ik jullie mening willen horen hier over, of dat jullie er zelf ervaring mee hebben.

Ook ben ik benieuwd of er mensen zijn met goede informatie over OMT en XP.

[Spider.007]

Dit lijkt mij een programmeertopic wat beter tot zijn recht komt in PW, nu met gratis titeledit

[ontwikkelen] SDM met UML > [VB] Ontwikkelmethodiek voor kleine projecten *
SA > PW

[Alarmnummer]

Verwijderd schreef op 27 april 2004 @ 10:06:
Voor me stage bedrijf moet ik een advies schrijven voor een ontwikkel methode die ze hier kunnen gaan gebruiken.

Ze hanteren op dit moment geen enkele methode en ze ontwikkelen in VB.

Ze ontwikkelen relatief kleine applicaties, dus een Iteratieve of Incrementele methode is niet zo heel noodzakkelijk.

Tenzij het hele kleine applicaties en tooltjes zijn zie ik niet in waarom een iteratieve methodiek niet handig zou zijn. Je geeft per iteratie aan wat je wilt bereiken (dus een aantal onderdelen aan het systeem afronden). Verder is het voordeel van iteratieve development dat je iedere feedback krijgt vanuit de praktijk. De gebruikers zien de applicatie en gillen wel als het toch niet is wat ze willen, maar je krijgt ook feedback over allerlei kwaliteitsattributen van het ontwerp zoals performance. Dus tenzij het echt hele kleine tooltjes en applicaties zijn van handje vol regels zie ik niet in waarom iteratief niet handig zou zijn.

Omdat ze in VB ontwikkelen, want (bijna) OO is, wou ik als Techniek UML hanteren. Nu ben ik er nog niet helemaal uit of dit haalbaar is.

Hmm tja. Ik ben niet thuis in vb dus ik weet niet wat oo technisch allemaal haalbaar is.

Ook ben ik benieuwd of er mensen zijn met goede informatie over OMT en XP.

OMT ken ik niet. XP is leuk maar is een beetje overhyped imho en verder stoor ik me aan de X uit XP (eXtreme). Iedere vorm van extreem kan per definitie niet goed zijn. Projecten zijn er in 10.000 vormen en maten en heb je toch meestal methodiek-oplossingen op maat en kun je niet alles tot in het extreme doorvoeren. Kijk verder ook naar RUP (Rational Unified Proces). Verder kun je veel onderdelen van XP ook perfect gebruiken bij andere methodieken hoor, zoals patterns, testing, refactoring, pair programming etc.

[ Voor 10% gewijzigd door Alarmnummer op 27-04-2004 10:51 ]

[Verwijderd]

Iteratief is in mijn mening niet nodig, omdat het bedrijf projecten uitvoerd met klanten. Voor een project wordt indien nodig een applicatie ontwikkeld die dit project ondersteunt.

Echter een klant gaat niet werken met de applicatie. Met de klant worden eisen aan het project gesteld niet aan de applicatie.

Gebruikers zijn niet aanwezig tijdens de ontwikkeling, want die worden in een later staduim pas ingehuurd (randstad ofzo) als het project start. De ontwikkelaar is ook een gebruiker eigenlijk. Dus communicatie met gebruiker is er niet.

Vandaar dat ik denk dat SDM als methode geschikt is. Maar omdat er in VB wordt ontwikkeld zie ik UML wel als techniek zitten. Weet alleen niet hoe dit in de praktijk uit zal pakken

[cavey]

voor kleine projecten is RAD/JAD/IAD uitermate geschikt.

SDM, waterval methode, voel je je wel goed? Dat is voor grote complexe projecten wel goed te doen... Analyse, implementeren, testen, plus de rest van het v-model......... integratie tests, applicatie test, acceptatie test...

RAD zie je meteen hoe of wat, direct feedback etc... en werkt prima met omt/uml

[edit]
ow, geen gebruikers aanwezig.. Hrmz....... hoe weet je dan wat je maken moet?

die gebruikers moeten er iig zijn ^_^

[ Voor 15% gewijzigd door cavey op 27-04-2004 11:20 ]

[Alarmnummer]

komakeef schreef op 27 april 2004 @ 11:19:
voor kleine projecten is RAD/JAD/IAD uitermate geschikt.

SDM, waterval methode, voel je je wel goed? Dat is voor grote complexe projecten wel goed te doen... Analyse, implementeren, testen, plus de rest van het v-model......... integratie tests, applicatie test, acceptatie test...

Uhh.. waterval methode voor grote projecten?? Voel jij je wel goed? Waterval moet je daar juist absoluut niet toepassen omdat er veel complexiteit en onduidelijkheden vaak nog zijn. Dingen die pas tijdens het ontwikkelen en testen ontdekt worden, worden niet meer gereflecteerd binnen het ontwerp. Dat is juist de kracht van iteratieve development. Je ziet dat er iets niet goed gaat, je kunt het ontwerp nog aanpassen. Als je dat krijgt bij de waterval methode dan heb je het volledige ontwerp al gemaakt en is het erg vervelend om die (en alle planningen die daarbij horen) weer aan te passen. Waterval is dus not done voor grotere projecten. Verder is er bij grote projecten ook een grotere kans dat er changes in the requirements komen. Bij de waterval methode heb je dan een enorm probleem. Bij een iteratieve methode veel minder omdat je niet alles tot in de kleinste details hebt uitontworpen.

RAD zie je meteen hoe of wat, direct feedback etc... en werkt prima met omt/uml

Ik heb altijd het gevoel dat er bij echte RAD omgevingen tot kwalitatief minder goeie producten uit de bus komen. Te veel wordt de nadruk gelegt op het snel in elkaar slepen van een applicatie en geen rekening gehouden met problematiek die kan optreden. Hoe ga je om met fouten? Hoe zit het met de performance? Hoe zit het met de onderhoudbaarheid? Als een project een kans van slagen wil hebben dan kan je dit niet negeren.

[Verwijderd]

Waterval methode is idd niet geschikt bij grote langdurige projecten.

Omdat het om relatief kleine applicaties zijn, de eisen van te voren bekend zijn is een waterval methode hier wel geschikt (lijkt mij). Van SDM wil ik dan een lichtere methode samenstellen. Door niet alles uit te voeren.

Nog een vraag, wat voor modellen worden er gebruikt bij RUB en IAD? of wordt daar helemaal niks gemodelleerd?

[jeroendevries]

Ik zou gaan voor de IAD methode. Iteratief development methode..

zoek maar op google.

[whoami]

RAD is imo geen methodiek om applicaties te ontwikkelen.
Onder ontwikkel-methodiek versta ik het gehele proces van analyse/design/programmatie/testen.

RAD is een manier om de UI van een applicatie in elkaar te klikken, niet meer en niet minder.

[farlane]

Alarmnummer schreef op 27 april 2004 @ 11:29:
Uhh.. waterval methode voor grote projecten?? Voel jij je wel goed? Waterval moet je daar juist absoluut niet toepassen omdat er veel complexiteit en onduidelijkheden vaak nog zijn.

Het is alleen de vraag of je de klant ook zover krijgt: die zijn vaak gewend aan die werkzijze en zijn niet altijd bereid om die 'zomaar' te wijzigen.

Ik heb altijd het gevoel dat er bij echte RAD omgevingen tot kwalitatief minder goeie producten uit de bus komen. Te veel wordt de nadruk gelegt op het snel in elkaar slepen van een applicatie en geen rekening gehouden met problematiek die kan optreden.

Daar kan ik het alleen maar helemaal mee eens zijn. Het is met dat soort pakketten wel degelijk mogelijk om goede produkten af te leveren, maar omdat er erg veel onervaren ontwikkelaars met zo'n pakket toch wel 'iets' in elkaar kunnen klikken krijgt het een slechtere naam dan eigenlijk nodig is. Volgens mij zijn we allemaal op dat punt geweest trouwens, het duurt alleen te lang voordat je merkt dat je pruttel hebt geproduceert. En daar zit je dan mooi mee opgescheept.

[Verwijderd]

Maar hoe zien jullie de constructie SDM met UML zitten?

[Verwijderd]

RAD is imo geen methodiek om applicaties te ontwikkelen.
Onder ontwikkel-methodiek versta ik het gehele proces van analyse/design/programmatie/testen.

RAD is een manier om de UI van een applicatie in elkaar te klikken, niet meer en niet minder.

RAD omvat 4 fasen:

Projectplanning
Application Design
Application Construction
Implementation

RAD omvat dus wel degelijk het hele traject van analyse tot oplevering.

RAD is met name geschikt als je een team hebt waarin projectleiders, gebruikers, ontwikkelaars erg nauw samenwerken, het legt de nadruk vooral op snelheid.
Dit heeft niet altijd het beste resultaat als gevolg, het ligt vooral aan de mate van commitment van je team.

Het grote voordeel van RAD is dat ontzettend veel papierwerk wordt overgeslagen (of het moet zijn dat je een papiermonster bent dan adviseer ik (B)IDO ) en al vrij snel dus gaat ontwikkelen.

Misschien zijn neefmethoden als IAD of LAD ook wel interessant

[Verwijderd]

Alle RAD varianten zijn niet hanteerbaar als je niet intensief samenwerkt met de gebruikers! toch?

Als die er niet zijn, dan is RAD en varianten IAD, LAD, DSDM niet handig.

[Verwijderd]

In principe niet omdat je constant feedback moet ontvangen van de gebruiker (Prototyping!). Heb je geen gebruikers tot je beschikking die feedback geven dan moet je met name het analyse gedeelte erg uitgebreid beschrijven (functioneel ontwerp) om zo evt. problemen die ander door gebruikers aan het licht zouden komen te ondervangen.

[bigbeng]

Ik zie dat idee van je wel zitten. Dat wil zeggen, mits ze VB op een OO manier gebruiken. Het is namelijk wel bijna OO, maar alleen als je het op die manier gebruikt.
Als hun manier van programmeren is een Form maken, mik en klik de objectjes erop en een knop waarmee je vervolgens alles afhandelt, dan kun je UML-en tot je een ons weegt, maar dan gaat dat niet aansluiten.

Ik heb met SDM gewerkt en het enige grote nadeel is dat als je het op de letter volgt het enorm moeilijk is om in een later stadium nog wijzigingen te maken aan het ontwerp. Maar goed, je hoeft natuurlijk niet alles te gebruiken.
Dat geldt ook voor UML trouwens.

[Verwijderd]

bigbeng schreef op 27 april 2004 @ 18:02:
Ik zie dat idee van je wel zitten. Dat wil zeggen, mits ze VB op een OO manier gebruiken. Het is namelijk wel bijna OO, maar alleen als je het op die manier gebruikt.
Als hun manier van programmeren is een Form maken, mik en klik de objectjes erop en een knop waarmee je vervolgens alles afhandelt, dan kun je UML-en tot je een ons weegt, maar dan gaat dat niet aansluiten.

Ik heb met SDM gewerkt en het enige grote nadeel is dat als je het op de letter volgt het enorm moeilijk is om in een later stadium nog wijzigingen te maken aan het ontwerp. Maar goed, je hoeft natuurlijk niet alles te gebruiken.
Dat geldt ook voor UML trouwens.

Ze gebruiken VB op een OO manier!

Ben zo ie zo van plan om SDM niet tot de letter op te volgen, maar op een redelijke wijzen aan passen zodat hij beter toe pasbaar is binnen dit bedrijf!