W dniu 2012-03-28 00:01, Andrzej Jarzabek pisze:
> On 27/03/2012 18:24, Wojciech Jaczewski wrote:
[...]
>> 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?").

Właśnie wymieniłeś w przykładzie rolę analityka (zbieranie wymagań).
Czyli w zasadzie nie chodzi o certyfikowanie programistów, tylko co
najmniej całego zespołu, a może lepiej - procesu? A może po prostu
produktu?

[...]
> 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.

Otóż to - część. Inne wynikają z błędów na innych etapach procesu lub
w innym fragmencie konstrukcji.

Certyfikowanie zespołu lub poszczególnych jego członków (np.
programistów) daje mniejszy wkład w efekt końcowy - bezpieczniejszy
produkt. W "dziurawym" procesie certyfikowany zespół może wyprodukować
bubla. Nie mówiąc o tym, że brak certyfikacji wszystkich osób
odpowiedzialnych za jakość w ogóle mija się z celem - brak certyfikatu
jednej osoby pełniącej istotną rolę "unieważnia" certyfikację
pozostałych zaangażowanych w proces.

Czyli wracamy do podnoszonej tu przez kilka osób kwestii - lepiej
certyfikować produkt lub proces (być może oba).

--
Paweł Kierski
n...@p...net