On Tuesday, March 27, 2012 4:14:55 PM UTC+1, Andrzej Jarzabek wrote:
> On Mar 27, 7:42 am, zażółcony <r...@c...pl> wrote:
> > W dniu 2012-03-26 10:10, malkontent pisze:
> >
> > > certyfikaty dla finansistów i mafiozów ? :))))))
> >
> > Ha, dobry pomysł !
> > Przeprowadźmy badania i wymuśmy certyfikaty
> > na szeregowych maklerach giełdowych, coby
> > odpowiadali osobiście za ... wybuchy :)
>
> Żebyś się nie zdziwił:
> http://en.wikipedia.org/wiki/Stock_broker#Requiremen
ts

O rany, ja co pol roku musze jakies szkolenia przechodzic, na ktorych mnie pouczaja,
ze insider trading jest be.

Jerome Kerviel i Kweku Adoboli tez pewnie takie przechodzili ;-)

RW

do góry

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.

do góry

On 27/03/2012 18:46, Roman W wrote:
> On Tuesday, March 27, 2012 4:14:55 PM UTC+1, Andrzej Jarzabek wrote:
>> On Mar 27, 7:42 am, zażółcony<r...@c...pl> wrote:
>>> Ha, dobry pomysł !
>>> Przeprowadźmy badania i wymuśmy certyfikaty
>>> na szeregowych maklerach giełdowych, coby
>>> odpowiadali osobiście za ... wybuchy :)
>>
>> Żebyś się nie zdziwił:
>> http://en.wikipedia.org/wiki/Stock_broker#Requiremen
ts
>
> O rany, ja co pol roku musze jakies szkolenia przechodzic, na ktorych mnie
pouczaja, ze insider trading jest be.

To chyba niedokładnie to samo, co licencja stock brokera?

> Jerome Kerviel i Kweku Adoboli tez pewnie takie przechodzili ;-)

Niewątpliwie również odpowiadają osobiście.

do góry

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

do góry

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

do góry

W dniu 2012-03-28 10:34, Paweł Kierski pisze:

>> 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?

Otóż to. Zespoły, procesy produkcyjne, metodyki pracy.

do góry

On Mar 28, 9:34 am, Paweł Kierski <n...@p...net> wrote:
> W dniu 2012-03-28 00:01, Andrzej Jarzabek pisze:
>
> > 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ń).

Masz problem na styku dwóch ludzi, z których jeden wie, co program ma
robić, a drugi zna się na pisaniu programów. Pierwszą osobę możesz
nazwać analitykiem biznesowym, domain specialist, kleintem (z punktu
widzenia twórcy oprogramowania) itd. Druga osoba w ten czy inny sposób
jest programistą czy inżynierem oprogramowania.

I teraz ta pierwsza osoba może określić wymagania, czyli np. napisać
dokument, w którym opisze to, jak w jej rozumieniu program ma działać
- za pomocą języka naturalnego, tabelek, pseudokodu, rysunków,
diagramów, reguł, przykładów i tak dalej.

Niestety opis działania programu napisany w ten sposób może zawierać
niejasności, niejednoznaczność, sprzeczności, niedookreślenia.
"Zbieranie wymagań" o którym mówię, to jest to, że druga osoba bierze
te pierwotne wymagania, zauważa niejasności, niejednoznaczności,
niedookreślenia, sprzeczności i tak dalej, i dowiaduje się jakie są
faktyczne wymagania w tych sytuacjach. I to właśnie miałem w tym
kontekście na myśli przez "zbieranie wymagań". Możesz sobie te
czynności nazwać analizą biznesową i analizą techniczną, czy
jakkolwiek - w przypadku np. oprogramowania do samochodów taka
terminologia raczej nie ma sensu, bo obydwa etapy są "techniczne".

