On Dec 18, 1:18 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> >> Ja bym raczej powiedzial na chlopski rozum, ze dokumentacja definiuje
> >> co jest bugiem, a co nie.
>
> > Bingo.
>
> Czyli jeśli zachowując się zgodnie z dokumentacją program doprowadza do
> wybuchu elektrowni ataomowej, to nie ma buga, po prostu to właśnie miał
> zrobić?

Jak na ironię, dokładnie tak tłumaczy się przypadek Ariane V. Kupa
dymu, bo program zadziałał zgodnie ze specyfikacją.

Żatry na bok, ale w powyższym przypadku jest bug w dokumentacji. Jej
zaletą jest fakt, że łatwiej znaleźć buga w dokumentacji, która
istnieje, niż w dokumentacji, która nie istnieje. W szczególności,
dokumentacja jest materiałem, który odtwarza się w posób powtarzalny,
podczas gdy rozmowy z OSCR mogą zawierać składnik stochastyczny
zależny od tego, ile kawy OSCR w danym dniu wypił.
Dlatego dokumentację można np. powielić i dać do audytu. Nawet
równoległego, przez wielu obserwatorów. OSCR takich ficzerów nie ma.

Nadal wolę dokumentację, zwłaszcza w przypadku elektrowni atomowej.

> > No właśnie. Bo jeśli program działa niezgodnie z istniejącą
> > dokumentacją, to coś należy poprawić. Ale jeżeli działa niezgodnie z
> > nieistniejącą dokumentacją, to projekt jest w ciemnej d*pie. I to jest
> > właśnie ta perspektywa, której się obawiam.
>
> Jeżeli działa niezgodnie z nieistniejącą dokumentacją, to nie przechodzi
> testów i nie może zostać zreleasowany.

Jakich testów? Tych, które powstały na podstawie nieistniejącej
dokumentacji i są z tą nieistniejącą dokumentacją niezgodne?

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com