Feeds:
Berichten
Reacties

Vandaag geen nieuw artikel, maar een aankondiging.
En deze is bestemd voor alle bezoekers van mijn blog en het gaat over een boek dat ik net af heb.

Is dit boek interessant voor jou?

Misschien wel, misschien niet.

Als je in de ICT werkzaam bent, tevreden met je huidige prestaties en het liefst alles bij het oude laat, dan is dit boek definitief niet voor jou.

Ben je echter bij het ontwikkelen van software betrokken, geef je leiding aan softwareprojecten, verantwoordelijk voor het verbeteren van het softwareproces of de kwaliteit van software en sta je open voor nieuwe ideeen, dan is mijn boek zeker de moeite waard.

Laat me je in het kort vertellen waarom.

Dit is eigenlijk geen boek in de traditionele zin, maar een 90 dagen plan om je te helpen:

  1. een doorslaggevende bijdrage te leveren aan het succes en de winstgevendheid van je bedrijf of je opdrachtgever
  2. meer te presteren met minder stress en minder inspanning

Te mooi om waar te zijn?

Ik kan me een dergelijke reactie voorstellen en ik heb daar een antwoord op.

Dit antwoord en alle informatie omtrent dit boek vind je vanaf maandag hier.

Tot dan.

Black Belt Kelly
Coherent Systems
kwg@coherentsystems.nl

In mijn vorige blog heb ik het er over gehad dat quality assurance zich richt op het voorkomen van defecten en dus ook op het minimaliseren van testen. Immers minder defecten, betekent minder testen.
Ik heb je toen ook beloofd dieper in te gaan op de toepassing van QA iun software. So, here we go!

Het zal je niet verbazen wanneer ik je vertel dat specificaties de zwakste schakel en de meest onzekere factor vormen in software engineering en het succes van je softwareprojecten kunnen maken of breken.

 

En hierin ligt de sleutel: complete en correcte specificaties.

Yep, that’s it.

Ik heb enige jaren terug de term adecurate specificaties hiervoor bedacht. Adecuraat is een samenvoeging van adequaat (voldoende) en accuraat (correct). Dit zijn de twee belangrijkste eisen die aan specificaties gesteld moeten worden. Want laten we eerlijk zijn: het is onmogelijk een goed systeem te ontwikkelen met incorrecte c.q. inadequate specificaties of specificaties die tijdens de uitvoering van een project worden aangevuld c.q. gecorrigeerd. En er bestaat, voor zover ik weet, nog geen tool of programmeur die van incorrecte c.q. onvolledige specificaties het gewenste systeem kan engineeren.

Maar is het dan mogelijk specificaties 100% correct en 100% compleet te krijgen?

Nee, dat zal nooit lukken, want ook informatici zijn mensen. Maar het is wel mogelijk zowel het specificatiesproces als het resultaat van dit proces aanzienlijk te verbeteren als je maar weet hoe.
Dit is exact wat ik je zo dadelijk zult leren.

Laten we eerst even samenvatten wat je tot nog toe geleerd hebt:

  • QA is gericht op het voorkomen van defecten
  • hoe minder defecten des te minder hoef je te testen
  • de vereiste testinspanning is een goede indicatie voor de aan- of afwezigheid van QA

Kun je je nog de kwaliteitsmeter uit mijn vorige blog herinneren? Wat daaruit naar voren komt is de relatie tussen QA en QC. Deze relatie behelst dat je niet aan QA kunt beginnen alvorens je QC hebt geimplementeerd. Om concreter te zijn betekent dit dat je 3-sigma controle over je proces, in dit geval je softwareproces, hebt. Is dit het geval dan is je proces nog niet rijp voor QA. Je doet er in dit geval beter aan een stap terug te doen en eerst met QC te beginnen.

Dit is een keiharde eis waar je niet aan ontkomt.

Laten we nu dieper ingaan op wat adecurate specificaties inhouden.

Laat me beginnen met vast te stellen dat ik niet pretendeer dat er zoiets als volmaakte specificaties bestaan. Wat ik claim is dat het mogelijk is met aanzienlijk betere (=completere + correctere) specificaties voor de dag te komen. En dat het mogelijk is je proces zo in te richten dat je tekortkomingen in de specificaties bijna uitsluit of anders vrijwel direct identificeert en corrigeert. Dat is wat echte QA inhoudt. En daar wordt iedereen beter van.

