On Monday, April 24, 2017 at 11:24:30 PM UTC+1, Maciej Sobczak wrote:
> W dniu poniedziałek, 24 kwietnia 2017 16:16:31 UTC+2 użytkownik Michal napisał:
>
> > > > 1) Ariane5 z Overflow Space Agency
> > >
> > > Program zrobił dokładnie to, do czego został zaprojektowany. To, że został
użyty *w kontekście*, do którego nie został zaprojektowany, było winą złej integracji
systemu a nie błędów w kodzie. Polecam lekturę raportu z fakapu.
> >
> > Ciekawe.
> > Nie chce mi sie calego czytac. Moglbys krotko napisac, czy aby na pewno
> > uzycie jezyka z mocniejszym systemem typow ( np. dependent typing ) nie pomogloby
> > zapobiec katastrofie?
>
> Katastrofa wynikała z tego, że z pośpiechu wzięto moduł z mniejszej rakiety i po
prostu trzymając kciuki wsadzono go do większej rakiety, której większa prędkość w
czasie startu (zdaje się, że pozioma składowa) nie zmieściła się w założonym
zakresie. Wynikający z tego wyjątek (nie ma znaczenia, że z powodu wyłączenia
wyjątków software'owych był to wyjątek hardware'owy) trafił do procedury obsługi
polegającej na wysadzeniu całej rakiety w p*zdu.
> Lepszy język? Tu nie było żadnego buga a program zachował się tak jak miał się
zachować. Błąd był po stronie inżynierów systemowych, którzy złożyli do kupy rakietę
z klocków z niewłaściwego pudełka. Żaden język przed tym specjalnie nie chroni.
>

No właśnie tu jest pytanie - czy może pomóc uchronić. Diabeł tkwi w szczegółach.
Przecież nie wzięli chyba kompilatu (binarki) z jednej maszyny i nie zainstalowali
tego na drugiej "jak leci". Podejrzewam, że _jakiś_ proces kompilacji/budowania i
testowania itp jednak był.

Czy dobry język (i - co najwazniejsze - wiążąca się z takim językiem metodyka )
pozwoliłby uniknąć tego rodzaju błędu (przepełnienie zakresu) - chociażby poprzez
"kłucie w oczy" ewidentnym problemem (zgłaszanym przez kompilator).


> > > > 2) Nadmiarowe zuzycie klawiatury
> > >
> > > W Notepadzie. Programiści używają lepszych edytorów.
> >
> > Ciekawe, ze ciagle slysze narzekania, ze trzeba wiecej pisac.
> > Ale ni cholery nikt nie narzeka, ze im mniej trzeba pisac, tym trudniej
> > sie czyta.
>
> Jest jeszcze gorzej. Średnia szybkość klepania kodu w takich systemach to 1
(słownie: jedna) linia kodu na inżyniera na dzień.

W przypadku "web apps" to rzędy wielkości więcej. Codziennie się przepisuje to, co
napisało się wczoraj - zgodnie z zasada "refactor mercilessly" i generalnie "agile".

--
Michal

do góry

On 4/25/2017 12:24 AM, Maciej Sobczak wrote:
> Katastrofa wynikała z tego, że z pośpiechu wzięto moduł z mniejszej rakiety
> i po prostu trzymając kciuki wsadzono go do większej rakiety

I nikt nie wpadł na to żeby napisać testy jednostkowe, lub nawet
symulator fizyki całej rakiety. Podobnie nikt nie wpadł na to samo przy
ostatnim overflow sondy marsjańskiej. Overflow Space Agency. Bo 4 bajty
sa lepsze niż 8, pamięć jest droga.

> , której większa prędkość w czasie startu (zdaje się, że pozioma składowa)
> nie zmieściła się w założonym zakresie.

