W dniu 2012-03-28 00:01, Andrzej Jarzabek pisze:
>> przez A.L. artykule, zaczynającym ten wątek, jakoś nikt nie odnosi się do
>> wypowiedzi żadnego software engineera, podczas gdy do wypowiedzi
>> electrical
>> engineera - tak. Jeśli omawiane w artykule zachowanie to jest to jakiś
>> błąd
>> w oprogramowaniu, to wynika on z nie-zauważenia jakichś szczegółów
>> związanych z elektryką, działaniem czujników,... a nie z programowaniem
>> samym w sobie.
>
> No więc inżynier oprogramowania nie musi się znać na elektryce i
> czujnikach, natomiast powinien się znać na zbieraniu wymagań. Również na
> takich rzeczach, jak np. stworzenie zestawu testów obejmujących jakieś
> przypadki brzegowe i zauważeniu, że np. specjalista od czujników
> opisujący, jak się ma zachowywać oprogramowanie w zależności od tego, co
> dostaje z czujników, zostawił pewną niewyspecyfikowaną plamę i podnieść
> temat do analizy przez domain experts ("a co jeśli ten czujnik mówi, że
> samochód przyspiesza, a tamten, że koła kręcą się coraz wolniej?").

Opisywałem podobny przypadek z rezystorem. W 90% przypadków podmiana
rezystora na podobny nie robi różnicy w działaniu, ale są przypadki, że
jednak ma to znaczenie. Wychodzi to dopiero przy testach - jeśli takowe
się przeprowadza, a czasem dopiero podczas eksploatacja, ponieważ przez
pierwszy okres czasu (w którym jest wykonywany test) wszystko działa
dobrze.

> Oczywiście nic nie wyeliminuje błędów powstałych z nieprawidłowej
> specyfikacji wymagań, ale porządnie zrobione zbieranie wymagań eliminuje
> jakąś, wydaje mi sie że dość znaczną, ich część.

Szczególnie, że oprogramowanie i sprzęt powstają zazwyczaj równolegle, a
specyfikacja sprzętu czasem ulega modyfikacji z różnych przyczyn....

> Dodatkowo część błędów w oprogramowaniu również wynika z błędó typowo
> programistycznych: błędnej logiki, race conditions, różnego rodzaju
> undefined behaviour i tak dalej.

W oprogramowaniu dla ludzi tak, w oprogramowaniu specjalistycznym -
raczej mało prawdopodobne, co nie znaczy, że zdarzyć się nie może.

> I jeszcze raz apiać: celem certyfikacji nie jest spowodowanie, że awarii
> spowodowanych błędami w oprogramowaniu nie będzie w ogóle, tylko że
> będzie ich mniej. Wydaje się sensownym założeniem, że jeśli się będzie
> lepiej zbierać i analizować wymagania, i będzie się popełniać mniej
> błędóww programistycznych, to ogólnie błędów będzie mniej.

Nie potrafisz pokazać, że błędów będzie mniej. Stawiasz jedynie tezę, ja
stawiam więc tezę inną - nie będzie mniej.


> Czy
> certyfikacja to da, i jeśli da, to czy zmniejszenie ilości awarii będzie
> na tyle istotne, że będzie to warto zrobić, to moim zdaniem warto zbadać
> sprawę.

To zbadaj - za swoje pieniądze....



--
Kaczus
http://kaczus.republika.pl