🚀 go-pugleaf

> > Co to jest "typowy system"?
> 
> Taki który jest na tyle typowy że produkuje się do niego bardzo, ale to 
> bardzo drogie narzędzia

Ciekawy pogląd, z którym się nie zgodzam. Typowy system (ogólnie: produkt) to taki, który przez swoją typowość znajduje się w mainstreamie, gdzie akurat podaż narzędzi jest największa. W rzeczywistości tak duża, że można z góry założyć jako normę, że wszystkie narzędzia są darmowe. Od edytorów przez kompilatory po systemy kontroli wersji aż po narzędzia do zarządzania zespołem. Wszystko za friko. To jest teraz typowe.

Drogie narzędzia robi się wtedy, gdy ktoś nie ma wyjścia i musi je kupić. Bo w szczególności nikomu nie chce się ich robić. To są z natury nietypowe (niszowe) rzeczy.

> Zacznij od 
> pojęcia "test plan".
> 
> https://en.wikipedia.org/wiki/Test_plan

No i co z nim? Na tej stronie ani razu nie pojawia się słowo "expensive". Ba, nawet słowo "tool" się nie pojawia, więc chyba w ogóle żadnych narzędzi nie trzeba mieć.

> Nie wejdziesz na rynek aplikacji krytycznych 
> bez bardzo rozbudowanego mechanizmu weryfikacji który sam podlega 
> regorystycznej weryfikacji.

Tak.

> > A jak jesteśmy w niszach, to trudno mówić o "typowym systemie".
> 
> Typowy system critical safe.

Właśnie o to pytam. Bo w moim rozumieniu nie ma czegoś takiego. Każdy jest nietypowy.

> Poczytaj o testplanach w okolicy pojęcia IpCore i programowania hardware.

Gdzie mogę o tym poczytać?

> Tylko że ludzie piszący 
> wymagania wiedzą że coś jest nierealne do osiągnięcia jak 100% pokrycia 
> itd itp. Zarządza się ryzykiem.

Nie w sotfwarze. W HW chyba obowiązuje kultura myślenia w procentach, bo tak się zarządza ryzykiem w odniesieniu do systemów fizycznych (np. mechanicznych), gdzie występują przypadkowe błędy produkcji, degradacja (zmęczenie) materiału, itd. Tak można też liczyć hardware w sensie hardware. Natomiast software nie ma takich zjawisk i dlatego zarządzanie ryzykiem w ten sam sposób nie ma sensu. Ludzie, którzy projektują hardware jadą jeszcze na tej kulturze wyniesionej z systemów fizycznych, ale w branży pojawiło się już zrozumienie, że VHDL czy inny Verilog to software a nie hardware i pojwinno się to robić według procesów software'owych a nie hardware'owych.
Czyli programowanie hardware'u przy użyciu procentów to ściema.

Bo alternatywą jest konsekwentne przeniesienie myślenia procentowego na software a to by był koniec systemów krytycznych w ogóle.

> Zorientował się przed napisaniem kodu. Oszacował ryzyko, w każdym 
> punkcie systemu inaczej.

A na jakiej podstawie oszacował?

> Nie dalej nie czaisz. Obecnie pisanie systemów krytycznych podlega pod 
> bardzo restrykcyjne zasady.

W procentach? To się nie rozumiemy.

> W nich samego pisania jest mało, znacznie 
> więcej jest dokumentowania wymagań, śledzenia zmian, akceptacji, 
> odpowiedzialności itp itd tylko że w przeciwieństwie do banków tutaj 
> całosć procesu jest automatyzowana w miarę możliwości w całości.

Niestety nie. Bo te restrykcyjne zasady dotyczą też narzędzi i w wielu przypadkach nie opłaca się automatyzować (!), bo weryfikacja automatu też jest kosztem, w dodatku przez management traktowanym jako uboczny - co jest zrozumiałe, klient płaci za produkt, a nie za automat użyty przy tworzeniu tego produktu.
I to właśnie dlatego pisania jest mało. Bo gdyby dało się wszystko zautomatyzować, to programiści by tylko pisali a cała reszta by się działa automatycznie. Mała ilość pisania jest właśnie miarą tego, jak bardzo ta branża jest niezautomatyzowana.

> > Cytat ze standardu do F-35 (bo tam zaczęliśmy):
> > "
> > AV Rule 208:
> > C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
> > Rationale: Tool support is not adequate at this time.
> 
> To trzeba zmienić tool.

Na jaki? Może tam w Ameryce nie wiedzą?

> > Problem w tym, że nadal jest "not adequate". I bardzo możliwe, że zawsze tak będzie.
> 
> Mało porawdopodobne. Standardy tego typu powstają kiedy obecni 
> użytkownicy szczali jeszcze w pieluchy. Wystarczy zauważyć że w ciągu 10 
> lat projkekt LLVM z pomysłu stał się praktycznie kombajnem do 
> weryfikacji i to zaskakującej jakości jak na projekt "akademicki".

I nadal jest to "not adequate". Bo kombajnem to on sobie może być, ale restrykjcyjne reguły, o których sam wspomniałeś, wykluczają go z użycia.

> Przypuszczam że Ariane miała zakaz przepełniania zmiennych. Nawet może 
> ktoś pogroził paluszkiem.

Zapewne. Ale zakaz rzucania wyjątków jest łatwiejszy, bo można to sprawdzić grepem.

> > A dlaczego nie dało się pokryć tego brakującego 1%?
> 
> Bo wymaga to 99% czasu więcej?

Własnie pytam, dlaczego. Cóż takiego tam jest, że wymaga 99% czasu więcej?

> Szacujący ryzyko ocenia na ile chce mieć 
> system działający vs system w wiecznej fazie produkcji.

Ale regulacje prawne nie określają, na ile działający ma być system. Zwłaszcza software'owy, gdzie nie można się tłumaczyć wadami materiałowymi, albo zmęczeniem struktury.

-- 
Maciej Sobczak * http://www.inspirel.com