Kvalitet kontra komplexitetens förbannelse

Jag har i ett tidigare blogginlägg spekulerat över bestående skador efter heartbleed-buggen. Forsätter här med en betraktelse om möjliga orsaker till att några få rader rader felaktig programkod kan få sådana följder, risken för att det kan komma fler och vad man möjligen kan göras för att förebygga dessa.

När Robin Seggelmann postade sin "patch" för OpenSSL den 30:e december 2011 fanns nog bara ett gott uppsåt. Men kvalitetsgranskningen av denna patch brast och "heartbleed-buggen" var ett faktum som sedan distribuerades med OpenSSL version 1.0.1 14:e mars 2012.

När man bygger något så förutsätter man att de ingående delarna eller komponenterna är felfria och har en förutsägbar (lång) livslängd. Fallerar någon del så riskeras helheten. Bilindustrin drabbas regelbundet av att någon bilmodell måste återkallas för att åtgärda felaktiga eller misstänkt felaktiga komponenter. Kostnaderna för detta och den ev. varumärkesskada kan bli mycket höga. Konsekvenserna är dock ofta kontrollerbara då bilbranschen har väl upparbetade distributionskanaler som gör det relativ enkelt att spåra de enskilda, misstänkta fordonen för att erbjuda felrättning. Om bilarna skulle förbli oåtgärdade finns risken för olyckor och incidenter där oskyldiga och ovetande kan bli skadade.

När man bygger IT-system använder man oftast ett stort antal fria eller kommersiella komponenter och förutsätter att de fungerar exakt som deras specifikationer beskriver. Hur kvalitetssäkringen av dessa görs är oftast helt okänd för de som inkluderar dem i sina produkter. Ju fler komponenter av okänd kvalitet som används ju större är risken att bygger en bristfällig slutprodukt.
Man bygger alltså in en risk för att produkten beter sig felaktigt och kanske farligt i vissa situationer.

Bygger man sedan samverkande system av produkter som innehåller okända komponenter ökar riskerna ytterligare för att helheten kommer att bete sig mycket oförutsett och att felsökning av sådant beteende blir svårt och felrättning kanske blir helt omöjligt.

Ytterligare en risk med att bygga komplexa system är att de som designar dem inte bara litar på att komponenter och produkter beter sig enligt specifikation utan att de också designar lösningar som i sig är så komplexa så att, även om de byggs av felfria komponenter,  de kommer få, till en del, oförutsägbart beteende.

Jag kallar ovanstående komplexitetens förbannelse. Av människan byggda system kan snabbt nå en komplexitet som inte längre kan förstås av människor, kanske inte ens av upphovsmännen.

Hur klarar vi då en framtid med dessa dystra förutsägelse?

Det som är enkelt att säga och svårt att leva efter är uttryck som "Keep it simple, stupid" (K.I.S.S.)" eller mitt eget motto; "ju enklare desto bättre".

I verkligheten är det väl snarast att man måste säkra kvaliteten i varje utvecklingssteg och för varje, koncept, arkitektur, komponent, produkt och slutligen det kompletta systemet.

För att säkra kvaliteten gäller först att med bra metoder och kunskap undvika att bygga in fel, nästa är att testa och då inte bara att det önskade beteende uppfylls utan också testa att inget oönskat kan ske.

När så en liten komponent som OpenSSL kan få hela internets trovärdighet i gungning så beror det på "komplexitetens förbannelse"!

Heartbleed-buggen och internets förlorade trovärdighet.

En av de små komponenterna som bygger internet är OpenSSL. OpenSSL är en implementation av internetprotokollet SSL/TLS (IETF/RFC6101) som hanterar hur man sätter upp en krypterad förbindelse mellan två datorer. OpenSSL tillhandahåller också ett antal verktyg för kryptering och framtagning av krypteringsnycklar och certifikat.

OpenSSL är en produkt som de senaste dagarna kommit i rampljuset från att vara något som bara IT-folk känt till. Orsaken till att exponeringen är den s.k. heartbleed-buggen som nu blivit känd och som framställts som ett av de största hoten hittills på internet.

Jag kommer här inte att beskriven buggen eller vilka åtgärder som nu krävs för säkra sina miljöer utan fokusera på möjliga konsekvenser i ett macroperspektiv.

