[Alg] Doelstelling verbetertraject ontwikkelproces *

[Verwijderd]

Voor een bedrijf gaat ik het software ontwikkelproces onder de loep nemen. Als vergrootglas wordt het Capability Maturity Model gebruikt.

Op basis van de uitkomst zullen er één of meerdere verbetertrajecten gestart worden om een aantal zwakke punten aan te pakken. Voor dit laatste staat een doorlooptijd van 7 weken.

Dit lijkt en is misschien ook wel vrij kort, maar omdat het bedrijf internetsites bouwt, is de doorlooptijd van een project gemiddeld 5 weken.

Het eerste resultaat van deze verbeteringen die de opdrachtgever zou willen zien, is dat de hoeveelheid bugs die nog ondekt worden nà oplevering, significant minder zal zijn (bv. 50%) na de procesverbeteringen in de pilot project.

Je voelt de bui misschien al hangen: op zo'n korte termijn is dat moeilijk te realiseren en eigenlijk onmogelijk te meten. De looptijd van de eerste verbetertrajecten is daarvoor te kort.

Nu wil ik de doelstelling aanpassen zodat deze haalbaar is, maar deze doelstelling moet wel nog een raakvlak hebben met de verbetering van de kwaliteit van het eindresultaat.

Iemand een goede insteek voor een betere doelstelling?

[demonite]

Dan "onderzoek" je toch gewoon wat langer... wat maakt jou dat nou uit.
Of pas het toe op 1 kleiner project.

[P_de_B]

"Door accountmanagers beloofde resultaten zullen worden gehaald, op of nabij het tijdstip van beloofde oplevering"

Je kunt hiermee een aantal kanten op bijvoorbeeld kennis van acc.managers moet omhoog zodat ze wensen/eisen op haalbaarheid kunnen inschatten en het plannen van projecten en mensen moet verbeterd worden.


* P_de_B heeft net hele slechte ervaringen met het opleveren van de nieuwe site

[Verwijderd]

Planning dient opgesteld te worden door degene die de realisatie uitvoeren, en dus niet door een accountmanager.

Misschien is een ontwikkelstraat wat voor je? Zie boek van Kranenburg.

[mbravenboer]

"de hoeveelheid bugs die nog ondekt worden nà oplevering, significant minder zal zijn (bv. 50%) na de procesverbeteringen in de pilot project."

Waarom vraag je om een aangepaste doelstelling en niet om middelen om die doelstelling te bereiken? Als de situatie in dit bedrijf zo rampzalig is als in te veel internet bedrijfjes is het nog best goed mogelijk dat die doelstelling met de juiste aanpak te bereiken is.

Suggesties:
- release regelmatig: zorgt een release voor bugmeldingen? release dan vaak! Tussen releases moet misschien maximaal 1 week zitten.
- gebruik een issue/bug tracking systeem
- pas unit-testing toe
- zorg voor automatische builds en release constructie
- gebruik een versie management systeem

[P_de_B]

[quote]Verwijderd schreef op 28 november 2003 @ 15:28:
Planning dient opgesteld te worden door degene die de realisatie uitvoeren, en dus niet door een accountmanager.

[quote]

Mee eens, helaas is dat een utopie in veel gevallen. Zeker als je met een groter bedrijf te maken hebt. Je raakt als klant verstrikt in een web van accountmanagers, projectleiders, technisch consultants, planners etc. Ik ben echt van mening dat veel bedrijven hier nog heel wat kunnen verbeteren.

[faabman]

P_de_B schreef op 28 november 2003 @ 18:21:
Mee eens, helaas is dat een utopie in veel gevallen. Zeker als je met een groter bedrijf te maken hebt. Je raakt als klant verstrikt in een web van accountmanagers, projectleiders, technisch consultants, planners etc. Ik ben echt van mening dat veel bedrijven hier nog heel wat kunnen verbeteren.

offtopic:
En daar komt de studie informatiemanagement voorbij zeilen

