Shipping buggy code: The most critical skill for a programme

C, C++, Pascal, Assembly, Raspberry, Java, Matlab, Python, BASIC, SQL, PHP, etc.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45168
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av TomasL »

swesysmgr skrev:
TomasL skrev:Det finns ett obegränsat antal icke simulerbara händelser i alla system, vilka kan få systemet att uppträda helt oberäkneligt.
Nej varför det? Du har begränsat med input och du vet exakt hur ditt system kommer att bete sig. Skall din krets som du verifierat bestrålas i rymden eller köras utanför specat temperaturområde då går det nog inte.
Problemet är att du inte kan begränsa din input, eftersom du kan få störningar utifrån som är omöjliga att ta bort, vilket kan ge dig fullständigt oberäkneliga indata, trigga multipla interrupt osv, blottlägga svagheter i kislet osv i all oändlighet.
Nerre
Inlägg: 26654
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av Nerre »

Mr Andersson skrev: Jag påstår att det är omöjligt att göra ett test som täcker 100% utan att testa 100% av all möjlig indata. Även om det går att matematiskt/statistiskt bevisa att koden är felfri kan det finnas kompilator- eller hårdvarubuggar som man inte vet om.
Det är visserligen sant, men om vi har en modul i en mjukvara som tar en byte som indata så behöver man väldigt sällan testa alla 256 varianterna.

Om programmet klarar att värdet är 7 borde det också klara 8, 9, 10 etc. Det som är mest relevant att testa är ju extremerna och sånt som kan påverka interna beräkningar (man kan alltså inte testa modulen som en svart låda, man måste veta vad som händer inuti för att kunna testa den på ett korrekt sätt).

Det är just därför som det här med testbarhet måste vara med redan från början, modulerna måste skrivas så att de kan testas. Att ta valfri "svart låda" och tro att man kan testa att den gör som den ska fungerar inte (eftersom man inte vet vad den har för hyss för sig internt, har den t.ex. nån form av "minne" så kan ju ett test ge olika resultat från gång till gång).
Nerre
Inlägg: 26654
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av Nerre »

Andax skrev:Swesysmgr, men problemet kvarstår fortfarande om modellen representerar verkligheten/problemställningen tillräckligt bra?
Gör den inte det kan man visserligen klappa sig på axeln och säga att modellen garanterat uppför på ett predikterbart sätt, men kanske inte som behövs för att lösa problemet.
Men det är nästa steg i det hela.

Att verifiera att nånting beter sig som det ska är det man brukar kalla för verifiering.

Att sen testa att det som den gör är det som den borde brukar kallas validering.

Det är två ganska olika saker, som ofta blandas ihop (antagligen eftersom båda börjar på V och man ofta pratar om "verifiering och validering").
Nerre
Inlägg: 26654
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av Nerre »

Icecap skrev: Att fixa en hastighetshållning är inte så svårt, det svåra är alla ting som sker och vad som ska hända då.
* Krock.
* Dålig hastighetssensor (t.ex. ABS-ringen som börjar bli dålig)
* Över/undervarv.
* Växel blir ryckt ur.
osv.
Men dessa saker identifierar man ju i den riskanalys som man lämpligen gör om det är kritisk mjukvara.

Är det riktigt kritiska system så gör man ju som i t.ex. JAS, man har flera separata system som så att säga övervakar varandra. I och med att alla systemen är designade på olika sätt så drabbas de sannolikt inte på samma sätt av samma störning.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45168
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av TomasL »

Jo, men då är inte programvaran/systemet i sig buggfritt, utan man accepterar en viss nivå på fel, och hoppas att samma fel inte skall utveckla sig samtidigt i övriga system.
Detta är något helt annat än buggfri kod, som tråden handlar om, efter vad jag förstått.

Förutom det är det faktiskt en definitionsfråga "vad är buggfri kod" eftersom en sann buggfri kod aldrig går att uppnå.
Användarvisningsbild
swesysmgr
Inlägg: 14127
Blev medlem: 28 mars 2009, 06:56:43
Ort: Göteborg

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av swesysmgr »

