On Monday, August 13, 2012 11:32:10 AM UTC+1, Paweł Kierski wrote:

> Ktoś może zaoponować, że to zwiększy próg wejścia z pewnymi rozwiązaniami, bo firmy
będą się bały konsekwencji oznaczających de facto bankructwo firmy oraz zarządów
(jeśli dołożymy odpowiedzialność na majątku decydentów).

Prog wejscia i tak juz jest bardzo wysoko, wiec to niewiele zmieni.

RW

do góry

W dniu 2012-08-13 14:05, Roman W pisze:
> On Monday, August 13, 2012 11:32:10 AM UTC+1, Paweł Kierski wrote:
>
>> Ktoś może zaoponować, że to zwiększy próg wejścia z pewnymi rozwiązaniami, bo
firmy będą się bały konsekwencji oznaczających de facto bankructwo firmy oraz
zarządów (jeśli dołożymy odpowiedzialność na majątku decydentów).
>
> Prog wejscia i tak juz jest bardzo wysoko, wiec to niewiele zmieni.

Miałem na myśli próg wejścia na produkcję rozwiązań typu automatyzacja
handlu. Chyba jednak inaczej podejmuje się decyzje, jeśli w razie
porażki: a) może zbankrutować twoja firma vs. b) może zbankrutować
twoja firma, a Ty zostaniesz w koszuli.

--
Paweł Kierski
n...@p...net

do góry

On Mon, 13 Aug 2012 08:22:11 +0200, Paweł Kierski <n...@p...net>
wrote:

>W dniu 2012-08-10 14:39, A.L. pisze:
>> On Fri, 10 Aug 2012 09:32:36 +0200, Paweł Kierski<n...@p...net>
>> wrote:
>>
>>> W dniu 2012-08-09 19:34, Andrzej Jarzabek pisze:
>>>> On 09/08/2012 12:23, Roman W wrote:
>>>>>
>>>>> Procesem nie podniesie sie umiejetnosci deweloperow, ale moze da sie
>>>>> uniknac tego:
>>>>>
>>>>> http://www.nanex.net/aqck2/3525.html
>>>>>
>>>>> "We believe Knight accidentally released the test software they used
>>>>> to verify that their new market making software functioned properly,
>>>>> into NYSE's live system."
>>>>
>>>> Teoretycznie tak, ale równie dużą masz szansę na to, że sama procedura
>>>> "urzędowego testowania" spowoduje w pewnym momencie błąd polegający na
>>>> wpuszczeniu testowych programów lub danych do produkcji.
>>>
>>> Jeszcze jeden możliwy scenariusz - "urzędowe testowanie" zmniejszy
>>> ciśnienie na testowanie własne. Skoro celem będzie nie bezbłędne
>>> oprogramowanie, a
>>
>> Nie ma bezblednego oprogramowania ani metod pozwalajacych stwierdzic
>> ze oprogramowanie jest bezbledne (pomijajakc oczywiscie PROSTE
>> programy 5 linijkowe)
>
>No i pytanie - w czym "urzędowe" testy będą lepsze? Czy zwiększą
>pokrycie - zmniejszą liczbę błędów? Z chęcią zobaczyłbym argument
>inny niż "bo będzie ich w sumie więcej", albo "urząd/państwo lepiej
>się zna".

Nie wiem co to sa "uzredowe testy". Klient okresla co system ma robic,
w jakim czasie, itede, daje problemy do testowania i tak dalej.
Kryteria odbioru sa sformulowane tak mniej wiecej: ma rozwiazac
problem ze 100 jednostkami w czasie godziny a z 500 jednostkami w
czasie nie dluzszym niz 2 godziny". To sa testy dotyczace globalnej
funkcjonalnosci a nie tego czy nacisniecie guzika daje prawidlowy
efekt.

W nromalnej firmie robiacej systemy "w rodzaju" mission critical - "w
rodzaju" - to znaczy moga spowodowac strate duzych pieneidzy ale
nikogo nei zabija, testowanie i QA pochlania 75% zasobow i kosztow
produkcji. I przeprowadzane jest przez duza i dosyc skomplikwoana
organizacyjnie grupe wedle dosyc sformalizowanych i drakonsko
przestzreganych procedur. Te testy nei wkluczaja "unit testing" ktore
sa odpowiedzalnoscia programisty (ale to ktore unit tests tez sa
kontrlowoane pzrez owa grupe, w szczegolnosci zapuszczane co noc).

A.L.

do góry

Dnia Mon, 13 Aug 2012 10:53:55 -0500, A.L. napisal:

