On Jan 20, 7:23 am, Tomasz Kaczanowski
<kaczus@dowyciecia_poczta.onet.pl> wrote:
> Andrzej Jarzabek pisze:
>
> > Bzdura, oczywiście, że wystawiający certyfikat ponosi
> > odpowiedzialność.
>
> Tak - izba lekarska tez ponosi? Więc pewnie dlatego stara się tuszowac
> wszelkie sprawy dotyczące niewłaściwego leczenia?
>
> >> (czyli maksimum zysk w z minimalnym ryzykiem). Dlaczego wi c mam dawa
> >> zarabia im, skoro mog da zarobi sobie, a odpowiedzialno za
>
> > Ale to nie Ty decydujesz.
>
> A skąd ta pewność, że nie on decyduje?
>
> Wypowiadasz się, rzucając liczby z kosmosu i uznając, że to pewnik
> niczym prawda objawiona. Wyrokujesz, kto o czym decyduje... Ty może
> jesteś jakimś nadczłowiekiem, który wie o wszystkim?

A skąd ta pewność, że nie jestem?

Chociaż akurat w tym wypadku wystarczy trochę logiki i zdrowego
rozsądku.

do góry

On Jan 20, 10:46 am, Tomasz Kaczanowski
<kaczus@dowyciecia_poczta.onet.pl> wrote:
> Andrzej Jarzabek pisze:
>
> > I co z tego? Analogiczne tutaj b dzie pytanie, czy ten, kto wystawi
> > licencj laboratorium na certyfikacj b dzie odpowiada , czy tylko
> > samo laboratorium.
>
> Ilo certyfikowanych laboratori w jest kilka rz d w wielko ci mniejsza
> ni by aby potrzeba programist w z certyfikatami, wiec atwiej nad tym
> zapanowa .

Na jakiej podstawie uważasz, że jest mniejsza? Ja np. uważam, że jest
znacznie większa. W podanym przykładzie producenta aparatury
medycznej, nad oprogramowaniem tego urządzenia o ile zrozumiałem nigdy
nie pracował więcej, niż jeden programista na raz.

> W laboratorium masz cho by cie szansy, e zostanie poddane badaniu. Czy
> oprogramowanie zosta o wyprodukowane w procesie, zgodnie z za o eniami
> procesu, to pozostanie s odk tajemnic tw rc w, nawet poczw rnie
> certyfikowanych.

W laboratorium masz cień szansy, że zostanie poddane badaniu, ale czy
rzeczywiście jakiekolwiek testy będą wykonane pozostanie słodką
tajemnicą nawet poczwórnie certyfikowanych pracowników nawet
poczwórnie czertyfikowanego laboratorium. I analogicznie to, czy
oprogramowanie zostanie wyprodukowane zgodne z certyfikowanym procesem
pozostanie słodką tajemnicą nawet poczwórnie certyfikowanych twórców,
ale choćby cień szansy na to jednak masz.

do góry

On 20.01.2011 12:01, Andrzej Jarzabek wrote:
> W laboratorium masz cień szansy, że zostanie poddane badaniu, ale czy
> rzeczywiście jakiekolwiek testy będą wykonane pozostanie słodką
> tajemnicą nawet poczwórnie certyfikowanych pracowników nawet
> poczwórnie czertyfikowanego laboratorium. I analogicznie to, czy
> oprogramowanie zostanie wyprodukowane zgodne z certyfikowanym procesem
> pozostanie słodką tajemnicą nawet poczwórnie certyfikowanych twórców,
> ale choćby cień szansy na to jednak masz.

W tych całych certyfikatach tylko o to chodzi, żeby klient więcej
zapłacił, bo jest mniejsza konkurencja, a poza tym uzasadnienie: ile
musieliśmy wydać na certyfikację.

--
wer <",,)~~
http://szumofob.eu

do góry