Który to zakres ustalił jakiś miłośnik assemblera i oszczędzacz bajtów.
Wiem, widzialem kod w okolicy tego buga, z raportu. Nie ma on żadnego
związku z Adą. To czysty assembler napisany (wyhackowany bardziej) w
języku wyższego poziomu ze wszystkimi możliwymi wadami takiego cuda. I
jestem pewien że jest tona dokumentacji podpisanej ważnymi podpisami.

do góry

W dniu 2017-04-25 o 19:21, Sebastian Biały pisze:
> On 4/25/2017 12:24 AM, Maciej Sobczak wrote:
>> Katastrofa wynikała z tego, że z pośpiechu wzięto moduł z mniejszej
>> rakiety
>> i po prostu trzymając kciuki wsadzono go do większej rakiety
>
> I nikt nie wpadł na to żeby napisać testy jednostkowe, lub nawet
> symulator fizyki całej rakiety. Podobnie nikt nie wpadł na to samo przy
> ostatnim overflow sondy marsjańskiej. Overflow Space Agency. Bo 4 bajty
> sa lepsze niż 8, pamięć jest droga.
>
>> , której większa prędkość w czasie startu (zdaje się, że pozioma
>> składowa)
>> nie zmieściła się w założonym zakresie.
>
> Który to zakres ustalił jakiś miłośnik assemblera i oszczędzacz bajtów.
> Wiem, widzialem kod w okolicy tego buga, z raportu. Nie ma on żadnego
> związku z Adą. To czysty assembler napisany (wyhackowany bardziej) w
> języku wyższego poziomu ze wszystkimi możliwymi wadami takiego cuda. I
> jestem pewien że jest tona dokumentacji podpisanej ważnymi podpisami.
>

Nie widziałem kodu, więc nie wiem, jak było tam, ale z pewnego
doświadczenia z producentami sprzętu i systemów opartych na tych
sprzętach, wiem, że ważna jest też konfiguracja takowego. Jeśli zestawy
sa niepowtarzalne, to trzeba taką konfiguracje dla niego przeprowadzić
osobno, defaultowo moga być urządzenia ustawione, aby reagowały np na
kazde wydarzenie (przykład po oddaniu jednej trasy tramwajowej w Łodzi,
często "brakowało prądu" - otóż powód był prozaiczny - urządzenia nie
były skonfigurowane dla tej trakcji - bo nie mogły być, bo urzadzenia
zgodnie z założeniami przetaru były dostarczone i zamontowane 2 miesiące
wcześniej, ale prąd doprowadzo dopiero na dzień przed uruchomieniem
całości, nasi wspaniali urzednicy zapomnieli, że takie urządzenia trzeba
konfigurować indywidualnie po pomiarach zrobionych w rzeczywistości, bo
są to rzeczy niepowtarzalne, a domyślna konfiguracja po prostu wszystko
co wyglądało podejrzanie traktowała jako wyjątek i odcinany był dopływ
prądu) Więc Mógł być to nawet i dobrze oprogramowany moduł, ale
niewłaściwie skonfigurowany do nowych zadań - nowych, bo jak ktoś tu
wspomniał miał pracowac w innych warunkach niż wcześniej.

--
http://kaczus.ppa.pl

do góry

> Przecież nie wzięli chyba kompilatu (binarki) z jednej maszyny i nie zainstalowali
tego na drugiej "jak leci".

Tego nie wiem, ale nie zdziwiłbym się. W końcu skoro moduł był przetestowany (a był,
w poprzedniej rakiecie), to z punktu widzenia integratora nadawał się do użycia.

> Podejrzewam, że _jakiś_ proces kompilacji/budowania i testowania itp jednak był.

I tutaj Ada ma wystarczające mechanizmy, żeby w procesie kompilacji wykryć
niezgodności zakresów. Nie ma znaczenia, czy tego procesu kompilacji w ogóle nie
było, czy też był ale nie skorzystano z tych mechanizmó - w żadnym z tych przypadków
nie można obwiniać języka.

