eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingBlad w oprogramowaniu Toyoty przyczyna wypadkowRe: Certyfikacja, było: Blad w oprogramowaniu Toyoty przyczyna wypadkow
  • Data: 2012-03-28 17:57:33
    Temat: Re: Certyfikacja, było: Blad w oprogramowaniu Toyoty przyczyna wypadkow
    Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On Mar 28, 9:34 am, Paweł Kierski <n...@p...net> wrote:
    > W dniu 2012-03-28 00:01, Andrzej Jarzabek pisze:
    >
    > > No więc inżynier oprogramowania nie musi się znać na elektryce i
    > > czujnikach, natomiast powinien się znać na zbieraniu wymagań. Również na
    > > takich rzeczach, jak np. stworzenie zestawu testów obejmujących jakieś
    > > przypadki brzegowe i zauważeniu, że np. specjalista od czujników
    > > opisujący, jak się ma zachowywać oprogramowanie w zależności od tego, co
    > > dostaje z czujników, zostawił pewną niewyspecyfikowaną plamę i podnieść
    > > temat do analizy przez domain experts ("a co jeśli ten czujnik mówi, że
    > > samochód przyspiesza, a tamten, że koła kręcą się coraz wolniej?").
    >
    > Właśnie wymieniłeś w przykładzie rolę analityka (zbieranie wymagań).

    Masz problem na styku dwóch ludzi, z których jeden wie, co program ma
    robić, a drugi zna się na pisaniu programów. Pierwszą osobę możesz
    nazwać analitykiem biznesowym, domain specialist, kleintem (z punktu
    widzenia twórcy oprogramowania) itd. Druga osoba w ten czy inny sposób
    jest programistą czy inżynierem oprogramowania.

    I teraz ta pierwsza osoba może określić wymagania, czyli np. napisać
    dokument, w którym opisze to, jak w jej rozumieniu program ma działać
    - za pomocą języka naturalnego, tabelek, pseudokodu, rysunków,
    diagramów, reguł, przykładów i tak dalej.

    Niestety opis działania programu napisany w ten sposób może zawierać
    niejasności, niejednoznaczność, sprzeczności, niedookreślenia.
    "Zbieranie wymagań" o którym mówię, to jest to, że druga osoba bierze
    te pierwotne wymagania, zauważa niejasności, niejednoznaczności,
    niedookreślenia, sprzeczności i tak dalej, i dowiaduje się jakie są
    faktyczne wymagania w tych sytuacjach. I to właśnie miałem w tym
    kontekście na myśli przez "zbieranie wymagań". Możesz sobie te
    czynności nazwać analizą biznesową i analizą techniczną, czy
    jakkolwiek - w przypadku np. oprogramowania do samochodów taka
    terminologia raczej nie ma sensu, bo obydwa etapy są "techniczne".

    To, jak podzieloną masz pracę, czy np. pożądane działanie komputera
    sterującego silnikiem będzie pisane przez "inżyniera mechanika" czy
    przez "analityka" jest osobną sprawą. Natomiast w jakiejkolwiek
    postaci nie dotrze ono do programisty, to nie będzie to działający
    kod, więc będzie miało potencjalną możliwość być sprzecznym,
    niejednoznacznym i nie obejmować pewnych przypadków. Natomiast
    działający kod ma to do siebie, że nie za bardzo możesz mieć ścieżkę
    logiczną czy kombinację wejść, z której nie będzie wynikało, jak
    program się zachowa. Co najwyżej możesz mieć różne formy "undefined
    behavior", ale właśnie jedną z rzeczy, jakie programista powinien
    wiedzieć, to to, że nie należy przekładać specyfikacji, z której nie
    wynika, jak program się ma zachować w jakichś warunkach, na program,
    który w takich warunkach ma undefined behavior.

    Oczywiście, że można sobie wyobrazić sposoby obejścia wymogu
    certyfikacji, np. żeby między produkującego poprawny opis wymagań
    certyfikowanego inżyniera mechanika, a certyfikowanego programistę,
    wstawić niecertyfikowanego łosia "analityka", który nieumiejętnie
    przełoży poprawny opis wymagań na jakieś sknocone UML-e czy inne
    diagramy i kawałki pseudokodu zawierające błędy rzeczowe. I również
    jest możliwość - w ramach certyfikacji programistów, na
    "delegalizację" takich sytuacji. Ale też musisz przyznać, że takie
    scenariusze są w sumie nie aż takie bardzo prawdopodobne, żeby
    koniecznie warto było tworzyć na nie specjalną klauzulę - w porównaniu
    do po prostu zatrudnienia przez producenta niekompetentnego
    programisty.

    > Czyli w zasadzie nie chodzi o certyfikowanie programistów, tylko co
    > najmniej całego zespołu, a może lepiej - procesu? A może po prostu
    > produktu?

    Chodzi o certyfikowanie programistów. A być może chodzi również o
    certyfikowanie procesów i produktów. W zależności od tego, co by
    wykazały ewentualne badania.

    > [...]
    > > Dodatkowo część błędów w oprogramowaniu również wynika z błędó typowo
    > > programistycznych: błędnej logiki, race conditions, różnego rodzaju
    > > undefined behaviour i tak dalej.
    >
    > Otóż to - część. Inne wynikają z błędów na innych etapach procesu lub
    > w innym fragmencie konstrukcji.
    >
    > Certyfikowanie zespołu lub poszczególnych jego członków (np.
    > programistów) daje mniejszy wkład w efekt końcowy - bezpieczniejszy
    > produkt. W "dziurawym" procesie certyfikowany zespół może wyprodukować
    > bubla. Nie mówiąc o tym, że brak certyfikacji wszystkich osób
    > odpowiedzialnych za jakość w ogóle mija się z celem - brak certyfikatu
    > jednej osoby pełniącej istotną rolę "unieważnia" certyfikację
    > pozostałych zaangażowanych w proces.

    Nie unieważnia. To nie jest przecież tak, że jak kogoś nie
    certyfikujesz, to on już na 100% jest niekompetentny. I nie jest tak,
    ze jak kogoś certyfikujesz, to nie będzie w ogóle popełniał żadnych
    błędów. Operujemy na prawdopodobieństwach pewnych zdarzeń. Jeśli (w
    uproszczeniu) masz dziurawy proces, w którym program ma 10% szansy
    pójść do produkcji bez testów, to jak wpływa na prawdopodobieństwo
    wybuchu to, czy programista zrobi błąd powodujący wycbuch z
    prawdopodobieństwem 0.1% czy z prawdopodobieństwem 50%?

    > Czyli wracamy do podnoszonej tu przez kilka osób kwestii - lepiej
    > certyfikować produkt lub proces (być może oba).

    No więc uważam, że nie da się na to pytanie odpowiedzieć gdybając.
    Trzeba konkretnie policzyć wybuchy, przyczyny, prawdopodobieństwa
    wystąpienia błędów na różnych etapach, oszacowac jak różne formy
    certyfikacji wpływają na te prawdopodobieństwa, oszacować koszty i
    porównać z kosztami i efentywnością innych środków poprawiających
    bezpieczeństwo (ratujących życie, zdrowie, redukujących straty
    materialne). Czyli zrobić te badania, o których pisałem.

    Natomiast tak sobie gdybając mogę tylko powiedzieć, że skuteczność
    certyfikacji zależy mocno od tego, na ile można powiedzieć "tak
    właśnie to należy robić". I na przykład jeśli chodzi o procesy, to nie
    wydaje mi się, żebyśmy w produkcji oprogramowania osiągnęli ten stan,
    gdzie już wiadomo, jak proces powinien wyglądać, ewentualnie można
    określić łatwo mierzalne parametry projektu, według których mozna
    wybrać taki lub inny proces.

    Nie wiem też, czy na przykład mamy taką wiedzę o testowaniu - czy
    można powiedzieć: to a to każdy tester oprogramowania, niezależnie od
    dziedziny czy używanych technologii, powinien wiedzieć lub umieć,
    jeśli jest kompetentny. Może jest coś takiego, na mojego czuja nie -
    ale nie znam się na tej dziedzinie.

    Natomiast na programowaniu trochę się znam, i moje zdanie jest takie,
    że właśnie w programowaniu, czy powiedzmy w "inżynierii
    oprogramowania" doszliśmy do tego, że można taki korpus wiedzy,
    umiejętności i praktyk wydzielić. Problem jest taki, że doszliśmy do
    tego niedawno, powiedziałbym, że to może kwestia ostatniej dekady. I
    jest tak, że wielu programistów robi źle, bo są mentalnie w latach 90-
    tych (albo wcześniej), bo się uczyli "po staremu", bo wydaje im się,
    że mogą sami wynaleźć koło od nowa i zrobią to lepiej (i być może
    niektórzy z nich mogą, ale niech to robia na uniwersytetach, a nie w
    fabrykach). Ale smutna (lub radosna, w zależnopści od punktu widzenia)
    prawda jest taka, że czasy kowbojów się skończyły. Więc jest sens,
    żeby zmiany w prawie dostosowały się do zmieniających się realiów.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: