On Jan 12, 6:34 pm, Michoo <m...@v...pl> wrote:
>
> > Teoretycznie tak, ale:
> > Po pierwsze komputery wk ada si do coraz wi kszej ilo ci rzeczy i
> > coraz wi cej zale y,
> > Po drugie zawodno oprogramowania generuje wysokie dodatkowe koszta w
> > postaci konieczno ci wstawiania dodatkowych elektrycznych lub
> > elektromechanicznych zabezpiecze , kt re oczywi cie musz by
> > projektowane przez certyfikowanych in ynier w.
>
> Ale zawodno sprz tu (taki procesor mo e si zawiesi na skutek
> oberwania cz stk o du ej energii) sprawia, e failsafe i tak jest
> konieczny. A sprz t mission-critical i tak wymaga certyfikat w.

No więc można sobie wyobrazić sytuacje, gdzie np. quorum voting system
jest sensowniejszym i bezpieczniejszym rozwiązaniem niż mechaniczny
failsafe, _jeśli_ mamy zaufanie do oprogramowania na takim poziomie,
jak do mechanicznego failsafe'u (który też przecież może zawieść).

W dodatku możesz mieć taki problem, że twój mechaniczny failsafe w
połączeniu z taką jakością kodu, jaką możesz załozyć, nie daje ci
odpowiedniej nizawodności. I żeby tę niezawodność osiągnąć musiałbyś
mieć lepszego failsafe'a, który kosztuje sto milionów i waży tonę. W
takiej sytuacji znacznie tańszą i lepszą alternatywą może być
zwiększenie niezawodności kodu.

> Przypadek poparzenia ludzi sprz tem do na wietlania (informacje by wiki)
> to by skutek usuni cia fizycznego zabezpieczenia(soft by b dny ju
> wcze niej). B d by zg aszany u ytkownikowi (lekarz z certyfikatem) i
> to u ytkownik wymusza kontynuacj mimo b du. Mimo, e na 99%
> instrukcja i szkolenia wyra nie m wi y "w razie b du skontaktuj si z
> serwisem".

Rozumiesz jednak, że w przypadku takiego systemu zabezpieczeń musi
nastąpić szereg błędów, każdy z określonym prawdopodobieństwem, i jak
te prawdopodobieństwa się składają? Jeśli na tysiące zastosowań typu
mission critical w kilku przypadkach zostanie popełniony błąd
konstrukcyjny, i na tysiące wdrożeń każdego z tych systemów w
kilkunastu przypadkach zawiedzie operator, i okazuje się, że w 1/3
przypadków tego typu dochodzi do katastrofy z powodu błędów w
oprogramowaniu, to widać, co jest słabym ogniwem (liczby oczywiście
wyssane z palca, ale spodziewam się, że w rzeczywistości może to
właśnie tak wyglądać).

> > Po trzecie brak certyfikacji ogranicza wbrew pozorom konkurencj na
> > rynku, bo startupom ci ej konkurowa w sytuacji, kiedy jedyn
> > gwarancj jako ci jest reputacja producenta.
>
> Aktualnie trendy s takie, e i tak jedyne czym mog konkurowa to cena.
> Jak opr cz ceny b d mieli dobr jako to zdob d renom . Certyfikat
> stwarza tylko "koszt wej cia".

No więc z konkurowaniem ceną jest problem, bo po pierwsze są granice,
poniżej których nie da się obniżyć kosztów bez poważnego odbicia się
tego na jakości, a po drugie mówimy o systemach, w których awaria może
powodować znaczne straty. Jeśli kupujesz oprogramowanie, którego
awaria może spowodować sto milionów strat, to jak masz produkt A
uznanej firmy z dużym doświadczeniem za milion, i produkt B firmy,
która dopiero wchodzi na rynek i niewiele się da powiedzieć o jakości
tego produktu, to jaka cena by Cię przekonała do wybrania produktu B?
Często odpowiedź będzie taka, że nie wybierzesz go nawet, jak go
dostaniesz za darmo, ani nawet jeśli dopłacą Ci milion. Tym bardziej
jeśli np. jako dyrektor szpitala czy właściciel linii lotniczych
ryzykujesz też sprawą karną i/lub tym, że samemu stracisz licencję.