W dniu 2011-01-20 11:38, Andrzej Jarzabek pisze:

> Jeśli natomiast wszyscy certyfikowani specjaliści w danej dziedzinie
> mówią, że nie da się czegoś zrobić, to masz raczej niewielkie szanse
> na to, że zrobi to zespół ludzi, którzy z różnych powodów takiego
> certyfikatu zrobić nie mogą (bo nie przeszli przeszkolenia, bo nie

Ty chyba żyjesz w świecie alternatywnym. Specjalista certyfikowany nie
jest i nigdy nie będzie alfą i omega w danej dziedzinie. Bo jeśliby aż
tak zaostrzyć kryteria wydawania certyfikatów to nikt nie byłby w stanie
go dostać.

> Ale z tego tylko wynika, że "dawanie gwarancji" w takim sensie jest
> bzdurnym kryterium, bo po pierwsze nic nie daje gwarancji, po drugie
> między dwoma sytuacjami, gdzie w obydwu "mnie ma gwarancji" może być
> nadal kolosalna różnica.

Oczywiście że jest bzdurne, bo gdzieś na początku musi być jednostka
zaufana wystawiająca certyfikaty pierwszego poziomu. I jeśli któraś z
długiego łańcuszka certyfikacji zawiedzie to pozostałe są guzik warte.

> No więc tak jak pisałem: to, że teraz Ty trzaskasz, a po ewentualnej
> certyfikacji będzie ewentualnie trzaskać ktoś inny, to jest coś, co
> obchodzi Ciebie i być może Twoją Starą, ale nie łudź się, że kogoś
> jeszcze.

Nie rozumiem? Ty pracujesz za darmo? Czy może dla korporacji
certyfikującej i płaczesz że Ty nie możesz zarobić. To znowu mnie w
ogóle nie interesuje. Dla mnie ze Swoją Starą możesz nawet pod mostem
siedzieć...

>> Jednostka certyfikująca wydała certyfikat dla programisty (w domyśle też
>> wydała go za kasę, niedostatecznie testując itd itp). Programista pisze
>> oprogramowanie, co jest jednoznaczne (wg tego co piszesz) z tym, że
>
> Niczego takiego nie pisałem, ale załóżmy, że tak.

A to ja pisałem?

>> IMHO Zresztą chore jest implikowanie że jeśli produkt jest wykonany
>> > przez osobę z certyfikatem to ten automatycznie też jest uważany za
>> > certyfikowany.
>W niektórych przypadkach to jest najsensowniejsze podejście.

> Ja bym to raczej widział tak:
> Program się sypie, więc jest prowadzone dochodzenie. W ramach

Jak czytam takie brednie o dochodzeniach, to mi przypomina działania
jednej partii...
Po pierwsze dojście do jakichkolwiek ustaleń jest prawie niemożliwe,
chyba że jednostka certyfikująca sama się podłoży (co jest nielogiczne).
Problem będzie jeśli błędnie wydany certyfikat jest znikomym procentem
ogółu.

> Przy czym akurat właśnie w przypadku oprogramowania testowanie
> laboratoryjne jest na tyle nieskuteczne, że rzeczywistym winnym awarii
> programu certyfikowanego przez laboratorium będzie faktycznie nie samo
> laboratorium, bo ono mogło przeprowadzić swoje testy rzetelnie, tylko
> debil, który zdecydował, że dla oprogramowanie wymagane są testy
> laboratoryjne zamiast certyfikacji procesu.

Ale przecież ten 'debil' ma certyfikat skoro pracuje w jednostce
certyfikującej.
Wybacz, ale sposób certyfikacji i testowania na dzisiaj określają trochę
mądrzejsze głowy (i całe szczęście).

> W jednym i w drugim przypadku mówimy o certyfikacji oprogramowania.
> Pytanie tylko, co jest warunkim certyfikacji: czy przejście przez to
> oprogramowanie testów laboratoryjnych wykonanych przez certyfikowane
> laboratorium zatrudniające certyfikowanych testerów, czy certyfikacja
> procesu, gdzie certyfikowany pracownik producenta zatwierdza, że
> oprogramowanie zostało wykonane zgodnie z pewnymi normami, które
> dotyczą _między innymi_ tego, że kod został napisany i/lub
> zatwierdzony przez certyfikowanego programistę, plus ewentualnie
> połączenie jednego z drugim.

A co ma do tego certyfikacja pracownika??? Od tego są normy ISO i ich
wdrożenie w firmie, szkolenie pracowników i ich stosowanie się do tych
norm. A to że pracownik nie musi mieć certyfikatu, to już bolączka firm
certyfikujących bo nie mogą sobie dodatkowej kaski zarobić.

Poza tym wycofujesz się okrakiem z swoich słów, że jeśli program
wytworzony jest przez certyfikowanego programistę to wynika z tego że
program jest certyfikowany. A teraz wprowadzasz jeszcze certyfikacje
przez jednostki tego programu.

> Dla mnie pierwszy sposób certyfikacji ma nikłą wartość ze względu na
> wielkość przestrzeni zmiennych programu: wadliwe programy często sypią
> się w bardzo specyficznych warunkach, które nigdy nie wystąpiły przy
> testowaniu, gdzie np. występuje bardzo rzadka kombinacja danych
> wejściowych i relacji czasowych między nimi. Laboratorium ma bardzo
> małe szanse wykrycia tych sytuacji na ślepo, znacznie mniejsze niż
> porządny proces trestowania wewnętrznego i UAT, które mogą być
> wymagane przez certyfikację procesu. Najbardziej efektywnym sposobem
> uniknięcia tych błędów jest stosowanie odpowiednich praktyk i wymóg
> pisania i/lub recenzowania kodu przez programistów z odpowiednią
> wiedzą i wykształceniem obejmującym rozmaite aspekty inżynierii
> oprogramowania.

Naprawdę? A jedno drugie wyklucza? Żeby otrzymać CE na oprogramowanie i
zarejestrować produkt w klasie medycznej trzeba mieć między innymi
certyfikat ISO w firmie. Firma więc musi przestrzegać odpowiednich
praktyk w zakresie wytwarzania produktów.

> Masz zatem w tej sprawie konflikt interesu który powoduje, że Twoje
> opinie są nic nie warte.

To samo mogę stwierdzić w stosunku do Ciebie. Dla mnie Twoje opinie są
nic nie warte, choćby dlatego, że piszę już któryś raz, że kwestie
dotyczące zarobku są mało ważne w kontekście problemu, a Ty się ich
uczepiłeś jak obłąkany i dodatkowo zszedłeś na poziom "Twojej Starej" co
jest świadczy tylko o Tobie.

Jeśli chcesz dyskutować merytorycznie, z tezami popartymi doświadczeniem
to proszę bardzo, jeśli chcesz uprawiać wycieczki osobiste i prezentować
widzimisię zamiast być obiektywnym to dla mnie EOT.

pozdrawiam,
Przemek O.