Nyt: ISO-9000 for FOSS projekter!

En af konsekvenserne af regnearkets opfindelse, er at folk får den ide, at hvis man bare fylder tal nok i dem, kommer der noget ud man kan bruge.

Robert Piersig skrev en bog der for alle praktiske formål lagde ideen om "kvalitet" som målbar størrelse i graven, med en træstage igennem hjertet, sølv om halsen og hvidløg mellem tænderne, men det forhindrede ikke ISO-9000 i at blive et fantastisk forretningsområde for banditter i habitter.

Eller måske skulle man slet og ret kalde dem snyltere ?

Nu er klokken faldet i slag for FOSS projekterne: Linux Foundation, der blev fundet sovende bag rattet da HeartBleed skabte panik, har lige siden skovlet vand med en møggreb i et forsøg på i det mindste at få adskilt skæg og snot på en eller anden måde.

Seneste iteration er et ny "dashboard" der ikke lader ISO-9000 certificeringer meget tilbage.

(Her er en glimrende artikel om det på TheRegister, hvis du er bange at jeg har kynismen skruet lidt for højt op.)

Nej, jeg er ikke imponeret og overhovedet ikke forhåbningsfuld om at alting nu bliver bedre.

Lad det være sagt med det samme: Det er gode folk med hjærtet på rette sted og de bedste hensigter man kan købe for andre folks penge.

Men der findes simpelthen ingen global skala for kvalitet og mindst af alt er kvalitet numerisk kvantificerbar.

Men de prøver.

De har rullet det existerende "CII Badge" videre under det nye navn & logo, men hvis man kigger på kriterierne, er alt vhad min finder salg af elastik i metermål.

Her er f.eks kriteriet for at få "Automated test suite" spejdermærket:

Illustration: Poul-Henning Kamp

OK, man skal have en test-suite, fint nok, enten har man en, eller også har man ikke en, det er til at finde ud af.

Men hvad fanden betyder det at testsuiten skal kunne startes "in a standard way for that language" ?

Folk der har været igennem ISO9001 kender den slags spørgsmål til hudløshed. En gang oplevede en eller anden slipsefyr noget frygteligt som aldrig må ske igen. Men hans sikkert velmenende og konkrete spørgsmål er blevet generaliseret og gruppearbejdet til ukendelighed, indtil det nu absolut intet fornuftigt siger folk der ikke har købt The Breeder's Guide

I modsætning til dette "SHOULD" krav, er det kun "SUGGESTED" at test-suiten faktisk "cover most (or ideally all) the code branches, input fields, and functionality."

Her skal man, præcis som med ISO9000 certificeringer, bemærke alt det der mangler.

Man kan faktisk godt teste alting 100%, det gjorde man f.eks på NASA's space-shuttle projekt.

...og alligevel stoppede The Bug Heard Around The World den første opsendelse for øjnene af alverdens TV-seere.

Derfor er det naturligt at kriteriet for spejdermærket ikke er "SHOULD test all ...".

Men at file det helt ned til "SUGGESTED ... most" gør det latterligt ligegyldigt, ligesom de fleste ISO-9000 certifikater er det.

Da jeg var der i 1990'erne hængte GiroBank stolt deres ISO-9000 certifikat op i receptionen.

Hvis man faktisk tog sig tid til at læse det, opdagede man at det de havde ISO-9000 certificeret var ... receptionen.

Alt det der med millioner af blanketter og millarder af kroner var ikke ISO9000 certificeret, men hvordan der blev sagt goddag i telefonen var.

At man har testet 50% af alting i et softwareprojekt er på ingen måde en garanti for at man har testet noget der var vigtigt, tværtimod faktisk, de første ca. 70% af koden er triviel at teste for den gør ikke noget kompliceret.

Men på samme måde som GiroBanks ledelse indkasserede deres bonus, kan FOSS projekterne indkassere deres spejdermærke og Linux Foundation kan stolt udbassunerer at takket være deres initiativ har X% af alle FOSS projekter nu en "Automated test suite".