Andrzej Jarzabek pisze:
> On Jan 20, 10:46 am, Tomasz Kaczanowski
> <kaczus@dowyciecia_poczta.onet.pl> wrote:
>> Andrzej Jarzabek pisze:
>>
>>> I co z tego? Analogiczne tutaj b dzie pytanie, czy ten, kto wystawi
>>> licencj laboratorium na certyfikacj b dzie odpowiada , czy tylko
>>> samo laboratorium.
>> Ilo certyfikowanych laboratori w jest kilka rz d w wielko ci mniejsza
>> ni by aby potrzeba programist w z certyfikatami, wiec atwiej nad tym
>> zapanowa .
>
> Na jakiej podstawie uważasz, że jest mniejsza? Ja np. uważam, że jest
> znacznie większa. W podanym przykładzie producenta aparatury
> medycznej, nad oprogramowaniem tego urządzenia o ile zrozumiałem nigdy
> nie pracował więcej, niż jeden programista na raz.

No i co z tego? Co to ma do rzeczy? Ilu programistów potrzebnych jest do
wytworzenia danego programu, a ile instytucji certyfikowanych jest
potrzebnych do zbadania gotowego produktu. Co wiecej instytucja taka
może też badać inne produkty.
No ale widzę, że wolisz jednak sam wymyślać dane i się tylko do nich
odnosić....




--
Kaczus
http://kaczus.republika.pl

do góry

On Jan 20, 11:32 am, Tomasz Kaczanowski
<kaczus@dowyciecia_poczta.onet.pl> wrote:
> Andrzej Jarzabek pisze:
>
> > On Jan 20, 10:46 am, Tomasz Kaczanowski
> > <kaczus@dowyciecia_poczta.onet.pl> wrote:
> >> Andrzej Jarzabek pisze:
>
> >>> I co z tego? Analogiczne tutaj b dzie pytanie, czy ten, kto wystawi
> >>> licencj laboratorium na certyfikacj b dzie odpowiada , czy tylko
> >>> samo laboratorium.
> >> Ilo certyfikowanych laboratori w jest kilka rz d w wielko ci mniejsza
> >> ni by aby potrzeba programist w z certyfikatami, wiec atwiej nad tym
> >> zapanowa .
>
> > Na jakiej podstawie uwa asz, e jest mniejsza? Ja np. uwa am, e jest
> > znacznie wi ksza. W podanym przyk adzie producenta aparatury
> > medycznej, nad oprogramowaniem tego urz dzenia o ile zrozumia em nigdy
> > nie pracowa wi cej, ni jeden programista na raz.
>
> No i co z tego? Co to ma do rzeczy?

Że jest to kontrprzykład do Twojej tezy.

> Ilu programist w potrzebnych jest do wytworzenia danego programu,

Zależy od programu.

> a ile instytucji certyfikowanych jest potrzebnych do zbadania gotowego produktu.

Zależy od produktu, od tego jak dobrze ma być zbadany i ile jest na to
czasu. W pewnych przypadkach będą to teoretycznie setki lub tysiące
takich instytucji, a w praktyce: "nie da się".

> Co wiecej instytucja taka mo e te bada inne produkty.

Programista też może programować inne produkty.

> No ale widz , e wolisz jednak sam wymy la dane i si tylko do nich
> odnosi ....

Jakie dane?
Proszę bardzo, podaj mi prawdziwe, nie zmyślone dane określające
stosunki liczby certyfikowanych laboratoriów (i certyfikowanych
pracowników laboratoriów) badających programy niecertyfikowanych
programistów, do ilości certyfikowanych programistów tworzących
programy przy takich samych miarach niezawodności certyfikowanych
programów w obydwu przypadkach.

do góry

On Jan 20, 11:08 am, "b...@n...pl" <b...@n...pl> wrote:
> On 20.01.2011 12:01, Andrzej Jarzabek wrote:
>
> W tych całych certyfikatach tylko o to chodzi, żeby klient więcej
> zapłacił, bo jest mniejsza konkurencja, a poza tym uzasadnienie: ile
> musieliśmy wydać na certyfikację.

W tym całym narzekaniu na certyfikację chodzi tylko o to, że kiepscy
programiści boją się, że nikt ich nie będzie chciał zatrudnić.

do góry

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.

do góry

