On 29/03/2015 23:18, Maciej Sobczak wrote:
>
>> W indywidualnym przypadkui nie wiemy, ale w skali dużej firmy jak
>> najbardziej można zbierać dane między wysiłkiem włożonym w
>> testowanie s stratami z fakapów.
>
> I właśnie piszę o tym, że z tych zebranych danych rodzi się
> zainteresowanie metodami formalnymi.

No więc OIMW w finansach takie dane są zbierane, a zainteresowanie
metodami formalnymi z tego nie wynika.

>> Z tym że mnie np. nie przekonuje to, czy wiedza z takich danych
>> jest loepsza niż intuicja doświadczonego inżyniera oprogramowania.
>
> Intuicja doświadczonego programity nie zostaje w firmie gdy on
> odchodzi. Wiedza z zebranych danych i wynikające z niej decyzje jak
> najbardziej mogą zostać i to też przyczynia się do zainteresowania
> metodami, które są przewidywalne.

Można też zatrudnić kolejną osobę z doświadczeniem i to wg. mnie nadal
jest bardziej opłacalne niż metody formalne (z wyjątkiem nisz etc. etc.)

>> Na ile rozumiem, to jest dokładnie tak samo, jak w "branżach
>> krytycznych" - jeśli bug w oprogramowaniu kogoś zabije, to
>> programista na etacie może straci pracę a może nie, ale procesu
>> karnego ani cywilnego raczej nie musi się obawiać.
>
> Przecież nie napisałem, że zawsze chodzi o programistów. Najczęściej
> to nawet nie oni wybierają metody pracy (jest odwrotnie: zwykle
> programiści są wybierani pod kątem metody, która ma być
> zastosowana). W branżach krytycznych jest jeszcze temat norm, które
> ten temat porządkują.

Aha, a osobom wybierającym metody pracy realnie grozi powództwo karne
lub cywilne (w sensie że się coś takiego zdarzyło)? W przypadku, kiedy
to są etatowi pracownicy?

>> Ale mnie ogólnie chodzi o to, że nawet w przypadku redukcji ryzyka
>> fakapu korzyść z tego będzie mniejsza niż całkowity koszt
>> zastosowania metod formalnych.
>
> Jeśli korzyść z redukcji ryzyka fakapu będzie mniejsza od czegoś,
> czego nawet nie wyceniłeś,

Tzn. czego? Gdybyś chciał wprowadzać metody formalne to nie tylko koszt
tego byłby wyceniony z góry, ale też i potem firma by mierzyła ile to
kosztowało.

> to przyznajesz, że koszty fakapu są
> relatywnie niewielkie albo jego prawdopodobieństwo epsilonowe - ale
> przyznałeś też, że milionowe fakapy nie są niczym niezwykłym.
> Wychodzi mi to, co napisałem wcześniej - że fakapy są relatywnie
> tanie.

Nie "wychodzi", tylko nie bierzesz pod uwagę jakie mogą być koszty metod
formalnych.

Jeśli przykładowo masz aplikację, która bez fakapów zarobi w ciągu roku
5 milionów, ale ryzyko jest 20% że przez fakapy straci się te 5
milionów, i w tym 5%, że się narobi straty netto na 5 milionów, to można
powiedzieć, że koszty fakapu są duże, ale podjęcie ryzyka i uruchomienie
tej aplikacji nadal może być sensowną decyzją biznesową (nie mówię, że
koniecznie taką będzie, ale przynajmniej może być).

Jeśli zastosowanie metod formalnych zredukuje te prawdopodobieństwa do
odpowiednio 0.002% i 0.0005%, ale będzie kosztować 5 milionów, to można
powiedzieć, że się kompletnie nie opłaciło, chociaż fakapy są kosztowne.

No chyba że "relatywnie tanie" oznacza relatywnie do kosztów
zastosowania metod formalnych. W takim razie nie wykluczam, że nawet te
fakapy na setki milionów są relatywnie tanie.

> Ważne słowa: audyt, normy, sąd, działania korygujące.
>
> Czy te słowa występują w branży finansowej? Mówimy o warstwie
> technicznej.

Jak rozumiem takie rzeczy się owszem, dzieją, ale nie jest to coś, czym
się szczególnie interesuję.

Tylko że wcześniej mówiliśmy o konsekwencjach dla osoby podejmującej
decyzje, nie dla firmy. Jakie były konsekwencje dla osoby podejmującej w
Toyocie decyzje oo metodach rozwoju oprogramowania? Stanęła przed sądem
jako oskarżony? Straciła pracę? Popełniła sepukku?

> Działania korygujące wyglądają tak:
>
> http://www.automotive-eetimes.com/en/toyota-utilizes
-spark-pro-programming-language-in-ultra-low-defect-
software.html?cmp_id=7&news_id=222902902
>
> Panowie zauważyli, że:
>
> "[...] it enables lower development and maintenance efforts since the
> formal approach [...]"

Po pierwsze tam jest tylko napisane, że uruchomili "research project".
Jakie były wyniki tego "research" nie udało mi się znaleźć. Cynik mógłby
powiedzieć że był to ruch PR-owy w reakcji na wiadome problemy, żeby w
prasie nazwa firmy pojawiła się w sąsiedztwie słów "ultra low defect".

A jeśli chodzi o moją intuicję - choć przyznam, że jest to kolejna
rzecz, na której się nie znam, to działanie programu przekładającego
informację o wciśnięciu pedałów w samochodzie na jakieś sygnały
sterujące elementami mechanicznymi może być właśnie takim tematem, gdzie
akurat metody formalne się mogą opłacać.

> I ja właśnie dokładnie o tym - o rosnącym zainteresowaniu metodami
> formalnymi, które coraz częściej są postrzegane jako tańsza
> alternatywa dla testów. Przy okazji wspomniałem też o tym, że branża
> finansowa nie jest poziomem referencyjnym w temacie dbania o jakość
> produktów, chociaż wcale nie chciałem, aby stało się to głównym
> tematem tego wątku.

A ja pisałem o tym, że zainteresowanie jest głównie niszowe, w takich
właśnie niszach, w których może się to opłacać. Branża finansowa była
podana jako przykład na to, że nie zależy to tylko od wysokości realnych
lub potencjalnych strat.

I praktycznie w kwestii kolegi, który na grupie pytał o porady dotyczące
zastosowania takich metod w programie, który samodzielnie dłubie dla
jakiegośtam klienta, sprowadzałoby się to właśnie do "uważaj, bo może
się okazać, że to, co próbujesz zrobić kosztuje miliony dolarów". I tak,
uważam, że zarówno ten cały research project Toyoty jak i ewentualne
wdrożenie takiego czegoś do produkcji to jest skala kosztów co najmniej
milionów dolarów, ale Toyotę na to może być stać, bo jest Toyotą, a
kolega pytający na grupie - niekoniecznie.