On Jan 19, 6:29 pm, "Przemek O." <p...@o...eu> wrote:
> W dniu 2011-01-19 17:41, Andrzej Jarzabek pisze:
>
> >> Tia, ale osoba posiadaj ca wymagany certyfikat r wnie mo e za da
> >> "trzysta miliard w".
>
> > Może. Ale może też nie. Jeśli taka wycena jest realistyczna, to być
> > może znaczy, że nie należy danej rzeczy produkować.
>
> To samo dotyczy jednostki certyfikującej. Jeśli jej wycena jest
> realistyczna, to znaczy to dokładnie to samo.

Może być taka sytuacja, wcale nie wydumana, że specjalista
certyfikowany do wytwarzania powie, że zrobi na danym poziomie jakości
za sensowną cenę i w sensownym czasie, a specjalista certyfikowany do
testowania laboratoryjnego powie, że testy sprawdzające ten poziom
jakości będą kosztować miliardy i trwać dziesiątki lat (lub w skrócie
- "nie da się").

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
zdali egzaminów, bo nie mają praktyki, bo są za głupi, bo w
przeszłości robili podobny projekt i tak go kompletnie schrzanili, że
im odebrano uprawnienia).

Ale oczywiście może to zależeć od specyfiki produktu.

> > Ale skoro w tym całym Theracu certyfikowane oprogramowanie nawaliło,
> > to najwyraźniej ta certyfikacja "nie daje gwarancji".
>
> Jak każda, niezależnie od poziomu na którym następuje.

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.

> > A w dowolnym laboratorium odpowiednia osoba potrafi bez jakiegokolwiek
> > testowania wystawić dokument certyfikujący dowolnie wadliwy produkt.
>
> Czyli nadal nie ma różnicy.

Jest różnica, po prostu stosujesz bzdurne kryteria.

> >> Jak to w czym? W tym e takie jednostki certyfikuj ce chc trzaska kas
> > O jejku jejku, ktoś chce trzaskać kasę.
>
> O jejku, ja też chce, i co może mam dobrowolnie dać innym trzaskać moją
> kasę? Na chwilę obecną ja trzaskam i właśnie co poniektórym się to nie
> podoba i kombinują jakby to "ucertyfikować", coby się nie narobić i zarobić.

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.

> > Bzdura, oczywiście, że wystawiający certyfikat ponosi
> > odpowiedzialność.
>
> Ok. Rozważmy.
> Pierwszy przypadek.
> Programista napisał aplikacje i dał ją do certyfikowania. Jednostka
> certyfikująca (po swoich testach) wydała odpowiedni certyfikat. Coś się
> kosi. Problem ma programista, ale odpowiedzialność za wydanie
> certyfikatu niezgodnego z prawdą ponosi jednostka certyfikująca (bo źle
> to zrobiła, nie chciało jej się czy cokolwiek innego).
> Drugi przypadek.
> 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.

> program jest certyfikowany. Program się sypie. Problem ma jedynie
> programista, a firma certyfikująca nie.

Na jakiej podstawie tak zakładasz? Czy inaczej - na jakiej podstawie
zakładasz, że ja coś takiego proponuję?
Ja bym to raczej widział tak:
Program się sypie, więc jest prowadzone dochodzenie. W ramach
dochodzenia programista odpowiada dlaczego pewne rzeczy zrobił tak, a
nie inaczej i wychodzi, że przyczyną błędów są braki w wiedzy. W
następnym etapie dochodzenia pod lupę brana jest w takiej sytuacji
jednostka certyfikująca: audytorzy sprawdzają programy i
przeprowadzają wywiady z inntymi osobami po certyfikacji lub będącymi
aktualnie w trakcie certyfikacji. Jeśli w wyniku dochodzenia okazuje
się, że jednostka certyfikująca regularnie wydaje certyfikaty osobom
bez odpowiednich umiejętności i wiedzy, może dyscyplinarnie utracić
lub mieć zawieszoną akredytację i dodatkowo odpowiadać w procesie
cywilnym za szkody wywołane awarią.

> Pomimo że to ona nawaliła na
> samym początku wydając certyfikat programiście. Dlaczego? Ponieważ nawet
> certyfikowany programista może napisać zły program.

I co z tego? Analogiczne tutaj będzie pytanie, czy ten, kto wystawił
licencję laboratorium na certyfikację będzie odpowiadał, czy tylko
samo laboratorium. Przecież nawet certyfikowane laboratorium może
wystawić certyfikat jakości wadliwemu programowi. Dlaczego w takiej
sytuacji miałoby odpowiadać samo laboratorium, zamiast doprowadzić do
dymisji rządu, który powołał ministra, który zatrudnił urzednika,
który zatrudnił urzędnika, który kierował urzędem, który akredytował
instytut, który weryfikował licencję laboratorium, które wydało
certyfikat?

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.

> Dla mnie więc większą wartość ma certyfikowanie oprogramowania niż
> programistów lub uściślając projektantów oprogramowania.

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.

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.

> Ale mylisz się w jednym. Na chwilę obecną to ja o tym decyduje, czy
> program będę certyfikował (czy muszę) i kto ową certyfikację
> przeprowadzi,

W czym się mylę?

> więc nie dziw się, że nie będę entuzjastycznie nastawiony
> do wywracania sposobu działania rynku, tylko dla zmiany, która po
> pierwsze jest kosmetyczna i nic nie zmienia w sprawach bezpieczeństwa, a
> po drugie dyktowana jest przez margines chcący wprowadzić demokratyczne
> państwo totalitarne.

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