> Czy dobry język (i - co najwazniejsze - wiążąca się z takim językiem metodyka )
pozwoliłby uniknąć tego rodzaju błędu (przepełnienie zakresu) - chociażby poprzez
"kłucie w oczy" ewidentnym problemem (zgłaszanym przez kompilator).

Problemy integracyjne nie są zgłaszane przez kompilator. To jest kwestia zarządzania
wymaganiami i co ciekawe, dzisiaj też nie ma na to dobrych uniwersalnych metod.

> > Jest jeszcze gorzej. Średnia szybkość klepania kodu w takich systemach to 1
(słownie: jedna) linia kodu na inżyniera na dzień.
>
> W przypadku "web apps" to rzędy wielkości więcej. Codziennie się przepisuje to, co
napisało się wczoraj - zgodnie z zasada "refactor mercilessly" i generalnie "agile".

I co? Lepiej jest?

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

do góry

> I nikt nie wpadł na to żeby napisać testy jednostkowe,

Napisał. Do poprzedniej rakiety.

> lub nawet
> symulator fizyki całej rakiety.

Z powodu oszczędności? Albo z powodów historycznych, bo nie było jeszcze tej dyskusji
na pl.comp.programming i nie mogli się z niej dowiedzieć, że powinni byli taki
symulator napisać?
I jaki to ma związek z użytym językiem?
I gdzie ostatnio widziałeś praktykę pisania takich symulatorów?

> Podobnie nikt nie wpadł na to samo przy
> ostatnim overflow sondy marsjańskiej.

Nikt nie napisał symulatora Marsa?

> Który to zakres ustalił jakiś miłośnik assemblera i oszczędzacz bajtów.
> Wiem, widzialem kod w okolicy tego buga, z raportu. Nie ma on żadnego
> związku z Adą.

Cały czas o tym piszę. To nie jest wina tego języka.

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

do góry

On 4/26/2017 3:53 PM, Maciej Sobczak wrote:
>> I nikt nie wpadł na to żeby napisać testy jednostkowe,
> Napisał. Do poprzedniej rakiety.

I kto wyleciał z roboty za niedbalstwo i debilizm?

>> lub nawet
>> symulator fizyki całej rakiety.
> Z powodu oszczędności?

Niemożliwe. Nie, po prostu niemożliwe. Mozna oszczędzać na farbie, ale
nie na testach. Żartujesz, prawda? Tam nie ma aż takich kretynów, prawda?

> Albo z powodów historycznych, bo nie było jeszcze tej dyskusji
> na pl.comp.programming i nie mogli się z niej dowiedzieć, że powinni
byli taki symulator napisać?

Przecież tam są sami najlepsi i pisza w najlepszych językach. Sami
wiedzą że testujemy oprogramowanie od dawna. Testujemy na wielu
poziomach. Testy integracyjne systemów musza mieć jakiś input. Za nim
wystrzelili pierwszą mogli to symulować. Testy nie musza być dokładne
żeby wykryc błedy oveflow czujników w oczywistych sytuacjach. To *TAKIE*
oczywiste.

> I jaki to ma związek z użytym językiem?

Myślę że ten wypadek pokazuje jak pusty jest mit o bezpieczeństwie Ady.
Zawsze trafi się idiota co wykorzysta tej język jak assembler. Co gorsza
nie jeden.

> I gdzie ostatnio widziałeś praktykę pisania takich symulatorów?

*WSZĘDZIE*. Poza Overflow Space Agency oczywiście. Tam nadrabiają tonami
dokumentacji z podpisami Ważnych Ludzi Od Pospisów.

Ogólnie to się testowanie nazywa. Pewnie, można robić testowanie na
rózne sposóby. Ale ciezko napisać nawigację rakiety bez symulatora
zjawisk fizycznych. Choć kto bogatemu zabroni?

>> Podobnie nikt nie wpadł na to samo przy
>> ostatnim overflow sondy marsjańskiej.
> Nikt nie napisał symulatora Marsa?

