Feeds:
Berichten
Reacties

Archive for augustus, 2006

Vandaag gaan we het hebben over Quality Control en Quality Assurance.
QC en QA zijn de twee enige kwaliteitssytemen die er bestaan en zijn of
onbekend of onbegrepen in de software wereld.

QC en QA is basiskennis voor elke CIO, elke software manager, elke project
manager en iedereen die leiding geeft aan of betrokken is bij initiatieven
om het softwareproces te verbeteren.

Neem bijvoorbeeld Quality Assurance. In de softwarewereld wordt testen
vaak met quality assurance verward. Niets is verder van de waarheid.

Zonder deze kennis loop je het risico een verkeerde weg in te slaan, te weinig
voor je investering terug te krijgen of dat de buitenwereld c.q. je klanten aan
het eind van het traject niets van je verbeteringen merken.

Om je softwareproces te kunnen verbeteren veronderstelt diepgaande kennis
van hoe je een proces meet, hoe je de meetgegevens interpreteert en welke
acties je op grond van deze interpretatie moet nemen. Hiervoor zijn de volgende
tools onontbeerlijk:

  1. de process behaviour chart,
  2. het ishikawa diagram,
  3. de pareto chart en
  4. de flowchart.

Ik ben er bijna zeker van dat je van deze tools alleen de flowchart en misschien
het ishikawa diagram (ook wel de fishbone of cause & effect diagram) kent.

Zonder de process behaviour chart bijvoorbeeld kunnen je acties zelfs
averechts werken en in mijn volgende weblog zal ik hier dieper op ingaan.

Het verbeteren van het proces dat de specificaties moet opleveren is weer een
ander verhaal. Hier heb je additionele kennis en een andere set tools nodig.

Quality management is een vak, zoals software engineering, en om het te
beheersen heb je kennis nodig. Deze kennis verkrijg je alleen door serieuse studie.
En deze studie is geen onderdeel van een opleiding tot software engineer, of
(software) manager.

Laten we nu van start gaan met Quality Control.

Wat is quality control?

Het ontstaan van QC voert terug tot rond 1920 met een opdracht van de Raad van
Bestuur van Bell Labs aan Dr. Walther Shewart. Bell Lab produceerde in die dagen
(de eerste) telefoon toestellen.

Waarom kreeg Dr. Shewart deze opdracht?

De kwaliteit van deze toestellen liet veel te wensen over en dat leidde tot
torenhoge productiekosten en ontevreden klanten. De reden? Omdat Bell
Lab in die tijd sterk afhankelijk was van ‘after-the-fact’ maatregelen zoals
inspecties en testen om de defecte toestellen te onderscheppen en zo te
voorkomen dat ze alsnog verscheept zou worden.

Dit werd zo’n grote verliespost voor Bell Lab dat het hoogste niveau van de
ondeneming ingreep en Dr. Shewart de opdracht gaf dit probleem te
onderzoeken en op te lossen. Dit onderzoek leverde de process behaviour
chart op en dat is het begin van Quality Control (ook daar zal ik in mijn
volgende weblog meer over vertellen).

Wat ik nu wel wil zeggen is dat de process behaviour chart tot de huidige
dag van vandaag onmisbaar is voor iedereen die beoogt een proces te
verbeteren.

Ook Six Sigma maakt gebruik van dit tool. In de loop der jaren zijn er nieuwe
tools bijgekomen en ze staan bekend onder de naam Statistical Process
Control (SPC).

Enkele van deze SPC tools zijn: de eerder genoemde pareto chart, de
cause & effect diagram en de flow chart.

Het doel van QC is het reduceren van defecten (defect reduction).
Dit wordt bereikt door de oorzaak van defecten terug te traceren naar een
lek in het proces en deze te dichten. QC maakt op deze manier een eind
aan het bestrijden van symptomen en voorkomt dat dezelfde fout in een
volgend project weer gemaakt wordt.

De idee die hier achter schuil gaat is dat het veel effectiever is de oorzaak
van een defect te elimineren in plaats van het symptoom.