Ja, selvfølgelig vil der blive fundet og rettet fejl undervejs, ligesom jeg er sikker på at certificeringen af Girobanks reception afslørede en frygtelig uvidenhed om de præcise regler for hvilke gæster der hvornår blev tilbudt kaffe og småkager mens de ventede.

Men nogen drastisk forbedring af kvaliteten af FOSS kommer det ikke til at medføre.

Hvis et projekt har gjort sig nogle tanker omkring tests og bruger deres testværktøjer som, ja, et værktøj, til at forbedre hvad de selv opfatter som projektets kvalitet, så vil det gøre en forskel.

Et ringbind med et flot projektlogo og centimetertykt støvlag gør ikke.

Og ja, jeg tager måske denne detalje lidt tungt, fordi jeg har brugt rigtig meget energi, i rigtig mange år på at prøve at gøre det rigtigt i Varnish Cache.

Vi har 855 test-scripts, som udfører 90.5% af linierne i vores kildetekst, men jeg tvivler faktisk lidt på om det kan kvalificere os til et "Automated test suite" spejdermærke.

Mest fordi jeg aner ikke om vores VTest program, der i parantes bemærket nu også bruges af HAproxy projektet, er "invocable in a standard way for that language" ?

phk

Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jørgen Elgaard Larsen

Jeg er generelt enig i betragtningerne om "kvalitetsmåling".

De fleste af os herinde har nok vores egne målepunkter for at vurdere, hvor modent et FOSS-projekt er - og om vi tør basere noget vigtigt på det?

Det er selvfølgelig ikke nødvendigvis noget, der kan munde ud i en målbar score. Mere en erfaring omkring, hvilke røde flag, man skal kigge efter.

Totalt fravær af tests og CI er et meget stort rødt flag. Det er straks mere bøvlet at vurdere, om en testsuite dækker nok vigtige dele.

Hvis sidste release er tudsegammel, kan det tyde på enten et dødt community (rødt flag) eller på klippestabil software (grønt flag).

Hyppige releases kan tyde på et aktivt community (grønt flag) eller bunker af panikrettelser (stort rødt flag).

ALt efter hvor dybt man graver i analysen kan man få forskellige farver og størrelser ud.

Opgave: Læg et ukendt antal af flag i varierende størrelse og farve sammen til et tal mellem 1 og 10.

  • 14
  • 0
#2 Mogens Bluhme

Det er da dejligt, at FOSS-miljøet endelig har set lyset og har fulgt med tidens strømning. Vi ved jo alle sammen, at det med at kun peers kan vurdere peers inden for det samme fagdomæne, er noget vrøvl. Se blot på hvilken success OECD og McKinsey har haft på uddannelsesområdet og KPI'er har på forskning.

Vi ved jo godt allesammen, at økonomer er meget klogere end alle andre fagfolk - tilsammen!

  • 20
  • 0
#5 Henrik Juul Størner

Da jeg var der i 1990'erne hængte GiroBank stolt deres ISO-9000 certifikat op i receptionen.

Hvis man faktisk tog sig tid til at læse det, opdagede man at det de havde ISO-9000 certificeret var ... receptionen.

Da jeg startede et nyt sted bad jeg også om at se deres ISO9000 "Statement of Applicability" (SoA i ISO-lingo). De kiggede forvirret på mig, men det lykkedes at finde den frem efter et par år. Det må være en god forretning at være ISO9000-konsulent.

  • 4
  • 0
#10 Magnus Jørgensen

Jeg kan ikke se en grund til at Software projecter ikke også skal testes med som med Tryk apparater: https://www.asme.org/codes-standards/find-codes-standards/bpvc-v-bpvc-se...

Vi er vandt til i software industrien kun at teste om tingene virker. Men vi bør egentlig også teste med "destructive testing".

