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.