Nikt nie napisał symualtora otwierania spadochronu i obliczenia
przeciążeń na żywym programie nawigacyjnym. Założono jak zwykle że 4
bajty wystarczą. Widuje takie podejście w całym świecie embedded i
przypuszczam że ten sam gatunek programisty jest odpowiedzialny za
pisanie firmware komputerów nawigacyjnych.

> Cały czas o tym piszę. To nie jest wina tego języka.

Język jest winien tworzenia idiotycznej atmosfery bezpieczeństwa w
ktorej obniża się jakość "bo jest bezpieczny, to po co sprawdzać czy
dobrze napisałem".

Kiedyś czytalem wypociny pewnego przygłupa od Ady który twierdził że
język jest tak znakomity że już nawet nie testują częsci kodu bo wiadomo
że działa dobrze. Nie pamiętam czy pracowałw Overflow Space Agency. Nie
wykluczam tego po ostatniej wpadce z Marsem.

do góry

On Wednesday, April 26, 2017 at 3:46:50 PM UTC+2, Maciej Sobczak wrote:
> > > Jest jeszcze gorzej. Średnia szybkość klepania kodu w takich systemach to 1
(słownie: jedna) linia kodu na inżyniera na dzień.
> >
> > W przypadku "web apps" to rzędy wielkości więcej. Codziennie się przepisuje to,
co napisało się wczoraj - zgodnie z zasada "refactor mercilessly" i generalnie
"agile".
>
> I co? Lepiej jest?

Oczywiscie. No... moze nie lepiej, ale na pewno zwinniej :P

--
Michal

do góry

On Wednesday, April 26, 2017 at 6:23:52 PM UTC+2, Sebastian Biały wrote:

> > I jaki to ma związek z użytym językiem?
>
> Myślę że ten wypadek pokazuje jak pusty jest mit o bezpieczeństwie Ady.

Ten wypadek pokazuje, że jak się nie korzysta z mechanizmów języka, to nie będzie
pozytywnych efektów, które te mechanizmy mogłyby dać.

Parafrazując - samochód utonął w rzece razem z kierowcą a Ty pokazujesz, jak pusty
jest mit o bezpieczeństwie poduszek powietrznych.

> > I gdzie ostatnio widziałeś praktykę pisania takich symulatorów?
>
> *WSZĘDZIE*.

Bad news: nie wszędzie byłeś. W szczególności nie byłeś tam, gdzie się tego nie robi.
To obniża efektywność tej dyskusji.

W Twoim trollowaniu są proste błedy logiczne - w tym samym poście twierdzisz, że
systemy krytyczne piszą idioci i jednocześnie że "wszędzie" pisze się symulatory
procesów fizycznych. Może przyjmij jakąś jedną spójną wersję. Nawet błędną, ale
jedną.

> > Cały czas o tym piszę. To nie jest wina tego języka.
>
> Język jest winien tworzenia idiotycznej atmosfery bezpieczeństwa

Nie. To wybór języka wynika z tej atmosfery. Atmosfera była wcześniej i jest
niezależna od użytego języka.
Naprawdę.

Dlatego właśnie w projektach w C nie jest lepiej - a byłoby, bo przecież z tego co
piszesz, wtedy nie byłoby "idiotycznej atmosfery bezpieczeństwa" i obniżania jakości.
Więc jakość powinna być wyższa. A wiadomo, że nie jest. Czyli znowu masz błąd
logiczny w Twoim trollowaniu.

Ogólnie - słabe.

> Kiedyś czytalem wypociny pewnego przygłupa od Ady który twierdził że
> język jest tak znakomity że już nawet nie testują częsci kodu bo wiadomo
> że działa dobrze.

Wykorzystanie statycznych metod analizy pozwala obniżyć rygor pokrycia testami i to
wynika z procesów a nie z zastosowanego języka. Takie strategie stosuje się
niezależnie od użycia Ady, w C również. I nie dotyczy to tylko latania w kosmos, ale
również np. cywilnej branży lotniczej.