Stil din løsning op i et test miljø og kast bruger med interactioner ind i det, som det er designet til og fortsæt derefter indtil systemet går i knæ. Så finder man også ud af hvad der er det svageste led og hvorfor.

  • 7
  • 0
#11 Steen Thomassen

ISO9000 har jeg været udsat for et par gange i fortiden og det var reelt set mere en certificering af at vi ville lave samme fejl hver gang end et mål for kvaliteten.

ISO 9000 er det fastsatte niveauet for kvalitet man går efter. Hvis der det er dyrt at undgå alle fejl. så lever man med det og tager højde for det enten ved at fange det inden det kommer ud til kunde eller håndtere klagen hvis det kommer ud til en kunde og registere det, så man tjekket om det er på det ønsket niveau.

Det samme med softwareudvikling... det koster at fange alle fejl.

  • 4
  • 1
#12 Steen Thomassen

Da den virksomhed jeg arbejde for i 90'erne blev 9000-certificeret, fyldte procedurer og instruktioner 9 (ni) ringbind. Kendt som Den Hvide Mur.

Nej, jeg var ikke begejstret.

Min egen erfaring, at i starten var alt med for meget formalia i mange steder, som for mange skulle sætte sig ind. På min tidligere arbejdsplads lykkes det at få indarbejde det meste hyppige afvigelser i de normalte processer, så det var kun af trække antal/sager fra systemet.

  • 1
  • 0
#15 Peer Hansen

Kritikken af ISO 9000 er, efter min mening, helt forfejlet idet der i denne standard fokuseres på virksomhedens processer. Alle processer, f.eks administrative processer, fremstillingsprocesser, udvikling af SW, bagning af en kage eller afholdelse af en workshop om innovation, har det til fælles at det ALTID er processen der er interessant og afgørende for om man indfrier sine mål. Nogle har en indgroet modstand mod formaliserede proccesser men alt hvad der foregår i FOSS miljøet eller i en virksomhed er processer, så de er der jo, ligegyldigt om man kan lide dem eller ej. Man kan så vælge om de skal have lov til at sejle eller man vil have dem under kontrol. Hvis man ikke har beskrevet dem og har dem under kontrol er resultatet af dem umuligt at forudsige og i princippet også umuligt at vurdere.

  • 6
  • 6
#16 Sune Marcher

Kritikken af ISO 9000 er, efter min mening, helt forfejlet idet der i denne standard fokuseres på virksomhedens processer.

Jeg tror vi har fundet proceskonsulenten i rummet? ;-)

Der er forhåbentligt ikke så mange professionelle der generelt er imod processer, men jeg vil skyde på mange af os stejler når det bliver et skuespil hvor det er proces for processens skyld...

  • 11
  • 0
#17 Per Michael Jensen

Der hvor det går galt for mange virksomheder, er at de egentlig kun er interesserede i ISO9001 certifikatet. Ledelsen tager ikke ansvar for kvalitet, man uddeleger til en "kvalitetsansvarlig" eller en "kvalitetsorganisation".

ISO9001 starter stort set med at definere at kvalitet er en "iboende egenskab" (hvilket ikke er i konflikt med Piersig) og at virksomheden selv skal fastlægge hvad kvalitet er (ud fra bl.a. kundekrav).

En iboende egenskab kan ikke udddelegeres. Det er et ledelsesansvar. Men kvalitet overtrumfes altid af økonomernes regneark.

Første gang account manageren/projektlederen/økonomichefen siger: "Vi skal have de varer ud inden månedsskiftet pga. månedsregnskabet!" - så ved medarbejderne at månedsregnskabet er vigtigere end kvalitet...

  • 5
  • 0
#20 Magnus Jørgensen

Langt hen and vejen er det vel hvad "fuzzing" gør ?

