Feeds:
Berichten
Reacties

Archive for januari, 2007

Het is weer enige tijd geleden sinds mijn vorige blog.
In de tussenliggende periode is er een reactie binnen-
gekomen en dat heeft me gestimuleerd de draad weer
op te pakken. Bovendien blijkt uit de statistieken dat
mijn blog een redelijk aantal bezoekers trekt
(om precies te zijn: 268).

Ik wil je daarom aanmoedigen mijn blog te blijven
bezoeken en vooral te reageren en je mening te geven.
Zo ontstaat er een dynamiek waar iedereen van kan leren.

Vandaag wil ik dieper ingaan op Quality Assurance voor
software, omdat er in de software wereld enkele hardnekkige
misverstanden hierover bestaan.

Zo verwarren veel software professionals en managers testen
met quality assurance. Niets is echter minder waar en een
grotere misvatting is ondenkbaar.

Om een en ander toe te lichten volgt hieronder de z.g.
kwaliteitsmeter.

q-meter.jpg

De kwaliteitsmeter geeft op heldere wijze weer wat onder quality
assurance (QA) verstaan moet worden en laat duidelijk zien dat
QA begint waar quality control (QC) eindigt.

Gaat het er bij QC om de lekken in je proces op te sporen en te
dichten, bij QA draait alles om preventie en de creatie van meer-
waarde. Dit zijn twee wezenlijk verschillende strategien.

Zoals uit de illustratie blijkt kom je met QC in het beste geval tot
zero defects (wat natuurlijk niet realistisch is). Maar Six Sigma
bijvoorbeeld komt tot maximaal 3,4 dpmo (defects per million
oppurtunities).

Dit is natuurlijk een geweldige prestatie. Reken uit met hoeveel
je je kosten terugdringt wanneer je slechts 3,4 fouten per miljoen
mogelijkheden op een fout maakt. En wat betekent het voor je
doorlooptijd: je behoeft immers minder tijd aan het opsporen en
corrigeren van fouten te besteden. En wat betekent het voor je
winst en je concurrentie positie?

Wat je echter niet mag vergeten is dat QC achteraf wordt toegepast
op bestaande processen die identieke producten voortbrengen.

Neem bijvoorbeeld de auto industrie waarbij van hetzelfde model van
een auto honderdduizenden identieke exemplaren moeten worden
gefabriceerd.

Sta je echter voor de uitdaging een compleet nieuw model te
ontwerpen dan heb je weinig aan QC. En hiervan is sprake bij
het ontwerpen van software.

Elk softwareproject is uniek, met een unieke set specificaties.
In software ontwikkelen we NOOIT twee keer hetzelfde systeem.
Daar hebben we in onze industrie het COPY commando voor.

Bij QA draait het om preventie – het inbouwen van voor-
zieningen in je proces om fouten te voorkomen.

In een van mij vorige logs hebben we het er over gehad: 94%
van alles wat fout gaat in organisaties is toe te schrijven aan het
systeem (het geheel van processen) en slechts 6% aan mensen.

Laat me het concreter maken: voor andere i.c. betere resultaten
moeten we onze processen veranderen. Hoe meer tijd je aan testen
in je softwareprojecten besteedt, des te minder AQ activiteiten er
in je proces zijn ingebouwd. Anders gezegd: testen is de graadmeter
voor de QA gehalte van je proces of QA is de tegenpool van testen.

De logische vraag die je nu hebt is ongetwijfeld:

Hoe realiseer je dit bij het ontwikkelen van software?

Goede vraag en het antwoord krijg je in mijn volgende blog.
Wat ik je echter nu al kan verklappen is dat het om slechts een
ding draait: betere specificaties.

Over dit onderwerp wil ik enkele revolutionaire en schokkende
inzichten met je delen. Kijk dus uit naar mijn volgende blog en ….
laat me weten wat je tot nog toe van mijn ideeen vindt.
Vindt je ze waardevol en moet ik hiermee doorgaan?
Je reacties zijn een extra stimulans om meer van mijn
tanden te laten zien.

Groet,
“Black Belt” Kelly
Certified Black Belt QFD facilitator
directeur Coherent Systems
kwg@coherentsystems.nl

Advertenties

Read Full Post »