TomasL skrev:
swesysmgr skrev:
TomasL skrev:Det finns ett obegränsat antal icke simulerbara händelser i alla system, vilka kan få systemet att uppträda helt oberäkneligt.
Nej varför det? Du har begränsat med input och du vet exakt hur ditt system kommer att bete sig. Skall din krets som du verifierat bestrålas i rymden eller köras utanför specat temperaturområde då går det nog inte.
Problemet är att du inte kan begränsa din input, eftersom du kan få störningar utifrån som är omöjliga att ta bort, vilket kan ge dig fullständigt oberäkneliga indata, trigga multipla interrupt osv, blottlägga svagheter i kislet osv i all oändlighet.
Jag vet inte vad du menar med "svagheter i kislet" men tillverkningsdefekter tar naturligtvis inte formell validering, inte heller slumpmässiga störningar utifrån utan det handlar om att bevisa att modellen av kretsen eller programmet är 100% logiskt korrekt vilket är fullt möjligt.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av lillahuset »

Jag får väl citera ur artikeln igen:
Despite the huge record of failing applications caused by simple “bugs”, many software developers insist that they can deliver flawless and completely bug free applications!

Whenever I hear something like this, I am sure that it represents the view of a junior and not very talented programmer who sounds like a salesman trying to please the ears of his audience!
Realistiskt sett får man väl utgå från att vi inte får se speciellt många icketriviala felfria program det här århundradet heller. En bra målsättning kan väl vara "good enough" som rogerk8 brukade använda.

Edit: swesysmgr, hur hanterar du multipla interrupt som kommer med slumpmässig timing?
Nerre
Inlägg: 26654
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av Nerre »

TomasL skrev:Jo, men då är inte programvaran/systemet i sig buggfritt, utan man accepterar en viss nivå på fel, och hoppas att samma fel inte skall utveckla sig samtidigt i övriga system.
Nja, inte riktigt. Det är snarare så att man är medveten om att det kan inträffa störningar som man inte har kunnat förutse. Man försöker ändå se till att det inte finns några detekterbara buggar i koden.

Det är i princip samma metodik för att verifiera mjukvara som för att verifiera diskret logik.

En AND-grind kan du testa med 4 olika kombinationer av input och på så vis visa att den beter sig som förväntat. Men även den kan påverkas av yttre störningar.

Om du har en bunt logik-kretsar som var och en har verifierats fungera som den ska, så kan du av dem bygga ett logiknät som du då kan förutsätta att det fungerar som det ska, utan att behöva testa igenom alla möjliga bitkombinationer i hela logiknätet.

Det är så man t.ex. gör när man verifierar en räknare, som jag beskrev tidigare. Istället för att låta räknaren räkna från 0 tills den wrappar igenom så testar man istället de inbyggda vipporna var för sig. Fungerar alla vipporna och interfacet mellan dem som kommer räknaren att fungera som den ska. Med en 32-bitars räknare innebär det kanske ett par dussin test, istället för att man ska stega igenom 4 miljarder steg.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45168
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av TomasL »

Nerre, det du pratar om är redundanta system, inte felfria system.
Det är två helt skilda saker, och har i princip inget med felfri kod att göra.
Mr Andersson
Inlägg: 1394
Blev medlem: 29 januari 2011, 21:06:30
Ort: Lapplandet

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av Mr Andersson »

Nerre skrev:
Mr Andersson skrev: Jag påstår att det är omöjligt att göra ett test som täcker 100% utan att testa 100% av all möjlig indata. Även om det går att matematiskt/statistiskt bevisa att koden är felfri kan det finnas kompilator- eller hårdvarubuggar som man inte vet om.
Det är visserligen sant, men om vi har en modul i en mjukvara som tar en byte som indata så behöver man väldigt sällan testa alla 256 varianterna.

Om programmet klarar att värdet är 7 borde det också klara 8, 9, 10 etc. Det som är mest relevant att testa är ju extremerna och sånt som kan påverka interna beräkningar (man kan alltså inte testa modulen som en svart låda, man måste veta vad som händer inuti för att kunna testa den på ett korrekt sätt).

