Calculatie van software

eehh, een duim eigenlijk.

..in combinatie met ervaring...

en desnoods wat stelpostjes.

Ik doe het met de natte vinger methode.

Reken ruim tijd zodat je je broek niet scheurt ook als het tegengaat.

Bedrijven zijn beter af als ze dit in regie laten uitvoeren want dan is dit de meest juiste kostprijs en zijn ze er meestal goedkoper van af.

Ja.. ook bij mij is die duim van toepassing. Alleen kan ik me niet voorstellen dat dit de juiste manier is..

Meestal een natte vinger inschatting voor de software * 2 (voor onvoorzien, testen, documentatie). En in de praktijk klopt dat doorgaans aardig, zolang er niet teveel 'oh-shit' momenten voorbij komen.

"zolang er niet teveel 'oh-shit' momenten voorbij komen."

als het regent druppelt het meestal ...
en je kan ook momenten hebben "when the shit hits the fan..."

Oké.. dus een nog niet zo'n ervaren programmeur zoals ik met regelmatig 'oh shit' momenten maakt met een natte vinger een calculatie en schrijft deze vervolgens met een vork?

Nee, als je nog niet zo ervaren bent heb je gewoon pech
Je presenteerd je bij je opdrachtgever als "onervaren waardoor er waarschijnlijk wat extra uren geschreven gaan worden"?

Het is toch niet zo heel erg als niet echt ieder uurtje word geschreven? Doe ik ook niet hoor.
Wat minder voor de buis hangen, en wat minder CO'en geeft niks.

Voordeel van 'minder ervaren' is doorgaans ook 'lagere uurprijs' (in elk geval voor je werkgever).

Met wat meer uren voor een lagere prijs, kom je waarschijnlijk niet eens zo beroerd uit.

Die momenten waar poep de ventilator raakt, zijn bij mij gelukkig vrij zeldzaam. Maar inderdaad, het komt wel eens voor. Da's dan pech voor de opdrachtgever (er komen meer uren uit; goed onderbouwen) of voor je werkgever (fixed-price).

Oh-shit momenten komen wat vaker voor, maar doorgaans is dat wel te overzien (dat calculeer je voor een deel in).

Verder is het bij een dergelijke inschatting belangrijk dat je de materie overziet. Als er een hoop 'vage stukken' in zitten (ben nu zelf met zo'n fijn projectje bezig...), zul je in de offerte wat op moeten nemen over meerwerk indien bla bla.

Al met al blijft het toch een kwestie van ervaring (wat het schatten betreft) en ervaring in het leren herkennen van stukken die tijd gaan vreten.

Verder heeft GJ_ natuurlijk ook gelijk. Als ik ergens een planning op afgeef en ik blijk wat te krap geschat te hebben, werk ik ook wel eens een pauze door of zit ik thuis nog even een paar uur te klussen. Dat is m'n eigen inschattingsfout, dus ook mijn probleem.
Ik zit tenslotte ook wel eens in de tijd van de baas wat te internetten...

Ja inderdaad een pauze doorwerken is ook voor mij geen enkel probleem als dit bijdraagt aan het project. En natuurlijk probeer ik wat thuisstudie te doen zodat het e.e.a binnen de perken blijft. Dit is tenslotte ten gunste van mijn persoonlijke ontwikkeling in dit vakgebied.

Dat is de goede instelling(althans zo doe ik het ook),tijd tekort=thuis wat doen, tijd over= co bekijken en wat bijleren.

Belangrijkste is om vooraf een zo nauwkeurige omschrijving te krijgen (op papier) van wat de software precies moet doen, voor je een kostenopgave moet doet. Nooit beginnen als je alleen weet "Als er iets gebeurt aan de ingangen moet er wat bij de uitgangen hoog worden".
Vaak vinden klanten het niet leuk om alles te moeten specificeren, maar het moet nu eenmaal...
(Anders krijg je naar afloop te horen "Dit is niet wat ik eigenlijk had bedoeld...")
Verder gewoon alles nalopen, en kijken of je ergens problemen verwacht.

software word toch altijd anders geleverd:

schrijf het heel crapy, als het de klant niet voldoet , schrijf je een nieuwe , iets minder crapy.

noem dat tweede programma een update , en laat je klanten betalen voor een update.

Ik deel meestal de software op in kleine delen. Per onderdeel kun je dan wel inschatten hoe lang je erover doet en welke onderdelen nog uitzoekwerk zijn. Met deze methode kan ik (achter gezien) akelig nauwkeurige ramingen afgeven.

Op 7 november 2007 23:37:24 schreef shiptronic:
software word toch altijd anders geleverd:

schrijf het heel crapy, als het de klant niet voldoet , schrijf je een nieuwe , iets minder crapy.

noem dat tweede programma een update , en laat je klanten betalen voor een update.

Eh... We werken niet allemaal voor Microsof hoor...

Bedankt voor de reakties.

Wat voor tools gebruiken jullie om een stukje software om te zetten naar leesbare taal voor een klant en om de evt calculatie te realiseren.
Ik maak namelijk meestal een flowchart in visio welke ik vervolgens kan bespreken met opdrachtgever en waarmee ik de software kan opdelen in kostenposten.
Het is alleen redelijk omslachtig (veel handelingen!) om met visio een grafset te realiseren.

Hebben jullie suggestie voor bovenstaande?

Alvast bedankt.

Dat doe ik gewoon in CAD. Ik heb hiervoor een aparte symboolbibliotheek aangemaakt.

Ofwel.. Wat voor tools gebruiken jullie om een calculatie te maken voor besturingssoftware?

door ervaring, materiaalkosten zijn uiteraard te berekenen in excel.

software door het aantal uren bij te houden van vorige projecten en altijd een reserve calculeren en steeds ieder project als "nieuw" benaderen.

veel op papier laten vastleggen door de klant, maar ook weer niet teveel , dat kan dan later als meerprijs doorgerekend worden.

denk eraan dat microcontroller geralteerde projecten nog de ontwikkeling en uitvoering van de pcb bij komen !

Eh... We werken niet allemaal voor Microsof hoor...

en eeuuh, µc en plc software projecten moeten anders benaderd worden dan pc.

plc hangt men bijna altijd af van de "mekaniekers".
toffe lui, maar niet software minded

pc is meestal database, webdesign, poortje aansturen.
veel meer "hobby" ondersteuning aanwezig op het internet dan plc.

pc hangen er ook meestal minder veiligheidsredenen aan vast.

[Bericht gewijzigd door shortcircuit op zaterdag 10 november 2007 17:31:56 (28%)]