W dniu 2011-01-19 22:02, Michal Kleczek pisze:
>> I dalej, do zaufania dla osób które wystawiają certyfikaty tym osobom.
>> Więc co za różnica czy będziemy ufać osobom/instytucjom wystawiającym
>> certyfikaty specjalistom, czy osobom/instytucjom wystawiającym
>> certyfikaty produktom.
>
> Zgadza sie - tak czy inaczej musimy weryfikowac _ludzi_ a nie produkty.

>> IMHO Zresztą chore jest implikowanie że jeśli produkt jest wykonany
>> przez osobę z certyfikatem to ten automatycznie też jest uważany za
>> certyfikowany.
>
> A co w tym zlego? Przeciez to jest jak najbardziej uznana praktyka. Wezmy

Tylko że jeśli istnieje wymóg certyfikowania oprogramowania (dla pewnego
zakresu) to bezpieczniej jest certyfikować produkt. Bo po pierwsze,
certyfikowany jest każdy produkt i jego wersja (w zakresie zmian). Po
drugie wydany certyfikat potwierdza, że dana wersja (gotowy produkt)
jest zgodna z wymogami, ustawą itd itp (na końcowym etapie produkcji).
Można więc, przyjmując rzetelność działania jednostki certyfikującej, że
produkt jest bezpieczny i można go stosować.
Jeśli by przyjąć że certyfikat wytwórcy implikuje certyfikat dla
produktu, nie mamy takiej gwarancji. Można założyć brak złej woli
wytwórcy, ale może się zdarzyć problem/błąd nie wykryty w procesie
testowania.
W pierwszym przypadku można mieć nadzieje, że jednostka certyfikująca
wyłapie ten problem i unikniemy poważnych konsekwencji (już nawet nie
dla wytwórcy, ale dla użytkownika lub pacjenta), w drugim przypadku może
się to skończyć bardzo źle. I pierwszy zmarły będzie efektem błędu.

Dla mnie w całej sprawie jest dziwne to, że zakłada się, że programista
/ wytwórca nieposiadający certyfikatu nie wytwarza oprogramowania wg
określonych standardów. Przecież nikt nie da tworzyć oprogramowania
osobom bez wiedzy w danym kierunku i nie posadzi pierwszej lepszej osoby
przed klawiaturą.
Certyfikowanie oprogramowania ma jedynie na celu potwierdzenie jego
zgodności z wymaganiami, ustawą itd itp, lub potwierdzeniem poprawnego
działania w zakresie przeprowadzonych badań klinicznych.

Przepraszam jednocześnie, że operuję terminami z zakresu medycznego, ale
właśnie tym się zajmuje i dla mnie certyfikacja oprogramowania łącznie z
badaniami klinicznymi to codzienność. I to sprawdzająca się w praktyce.

> przyklad projektow domow jednorodzinnych. Na rynku jest tego masa i
> wybierasz taki, ktory ci sie podoba. Ale przeciez nikt przy zdrowych
> zmyslach nie sprawdza konkretnego projektu pod katem np. poprawnosci
> obliczen wytrzymalosci belki stropowej - wystarczy wiedza, ze zostal
> wykonany pod nadzorem ludzi posiadajacych odpowiednia wiedze i praktyke
> (potwierdzona powszechnie uznanymi certyfikatami).

No tak, ale i tak ten dom musi przechodzić odbiór techniczny,
sprawdzenie straży pożarnej i innych. Czyli jest kontrola.
Nie sprawdza się tak jak piszesz obliczeń, ale i każdy programista /
zespół stosuje testowanie niezależnie od posiadania lub nieposiadania
certyfikatów.

pozdrawiam,
Przemek O.

do góry

On Jan 20, 3:00 pm, "Przemek O." <p...@o...eu> wrote:
> 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ć.