Buggen innebär att information kan läcka från drabbade serverar, information som kan vara känslig och hemlig. OpenSSL är sig en liten komponent men den finns spridd i kanske 100-tals miljoner kopior, många av dessa kan vara inkluderade i produkter som mobiltelefoner, routrar och brandväggar, produkter som kan sakna support eller där det inte är tydligt att OpenSSL ingår. Åtgärder pågår för att reparera felen där de är kända men sannolikt kommer många installationer att bli bortglömda och därmed vara ett fortsatt hot. Det spekuleras mycket om hur mycket information som läckt under de två år buggen har funnit. Svaret på detta finns inte och kommer nog förbli obesvarat.

Vi är nu i ett tillstånd som liknar det som var inför sekelskiftet och den s.k. millenniebuggen. Före sekelskiftet hade man dålig kontroll på hur mycket av världens programvara som inte var förberedd det nya seklet och de konsekvenser som dessa brister skulle kunna medföra. Stora projekt för att granska system och program startades, mycket rättades men ingen visste hur mycket som skulle fallera 2000-01-01. Allt nog, det mesta gick bra, dels var farorna kanske överdrivna men också den metodiska ansatsen att faktiskt göra så mycket som möjlighet för att förbygga problem bidrog nog till att det gick bra.

Vi är nu i ett liknande läge, vi vet inte alls hur många ställen som den dåliga koden finns, vi får leta och rätta men till skillnad mot millenniebuggen kommer inget tillfälle då vi vet att det gått bra. Det kan när som helst i framtiden komma fram information som läckt från tidigare trasiga system eller sådana som ännu inte reparerats. Information som kan komma att användas i onda syften.

Fungerade, pålitligt kryptering är en förutsättning för många tjänster på internet. Vi behöver det för att säkert kunna identifiera oss på nätet, vi behöver det för att veta att ingen manipulerar eller tar del av de data vi utväxlar på nätet. Kryptering är nödvändigt för att hantera banktjänster på nätet, att kunna överföra privat eller sekretessbelagd information m.m.

En stark trend för närvarande är s.k. "identitetsfederationer" där det förutsätts fullt förtroende för övriga parter och att dessa inte har några brister i sin system. Skulle någon medlem i federation ha fel i sina kryptosystem t.ex. p.g.a heartbleed-buggen så kan förtroende för hela federationen ifrågasättas.

Heartbleed-buggen har dessutom spräckt en myt. Att open-source gör det möjligt för var och en att granska säkerhet i koden. Det är sant men tyvärr verkar det som de flesta förväntar sig att "någon annan" granskar och dessutom i ärligt uppsåt återrapporterar ev. brister. Detta har dock inte skett på två år...

Frågan är hur många andra, för internet viktiga "komponenter" som har allvarliga brister? Man kan nu med rätta ifrågasätta om det som setts som säkert på internet verkligen är säkert och trovärdigt? 

Så arbetet med att spåra och rätta alla ställen där heartbleed-buggen kan finnas måste fortgå. Ny teknik måste förmodligen också fram för att framtidssäkra internet så att vi åter kan få förtroende.
Tillsvidare bör man vara mycket försiktig användning av internet när höga krav på sekretess och riktighet som t.ex. kontakter med media där meddelarskyddet är viktigt, patientjournaler på nätet, allmänna val, vissa ekonomiska transaktioner m.m.

Okrypterade meddelanden på internet jämförs ofta med vykort (som kan läsas av brevbäraren). Krypterade meddelande är kanske som kuverterade brev men det kan ändå vara många som kan öppna och tjuvläsa dessa...

---

Heartbleed-buggen och OpenSSL

De senaste dagarna har det skrivits om det största hotet genom tiderna på internet och att vi alla kan vara drabbade.

Vad har då hänt?
När du besöker en ”säker” webbplats och ser hänglåssymbolen i webbläsaren kopplas du upp via en säker, krypterad kanal till servern så att ingen kan avlyssna det som skickas, t.ex. dina lösenord. Det som upptäckts nu är den s.k. Heartbleed-buggen i krypteringsprogramvaran OpenSSL. Den felaktiga versionen av OpenSSL används av många men långt ifrån alla servrar på internet. Buggen möjliggör att obehöriga kan koppla upp sig mot säkrade servrar och tjuvlyssna på den krypterade trafiken och ev. då hitta lösenord och annan känslig information.
Buggen har funnits sedan mars 2012 men varit okänd eller i varje fall inte offentliggjord förrän 8:e april 2014. Detta gör att det är svårt att säga om någon information har läckts under tiden. När det nu är känt kommer förmodligen många, av olika skäl, att försöka avlyssna krypterad internettrafik varför åtgärder mot detta måste tas omgående. Ägare av servrar på internet har eller håller förhoppningsvis på med att rätta felen enligt de anvisningar som tagits fram. Men även användare bör byta lösenord så snart servrarna är rättade. Det vore därför lämpligt att webbplatser som gjort sina rättningar också visar det på sina hemsidor och uppmanar användare att byta lösenord.