> On Mon, 13 Aug 2012 08:22:11 +0200, Paweł Kierski <n...@p...net>
> wrote:
>
>>W dniu 2012-08-10 14:39, A.L. pisze:
>>> On Fri, 10 Aug 2012 09:32:36 +0200, Paweł Kierski<n...@p...net>
>>> wrote:
>>>
>>>> W dniu 2012-08-09 19:34, Andrzej Jarzabek pisze:
>>>>> On 09/08/2012 12:23, Roman W wrote:
>>>>>>
>>>>>> Procesem nie podniesie sie umiejetnosci deweloperow, ale moze da sie
>>>>>> uniknac tego:
>>>>>>
>>>>>> http://www.nanex.net/aqck2/3525.html
>>>>>>
>>>>>> "We believe Knight accidentally released the test software they used
>>>>>> to verify that their new market making software functioned properly,
>>>>>> into NYSE's live system."
>>>>>
>>>>> Teoretycznie tak, ale równie dużą masz szansę na to, że sama procedura
>>>>> "urzędowego testowania" spowoduje w pewnym momencie błąd polegający na
>>>>> wpuszczeniu testowych programów lub danych do produkcji.
>>>>
>>>> Jeszcze jeden możliwy scenariusz - "urzędowe testowanie" zmniejszy
>>>> ciśnienie na testowanie własne. Skoro celem będzie nie bezbłędne
>>>> oprogramowanie, a
>>>
>>> Nie ma bezblednego oprogramowania ani metod pozwalajacych stwierdzic
>>> ze oprogramowanie jest bezbledne (pomijajakc oczywiscie PROSTE
>>> programy 5 linijkowe)
>>
>>No i pytanie - w czym "urzędowe" testy będą lepsze? Czy zwiększą
>>pokrycie - zmniejszą liczbę błędów? Z chęcią zobaczyłbym argument
>>inny niż "bo będzie ich w sumie więcej", albo "urząd/państwo lepiej
>>się zna".
>
> Nie wiem co to sa "uzredowe testy". Klient okresla co system ma robic,
> w jakim czasie, itede, daje problemy do testowania i tak dalej.
> Kryteria odbioru sa sformulowane tak mniej wiecej: ma rozwiazac
> problem ze 100 jednostkami w czasie godziny a z 500 jednostkami w
> czasie nie dluzszym niz 2 godziny". To sa testy dotyczace globalnej
> funkcjonalnosci a nie tego czy nacisniecie guzika daje prawidlowy
> efekt.
>
> W nromalnej firmie robiacej systemy "w rodzaju" mission critical - "w
> rodzaju" - to znaczy moga spowodowac strate duzych pieneidzy ale
> nikogo nei zabija, testowanie i QA pochlania 75% zasobow i kosztow
> produkcji. I przeprowadzane jest przez duza i dosyc skomplikwoana
> organizacyjnie grupe wedle dosyc sformalizowanych i drakonsko
> przestzreganych procedur. Te testy nei wkluczaja "unit testing" ktore
> sa odpowiedzalnoscia programisty (ale to ktore unit tests tez sa
> kontrlowoane pzrez owa grupe, w szczegolnosci zapuszczane co noc).

To nie wyklucza czegoś w rodzaju "acceptance tests", zrobione dla
urzędu przez jakąś firmę. Mogą symulować wszelkie skrajne i nieskrajne
sytuacje na rynku, taki NYSE Compatibility Toolkit ;-) - jak nie
przechodzi to nie ma wstępu na rynek.

Z technicznego punktu widzenia, sens praktyczny zupełnie pomijam.

Edek

do góry

On Mon, 13 Aug 2012 16:50:26 +0000 (UTC), Edek Pienkowski
<e...@g...com> wrote:

>To nie wyklucza czegoś w rodzaju "acceptance tests", zrobione dla
>urzędu przez jakąś firmę.

Jakiego "urzedu"?...

A.L.

do góry

Dnia Mon, 13 Aug 2012 13:40:13 -0500, A.L. napisal:

> On Mon, 13 Aug 2012 16:50:26 +0000 (UTC), Edek Pienkowski
> <e...@g...com> wrote:
>
>>To nie wyklucza czegoś w rodzaju "acceptance tests", zrobione dla
>>urzędu przez jakąś firmę.
>
> Jakiego "urzedu"?...

Regulatora rynku. Na tym polu ma moc urzędową, prawda?

Edek

do góry

On 13/08/2012 16:53, A.L. wrote:
>
> Nie wiem co to sa "uzredowe testy".

Proponowane rozwiązanie, o którym dyskutujemy w tym wątku.

> Klient okresla co system ma robic,
> w jakim czasie, itede, daje problemy do testowania i tak dalej.

W przypadku takiej firmy jak Knight Capital klient nic takiego nie
określa, w ogóle raczej nie ma styczności z "systemem". Klient tylko
daje pieniądze i mówi "zainwestujcie mi to"