Eén van de grootste fouten die we project na project maken is aannemen dat gebruikers precies weten wat ze willen. Dit zou dan betekenen dat ze hun situatie grondig hebben geanalyseerd en precies weten welke mogelijkheden IT hen biedt. Het traditionele softwareproces is ook op deze aanname gebaseerd. Het zal je nu niet meer verbazen dat ik deze aanname sterk in twijfel trek.Bovendien moet software voldoen aan de specificaties die gelden NA oplevering van het systeem.

Gebruikers kunnen je alleen vertellen wat ze gister en vandaag deden, maar niet wat ze na oplevering van het systeem zullen (moeten) doen.

Een andere misvatting is dat de persoon die de gebruiker interviewt precies weet welke vragen hij moet stellen en …. precies weet wanneer de laatste vraag gesteld is. Deze veronderstelling moet ook onjuist zijn. Hoe is het anders te verklaren dat tijdens de uitvoering van een project nog nieuwe specificaties boven water komen? Sterker; zelfs tijdens het testen worden er nog nieuwe specificaties geformuleerd. En wat te zeggen van alle incidenten tijdens de eerste twee maanden na uitrol?

Mijn ervaringen de afgelopen 30 jaar in meer dan 50 organisaties in 7 landen (incl. Japan en Amerika) op 4 continenten en een kleine 100 projecten hebben mij anders geleerd.

Ik claim dat adecurate specificaties het resultaat zijn van een ontdekproces en veel minder van een interviewproces.

Laat me dit toelichten.

Soorten specificaties

Om je klant c.q gebruikers tevreden te stellen en hun verwachtingen te overtreffen veronderstelt dat je een diep inzicht hebt in wat ze willen en hoe het vervullen van hun wensen hun tevredenheid beinvloed.

Dit kun je allen maar wanneer je je bewust bent van het feit dat er twee groepen specificaties bestaan.

  1. de impliciete en
  2. de expliciete specificaties

Laten we met de tweede groep beginnen want deze ligt het meest voor de hand. Dit zijn de specificaties waar de gebruiker en de interviewer zich van “bewust” zijn en die in het interview aan bod komen.

Met de eerste groep is het wat lastiger, want deze ligt minder voor de hand en daarom komen ze in het interview niet aan bod. Om het nog complexer te maken. Deze groep kan weer onderverdeeld worden in drie subgroepen:

  • de vanzelfsprekende,
  • de toekomstige en
  • de attractieve specificaties

Zoals de naam van aangeeft zijn de vanzelfsprekende specificaties voor de gebruiker zo vanzelfsprekend dat ze er niet op komt ze in het interview ter sprake te brengen. Ze gaat er van uit dat de interviewer die immers de expert is en het verloop van het interview dicteert wel weet dat deze specificaties bij het systeem horen. Zelfs wanneer een samenvatting van het interview naar de geinterviewde wordt gestuurd gaat er geen lampje branden. Dat is typerend voor deze subgroep.

De toekomstige specificaties zijn de specificaties die zullen gelden na opleveren van het systeem. De gebruikers van je systeem weten wat ze vandaag doen, maar hebben geen notie van wat ze morgen nodig zullen hebben. Zo kijken ze niet tegen hun werk aan. Wanneer je ze dus interviewt vertellen ze je wat ze in het verleden deden. Jij bouwt echter aan een systeem dat moet voldoen aan de eisen die gelden NA oplevering van het systeem.Begin je nu de omvang van het probleem te onderkennen?

De attractieve specificaties zijn specificaties die de gebruiker niet kan weten, want dat zijn oplossingen voor problemen waar ze zich niet eens van bewust zijn of elegante toepassingen van de technologie waardoor ze dingen kunnen die ze vroeger niet konden.

De samenhang tussen specificaties en tevredenheid van de gebruiker

Vervulling van de expliciete specificaties leidt tot wat ik zou willen noemen evenredige tevredenheid.

Dit wil zeggen dat de tevredenheid toeneemt naarmate er meer expliciete specificaties worden vervuld en afneemt naarmate er minder worden vervuld. Ontbrekende expliciete specificaties worden vrij snel ontdekt en kunnen eenvoudig worden aangepast.

Het vervullen van de toekomstige specificaties zal de gebruiker je niet al te sterk aanrekenen, omdat niet van je geëist kan worden dat je ze wist. Ze weten ook dat het om dingen gaat die ze niet gevraagd hebben. Het verhelpen van ontbrekende toekomstige specificaties kan daarom met recht tot
onderhoud gerekend worden.