To są ciekawe tematy, ale jeśli chcesz podyskutować, to przestań trollować. Na
pytania chętnie odpowiem, ale z trollowaniem nie chce mi się walczyć.

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

do góry

On 4/27/2017 3:16 PM, Maciej Sobczak wrote:
>> Myślę że ten wypadek pokazuje jak pusty jest mit o bezpieczeństwie Ady.
> Ten wypadek pokazuje, że jak się nie korzysta z mechanizmów języka, to nie będzie
pozytywnych efektów

Czyli nie pisali w Adzie. Dziwne, bo się tym wielu ludzi chwalilo, na
newsach też często czytam że krytyczny soft pisze się w Adzie.

> Parafrazując - samochód utonął w rzece razem z kierowcą a Ty pokazujesz
>, jak pusty jest mit o bezpieczeństwie poduszek powietrznych.

Inaczej: mit Ady doprowadza do twierdzeń z gatunku "moj samochód ma
poduszki powietrzne, więc nie zatonie". Zauważ że decyzje biznesowe
dotyczące wyboru technologii prawie nigdy nie podlegają osobie która ma
o nich pojęcie. W korpo w szczegolnosci, w ESA nie wiem, może.

>>> I gdzie ostatnio widziałeś praktykę pisania takich symulatorów?
>> *WSZĘDZIE*.
> Bad news: nie wszędzie byłeś.

Brawo.

> W szczególności nie byłeś tam, gdzie się tego nie robi. To obniża efektywność tej
dyskusji.

Nie, nie obniża, przeciez to trolowanie. Pokazuje jednak dośc istotne
zjawisko: wszedzie powinno się doprowadzać do testow z uzyciem jakiegoś
inputu rzeczywistego. W przypadku rakiety symulacja nie była by trudna
do zrobienia. Policzenie na kartce siły ciągu, przyspieszenia i kilku
innych parameterów też jest w zasiegu. Nie zrobiono tego. Mimo że
wystarczający model wykrywający takie bugi jest w zasiegu studenta
mechaniki/fizyki.

> W Twoim trollowaniu są proste błedy logiczne - w tym samym poście twierdzisz
>, że systemy krytyczne piszą idioci i jednocześnie że "wszędzie" pisze się
symulatory procesów fizycznych.

Wszedzie pisze się testy. Przynajmniej wszedzie w ciezkiej i drogiej
informatyce. Akuratnie nie musza być symulatorami fizyki, bywają. Taki
matlab kroi z tego niebotyczną kasę.

> Może przyjmij jakąś jedną spójną wersję. Nawet błędną, ale jedną.

Proszę: caly świat testuje oprogramowanie in vitro poza esą ktora robi
to na hura. O ile w przypadku Ariane 5 to mogła być wpadka jakich wiele,
to następna, prawie identyczna zaczyna zastanawiać. Zrobili testy tego
kodu *PO* katastrofie sondy. Zabawne, naprawdę. Wychodzi na to że się
dało i to dosc szybko, przetestować kod. Mnie by nie było stać na
wysyłanie w ciemno kodu z tonami podpisów.

>>> Cały czas o tym piszę. To nie jest wina tego języka.
>> Język jest winien tworzenia idiotycznej atmosfery bezpieczeństwa
> Nie. To wybór języka wynika z tej atmosfery. Atmosfera była wcześniej i jest
niezależna od użytego języka.
> Naprawdę.

Tu bez wątpienia mogło by godzinami rozmawiać kilku filozofów co z czego
wynika.

> Dlatego właśnie w projektach w C nie jest lepiej - a byłoby
>, bo przecież z tego co piszesz, wtedy nie byłoby "idiotycznej
> atmosfery bezpieczeństwa" i obniżania jakości. Więc jakość powinna
> być wyższa. A wiadomo, że nie jest. Czyli znowu masz błąd logiczny w Twoim
trollowaniu.