Oczywiście, że nie jest alfą i omegą. Ale też nie mówimy o jednym
specjaliście, tylko o _wszystkich_ specjalistach w danej dziedzinie.
Jeśli, jako powiedzimy nie-specjalista, wymyślasz sobie albo zgłaszasz
zapotrzebowanie na dajmy na to jakiś element mechaniczny o określonych
parametrach m. in. niezawodności, i każdy specjalista od projektowania
takich elementów, powiedzmy w skali kraju czy np. w Unii Europejskiej
(bo możemy założyć, że certyfikaty będą wzajmenie uznawane), czy nawet
w szerszej grupie krajów, obejmującej np. wszystkie tzw. cywilizowane
kraje na świecie,mówi CI, że to "niemożliwe", a Ty znajdziesz grupę
samouków i świeżych absolwentów, która podejmie się zrobienia tego,
to ja nawet przecież nie mówię, że to absolutnie niemożliwe, żeby im
się udało. Tylko że to bardzo, bardzo mało prawdopodobne. Na tyle mało
prawdopodobne, że jeśli od prawidłowego działania takiego elementu ma
zależeć życie i zdrowie ludzi, to wdrażając go do produkcji
podejmujesz nieakceptowalne ryzyko. I ja wolę, żeby w takich
sytuacjach raz na sto tysięcy razy czegoś nie wyprodukowano, niż żeby
99999 razy podjęto niedopuszczalne ryzyko dla życia i zdrowia.

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

Nie jest guzik warte, bo na każdym poziomie certyfikacji istnieje
nadzór i szansa na wyłapanie takiej sytuacji.

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

Nie pracuję za darmo. Co to ma do rzeczy?

> Czy może dla korporacji certyfikującej i płaczesz że Ty nie możesz zarobić.

Nie pracuję dla korporacji certyfikującej ani nie mam żadnego innego
konfliktu interesów.

> To znowu mnie w
> ogóle nie interesuje. Dla mnie ze Swoją Starą możesz nawet pod mostem
> siedzieć...

No więc nie rozumiem, dlaczego z kolei używasz Swojej Starej jako
argumentu w dyskusji.

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

A nie? Ktoś się pod Ciebie podszywa?

> > 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).

Dlaczego?

> Problem będzie jeśli błędnie wydany certyfikat jest znikomym procentem
> ogółu.

To nie jest problem, to jest właśnie pożądany stan rzeczy.

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

Nie, w tym przypadku ten debil jest urzędnikiem w ministerstwie,
członkiem rządu lub parlamentarzystą.

> Wybacz, ale sposób certyfikacji i testowania na dzisiaj określają trochę
> mądrzejsze głowy (i całe szczęście).

Również w tych dziedzinach, gdzie obowiązują uprawnienia zawodowe?

> > 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ć.

To, że żadna norma ISO nie wymaga prawidłowego synchronizowania
wątków, praktykowania code reuse, pisania czytelnego i łatwego w
utrzymaniu kodu, tworzenia unit testów, refaktoryzacji, komentowania,
poprawnego doboru struktur danych i algorytmów, itd. itp.

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

Nie wycofuję się z niczego. Po prostu w ramach certyfikacji możesz
mieć różne specyficzne rozwiązania, różnie stopnie uprawnień
zawodowych i różne certyfikaty. W przypadku aparatury medycznej, gdzie
oprogramowanie tworzone jest przez jednego programistę może istnieć
certyfikat, który pozwoli mu certyfikować to oprogramowanie
samodzielnie, który by obejmował nie tylko certyfikację umiejętności
oprogramowania jako takiego, ale też całego procesu produkcji
oprogramowania, z metodologią testów itd., ale też mogą istnieć inne
rozwiązania pasujące do większych zespołów, gdzie jest więcej niż
jeden programista i jedna osoba odpowiedzialna za zarządzanie procesem
produkcji, która niekoniecznie sama jest programistą.

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

Właśnie nie wyklucza. Dlatego można wprowadzić certyfikację
programistów przy zachowaniu jakichkolwiek innych wymogó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.

A masz jakąś podstawę, żeby twierdzić, że mam w tej kwestii konflikt
interesów? Bo tak się składa, że nie mam.

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

Bo dla mnie akurat jest ważne, że ktoś, kto używa swojej opinii jako
argumentu, ma jednocześnie w tej sprawie konflikt interesów.

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

