How Is Critical 'Life or Death' Software Tested?
Hogyan csökkenthető ezredrészére a hibák száma? Miért nem elég még ez sem? Mit tehetünk még a biztonságért?
■ H | K | Sze | Cs | P | Szo | V |
---|---|---|---|---|---|---|
25 | 26 | 27 | 28 | 29 | 30 | 1 |
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 | 1 | 2 | 3 | 4 | 5 |
Az igazi tanulság
A blogmarkban jelzett cikkhez észrevételek még itt.
Emlékezetes eset volt az Ariane 5 felrobbanása is. Az okairól és a megelőzésükről anno sok vita folyt. Bertrand csak arról hallgat, mit eredményezett volna a DbC a rakéta fellövése után :), akár bekapcsolva hagyták volna az ellenőrzéseket, akár nem.
Ha nem kritikusak a válaszidők, akkor érdemes futásidőben is ellenőrizni az elő- és utófeltételeket, az Eiffel DbC-jéhez hasonlóan. Az "igazi" DbC több ennél, és nyelvi támogatás nélkül nem érhető el (nem csak assertek kellenek, hanem örökölt invariánsok is, ahhoz pedig szigorú OOP), de ettől még nagyon hasznosak az ilyen "félszívű" ellenőrzések is.
Eiffel for embedded systems at Hewlett-Packard, avagy hogyan találtak meg hardverhibát és örökölt kódbeli bugokat nyomtatókban.
Konkurens kódokhoz Eiffelben nincs a Góéhoz hasonló race detector, újabb példa a nyelv(i eszközök) fontosságára.
Az igazi tanulság szerintem az, hogy 1) minden lehetséges eszköz jól jöhet a hibák kiküszöböléséhez 2) a megelőzés fontosabb, mint a "gyógyítás".
Vannak még érdekes és értékes példák, jó lenne, ha az új hozzászólások előre hoznák a régebbi blogmarkokat a listában :). Enélkül fontos témák süllyednek el.
Az Ariane esetében érdemes
Egyszer érdekes volna látni egy kimutatást arról, a hibák hány százalékát okozza a felhasznált külső megoldás működésének elégtelen ismerete.
Fatal A400M crash linked to data-wipe mistake
DevOps szakemberek csóválják