To, jak podzieloną masz pracę, czy np. pożądane działanie komputera
sterującego silnikiem będzie pisane przez "inżyniera mechanika" czy
przez "analityka" jest osobną sprawą. Natomiast w jakiejkolwiek
postaci nie dotrze ono do programisty, to nie będzie to działający
kod, więc będzie miało potencjalną możliwość być sprzecznym,
niejednoznacznym i nie obejmować pewnych przypadków. Natomiast
działający kod ma to do siebie, że nie za bardzo możesz mieć ścieżkę
logiczną czy kombinację wejść, z której nie będzie wynikało, jak
program się zachowa. Co najwyżej możesz mieć różne formy "undefined
behavior", ale właśnie jedną z rzeczy, jakie programista powinien
wiedzieć, to to, że nie należy przekładać specyfikacji, z której nie
wynika, jak program się ma zachować w jakichś warunkach, na program,
który w takich warunkach ma undefined behavior.

Oczywiście, że można sobie wyobrazić sposoby obejścia wymogu
certyfikacji, np. żeby między produkującego poprawny opis wymagań
certyfikowanego inżyniera mechanika, a certyfikowanego programistę,
wstawić niecertyfikowanego łosia "analityka", który nieumiejętnie
przełoży poprawny opis wymagań na jakieś sknocone UML-e czy inne
diagramy i kawałki pseudokodu zawierające błędy rzeczowe. I również
jest możliwość - w ramach certyfikacji programistów, na
"delegalizację" takich sytuacji. Ale też musisz przyznać, że takie
scenariusze są w sumie nie aż takie bardzo prawdopodobne, żeby
koniecznie warto było tworzyć na nie specjalną klauzulę - w porównaniu
do po prostu zatrudnienia przez producenta niekompetentnego
programisty.

> 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?

Chodzi o certyfikowanie programistów. A być może chodzi również o
certyfikowanie procesów i produktów. W zależności od tego, co by
wykazały ewentualne badania.

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

Nie unieważnia. To nie jest przecież tak, że jak kogoś nie
certyfikujesz, to on już na 100% jest niekompetentny. I nie jest tak,
ze jak kogoś certyfikujesz, to nie będzie w ogóle popełniał żadnych
błędów. Operujemy na prawdopodobieństwach pewnych zdarzeń. Jeśli (w
uproszczeniu) masz dziurawy proces, w którym program ma 10% szansy
pójść do produkcji bez testów, to jak wpływa na prawdopodobieństwo
wybuchu to, czy programista zrobi błąd powodujący wycbuch z
prawdopodobieństwem 0.1% czy z prawdopodobieństwem 50%?

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

No więc uważam, że nie da się na to pytanie odpowiedzieć gdybając.
Trzeba konkretnie policzyć wybuchy, przyczyny, prawdopodobieństwa
wystąpienia błędów na różnych etapach, oszacowac jak różne formy
certyfikacji wpływają na te prawdopodobieństwa, oszacować koszty i
porównać z kosztami i efentywnością innych środków poprawiających
bezpieczeństwo (ratujących życie, zdrowie, redukujących straty
materialne). Czyli zrobić te badania, o których pisałem.

Natomiast tak sobie gdybając mogę tylko powiedzieć, że skuteczność
certyfikacji zależy mocno od tego, na ile można powiedzieć "tak
właśnie to należy robić". I na przykład jeśli chodzi o procesy, to nie
wydaje mi się, żebyśmy w produkcji oprogramowania osiągnęli ten stan,
gdzie już wiadomo, jak proces powinien wyglądać, ewentualnie można
określić łatwo mierzalne parametry projektu, według których mozna
wybrać taki lub inny proces.

Nie wiem też, czy na przykład mamy taką wiedzę o testowaniu - czy
można powiedzieć: to a to każdy tester oprogramowania, niezależnie od
dziedziny czy używanych technologii, powinien wiedzieć lub umieć,
jeśli jest kompetentny. Może jest coś takiego, na mojego czuja nie -
ale nie znam się na tej dziedzinie.