> W nromalnej firmie robiacej systemy "w rodzaju" mission critical - "w
> rodzaju" - to znaczy moga spowodowac strate duzych pieneidzy ale
> nikogo nei zabija, testowanie i QA pochlania 75% zasobow i kosztow
> produkcji.

A firmy finansowe typu Knight Capital to są normalne czy nienormalne?

> I przeprowadzane jest przez duza i dosyc skomplikwoana
> organizacyjnie grupe wedle dosyc sformalizowanych i drakonsko
> przestzreganych procedur.

A jednak się stało co się stało.

do góry

On 13/08/2012 11:32, Paweł Kierski wrote:
> W dniu 2012-08-13 11:32, Andrzej Jarzabek pisze:
>>
>> Ja myślę jednak, że w praktyce byłoby to relizowane tak, że samo
>> tworzenie testów i testowanie byłoby wykonywane przez prywatną firmę,
>> wyłonioną w jakimś przetargu.
>
> Czyli jeszcze jedno miejsce styku, gdzie możemy zapodziać istotną
> informację dotyczącą faktycznej natury i celu testów.

Natura i cel testów wpisane byłyby w odpowiednie przepisy i w treść
przetargu. Jakoś w innych dziedzinach nie sprawia to szczególnych
problemów: np. jak rząd zleca prywatnemu wykonwacy budowę autostrady z A
do B, to jakoś nie widać, żeby zamiast tego wykonawcy nagminnie budowali
szosy jednopasmowe z C do D.
> [...]
>> Ale przynajmniej część szkodników się wykosi.
>
> Teoretycznie to powinno zadziałać i być lepiej. Boję się, że praktyka
> może przynieść (przy sporych dodatkowych kosztach) wyniki słabe, albo
> wręcz odwrotne.

Niby dlaczego? Od razu uprzedzam, że argument "bo jak urzędnik coś
urzędowo nakaże, to zawsze jest gorzej' jest słaby. Wiele rzeczy, które
urzędnicy nakazują działa dobrze. Na przykład normy emisji dla
samochodów. Albo, chociażby taki drobny fakt: w tej chwili znajduję się
w kraju UE innym niż mój operator komórkowy. Kiedyś było tak, że
wykonywanie i odbieranie telefonów w takiej sytuacji oznaczało jakieś
absurdalne opłaty. Teraz co prawda kosztuje mnie to nadal trochę drożej
niż dzwonienie w kraju, ale jednak - właśnie dzięki interwencji
urzędnika - są to jakieś w miarę rozsądne opłaty.

> Chyba faktycznie ostatecznym rozwiązaniem byłoby zwiększenie
> odpowiedzialności za błędy, które i tak wystąpią. Ktoś może zaoponować,
> że to zwiększy próg wejścia z pewnymi rozwiązaniami, bo firmy będą się
> bały konsekwencji oznaczających de facto bankructwo firmy oraz zarządów
> (jeśli dołożymy odpowiedzialność na majątku decydentów).

Teoretycznie taka odpowiedzialność istnieje. Tylko, pomijając w ogóle
jak to wygląda w praktyce, to trzeba udowodnić, że to oni i ich decyzje
spowodowały te straty.

> Cóż - nie ma
> obowiązku ryzykować i wdrażać skomplikowanych systemów, w których
> zawsze będzie jeszcze jeden błąd...

Przecież nie robią tego z obowiązku, tylko dla kasy.

do góry

On 13/08/2012 13:40, Paweł Kierski wrote:
>
> Miałem na myśli próg wejścia na produkcję rozwiązań typu automatyzacja
> handlu. Chyba jednak inaczej podejmuje się decyzje, jeśli w razie
> porażki: a) może zbankrutować twoja firma vs. b) może zbankrutować
> twoja firma, a Ty zostaniesz w koszuli.

No ale nie tak działa ten ustrój.

do góry

On Mon, 13 Aug 2012 18:53:51 +0000 (UTC), Edek Pienkowski
<e...@g...com> wrote:

>Dnia Mon, 13 Aug 2012 13:40:13 -0500, A.L. napisal:
>
>> On Mon, 13 Aug 2012 16:50:26 +0000 (UTC), Edek Pienkowski
>> <e...@g...com> wrote:
>>
>>>To nie wyklucza czegoś w rodzaju "acceptance tests", zrobione dla
>>>urzędu przez jakąś firmę.
>>
>> Jakiego "urzedu"?...
>
>Regulatora rynku. Na tym polu ma moc urzędową, prawda?
>
>Edek

Co to jest "regulator rynku" i co on ma wspolnego z testowaneim
oprogramowania?...

A.L.

do góry