Det är just därför som det här med testbarhet måste vara med redan från början, modulerna måste skrivas så att de kan testas. Att ta valfri "svart låda" och tro att man kan testa att den gör som den ska fungerar inte (eftersom man inte vet vad den har för hyss för sig internt, har den t.ex. nån form av "minne" så kan ju ett test ge olika resultat från gång till gång).
Absolut, du behöver inte testa alla invärden. Det räcker som du säger med att testa vissa invärden för att få ett rimligt antagande att koden fungerar korrekt för alla indata. Men vi pratade om att bevisa felfrihet. För att bevisa att koden aldrig kommer att göra någonting ospecificerat måste du bevisa att hela kedjan, från användare, till hårdvaran, till kvantfysiken som bestämmer elektronernas beteende, är felfri. Vilket i princip är omöjligt.
Användarvisningsbild
swesysmgr
Inlägg: 14127
Blev medlem: 28 mars 2009, 06:56:43
Ort: Göteborg

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av swesysmgr »

lillahuset skrev:Jag får väl citera ur artikeln igen:
Despite the huge record of failing applications caused by simple “bugs”, many software developers insist that they can deliver flawless and completely bug free applications!

Whenever I hear something like this, I am sure that it represents the view of a junior and not very talented programmer who sounds like a salesman trying to please the ears of his audience!
Realistiskt sett får man väl utgå från att vi inte får se speciellt många icketriviala felfria program det här århundradet heller. En bra målsättning kan väl vara "good enough" som rogerk8 brukade använda.
Jo visst för det mesta är det så, får någon fel topping på sin pizza pga. logiskt fel i koden då är alternativkostnaden att bjuda på en ny pizza gratis men måste du stoppa ditt mobilnät i hela landet och debiterar 0:- medans du felsöker och startar om samtidigt som en skitstorm i Postnord-klass drar in över din Facebooksida då duger inte "good enough" och kostnaden för dyra kravfångst- och verifieringskonsulter blev peanuts.
lillahuset skrev:Edit: swesysmgr, hur hanterar du multipla interrupt som kommer med slumpmässig timing?
Det vet jag inte på rak arm men jag hade försökt arrangera dem i prioritetsordning (nivåer) för att oklarheter aldrig skall kunna uppstå och sedan formellt verifierat att det fungerar som planerat och att systemet fortsätter rulla även om någon hamrar in nivå-0 interrupts.
Användarvisningsbild
swesysmgr
Inlägg: 14127
Blev medlem: 28 mars 2009, 06:56:43
Ort: Göteborg

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av swesysmgr »

TomasL skrev:Nerre, det du pratar om är redundanta system, inte felfria system.
Det är två helt skilda saker, och har i princip inget med felfri kod att göra.
Nej du använder samma idéer och verktyg för att verifiera hårdvara som mjukvara.

Redundant system är för mig när du har parallell hård- och mjukvara som övervakar varandra och kan träda in i varandras ställe, logiskt korrekt och 100% verifierat är något annat.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av lillahuset »

swesysmgr: Jodå, "good enough" duger utmärkt. Det är bara att definitionen blir lite annorlunda.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45168
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av TomasL »

Swesys, Vilket vad det Nerre skrev om.
Multipla system med samma hårdvara som körs parallellt och övervakar varandra.
Nerre
Inlägg: 26654
Blev medlem: 19 maj 2008, 07:51:04
Ort: Upplands väsby

Re: Shipping buggy code: The most critical skill for a progr

Inlägg av Nerre »

Mr Andersson skrev: För att bevisa att koden aldrig kommer att göra någonting ospecificerat måste du bevisa att hela kedjan, från användare, till hårdvaran, till kvantfysiken som bestämmer elektronernas beteende, är felfri. Vilket i princip är omöjligt.
Nu blandar du ihop att visa att hela lösningen fungerar som avsett med att enbart koden fungerar som avsett.

Blir det "fel" på hårdvaran är det inte "fel" på koden.
Skriv svar