Nigdzi nie pisałem o uzywaniu C więc ciezko się wywodzi o czyjejś logice
na podstawie wyssanych z palca cytatów.

Co do jakości: więcej testowania niekoniecznie ją podnosi. Gdyby
testowani Ariane5 invitro to kod dalej by wyglądał jak wypociny hackera
od asm. Zmniejsza tylko szanse na błąd takiego kalibru.

>> Kiedyś czytalem wypociny pewnego przygłupa od Ady który twierdził że
>> język jest tak znakomity że już nawet nie testują częsci kodu bo wiadomo
>> że działa dobrze.
> Wykorzystanie statycznych metod analizy

Nie wykorzystują. Pisza i od razu jest dobrze, tak powiedział.

> pozwala obniżyć rygor pokrycia testami

Pod warunkiem że bugi tkwią w składni lub algorytmice. Gorzej gdy w
zakresach. Ale obniżyć zawsze warto, wiadomo, jak oszczędzać to na
rzeczach krytycznych.

> i to wynika z procesów a nie z zastosowanego języka. Takie strategie
stosuje się
> niezależnie od użycia Ady, w C również. I nie dotyczy to tylko latania w kosmos,
> ale również np. cywilnej branży lotniczej.

Mówisz np o DO-254. No więc coś Ci powiem o tym. Akuratnie ilośc
testowania kodu w hardware i software rośnie. Nigdy tak wiele nie
testowano i robimy tego coraz więcej. Mozna powiedzieć że testowanie
eksplodowalo jakieś 10 lat temu i ta eksplozja trwa. Wyrosły ogromne
metodyki, od korporacyjnych po detaliczne, jak testować *każdy* aspekt
kodu/hardware. Od testow jednostkowych przez radomizacje, po symulacje
fizyki i obieg dokumentów.

Nikt tu niczego nie ogranicza. Wręcz przeciwnie. EDA rośnie prawie
wyłącznie w dziedzinie weryfikacji. Obecnie hardware i software zlewają
sie w jedno, wiec dotyczy to rownież firmware embedded.

> To są ciekawe tematy, ale jeśli chcesz podyskutować, to przestań trollować.

Czasem trzeba. Inaczej programisci Ady będa chodzili tak samo nadęci jak
programiści VHDLa mimo że świat jest hektary dalej w metodach
weryfikacji niż silne typowanie i ładne exceptiony.

> Na pytania chętnie odpowiem, ale z trollowaniem nie chce mi się walczyć.

Nie ma pytań: ESA dała dupy dwukrotnie w ten sam sposób. Nie pomogła im
Ada bo na idiotów nie ma rady.

Spuśc troche powierza. Zarobiłem zaczepkę z mrugnięciem i od razu
zaczynasz straszliwą dyskusję i edukowanie kogo popadnie i kiwaniem
palcem. Zważ że inni mają tez jakieś punkty widzenia i czasem trzeba
odsunąć się od swojej pracy żeby zobaczyć jak wiele błedow popełniamy w
programowaniu.

Ja widze jak się weryfikuje hardware/firmware w dużej skali, z miejsca
gdzie siedzę. Nie zgadzam się z tym że na tym się oszczędza. Nie,
pompuje się mld dolarow w weryfikacje na całym świecie, wiele procent
tej weryfikacji zalezy rownież od symulatorów fizyki. Powstało tysiące
firm dostarczających narzedzia aby robić to lepiej, szybciej. Wszyscy
weryfikują. To jest teraz ważniejsze od pisania kodu.

do góry

On Thursday, April 27, 2017 at 7:53:32 PM UTC+2, Sebastian Biały wrote:

> Czyli nie pisali w Adzie.