voor de TS:
een aantal overwegingen (let wel, dit zijn losse flodders, dus nofi ):
- ik heb van meerdere kanten vernomen en zelf ervaren dat het debuggen van een 'from scratch' applicatie net zo lang duurt als het ontwikkelen van de app zelf...


- lees voor het formuleren van een goede doelstelling eens het boek 'het ontwerpen van een onderzoek', verschuren & doorewaard, isbn 90-5189-886-x, op de FEE (Economische Faculteit vd UvA) vind men dat een goed boek, heb het zelf op aanraden van een medestudent van de week gekocht, dus ben nog niet echt ver met lezen, maar wat ik tot nu toe zie ziet er goed uit


- bepaal desnoods aan de hand van je huidige doelstelling een aantal subvragen en pas aan de hand van de overwegingen die je daarbij maakt je doelstelling aan (wordt volgens mij ook wel iteratie genoemd)


- nu ik je doelstelling nog eens lees vind ik hem wel heel vaag:
- bugs; wat is een bug, is dat een fout in je applicatie of een verkeerd geinterpreteerde opdracht
- significant; definieer dat eens beter, bv. 50% is geen definitie


p.s. ; misschien is dit wel geen onderwerp wat volledig thuishoort in P&W, maar ik vind het wel (lekker ouwehoeren over studievaardigheden )

[Verwijderd]

Allereerst bedankt voor alle goede response. Hier kan ik zeker wat mee!

FvKnijf,

De doelstelling zoals hij hier gesteld is, is inderdaad nogal vaag. De echte doelstelling is uitgebreider en SMART (Specifiek, meetbaar etc).

De kern van het probleem is deze: ik heb wel de middellen om de doelstelling te halen, maar ik vind het lastig om op zo'n korte termijn al een conclusie te verbinden aan de hoeveel post-release bugs. In het beste geval heb ik 4 weken om te wachten op de bugs na oplevering. En da's vrij krap.

[ Voor 3% gewijzigd door Verwijderd op 01-12-2003 09:57 ]

[ATS]

Misschien moet je dus gewoon concluderen dat je op die korte termijn niet zulke conclusies kunt trekken. Ik denk niet dat je daar onderuit gaat komen eerlijk gezegd. Als de doorlooptijd van een project een week of 5 is, dan kan heb je gewoon een periode na dat project nodig om te kunnen meten of er nog bugreports komen en hoeveel dan. Ook lijkt één project me niet echt een significante steekproef. Eigenlijk heb je eerst een nulmeting nodig (hoeveel en wat voor reports krijg je nu?) voor je uberhaupt begint, anders heb je geen formele gegevens om je resultaten mee te kunnen vergelijken, en dus kan je niet evalueren of je aanpak succes heeft gehad of niet. Stel dat je die gegevens uit archieven zou kunnen halen, dan redt je het nog niet binnen een week of tien lijkt me.

[Alarmnummer]

Zoals mbravenboer al zei, maar imho nog niet duidelijk genoeg overkwam, gebruikt unit tests om het aantal bugs omlaag te brengen. Ik gebruik het zelf ook voor mijn software, en je kan veel vroeger bugs vinden (de meeste al terwijl je de code aan het schrijven bent). Verder is het ook handig als je de unit tests gaat automatiseren door ze toe te voegen aan je build scripts.

[ Voor 14% gewijzigd door Alarmnummer op 01-12-2003 10:12 ]

[EfBe]

Alarmnummer schreef op 01 december 2003 @ 10:08:
Zoals mbravenboer al zei, maar imho nog niet duidelijk genoeg overkwam, gebruikt unit tests om het aantal bugs omlaag te brengen. Ik gebruik het zelf ook voor mijn software, en je kan veel vroeger bugs vinden (de meeste al terwijl je de code aan het schrijven bent). Verder is het ook handig als je de unit tests gaat automatiseren door ze toe te voegen aan je build scripts.

1) je software die de unittests uitvoert moet bugfree zijn. Dit lijkt een formaliteit maar is het niet, m.a.w.: kloppen je tests wel?
2) lang niet alles is via unittests te testen. Ga maar eens database transacties testen met je unittests