Wat is quality assurance?

QA is verschillend van QC. Ligt de nadruk bij QC vooral op defect reduction,
in feite het minimaliseren van negatieve kwaliteit, bij QA gaat het vooral om
defect prevention en het maximaliseren van positieve kwaliteit.

QC zet je in om bestaande processen te verbeteren. Maar hoe voorkom je
dat nieuwe producten defecten vertonen? Defecten 100% voorkomen is
onmogelijk, maar het blijkt met QA wel degelijk mogelijk nieuwe producten
te onwikkelen met een extreem laag defect gehalte.

Tot slot nog het volgende: voorbeelden van CQ systemen zijn The Deming
Method en Six Sigma.

Quality Function Deployment is tot nog toe het enige QA systeem.

In mijn volgende weblog zullen we het hebben over de tools van QC en QA
en hoe je ze in software engineering inzet.

Tot de volgende keer,
Black Belt Kelly

Advertenties

Read Full Post »

Ok, in mijn blog van gisteren heb ik je laten zien dat er een functionele afhankelijkheid bestaat tussen kosten en duur van softwareprojecten:

kosten = f(duur)

Dit betekent dat de kosten vanzelf naar beneden gaan wanneer het project in een hoger tempo wordt uitgevoerd en omgekeerd. Hiermee bedoel ik niet dat software specialisten harder moeten werken, als dat al zou kunnen. Sterker, de inzichten en concepten die ik propageer gaan er juist van uit je minder hard hoeft te werken om beter te presteren.

Ik kom zelf ook uit die wereld en weet hoe hard software engineers moeten werken.
Nee, wat ik bedoel is dat we onze aandacht moeten verplaatsen van mensen naar het proces.

Herinner je je nog de verontrustende statistic dat slechts 6% van wat er fout gaat in softwarteprojecten aan mensen toe te schrijven zijn en 94% aan het proces?

Gisteren ben ik ingegaan op de impact van de rework cycle. Als je deze kunt doorbreken boek je een forse tijdsbesparing. Hoe je dat bereikt heb ik ook laten zien: door het voorkomen van defecten. En hoe voorkom je defecten? Door de specificaties correct, compleet en actueel te krijgen. En hoe krijg je specificaties correct, compleet en actueel?

Eh…nu gaan we iets te snel. Alles op z’n tijd. Voordat ik je dat vertel, moeten we eerst een solide fundament hebben waarop we kunnen bouwen. En daar werken we nu aan.

Maar het elimineren van de rework cycle is niet de enige manier om de doorlooptijd van softwareprojecten te reduceren. Kijk bijvoorbeeld naar de volgende flowchart van het softwareproces:

sw-process-3.jpg
Deze geeft aan hoe het er werkelijk aan toe gaat in softwareprojecten. Een geheel andere flowchart dan je gewend bent te zien. Niet?

Wat deze flowchart aangeeft zijn de wachttijden in softwareprojecten. Deze zijn het gevolg van het proces en ontstaan bij elke overgang van de ene naar de andere fase.

Bijvoorbeeld: de analyse fase is afgerond en de gebruikers en het management moeten het rapport eerst goedkeuren voordat het project kan worden vervolgd. Bij grote projecten is het gebruikelijk dat de stuurgroep het ook moet bestuderen, gezamenlijk bespreken en haar goedkeuring uitspreken.

Daarna komt een volgende specialist die het op haar beurt moet bestuderen. En dit ritueel herhaalt zich bij elke fase overgang. Hoeveel tijd wordt hiermee verspeeld?

Wat in bovenstaande diagram naar voren komt en met de realiteit correspondeert is dat de rework cycle die ik gister heb geïntroduceerd, zich niet beperkt tot rework aan het eind van het traject, maar van kracht is aan het eind van elke fase.

Er zijn overigens nog meer factoren in het spel die je projecten kunnen versnellen of vertragen, maar ik wil het hier voorlopig bij laten.

