Perl omzetten naar Java

[KopjeThee]

Ik heb als opdracht (asap) een hele globale inschatting te maken van de hoeveelheid tijd die nodig is om stukken perl script om te zetten in Java (dit staat niet ter discussie). Het gaat om een hele berg code (schatting zou best op een jaar kunnen en mogen uitkomen). Ik heb er nog niet in detail naar gekeken en weet alleen globaal wat het doet. Verdere verfijning van de schatting komt natuurlijk bij het verder uitwerken van de planning. Men is nu met name geinteresseerd om asap de orde van grootte van deze opdracht te bepalen.

Ik zoek eigenlijk een lijst van belangrijke aandachtspunten, zoals:

• Complexiteits maten: regels code, cyclomatic complexiteit
• Kwaliteit documentatie (ook het commentaar in de code)
• Gebruik van conventies
• Gebruik van modules die niet eenvoudig na te maken zijn. Hoe bepaal ik dat?
• Etc.

Dat zijn allemaal dingen die ik vrij snel kan bepalen, omdat het vrij oppervlakkig is.

Dan zoek ik nog een methode om alles wat ik heb gezien te vertalen naar uren (dagen, maanden). Ik denk aan iets van: Een complexiteitsmaat vermenigvuldigd met een of andere factor. Die factor hangt dan af van wat de verdere staat van de originele code is (documentatie, conventies, etc.).

Hebben jullie nog ideeen om snel een globale schatting te geven?

[P_de_B]

http://www.functiepuntanalyse.nl/ ?

Dit is niet iets wat je even snel doet, zeker niet als je minder ervaren bent in het maken van schattingen. Voordeel voor jou is dat je weet wat je moet maken, immers er is een bestaande applicatie die 1-op-1 over kan. Maar ook dan kun je geen schatting voor een hele applicatie maken, je zult het in kleine stukjes moeten opknippen en die gaan schatten. Sowieso ben je geneigd om snel te laag te schatten, neem dat zeker mee in je achterhoofd.

Let er wel op dat wat jij noemt als schatting direct als waarheid wordt beschouwd. Even snel een schatting maken voor een project van enkele tonnen is best risicovol, er is een reële kans dat jij of het development-team worden afgerekend op deze initiële schatting.

[KopjeThee]

P_de_B schreef op zondag 25 september 2011 @ 09:49:
http://www.functiepuntanalyse.nl/ ?

OK, hier haal ik in ieder geval uit dat het aantal verbindingen met andere andere systemen ook een belangrijk punt is. Die zijn ook eenvoudig vast te stellen.

Verder lijkt ook hier het behoorlijk natte vinger werk om punten om te rekenen naar uren.

Het opdelen in stukken doe ik sowieso.

Bedankt voor de tip.

[voodooless]

Ga je code 1:1 overzetten, of ga je het blackbox omzetten, dus enkel zorgen voor de zelfde functionaliteit aan de buitenkant? Dat is nogal relevant voor het schatten van je uren.

[leuk_he]

P_de_B schreef op zondag 25 september 2011 @ 09:49:
http://www.functiepuntanalyse.nl/ ?

Even afgezien van de andere punten die je al aanhaalt , en dat je relatief meer overhead zult hebben dat de bouw (project management, testen, implementatie), is de vraag hoeveel een functiepunt in uren kost toch een belangrijk punt. 0,5 uur of 1,5 uur is immers een factor 3. En het zijn toch vooral de uren die tot de prijs leiden.

Maar het is een betere kapstok dan zomaar "een jaar" te noemen, het is in ieder geval te onderbouwen.

Dat is toch vooral een ervarings verhaal. ( bestaat je ontwikkel team uit juniors, of juist erg senior mensen enzo).

[Bigs]

voodooless schreef op maandag 26 september 2011 @ 10:07:
Ga je code 1:1 overzetten, of ga je het blackbox omzetten, dus enkel zorgen voor de zelfde functionaliteit aan de buitenkant? Dat is nogal relevant voor het schatten van je uren.

Dit.. in mijn ervaring komen dit soort projecten meestal neer op een complete rewrite. Door niet naar de code maar de functionaliteit te kijken kun je de hoeveelheid werk waarschijnlijk eenvoudiger inschatten.

Er zijn echter wel veel dingen om rekening mee te houden, de schatting wordt natuurlijk een ander verhaal als de code gekoppeld is aan andere systemen die rekenen op bepaalde quirks uit de oude code.