Verder is unittesting iets wat imho thuishoort in de categorie 'development details'. Ik geef je op een briefje dat een goed geschreven FO en TO die zijn onderbouwd met gedegen onderzoek veel en veel meer profijt brengt dan wat unittests aanbreken, want als je niet weet wat je moet testen (en dat weet je botweg niet als je GEEN gedegen ontwerp hebt) kun je wel testen maar je kunt niet bepalen of de testresultaten kloppen.

[Alarmnummer]

EfBe schreef op 01 december 2003 @ 11:29:
[...]

1) je software die de unittests uitvoert moet bugfree zijn. Dit lijkt een formaliteit maar is het niet, m.a.w.: kloppen je tests wel?

Tja.. [flauw]je kan natuurlijk ook unit tests gaan schrijven voor je unit tests :P[/flauw]. Je tests kunnen ook fouten bevatten, daar ben ik het helemaal mee eens. Maar ik spreek uit ervaring dat code met unit tests minder bugs bevat dan code zonder unit tests. Ten 1e omdat je meer gaat testen (alle interessante combinaties die tests je voor bv een methode), ten 2e omdat je de unit tests aan je scripts kan toevoegen waardoor je dagelijks je units tests kan uitvoeren, terwijl die tests misschien al maanden oud zijn. Hierdoor blijf je de code testen, terwijl het op de klasieke manier (lees: klikken en kijk of het goed gaat) manier toch maar tot enkele malen uitproberen beperkt blijft. Ten 3e is je unit test een stuk documentatie over wat een stuk code omdat je exact weet wat het gedrag ervan is. Deze kennis komt de kwaliteit ten goede omdat je beter weet wat code doet. En als laatste denk je beter na (omdat je toch alle combinaties moet uitproberen) wat je code exact moet doen.

2) lang niet alles is via unittests te testen. Ga maar eens database transacties testen met je unittests

Gelukkig is dit wel mogelijk (voor java in ieder geval). Er zijn oa een aantal db unit tests addons voor junit uit.

Maar idd, niet alles is testbaar. Een van de dingen waar ik nog steeds geen oplossing voor heb (waar ik tevreden ben) is unit tests voor de gui.

Verder is unittesting iets wat imho thuishoort in de categorie 'development details'. Ik geef je op een briefje dat een goed geschreven FO en TO die zijn onderbouwd met gedegen onderzoek veel en veel meer profijt brengt dan wat unittests aanbreken, want als je niet weet wat je moet testen (en dat weet je botweg niet als je GEEN gedegen ontwerp hebt) kun je wel testen maar je kunt niet bepalen of de testresultaten kloppen.

Helemaal mee eens. Unit testen is niet de manier om software te schrijven/ontwerpen, maar het een van de kleine dingetjes die het leven net iets plezieriger maken. En verder.. hoeveel bugs zijn vaak het gevolg van hele kleine foutjes?? (dus niet zozeer een ontwerp fout)

[edit]
Oja.. Ik ben een ander erg belangrijk gevolg van unit testen helemaal vergeten, namelijk het gevoel van de programmeur. Als alles tegen zit, en de stress is hoog, dan geeft het altijd nog een fijn gevoel om te zien: testing succesfull. Ik vind het in ieder geval erg fijn als mijn tests het doen.

[ Voor 18% gewijzigd door Alarmnummer op 01-12-2003 12:23 ]

[Alarmnummer]

*kick*

[Verwijderd]

nou even qua richtlijn werk momenteel bij een bedrijf die ook met CMM bezig is... bedrijf is zich aan het voorbereiden voor CMM lvl 2...

dit tracject loopt al meer dan 1 jaar.... dus tja 6 weken... nou dat gaat echt niet lukken!

daarnaast is CMM geen hulp middel om betere qualiteit software te leveren... CMM is een richtlijn om gestructueerd te werken! het is dus een illusie dat je met CMM bugs oplost!