Is dit enigszins herkenbaar voor je? Hoeveel sneller zouden softwareprojecten in je organisatie worden uitgevoerd, wanneer je de rework cycle en de vertragingen tussen de fasen zou weten te elimineren?

Samenvatting:

De afgelopen twee dagen heb je gelezen dat:

  1. de rework cycle en
  2. de pijlen in je flowchart

het tempo bepalen waarmee je software kunt ontwikkelen.

Elimineer beide en je verdubbelt je tempo. Gegarandeerd!
En nu meteen aan de slag.

Kelly

Read Full Post »

Gisteren heb ik op deze pagina laten doorschemeren dat het mogelijk is kosten en duur van softwareprojecten te halveren. Ik weet zeker dat je dit te mooi vindt om waar te kunnen zijn, maar nu is het moment aangebroken om deze bewering te onderbouwen.

Zoals je bekend is worden de uiteindelijke kosten voor het ontwikkelen van software bepaald door 2 factoren:

  1. de duur van het project en
  2. het uurtarief van de deelnemers

(Het feit dat meerdere mensen aan een project werken en dat hun uurtarieven kunnen verschillen doet niets af aan deze argumentatie).

kosten = uurtarief * duur

Wat gebeurt er met de kosten als de duur van het project terugloopt en het uurtarief onveranderd blijft? Uit de formule kun je eenvoudig afleiden dat de kosten van je project naar beneden gaan wanneer het tempo van uitvoering kan worden verhoogd.

Dan blijft er nog maar een vraag over: hoe versnel ik mijn projecten? Immers, deze versnelling is bepalend voor de uiteindelijke kosten en hoeveel ze teruglopen.

 

Hoe versnel je de uitvoering van je softwareprojecten?

 

 

Om tot de kern van dit probleem door te dringen is het nodig een project voor te stellen als een bepaalde hoeveelheid werk. Dit werk wordt verdeeld in discrete taken die of nog uitgevoerd moeten woren of al uitgevoerd zijn of in uitvoering zijn. Zijn alle taken goed uitgevoerd dan is het project ten einde. Zie onderstaand figuur:

rework-cycle-1.jpg

Dit figuur is opgebouwd uit twee pools en een flow. Een pool is een opslagplaats voor materie. In de pool ‘uit te voeren werk’ is alle werk opgeslagen. De flow geeft aan dat elke taak die af is van deze pool naar de pool ‘uitgevoerd werk’ stroomt. Het kraantje in de flow kan elke stand aannemen tussen open en dicht en hoe verder het wordt opengedraaid hoe sneller de pool ‘uit te voeren werk’ leegstroomt.

Dit is hoe we in de praktijk naar onze projecten kijken en hoe we ze plannen. Maar … er schuilt een giftige adder onder het gras. En deze adder is: de rework cycle.

Niet al het werk dat de pool ‘uit te voeren werk’ verlaat komt in de pool ‘uitgevoerd werk’ terecht. Was dat het geval dan was er niets aan de hand geweest. Een (fors) deel van het uitgevoerd werk komt niet door de test, gaat terug naar de pool ‘uit te voeren werk’ en genereert extra werk, een hoop frustraties en stress en … extra kosten. (zie onderstaand figuur).

rework-cycle-2.jpg

 

Wat betekent dit voor de duur en kosten?

Wat veel mensen zich niet realiseren is dat testen uit 3 subactiviteiten bestaat:

  1. detectie; om zo veel mogelijk defecten aan het licht te brengen
  2. localisatie; om de code die het defect veroorzaakt op te sporen
  3. correctie: de code te corrigeren

Zoals je ziet is de prijs die voor een defect betaald wordt onevenredig hoog:

1. eerst wordt iemand betaald om een defect te maken
2. vervolgens is er een tester nodig om het defect op te sporen
3. daarna moet iemand uitzoeken wellke code het defect veroorzaakt, en
4. vervolgens moet het defect gecorrigeerd worden

Uit het bovenstaande blijkt dat je voor elk defect niet minder dan 4 keer betaalt. Waar komt al deze verspilling vandaan?

Defecten die het gevolg zijn van incomplete, incorrecte en verouderde specificaties.

