On 27/03/2012 18:24, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>>
>> Poza tym jak widać na przykładzie owego samochodu, nie tylko odbiorca
>> oprogramowania może być poszkodowany przez błędy w tymże. Nawet jeśli
>> mój samochód nie ma takiego buga, wolałbym, żeby inny w
>> niekontrolowany sposób przyspieszający samochód nie wbił się w mój ani
>> nie rozjechał mnie na pasach.
>
> A teraz zastanówmy się: jaki związek ma tego typu oprogramowanie w
> samochodzie z certyfikatami dla programistów?

Hmm, pomyślmy... o, już wiem: otóż związek jest taki, że tego typu
oprogramowanie piszą programiści.

> Żeby był jakiś związek, powinniśmy omawiać celowość posiadania przez
> programistów certyfikatów z mechaniki i elektryki samochodowej. We wskazanym

Niby dlaczego? Od tego masz odpowiednich inżynierów, którzy jak
najbardziej mogą mieć odpowiednie certyfikaty w swoich dziedzinach.

> 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?").

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ęść.

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.

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. 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ę.

I pewnie oczywiście tak jest, że Toyota zatrudnia akurat niezłych
programistów, ale też coraz bardziej jest tak, że program, który może
zabić albo zrobić krzywdę może sterować kuchenką mikrofalową albo
boilerem gazowym albo jakąś frezarko-tokarką, a już producenci tego
sprzętu mogą nie mieć tak wysokich standardów jeśli chodzi o
zatrudnianie programistów, jakie być może ma Toyota.