Nie ma systemów napisanych w 100% w Adzie. To, że wywaliło się w tym kawałku, gdzie
Ada nie była wykorzystana (albo nie była wykorzystana w pełni) pokazuje, że problem
nie był w Adzie. Dla mnie to logiczne.

> Dziwne, bo się tym wielu ludzi chwalilo, na
> newsach też często czytam że krytyczny soft pisze się w Adzie.

W tym samym poście twierdzisz, że pisali, i że nie pisali.

> Zauważ że decyzje biznesowe
> dotyczące wyboru technologii prawie nigdy nie podlegają osobie która ma
> o nich pojęcie.

Nadal nie wykazałeś, że decyzja o wyborze technologii była zła.

> > Może przyjmij jakąś jedną spójną wersję. Nawet błędną, ale jedną.
>
> Proszę: caly świat testuje oprogramowanie in vitro poza esą ktora robi
> to na hura.

Proszę: https://en.wikipedia.org/wiki/List_of_software_bugs

Jak widać, "cały świat" testuje. Na symulatorach, zapewne.

> > Wykorzystanie statycznych metod analizy
>
> Nie wykorzystują.

Wykorzystują, bo część takich metod jest wpisana w język, np. w system typów.

> Pisza i od razu jest dobrze, tak powiedział.

Niech zgadnę - zrobiłeś skrót z cudzej skróconej wypowiedzi? A może za tą wypowiedzią
stoi jakiś bardziej przemyślany proces? Ale nie, na pewno na świecie jest N-1
idiotów.

> > pozwala obniżyć rygor pokrycia testami
>
> Pod warunkiem że bugi tkwią w składni lub algorytmice. Gorzej gdy w
> zakresach.

Właśnie testowanie zakresów da się w ten sposób wykluczyć najszybciej.

> Mówisz np o DO-254. No więc coś Ci powiem o tym. Akuratnie ilośc
> testowania kodu w hardware i software rośnie.

Skoro rośnie, to kiedyś była mniejsza. Ariane 5 to było 20 lat temu.
To, że 20 lat później masz poczucie wyższości nad tamtymi ludźmi to nie jest wielkie
osiągnięcie. Trzeba było tam być 20 lat temu.

> Nigdy tak wiele nie
> testowano

Przecież cały czas o tym piszę. W Ariane 5 wsadzono moduł z mniejszej rakiety, bez
kompletnych testów integracyjnych.

> > To są ciekawe tematy, ale jeśli chcesz podyskutować, to przestań trollować.
>
> Czasem trzeba. Inaczej programisci Ady będa chodzili tak samo nadęci

Akurat ci, których znam, są raczej skromni. Zdaje się, że swiadomi swoich ograniczeń.

> Spuśc troche powierza. Zarobiłem zaczepkę z mrugnięciem i od razu
> zaczynasz straszliwą dyskusję

Nie wyrażam się z pogardą o nikim. Nikogo nie nazwałem idiotą ani debilem. I tak
dalej. Nawet nie ja zacząłem tą dyskusję. Przeczytaj swoje posty i porównaj.

Dyskutujemy czy trollujesz dalej?

> Nie zgadzam się z tym że na tym się oszczędza.

Oszczędza się właśnie na tym, bo weryfikacja nie produkuje żadnych artefaktów. I
widać to zwłaszcza w waterfallu, który był (i nadal jest) popularną metodą w takich
systemach.

BTW:

http://www-users.math.umn.edu/~arnold/disasters/aria
ne5rep.html

"It is not mandatory, even if preferable, that all the parts of the subsystem are
present in all the tests at a given level."

Jak również:

"A large number of closed-loop simulations of the complete flight simulating ground
segment operation, telemetry flow and launcher dynamics were run in order to verify
[...]"

Porównaj to ze swoimi wypowiedziami na temat tego, co zrobili albo czego nie zrobili
albo co zrobiłby każdy student, albo co robią wszyscy na całym świecie, itd.
I przede wszystkim, przeczytaj ten raport.

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

do góry