Ik weet niet of je software ontwikkelt of ooit ontwikkeld hebt, maar stel je het volgende scenario voor: je krijgt de opdracht een project uit te voeren op basis van specs die absoluut 100% correct, compleet en actueel zijn.

Hoe zou volgens jou de uitvoering van dit project verlopen? Hoe groot is de kans dat je het op tijd en binnen het budget kunt opleveren?

Je gelooft het haast niet, maar onderzoek heeft aangetoond dat tussen de 30 en 70% van de inspanning en het budget opgaat aan testen en rework. Mijn eigen inschatting is dat dit percentage voor de meeste bedrijven boven de 50% ligt.

Wanneer je in staat bent deze rework cyclus te doorbreken ben je een heel eind op weg de duur en kosten van je softwareprojecten te halveren.

Maar dit is nog lang niet alles. De komende weken komen er meer zaken aan de orde die softwareprojecten vertragen en de kosten uit de pan doen rijzen.

Voordat ik vandaag afsluit wil ik een vitale statistic met je delen: 94% van alle problemen in softwareprojecten zijn niet toe te schrijven aan de mensen die het project uitvoeren.

Begint het nu voorzichtig tot je door te dringen waarom nieuwe tools, nieuwe technologie, nieuwe methoden of een reorganisatie geen duurzame oplossing zijn voor deze problemen?

Warme groet,
Kelly “Black Belt” Anches
The Profit Optimizer

p.s. ik lees net op een Nederlandse site dat 33% van alle softwareprojecten vroegtijdig eindigen.

var sc_project=2636855;
var sc_invisible=0;
var sc_partition=25;
var sc_security=”352f6c2d”;

blog counter

Read Full Post »

Ik heb geen flauw idee hoe je deze weblog hebt weten te vinden.

Misschien via een zoekmachine, een vriend(in) of misschien wel per toeval.

Hoe je het ook voor elkaar gekregen hebt: wees welkom en voel je thuis!

Wat mag je van deze weblog verwachten?

Informatie, uiterst cruciale informatie, om de duur en kosten van softwareprojecten te halveren en de bijdrage van IT aan het succes van de onderneming waar je voor werkt te maximaliseren.

That’s it!

Vergis je echter niet! Deze blog gaat niet over betere programmeertechnieken of nieuwe testmethoden. Evenmin gaat het over nieuwe analyse of ontwerp technieken.

Nope! Geen verhandelingen over techniek. Voor die informatie kun je elders op het internet in ruime mate en veel beter terecht.

Wat je hier aan informatie zult vinden gaat dieper en is exclusief gebaseerd op verbetersystemen zoals: The Deming Method, Quality Function Deployment, Six Sigma en hoe je ze specifiek in software toepast.

Ik beloof je dit: als je regelmatig deze blog bezoekt, kijk je binnen enkele weken heel anders tegen software engineering aan. Je zult verbijsterd zijn over de impact van wat je gaat lezen. Je zult ook ontdekken dat we veel en veel beter kunnen presteren. Als we maar de juiste dingen doen.

Zal ik als voorproefje alvast een tipje van de sluier lichten? In software engineering wordt testen gezien als een techniek om de kwaliteit van software te verbeteren. Dit staat haaks op alles wat bovengenoemde verbetersystemen propageren. Ik zal aantonen dat het tegendeel waar is: software wordt van testen niet beter, eerder slechter!

Misschien wel het belangrijkste dat in deze blog de revue zal passeren, is de noodzaak en de introductie van het eerste pro-actieve software model.

Deze weblog schrijf ik voor een ieder die beslist over, leiding geeft aan of betrokken is bij het serieus verbeteren van het softwareproces c.q. het ontwikkelen van software.

Mijn voornemen is 3 a 4 blogs per week te schrijven. Wat ik van jou verwacht? Heel simpel: dat je feedback geeft en stof helpt aandragen in de vorm van vragen c.q. opmerkingen c.q. aanvullingen.
(meer…)

Read Full Post »

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

Read Full Post »