On Mar 22, 10:40 am, zażółcony <r...@c...pl> wrote:
> W dniu 2012-03-21 17:07, Andrzej Jarzabek pisze:
[...]
> Natomiast z oprogramowaniem jest nieco inaczej, dlatego, że
> najczęściej pełni ono rolę usługową, pomocniczą, jest 'przykryte'
> kompetencjami usług, które z niego korzystają. Np. jeśli
> oprogramowanie CAD ma błąd i źle wylicza jakieś parametry
> budynku, to odpowiedzialności za ten stan rzeczy nie bierze
> programista, tylko w dalszym ciągu bierze ją architekt,
> który takie oprogramowanie wybrał do swojego użytku.

No właśnie nie zawsze tak jest jak piszesz, często oprogramowanie
steruje różnymi rzeczami w czasie rzeczywistym i nie bardzo jest
możliwość skorygowania jego błędów. Jeśli np. na wskutek błędu w
oprogramowaniu samochód zacznie w niekontrolowany sposób przyspieszać,
to jest całkiem p-rawdopodobne, że certyfikowany kierowca nie będzie
mógł zbyt wiele zrobić, żeby uniknąć wypadku.

Dalej: nawet jeśli jest taka możliwość, powiedzmy jak w samolocie,
gdzie certyfikowany pilot może zdać sobie sprawę, że komputer
pokładowy wariuje, wyłączyć go i przejść na ręczne sterowanie, to nie
oznacza, że żle działające oprogramowanie nie jest poważym problemem,
bo za ewentualną katastroffę odpowiada pilot a nie producent
oprogramowania.

Dalej: użytkownik oprogramowania często w ogóle nie jest
certyfikowanym specjalistą, tylko zwykłym konsumentem. Jeśli ktoś np.
korzysta z bankowości internetowej, i wykorzystując błędy w
oprogramowaniu na jego pececie przestępcy wyczyszczą mu konto i
jeszcze nabiją na maksa kredyt, to raczej trudno powiedzieć, że
użytkownik sam sobie winien, bo skoro ma peceta, to powinien wiedzieć,
jak go zabezpieczyć przed takim atakiem.

> Ale dobijając do brzegu: dopóki architekci budynków
> sami nie domagają się, by część odpowiedzialności zrzucić
> na "architektów oprogramowania" to imo nie ma o czym mówić,
> po prostu nie ma problemu. Oznacza to, że czują się
> bezpiecznie, pomimo złożoności oprogramowania narzędziowego
> mają poczucie kontroli nad sytuacją i odpowiedzialność
> jest ustawiona właściwie.

No więc ja, jako użytkownik samochodów, samolotów, potencjalny pacjent
diagonozowany i leczony aparaturą medyczną, być może mieszkaniec
obszaru, będącego w zasięgu rażenia elektrowni atomowej, potencjalna
ofiara przestępców internetowych, i tak dalej, domagam się żeby
podejmować jakieś działania redukujące ryzyko mojej szkody. Domagam
się w ramach tego, żeby prowadzić badania na temat tego, jakie
działania przynoszą dobre rezultaty w stosunku do kosztów. I jeśli z
tych badań wyjdzie, że certyfikacja programistów, w jakichś
sytuacjach, w jakimś zakresie, byłaby odpowiednio skutecznym, w
stosunku do kosztów, środkiem, to domagam się, żeby olać marudzenie
kolesi, którzy np. mówią, że certyfikacja zła, bo wolny rynek cośtam
cośtam. I tyle.

Co z takich badań ewentualnie wyjdzie, tego oczywiście nie wiem. Gdyby
było wiadomo, to nie trzeba by robić badań. Może zresztą są jakieś
badania, ale ja nie śledze tematu, nie znam się na tym, więc i tak bym
nie wiedział. Ale gdyby metodologie były już opracowane, dane zebrane,
wnioski wyciągnięte, i należałoby się tylko po nie schylić, to tym
bardziej uważam, że państwo powinno się schylić i skorzystać z tych
wniosków.

> I w taki imo sposób należałoby podejść do całości
> zagadnienia - nie od pomysłu 'certyfikacji informatyków'
> w reakcji na bardzo ogólny problem "śmiertelny BUG",
> ale przez przegląd różnych branż uzależnionych
> od oprogramowania - i zbadania, czy właściwie są tam
> 'sparowane' kompetencje z odpowiedzialnością.

Problem jest taki, że ryzyko się kumuluje. Weź na przykład lotnictwo
cywilne: oczywiście, w wielu przypadkach katastrofy spowodowanej
błędem oprogramowania można powiedzieć "błąd pilota". Tylko że
postulat, żeby każdy pilot był tak wyszkolony, żeby nie popełniał
błedów nawet w najbardziej niesprzyjających warunkach, w momencie
kiedy wszystkie instrumenty podają mu nieprawdziwe dane, to fikcja.
Piloci cywilni już są certyfikowani, certyfikacja do przewożenia
pasażerów liniami lotniczymi i tak już jest ekstremalnie rygorystyczna
- jeśli podwyższysz wymagany poziom kwalifikacji tak, żeby tylko co
dziesiąty dzisiaj latający pilot mógł latać, to po prostu zarżniesz
lotnictwo. Jeśli powiesz pilotom, że nie mogą polegać na komputerze
pokładowym, to równie dobrze możesz ten komputer wymontować i wywalić
do śmieci. Co zresztą z punktu widzenia bezpieczeństwa byłoby
kompletnie bez sensu: komputery w samolotach znacznie częściej
zapobiegają czy korygują błędy pilotów, niż same generują błędy,
którym mógłby ewentualnie zapobiec pilot, gdyby go nauczyć nie ufać
komputerom.

Tak więc być może zwiększenie niezawodności opgrogramowania byłoby
skuteczniejszym sposobem zwiekszenia bezpieczeństwa lotów, niż zmiana
sposobu certyfikacji lub szkolenia pilotów. I być może właśnie
certyfikacja programistów byłaby najlepszym sopsobem na zwiększenie
niezawodności oprogramowania samolotów.

> Moim zdaniem informatyzacja wszystkiego i postęp złożoności
> jak najbardziej wymusza wprowadzanie nowych mechanizmów
> kontroli i odpowiedzialności, ale te same zjawiska
> powodują również, że certyfikowanie LUDZI jest
> niewystarczające/nieadekwatne. Certyfikacji podlegają
> całe systemy informatyczne, instytucje, procesy produkcyjne
> i przyklepują ich np. tak jak u nas - osoby ze specjalnymi uprawnieniami.

Jedno drugiego nie wyklucza. A chyba nie spodziewasz się, że audytor
zatwierdzający certyfikację typu ISO 9000 będzie mógł zauważyć, że
oprogramowanie używa wątków, a nie synchronizuje poprawnie dzielonych
danych. Albo choćby że kod jest nieczytelny.

> Bardzo istotne jest też to, że są to osoby Z ZEWNĄTRZ,
> czyli minimalizuje się przy okazji zjawisko KONFLIKTU
> INTERESÓW.

Jakoś przy budowie mostó niezależnie od tego, że masz nadzór z
zewnątrz, masz też wymóg certyfikacji inżynierów.