Användbarhetstester och Taylorism

När jag var liten (60-tal) fanns inom verkstadsindustrierna en av industriarbetarna ofta illa ansedd yrkesgrupp benämnd tidsstudiemän. Deras attribut var ofta den grå lagerrocken med Pocket protector, skrivplatta med stoppur och deras lära var Taylorism. En av tidsstudiemän vanligt använd metod var MTM (Methods-Time Measurement) vars mål var att optimera repetitiva arbetsprocesser inom industrin. Man bröt ner processerna i korta men mätbara moment och mätte tid för dessa. Momenten kunde vara; hämta skruv från låda A, passa in skruv i hål B på arbetsstycke C o.s.v. Under tiden kontrollerades om det fanns några onödiga rörelser som t.ex. kunde elimineras genom att t.ex. ändra placeringen av låda A. Att tidsstudiemännen ofta var illa sedda var förmodligen kopplat till att de störde yrkesstoltheten hos de "studerade" och att dessa blev lättare utbytbara när processerna blev nedtecknade.

Nog om historia nu. Jag kom att tänka på detta i samband med användbarhetstester av IT-system. Ofta sker användbarhetstester mot enstaka IT-system för att validera systemets specifikationer, sällan kopplat till de arbetsprocesser som systemen kan vara en del av. Min idé (som kanske finns förverkligad som metod men som jag i så fall är okunnig om) är att tänka lite MTM vid krav och tester av IT-system som är del i arbetsprocesser bland flera andra IT-system och alla icke-IT delar i arbetsprocessen. Det enskilda IT-systemet kanske inte uppvisar några hinder för att användaren skall kunna göra ett bra arbete men i den totala arbetssituationen kan systemet upplevas som mycket ovänligt. T.ex. upprepade in och utloggningar i olika system, möjligheter att klippa/klistra mellan systemen, olika GUI och kortkommandon m.m. påverkar arbetssituationen påtagligt.
Idéerna med MTM och Taylorismen skulle här inte användas för att ifrågasätta användarna utan för att kunna ställa rätt krav vid upphandling och utveckling av IT-system som ingår i större arbetsprocesser och för validering/användbarhetstester av hela processer.

Användbarhetstester bör utgå från användarens arbetsdag och arbetssituation, inte det enskilda IT-systemet "användbarhet"

Kvalitet i projekt

Den här texten berör i princip allt man förädlar för att sedan lämna i från sig men jag har valt att lägga fokus på projektperspektiv och för projektledarrollen.

Som projektledare har man ansvaret för att leverera ett resultat som motsvarar specifikationerna inom överenskommen tidsplan och med de resurser man tilldelats. D.v.s. allt mätbart man kommit överens om med uppdragsgivaren. Men allt är inte mätbart. Mycket av den kvalitet man upplever är subjektiv.

En kvalitetsaspekt är en produkts användbarhet. Användbarhet är svårt att definiera och även finna vad som ger en god användarupplevelse. Men varje person som kommer att använda den kommer snabbt till klarhet i om den är användbar och bra.

Mycket av den icke mätbara kvaliteten kommer från yrkeskunnande, erfarenhet och engagemang hos den eller de som tar fram produkten. Att de som utvecklar produkten dessutom måste förstå hur den skall användas och i vilken kontext är en förutsättning för att nå förväntad kvalitet d.v.s. utöver det som är mätbart.

De som har yrkeskunnande och erfarenhet vet när de tvingas lämna i från sig något som riskerar att ha dålig kvalitet, brister som kanske upptäcks långt senare när leveransen är gjord och projektet upplöst.

Men...

Har beställaren allt för stort fokus på specificerade mål och det samtidigt uppstår problem i projektet kan projektledaren pressas att bara tillgodose specifikationen och bortse från de subjektiva kvalitetsönskemålen och därmed det yrkeskunnande och den erfarenhet som finns i projektet..

Jag tror att ovanstående är orsak till många av de dåliga och svåranvända produkter vi har i vår omgivning, att kvalitéer som inte är mätbara utelämnas, med- eller omedvetet, i leveranser.

