On Jan 21, 12:15 pm, Tomasz Kaczanowski
<kaczus@dowyciecia_poczta.onet.pl> wrote:
> Andrzej Jarzabek pisze:
>
> >> pisz c biblioteki dla urz dze szyfruj cych pod windows, tak aby
> >> biblioteka pracowa a bezproblemowo pod systemem windows musi ona by
> >> podpisana przez Microsoft. Bynajmniej nie wysy asz tam kodu biblioteki,
> >> tylko gotow binark , kt r microsoft (je li nie znajdzie zagro enia)
> >> podpisuje. Poniewa tu istotne jest, czy wyst puje zagro enie, czy nie,
> >> czy binarka nie jest przypadkiem zawirusowana, wystarcza jedynie
> >> certyfikacja tej binarki.
>
> > Ale m wili my o systemach mission critical, gdzie bardzo istotnym
> > parametrem jest niezawodno . Microsoft nie certyfikuje takiej
> > biblioteki na niezawodno .
>
> no ale w a nie takie programy zazwyczaj s w urz dzeniach i dzia aj w
> jakim rodowisku. atwiej jest jednak sprawdzi , czy rzeczywi cie
> ca o dzia a dobrze, ni , czy kod jest przejrzysty i zrozumia y.

Można sprawdzić, czy działa dobrze dla jakiegoś drobnego ułamku
procenta wszystkich możliwych sytuacji. To czy działa dobrze w
znaczącym procencie sytuacji, żeby np. wykluczyć możliwość race
conditions czy deadlocks pojawiających się w szczególnych
konfiguracjach i przy szczególnych relacjach czasowych jest bardzo
trudno.

A sprawdzić, czy kod jest przejrzysty i zrozumiały nie jest tak
trudno, zwłaszcza jeśli się jest autorem teego kodu lub członkiem
zespołu piszącego kod.

> W a nie to mo na sprawdzi w laboratorium, jak na b dy (b d sytuacje
> ekstremalne) generowane przez rodowisko i sprz t, czy oprogramowanie
> zareaguje w a ciwie. Czy przy przepi ciu zadzia aj zabezpieczenia, i
> czy uda si zapisa gdzie informacj o takim zdarzeniu, tudzie wys a
> odpowiedni informacj do centrum nadzoru.

Ale wiele błędów oprogramowania wcale nie ujawnia się w sytuacjach,
które można łatwo zidentyfikowac jako "ekstremalne".

> Tu nawet najpi kniej i
> najlepiej napisany kod nic nie pomo e. System mission critical musi by
> i tak brany w a nie jako ca o , gdyz najcz ciej problemy nie pojawiaj
> si w kodzie danego systemu, tylko na styku dw ch system w. Pami tam

Po pierwsze, wcale nie uważam, że takich systemów nie należy testować
jako całość. Oczywiście, że należy. Uważam, że w wielu sytuacjach to
nie wystarczy.

Po drugie to, gdzie problemy pojawiają się "najczęściej" wymagałoby
jednak podparcia jakimiś nieanegdotycznymi danymi. Ja nie wiem, gdzie
błędy pojawiają się najczęściej, moje doświadczenie mówi mi jednak, że
błędy w kodzie jako takim, wynikające ze złych praktyk typu
nieczytelny kod, źle wyspecyfikowana funkcjonalność, z błędnej
sychronizacji wątków, zastosowania niewłaściwych struktur danych i
algorytmów, niezrozumienia różnych aspektów używanego języka
programowania itd. - nie są wcale rzadkie. I takie właśnie błędy są
często właśnie tym typem błędów, które, jeśli nie zostaną wyłapane w
testach wewnętrznych, to mają małe szanse być wychwycone w
zewnętrznych badaniach laboratoryjnych, a w rzeczywistym świecie wiele
z nich wybuchnie użytkownikowi w twarz.

> nawet (w mniej critical system) sytuacj , gdy czylismy dwa systemy, by
> wsp dzia a y ze sob jednocze nie. Ka dy z tych system w osobno dzia a
> poprawnie, jednak na styku okaza o si , e musz mie 1) inaczej
> skonfigurowane rodowisko 2) konieczny by dost p do jednej z tabel
> jednej z baz i tu wysz a druga rzecz, w obu systemach stosowano inne
> rodzaje transakcji (bo system tamten pozwala na r zne podej cia do tego
> problemu) i tu systemy si pi knie zakleszcza y.... Oczywi cie problem
> by do rozwi zania, ale widzisz, oba kody napisane zgodnie z zasadami,
> oba kody samodzielnie dzia aj dobrze, ale gdy potrzebna jest wsp praca
> ju nie jest tak weso o.

Wiesz, w przypadku łączenia różnych komponentów oprogramowania
OCZYWIŚCIE że nie działałoby to tak, że jeśli komponent A jest
certyfikowany i komponent B jest certyfikowany, to system złożony ze
współdziałających komponentów A i B może zaprojektować i skonfigurować
nocny stróż, a on i tak będzie miał certyfikat. Wiadomo, że przede
wszystkim musi mieć uprawnienia osoba certyfikująca system jako
całość. Kwestia jest taka, że te uprawnienia idą w parze z pewnymi
regułami sztuki, mówiącymi w jakich sytuacjach można dany system
certyfikować. I zgodnie z tymi regułami powinno być tak, że komponenty
powstające na zamówienie muszą również być certyfikowane przez osobę o
odpowiednich uprawnieniach, które niekoniecznie muszą się pokrywać z
uprawnieniami integratora systemu. Na przykład można się spodziewać,
że ktoś nie znający danego języka programowania nie może lub nie
powinien certyfikowac programu napisanego w tym języku - ale może użyć
komponentu już certyfikowanego przez programistę/kierownika projektu/
menedżera procesu posiadającego odpowiednie oprogramowania. I z kolei
uprawnienia tej osoby albo bezpośrednio pozwalają jej certyfikować kod
(programista), albo wymagają od niej, żeby oprócz spełnienia innych
warunków (cykl testu, dokumentacja), certyfikowany program miał
również certyfikowany przez programistę z uprawnieniami kod.