Het niet vervullen van de vanzelfsprekende specificaties is een regelrechte ramp en leidt tot ernstige ontevredenheid. Heb je wel eens een gebruiker horen klagen dat ze het systeem niet kan gebruiken?
Dan heb je met deze subgroep van doen. Het nare is dat het tot de confrontatie van de gebruiker met
het systeem duurt voordat het aan het licht treedt dat ze ontbreken.Dit is buitengewoon tragisch, omdat het alsnog honoreren van deze subgroep een “pijnlijk” proces is in de zin van bewerkelijk en duur.
Bovendien kan het systeem niet live, zolang dit euvel niet is opgelost.

Vanzelfsprekende specificaties kun je niet via reguliere interviews vastleggen enze maken of breken het succes van je project. Toch er is geen enkele voorziening in het traditionele softwareproces om hier verbetering in aan te brengen.

Voor zover ik objectief kan oordelen en het kan overzien is Quality Function Deployment het enige quality management systeem met voorzieningen en een complete toolset om zowel toekomstige als vanzelfsprekende specifdicaties te ontdekken.

QFD wordt sinds 1982 met indrukwekkende resultaten in Japan gebruikt om software te ontwikkelen en sinds 1992 in Amerika.

Om je een beeld te geven van de kracht van QFD in software te geven: in 1987 wordt de Deming price for Quality voor het eerst toegekend aan een softwarebedrijf dat met QFD tot de volgende resultaten bereikte:

  1. een gemiddelde versnelling van haar softwareprojecten met 520%
  2. het terugbrengen van haar onderhoudsinspanning tot 1 correctie per2.000.000 regels uitvoerbare code gedurende het eerste jaar na implementatie (dit was in 1987)
  3. vrijwel volledige eliminatie van testen. Als je bijna geen fouten maakt is het ook niet nodig veel tijd aan testen te besteden

Een vereiste bij preventie is dat alle lekken in je proces zijn opgespoord en gedicht. Je processen zijn dus a.h.w. waterdicht en laten uitsluitend nog menselijke fouten door.

Menselijke fouten zijn nooit uit te sluiten, ook niet door een QA systeem. Maar … ik heb een geruststellende statistiek voor je.

Mensen die het absoluut kunnen weten (dr. Deming) en die we gerust kunnen vertrouwen beweren met klem dat slechts 6% van wat er in organisaties fout gaat (en misschien geldt dit in nog sterkere mate voor s/w projecten) aan mensen ligt.

En de resterende 94%? Wees gerust, want daar kunnen jij noch ik iets aan doen. Ze zijn het logische gevolg van gebreken aan de processen waarmee we werken.

Een absolute eis van een QA systeem is dus dat het je fouten moet helpen voorkomen. Anders gezegd: een QA systeem moet je helpen je proces zo in te richten dat het uitsluitend uit activiteiten bestaat die de kwaliteit van software garanderen en de noodzaak voor testen minimaliseren.

Anders is het geen QA systeem.

Testen of beter gezegd: de tijd en de inspanning die je achteraf kwijt bent met het opsporen, lokaliseren en corrigeren van fouten die nooit gemaakt hadden mogen worden zijn de enige en beste graadmeter voor het QA gehalte van je proces.

En als je nog steeds niet overtuigd bent dan heb ik de volgende vragen voor je:

Heb je ooit meegemaakt dat de eigenaar van een nieuw huis eerst 10 sterke schouders van de plaatselijke sportschool inhuurt om zo hard mogelijk tegen de muren te duwen voordat hij zijn nieuw huis durft betreden?

Heb je ooit meegemaakt dat de brandweer op last van de eigenaar van een nieuw huis moest uitrukken om het dak te besproeien om te testen of het binnen droog blijft tijdens een regenbui?

Dit is wat testen eigelijk is. Wat is er mis? Kan het zijn dat het softwareproces niet minder geschikt is voor wat het moet doen?

Tot de volgende blog,
“Black Belt Kelly”
Coherent Systems
kwg@coherentsystems.nl

p.s. wil je weten hoe QFD je kan helpen je succes als ITC-er te maximaliseren en onmisbaar te worden in de winstgevendheid van je onderneming of klant? Stuur me een email.

 

 

 

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

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

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

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

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.
Lees verder »