Natomiast na programowaniu trochę się znam, i moje zdanie jest takie,
że właśnie w programowaniu, czy powiedzmy w "inżynierii
oprogramowania" doszliśmy do tego, że można taki korpus wiedzy,
umiejętności i praktyk wydzielić. Problem jest taki, że doszliśmy do
tego niedawno, powiedziałbym, że to może kwestia ostatniej dekady. I
jest tak, że wielu programistów robi źle, bo są mentalnie w latach 90-
tych (albo wcześniej), bo się uczyli "po staremu", bo wydaje im się,
że mogą sami wynaleźć koło od nowa i zrobią to lepiej (i być może
niektórzy z nich mogą, ale niech to robia na uniwersytetach, a nie w
fabrykach). Ale smutna (lub radosna, w zależnopści od punktu widzenia)
prawda jest taka, że czasy kowbojów się skończyły. Więc jest sens,
żeby zmiany w prawie dostosowały się do zmieniających się realiów.

do góry

W dniu 2012-03-02 03:44, A.L. pisze:
> W ciagu ostatnich paru lat w USA byl osporo wypadkow z udzialem
> niektorych model isamochodow Toyota - samochod gwaltownie przyspieszal
> i nie dawal sie zatrzymac. Sporo wypadkow bylo smiertelnych.
>
> Toyota twierdzila ze to wina dywanikow podlogowych albo zawiasow
> pedalu gazu. Byla masowa akcja wymiany dywanikow i pedalow gazu. W
> niektorych przypadkach osoby raportujace takie wypadki byly oskarzane
> o klamstwo i chec wyciagniecia odszkodowania.
>
> Ale... Ostatnio CNN wydostala dokumenty pokazujace ze jest blad w
> oprogramowaniu komputera pokladowego
>
> Experts: Translated Toyota memo shows electronic acceleration concern
>
> Washington (CNN) -- Toyota engineers found an electronic software
> problem that caused "sudden unintended acceleration" in a test vehicle
> during pre-production trials, according to a company engineering
> document obtained by and translated for CNN.
>
> The 2006 document, marked "confidential," recounted the results of an
> adaptive cruise-control software test in a model internally designated
> the 250L, a vehicle later sold as the Lexus 460 in Japan and Europe.
> The document says a "fail-safe overhaul" would be needed for another
> model in production, internally designated the 180L, which the company
> says was later sold as a Toyota Tundra..
>
> http://www.cnn.com/2012/03/01/us/toyota-memo-acceler
ation-concerns/index.html?hpt=hp_t1
>
> W artykuke linki do oryginalnych dokumentow i tlumaczen. Ciekawe do
> dyskusji na temat odpowiedzialnosci programistow


Dyskusja nam trochę siadła, może trzeba trochę podgrzać ?
A więc wracamy do pytania: czy programista systemu do tego
samochodu powinien mieć jakiś certyfikat ?

Filmik:
http://www.youtube.com/watch?feature=player_embedded
&v=cdgQpa1pUUE

do góry

On Monday, April 2, 2012 10:12:59 AM UTC+1, zażółcony wrote:

> Dyskusja nam trochę siadła, może trzeba trochę podgrzać ?
> A więc wracamy do pytania: czy programista systemu do tego
> samochodu powinien mieć jakiś certyfikat ?

Ide sie pociac.

RW

do góry

Użytkownik "zażółcony" <r...@c...pl> napisał w wiadomości
news:jlbqit$rcm$1@news.task.gda.pl...
>W dniu 2012-03-02 03:44, A.L. pisze:
>> [....]
>
>
> Dyskusja nam trochę siadła, może trzeba trochę podgrzać ?
> A więc wracamy do pytania: czy programista systemu do tego
> samochodu powinien mieć jakiś certyfikat ?
>
> Filmik:
> http://www.youtube.com/watch?feature=player_embedded
&v=cdgQpa1pUUE



Oczywiście, że powinien mieć, wszystkie certyfikat wymagane przez
pracodawcę.

tx

do góry