Det kunne da have været rart hvis Polsag havde været igennem det før man prøvede at rulle det ud på bornholm. Men jeg synes også at der skulle være en eller anden form får test af hvordan systemet skalerer og håndterer f.eks. et DDOS angreb. Det betyder jo ikke at det er det eneste man skal teste for. Desuden betyder det ikke at man skal basere standarden alene på tests. Sikring af processernes validitet og testning er ikke indbyrdes udelukkende.

  • 1
  • 0
#22 Peer Hansen

"Sikring af processernes validitet og testning er ikke indbyrdes udelukkende"

Helt enig - Sw-udvikling er en proces som genererer fejl i et uacceptabelt omfang og så er det naturligvis nødvendigt at teste på output. Men man skal være klar over at test virker som en reduktionsfaktor, så hvis der findes mange fejl under testen, vil der være tilsvarende mange som ikke bliver fundet. Derudover har test, for det meste, en forholdsvis lav reduktionsfaktor. At hæve reduktionsfaktoren til noget der ligner 100% er, som PHK skriver, enormt resourcekrævende og det er derfor jeg argumenterer for at man bør optimere processerne, med henblik på at reducere mængden af fejl. Det kræver selvfølgelig nogle resourcer til procesoptimeringsarbejdet, med det skal kun gøres én gang :-)

  • 1
  • 1
#23 Kjeld Flarup Christensen

Jeg ved ikke om det er en storm i et glas vand det her.

Automatisk test er kommet for at blive, og heldigvis er der kommet mange gode værktøjer de sidste år. FOSS projekterne kan også få sponsoreret afvikling af disse.

Nej, automatisk test gør det ikke alene og 100% test coverage giver ofte ikke nogen mening.

Men uden et automatisk test setup, så risikerer man let, at man kommer til at glemme de svære cases hvor man lave en workaround, og glemmer alt om den. Hvis det første man gør når man finder en speciel fejl som kræver et specielt kontekst er at genskabe den i en test case. Så har man sikret sig, at rettelsen ikke optimeres ud senere.

Det tager tid at bygge test op, men som et kinesisk ordsprog siger, en rejse starter med det første skridt.

  • 1
  • 1
#24 Ole Laursen

... og det er derfor jeg argumenterer for at man bør optimere processerne, med henblik på at reducere mængden af fejl. Det kræver selvfølgelig nogle resourcer til procesoptimeringsarbejdet, med det skal kun gøres én gang :-)

Hvis vi et øjeblik træder et skridt højere op end det du bevæger dig på her, så kan vi spørge os selv om det syn du lægger til grund her fører til effektive resultater. Jeg har personligt set eksempler på det modsatte, at "procesoptimering" førte til at folk spændte ben for sig selv. Omvendt optimerer jeg fra tid til anden med held på mine egne små processer, dog ikke ud fra det tankegods du giver udtryk fra.

Hvis jeg skulle sætte flere ord på, vil jeg sige at procesdesign er svært, og at mange mennesker efter min erfaring bedre kan arbejde med det intuitivt når de står i situationen, end formaliseret.

At det er svært skyldes bl.a. at der er modstridende hensyn, at kompleksiteten ofte er høj, og at feedback-løkken kan være støjfyldt og kræve langsigtede eksperimenter.

I øvrigt er det her du skrev tidligere en non-sequitur:

Man kan så vælge om de skal have lov til at sejle eller man vil have dem under kontrol. Hvis man ikke har beskrevet dem og har dem under kontrol er resultatet af dem umuligt at forudsige og i princippet også umuligt at vurdere.

Professionelle mennesker, dvs. ikke klamphuggere, har styr på deres processer, uden at de er beskrevet. Det kaldes selvorganisering. Medmindre kompleksitetsgraden at det udførte arbejde er lav så det kan udføres bureaukratisk med centralt udtænkte regler, er selvorganisering typisk det mest effektive.

  • 2
  • 0
Log ind eller Opret konto for at kommentere