On Thu, 14 Apr 2011 21:13:24 +0200, Michal Kleczek <k...@g...com>
wrote:

>
>To jakies waskie pojmowanie "prawidlowego zachowania oprogramowania".
>
>Niewatpliwie wypadek byl spowodowany wadliwym dzialaniem systemu
>komputerowego. Co wiecej - nie byla to awaria sprzetu (tzn. nic sie nie
>spalilo, ani tez nie nastapila np. przypadkowa zmiana zawartosci pamieci),
>lecz wadliwe dzialanie oprogramowania, ktore nie bylo przygotowane na
>obsluge rzeczywistych danych wejsciowych. Nie nazwalbym tego "software
>zachowal sie prawidlowo". To, ze zachowal sie zgodnie z jakas tam
>specyfikacja nie oznacza, ze zachowal sie prawidlowo.
>

Software zachowuje sie prawidlowo jezeli dziala zgodnie ze
specyfikacja. Specyfikacja moze byc nieprawilowa.


>Operacja sie udala, pacjent zmarl. MSPANC
>
>>
>> Nie znam formalnych metod ktore sprawdzalyby poprawnosc i logike
>> zalozen projektowych.
>>
>
>Czyli stosowanie metod formalnych nie zapobieglo wypadkowi.
>Nie znam sie na metodach formalnych, ale wydawalo mi sie, ze stosowanie ich
>ma zapobiegac pojawianiu sie bledow zarowno w implementacji jak i
>_specyfikacji wymagan_ .

Zalezy gdzie sie zaczyna owa "specyfikacja". W przypadku Ariadne 5 byl
blad ludzki: nie powinno sie adaptowac modulu z Ariadne 4. Natomiast
nei wiem czy specyfikacja porgramu mowiaca ze komputer ma byc
wylaczony gdy zakres liczb zostanie przekroczony byla specyfikacja
sensowna czy nie. Takie rzeczy nie poddaje sie zadnym formalnym
sprawdzianom.

A.L.