Ja chcę dyskutowac merytorycznie. Dlatego odrzucam z góry argumentację
typu "IMHO Zresztą chore jest...", "Jak dla mnie to...", "Dlaczego
miałbym...", "Jak czytam takie brednie... to mi przypomina...", "Jakoś
nie zdarzyło mi się jeszcze...".

To są Twoim zdaniem obiektywne i merytoryczne argumenty?

do góry

On Jan 20, 3:17 pm, "Przemek O." <p...@o...eu> wrote:
>
> Jeśli by przyjąć że certyfikat wytwórcy implikuje certyfikat dla
> produktu, nie mamy takiej gwarancji. Można założyć brak złej woli
> wytwórcy, ale może się zdarzyć problem/błąd nie wykryty w procesie
> testowania.

A błąd nie wykryty w procesie testowania przez certyfikujące
laboratorium nie może się zdarzyć? Według mnie szanse wykrycia błędu w
oprogramowaniu przy testowaniu laboratoryjnym są znacznie mniejsze niż
przy podobnym nakładzie środków przy testowaniu przez QA. Bo dział QA
testuje tylko produkty tej firmy, być może jest zespół, który testuje
tylko dany produkt, dodatkowo mają wskazówki od developerów gdzie
należy szukać błędów i mają możliwość testowania produktu we
wszystkich stadiach produkcji.

Jeśli chodzi o błędy polegające na tym, że w bardzo specyficznych
sytuacjach, przy specyficznej konfiguracji, przy specyficznych danych
wejściowych pojawiających się w specyficznych relacjach czasowych
program się wysypuje, to testy laboratoryjne mają bardzo słabe szanse
na ich wyłapanie, bo są w stanie przebadać jedynie bardzo wąskie
wycinki całkowitej przestrzeni zdarzeń.

> W pierwszym przypadku można mieć nadzieje, że jednostka certyfikująca
> wyłapie ten problem i unikniemy poważnych konsekwencji (już nawet nie
> dla wytwórcy, ale dla użytkownika lub pacjenta), w drugim przypadku może
> się to skończyć bardzo źle. I pierwszy zmarły będzie efektem błędu.

W obydwu przypadkach można mieć nadzieję, i w obydwu może się to
skończyć bardzo źle.

> Dla mnie w całej sprawie jest dziwne to, że zakłada się, że programista
> / wytwórca nieposiadający certyfikatu nie wytwarza oprogramowania wg
> określonych standardów.

Zakłada się, że jeden wytwarza, a inny nie wytwarza.

> Przecież nikt nie da tworzyć oprogramowania
> osobom bez wiedzy w danym kierunku i nie posadzi pierwszej lepszej osoby
> przed klawiaturą.

Ktoś tego programistę od Theraca posadził.

> Certyfikowanie oprogramowania ma jedynie na celu potwierdzenie jego
> zgodności z wymaganiami, ustawą itd itp, lub potwierdzeniem poprawnego
> działania w zakresie przeprowadzonych badań klinicznych.
>
> Przepraszam jednocześnie, że operuję terminami z zakresu medycznego, ale
> właśnie tym się zajmuje i dla mnie certyfikacja oprogramowania łącznie z
> badaniami klinicznymi to codzienność. I to sprawdzająca się w praktyce.

No więc skoro się tym zajmujesz, to napisz: czy w innych (niż
oprogramowanie) aspektach produkcji aparatury medycznej również nie ma
wymagań certyfikacji osób projektujących tę aparaturę?

> No tak, ale i tak ten dom musi przechodzić odbiór techniczny,
> sprawdzenie straży pożarnej i innych. Czyli jest kontrola.

No i owszem, różne rzeczy są testowane, ale inne rzeczy nie są.
Zamiast tego wymaga sie odpowiednich uprawnień od projektantów i
wykonawców.

> Nie sprawdza się tak jak piszesz obliczeń, ale i każdy programista /
> zespół stosuje testowanie niezależnie od posiadania lub nieposiadania
> certyfikatów.

Ale szansa na to, że w programie będą błędy, które nie zostaną
wychwycone przez testy, jest bardzo mocno zależna od doświadczenia i
umiejętności programistów.

do góry