Hotet mot kvalitet är management i allt för rigida former, har inte beställaren förståelse för subjektiv kvalitet och reserverar resurser för detta kommer leveransen också sakna kvalitéer. En ödmjuk (men kompetent) beställare kan nå mycket längre. Förtroende för yrkeskunnande och yrkesstolthet är en förutsättning. Egenskaper som inte kan ersättas med metoder.

Big Data - Hur BIG kan det bli?

“Big Data” är hype men hur stor kan det bli? Vilka kommer att tjäna pengar på detta?

“Big Data” är ett ganska nytt begrepp för att utvinna och härleda information ur stora datamängder. Tidigare har begreppet “data mining” används för att beskriva detta. Men “data mining” har oftast varit kopplad till att analysera det data man “råkar” ha, inte som man mer strategiskt samlat in för att kunna göra bättre analyser.

Om vi tar upp perspektivet leverantör-kund så kan man med “data mining” hitta mönster i vad kunder har köpt och vad potentiella kunder har frågat efter eller vilket mönster de haft när de besökt din hemsida. Du kan med detta underlag kan du anpassa ditt erbjudande.

Men...

Du har svårt att av de data du har tillgång till lära känna din kund utöver den relation ni har. Vilka konkurrerar du med om kundens gunst? Hur är kundens förhållande till dessa? Vad har kunden för andra intressen och hur kan dessa korsa dina? Detta har du svårt att veta utifrån de data kunden lämnat hos dig och din analys blir svår.

Men vilka kan göra en bättre analys om dina kunder än du själv kan? Jo de som vet mer om dina kunder än du själv vet. De som kan se relationen från båda sidor har ett klart övertag. Idag är det få aktörer som är stora på detta, främst är det  Google, Facebook, välfungerande underrättelsetjänster m.f. som sitter på mycket mer data än vad du själv kan samla in. Förmodligen kommer det snart gå att köpa analyser från flera av dessa gigantiska datalager men att köpa obearbetade data för egna analyser blir nog svårare.

Min slutsats är att Big Data bara blir BIG för de allra största.

Det kostar att ha otur när man tänker

Systemutveckling i sammanhanget utveckling av IT-system härrör sig (förhoppningsvis) från en intention i att utveckla någon form av verksamhet m.h.a. IT så att den upplevs bättre. Bättre lönsamhet, effektivitet, produktivitet, miljömässigt eller arbetsmiljömässigt eller anpassning till yttre krav. Intentionen bör vara uttalad och följa genom de projekt som startas.

Utöver projektens mål d.v.s. en formaliserad beskrivning av intentionerna sätts också ramar upp för de projekt som startas. Ramarna består ofta av en tidsplan, med eller utan delmål,  och en beskrivning vilka resurser som projektet får tilldelat.

Ett övergripande sätt att beskriva de steg ett utvecklingsprojekt för verksamheten kan vara:

Ursprunglig verksamhet                        Förändrad verksamhet

Idé--> Design--> Kodning--> Integration--> Leverans--> Förvaltning

Vad som är känt är att ju tidigare ett tankefel introduceras (som inte ifrågasätts och åtgärdas löpande) i projektet ju högre blir kostnaden för att åtgärda felet.

Konceptuella fel, designfel eller kodbuggar beror på “den mänskliga faktorn”, någon har haft otur i sitt tänkande.

För att fånga fel används tester och metoder för test utvecklas löpande. Men... avståndet i tid mellan att ett fel introduceras tills att det upptäcks med hjälp av tester kan vara ganska lång.

Etablerade testmetoder hanterar i huvudsak den kod som levereras i samband med leverans av delar eller hela systemet.

Designfel kanske inte upptäcks förrän integrations- eller leveranstester görs. Idéfel kanske upptäcks först i förvaltningsfasen. Ett designfel kan resultera i ett misslyckat och bortkastat projekt även om alla har gjort ett perfekt arbete i projektets senare skeden.

Ett “perfekt genomfört” projekt kan också betraktas som misslyckat om det inte genererar verksamhetsnytta. Har bakomliggande idé varit dåligt genomarbetad kommer projektet inte att generera förväntad nytta.

Det gäller alltså att så snabbt som möjligt fånga resultatet av de tankefel som de inblandade orsakar och övriga risker som föreligger så att bra beslut kan tas löpande i projekten. För att göra detta behövs bättre metoder för kvalitetssäkring av projektens tidiga faser.

Kvalitetssäkrar man inte alla projektsteg med korta loopar kan “otur när man tänker” bli dyrt.