Had- és rendvédelem-história, kicsit másképp

Összeálltunk páran, hogy kipróbáljuk: lehet-e szórakoztatóan, ugyanakkor informatívan foglalkozni rendvédelem-történeti, valamint katonahistóriai témákkal. Szerintünk igen. *** imélke nekünk: blog.lemil(at)yahoo.co.uk --- BLOGUNK A MAGYAR BLOGGERSZÖVETSÉG TAGJA ---

Megjelent a Kémek krémje!

borito_240.jpg

Naptár

december 2019
Hét Ked Sze Csü Pén Szo Vas
<<  < Archív
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

Lemil-fészbúk

Olvasóink lobogói

Pillanatnyi olvasólétszám:

website stats

Utolsó öt komment

Fontosabb címkék

1848 49 (46) afganisztán (6) afrika (13) ajánló (87) alagút (7) állat (8) amerikai (101) angolok (8) arabok (15) argentin (5) átirányítás (13) atom (13) ausztrál (6) ázsia (15) balkán (6) betyár (5) biofegyver (5) biztonságpolitika (6) brazil (7) brit (67) buli (6) büntetésvégrehajtás (7) büntetőjog (11) címer (6) csata (9) csatabemutató (9) csendőrség (6) dél amerika (11) ejtőernyős (27) életrajz (41) elmélet (12) erdély (5) erőd (8) értékelőposzt (7) évforduló (53) fegyver (7) ferencjózsef (11) francia (24) gallup (5) görgey (13) görögök (5) háború (6) háborús bűn (8) hadifogoly (5) haditechnika (96) haditengerészet (53) hadsereg (15) hadtörténelem (159) hadtörténet (22) hadvezérek (9) hagyományőrzők (5) hajók (5) harckocsi (23) határőrség (7) hellókarácsony (5) helyi háborúk (17) hidegháború (52) híres bűnözők (8) honvédség (12) horthy (6) humint (24) huszár (10) i. világháború (49) ii világháború (107) izrael (26) japán (22) játék (6) k.u.k. (8) kalóz (6) kamikaze (6) kanada (7) katonazene (10) kelták (5) kémek és hírszerzők (59) kiképzés (7) kína (5) kínai (5) kivégzés (6) könyv (5) könyv ajánló (5) középkor (10) közép amerika (7) kuba (9) különlegesek (71) légierő (56) légvédelem (9) lengyel (17) lengyel magyar barátság (8) lista (5) lovas (6) lovasság (10) lövészárok (5) magyar (152) makett (7) monarchia (13) múzeum (12) német (68) nők (12) ókor (13) olasz (13) önvédelem (5) orosz (31) ostrom (6) osztrák (30) osztrák magyar (28) pestis (6) plakát (12) podcast (9) polgárháború (5) porosz (5) portugál (6) programajánló (10) reform (6) reklám (5) rendőr (7) rendőrség (10) rendvédelem (54) róma (13) román (8) rövidhír (18) sigint (6) skandináv (7) skót (6) sorozat (15) spanyol (5) svájci (5) svéd (7) számítógép (9) szavazás (20) szerb (11) szlovák (5) szolgálati közlemény (39) szovjet (63) sztálin (5) telefonkártya (6) tengeralattjáró (17) tengerészgyalogos (10) terror (25) titkosszolgálat (71) török (15) tűzfegyver (9) ünnep (5) USA (7) usa (54) utánközlés (24) vadászgép (12) várostrom (6) vendégposzt (80) vértanú (11) vicc (7) vietnam (5) vitaposzt (74) wysocki légió (12) zene (11) A többi címke

Közkívánatra: feedek

General Protection Fault - II.

2012.04.09. 08:00 Papírzsepi

A szép júniusi napon a 61 éves asszony belépett a Mariettában (Georgia állam) álló Kenneston kórház ajtaján. Mellrákjának eltávolítása után 10 MeV (mega-elektronvolt) energiájú elektronsugár-kezelést írtak fel neki, így ezen a napon a kórház új terápiás röntgengépével, a mindössze fél éve vásárolt Therac-25-ös géppel volt randevúja.

Ez a röntgengép-típus az eset idején, 1985-ben már bő két éve üzemelt más kórházakban, és a Kenneston is elégedett volt vele. Már az elődje, a Therac-20 is nagyon megbízható eszközként volt ismert, de az ugyanazzal a szoftverrel vezérelt, ám sokkal kompaktabb és erősebb Therac-25-tel sem voltak problémák. Egészen eddig.

Az asszony felsikoltott fájdalmában, mikor a gép üzemelni kezdett. Hatalmas forróságot érzett, amely megperzselte a testét. Ugyan panaszkodott a kezelő személyzetnek, de nem volt látható égési sérülése, így az esetet nem vették túl komolyan. Azért a biztonság kedvéért felhívták a gyártót, az AECL-t, hogy lehetséges-e, hogy a gép összeégesse a pácienst, de két nappal később azt a választ kapták, hogy ez kizárt. A későbbi periratokból kiderül, hogy gyártó alkalmazottja minden vizsgálat nélkül lerázta a kórházi dolgozókat, érdemben nem foglalkozott senki az esettel és nem is jelentették tovább a főnökeiknek.

A hölgy fájdalmai fokozódtak, a háta lemerevedett, a bőre foszlani kezdett. A kezei is lebénultak. Végül a súlyos sugárártalom miatt a melleit is le kellett venni. A szakértők szerint 15-20 ezer rad dózist kapott, ami jelentősen több, mint kellett volna. Az esetet jelentették, ennek ellenére a gyártó továbbra sem tett semmit, mert kizártnak tartotta, hogy a Therac-25 legyen a bűnös.

Hét héttel később, Kanadában, Ontartioban csapott le újra a röntgengép. Egy negyvenes nő jött a rákközpontba a huszonnegyedik sugárkezelésére, de ezúttal nem ment simán a dolog. Az operátor aktiválta a gépet, de az leállt öt másodperc múlva egy fura hibaüzenettel. Ám mivel úgy tűnt, hogy csak valami átmeneti probléma van, az operátor ezt felülbírálta, és folytatásra utasította a gépet. Ez bevett gyakorlat volt; a röntgengép szoftvere nem volt nagyon megbízható, rendszeresen leállt adatbevitel közben különféle hibaüzenetekkel. Ezúttal viszont a P-gomb lenyomása (Proceed) után a gép megint leállt ugyanezzel a hibajelzéssel. Gyorsan átnézték a gépet, de mindent rendben találtak, ami szintén nem volt szokatlan.

A kezelés során ez a nő is égési sérüléseket szenvedett. Kórházba került, de végül november 3-án meghalt rákban. A halottkém szerint ez a páciens sem az örömtől sugárzott: 13-17 ezer rad sugárdózist kapott.

A gyártó ekkor már vizsgálódni kezdett, és úgy találta, hogy csak egy mikrokapcsoló döglött be; igazából még mindig nem vették komolyan az esetet. De a gép, melyből 11 üzemelt az USA-ban és Kanadában, hat hónap múlva, 1986 márciusában ismét hallatott magáról. Ekkor egy bizonyos Ray Cox kapott az előírtnál 125-ször erősebb dózist. Ráadásul ennél az esetnél a kezelő helyiségben nem működött az audio-videó rendszer és a vészhívó sem, így a röntgengéppel szenvedő technikus nem is tudott róla, hogy odabent épp eltesz valakit láb alól. Végülis praktikus: így legalább a beteg ordítása nem zavarta az operátort a koncentrációban.

Aztán 10 nap múlva az eset ugyanitt ismét megismétlődött, majd 1987. január 17-én a Yakima Valley kórházban is megsütöttek valakit. Összesen hat embernek kellett meghalnia, mire végre ténylegesen nekiálltak kideríteni, hogy mi történt.

A röntgengépet egy PDP-11-es számítógép vezérelte, melyen egy assemblyben írt program futott. Egy standard szöveges terminálon át lehetett vele kapcsolatot létesíteni. 

A gép kétféle üzemmóddal rendelkezett: elektronsugár móddal és röntgen-móddal. Az eszköz lelke egy változtatható erősségű elektronsugár-forrás volt, ami akár 25 MeV energiájú sugárnyalábot is képes volt kibocsájtani. Ez önállóan igen veszélyes, ezért amikor a gépet elektronsugár-kezelésre használták, akkor különféle mágnesekkel szétszórták és gyengítették a sugarat a megfelelő felületű és erősségű kezeléshez. De a szétszórás és a gyengítés mellett sem használták kis a teljes elektronágyú-kapacitást, mivel arra csak a másik üzemmódban volt szükség. Röntgen-módban ugyanis a sugár útjába egy fluorescent lemezt tettek, mely az elektronsugarat röntgen-fotonokká alakította. Ez igen tetemes veszteséggel járt, ezért kellett a nagy kiindulási energia.

A kétféle üzemmód között tehát cserélni kellett a sugár útjába kerülő elemeket, amit mechanikusan, egy forgótányér segítségével végeztek el (a tányért is a PDP-11 vezérelte). Kritikus volt tehát, hogy a forgótányér a megfelelő állásban legyen. Ezért a korábbi modelleknél a tányér helyzetét mechanikus módszerekkel is ellenőrizték: ha nem volt jó helyen a forgótányér, nem indult el a kezelés. Ezt a mechanikus zárolást a Therac-25 esetében elhagyták, és teljes egészében a szoftverre bízták a pozíció-ellenőrzését.

A szoftvert pedig lényegében változtatás nélkül vették át a korábbi gépekből, és nem is nagyon nyúltak hozzá, mivel addig nagyon megbízhatóan működött (értsd: nem halt meg addig senki). Csak egy extra pozíció-ellenőrző programrésszel egészítették ki, de még azt sem próbálták ki a gép éles üzembe helyezése előtt.

Ám az örökölt szoftver közel sem volt olyan jó minőségű. Már az alapstruktúrája is el volt fuserálva, amit aztán gyalázatos minőségű programkóddal töltöttek meg. Az is csoda volt, hogy egyáltalán működött. A kezelői felülete sem volt igazán kényelmes, de még csak informatív sem. Rendszeresek voltak a programhiba-üzenetek, melyeket általában csak kóddal azonosítottak a képernyőn („Malfunction 54”). Hogy melyik kód mit jelent, az nem volt leírva sehol. De a fő baj az volt, hogy a mechanikát kezelő programrészek párhuzamosan futottak az adatbeviteli részekkel, így ha a kezelő túl gyorsan vitte be az adatokat (kellően nagy gyakorlatra tett szert), akkor egyes esetekben előfordulhatott, hogy a forgótányér hibásan lett beállítva. Ez jellemzően akkor fordult elő, amikor a technikus rutinból X gombot nyomott (X-ray mód) kezelési üzemmódnak, majd villám gyorsan rájött a hibára, visszalépett, és korrigált E (Electron) módra; ekkor a gép fele X, a másik fele E módot állított be: a forgótányér visszament E üzemmódba, a sugárforrás pedig maradt teljesen energián.

Ahhoz, hogy ez előálljon, kellett még pár további elfuserált ötlet a kezelői felülettel kapcsolatban: például, hogy az operátornak sok Entert kellett nyomnia egymás után az adatbevitel során, de ha a sok Enter közben hibaüzenet jelent meg (például, hogy az energiaszint és a mód beállítása nem egyeznek), akkor mindjárt azt is lekezelte a sok lendületes Enter gomb… 

A kritikus forgótányér-hibát persze észre kellett volna vennie a szép új ellenőrző modulnak, hiszen pont ezért volt ott. Csakhogy a pocsék minőségű kód itt is visszaütött: egy sima aritmetikai hiba (túlcsordulás) miatt az ellenőrző programrészek egyszerűen le sem futottak. Ez a korábbi modelleknél sem volt nagyon máshogy, de ott még megvolt a mechanikus védelem, mint utolsó védőbástya.

A programot a gyártó egyáltalán nem tesztelte a Therac-25-ben. Egy-az-egyben átvették a korábbi gépről, beszerelték az új röntgengépbe, és kiszállították a kórházba. Ott futott életében először ezen a hardveren (a Therac-25 prototípusa nem számítógép-vezérelt volt). Végeztek ugyan biztonsági számításokat, hogy például mennyi a valószínűsége, hogy rossz tányér-helyzettel indul a kezelés, de ezeknél egyáltalán nem vették figyelembe a szoftver lehetséges hibáit. Tehát az AECL gyönyörűen bemutatta annak az iskolapéldáját, hogy hogyan NE tervezzünk és supportáljunk biztonságkritikus, szoftver-vezérelt rendszert.

Végül 1987-ben az összes Therac-25-öt visszahívták, és korrektül orvosolták az összes feltárt problémaforrást. De akkor már mindegy volt: a Therac-25 név addigra már a felelőtlenség és az impotens programkészítés szinonimájává vált. [Forrás]

A gyenge minőségre nincs mentség, és a tesztelés hiánya sem elfogadható. De azért a tisztánlátás miatt érdemes pár szót szólni a szoftverek teszteléséről vagy éppenséggel teszteletlenségéről, mivel ezzel más alkalmazási területeken is gyakran találkozhatunk.

Miért nem lehet minden hibát megtalálni és idejében kijavítani a program kellően alapos kipróbálásával? Vagy ha nem is mindet, legalább a biztonság szempontjából aggályosokat?

A válasz a szoftverek komplexitásában rejtőzik. Ha egy programot simán csak ´próbálgatunk´, akkor az elképesztően nagy komplexitás miatt legfeljebb a benne lévő hibák 10%-át fogjuk tudni megtalálni. Rengeteg állapot, eshetőség, egybeesés és használati módszer ugyanis eszünkbe sem fog jutni.

Ha mindent módszeresen, alaposan végigveszünk és kipróbálunk, akkor sokkal jobb eredményt kaphatunk: szisztematikus teszteléssel akár a hibák 30-40%-át is megtalálhatjuk; igaz, ilyenkor a tesztelés önállóan jóval-jóval több időt és pénzt emészt fel, mint magának a programnak a megírása.

Persze meg lehet próbálni a vizsgálandó program minden lehetséges állapotát minden lehetséges esetre átnézetni egy számítógéppel, de mivel az ilyen teszt csak pár ezer év alatt futna le, túl lassú lenne a piacra dobás. 

És ha sikerül is megtalálni és kijavítani egy-két hibát, akkor is gyakori, hogy a javítással újabb hiba kerül a rendszerbe. Előfordult ilyen többször is, például az űrsikló program kezdetén is harcolt egy ilyen hibával a NASA.

Jól mutatja a hibakeresés és hibajavítás reménytelenségét az alábbi eset is.

Aranylövés

1995-ben a Gish Biomedical Inc, egy kis cég számára úgy tűnt, hogy az orvosi eszközök gyártása lesz a jövő nagy dobása, mivel ez a terület akkor kezdett felfutni. A piacra lépésükhöz viszont szükség volt egy jó termékre, mégpedig gyorsan. Így hát a lassú fejlesztés helyett inkább gyorsan megvásároltak egy mások által tervezett, már létező terméket; a nevadai Creative Medical Development Inc. adta el nekik 2,6 millió USD-ért a saját tervezésű Creative's EZ Flow injekciós adagolókészülékét, a benne lévő szoftverrel és annak rejtett hibáival együtt.

A kis kütyüt egy mikrokontroller irányította, kicsi volt, könnyű, praktikus és egyszerűen kezelhető. A kb. 2000 USD-be kerülő készülék ráadásul többfeladatos volt: inzulin, infúzió, és bizonyos gyógyszerek adagolása és beadása mellett fájdalomcsillapításra is alkalmas volt – ekkor morfiumot adagolt a páciensnek.

Sajnos a készülékkel elég hamar konstrukciós gondok adódtak. A beragadó gombok és a bizonytalan működés miatt már az újratervezését fontolgatták, aminek külön lendületet adott, amikor 1996-ban a kütyü túladagolta a gyógyszert egy betegnek. Az illetőnek nem lett baja, de a cég nem akart kockáztatni, így az egész szériát azonnal visszahívták átdolgozásra.

A hibát kijavították, a gépet újra forgalmazni kezdték, és úgy tűnt, minden rendben van. De 1997 szeptemberében a helyzet egy csapásra megváltozott, és rémálommá vált a cég számára. Az újonnan átdolgozott-kijavított készülék ugyanis simán túladagolta egy végstádiumos rákbetegnek a morfiumot – aki emiatt meghalt. (Lehet, hogy így járt jobban…)

A hibát egy szoftver hiba okozta, így a cég kénytelen volt újra visszahívni az összes egységet. Megpróbálták újra megtalálni és kijavítani a szoftver hibát, de egy évnyi szenvedés és rengeteg beleölt pénz után sem voltak képesek ezt megtenni. Hiába, no: ha egy programot egyszer rosszul kezdenek el, később már reménytelen javítani. Ezért a Gish végső elkeseredésében inkább a szoftver teljes újraírása mellett döntött, mert így legalább volt remény (kellően) hibátlanná tenni.

A Gish Biomedical Inc közben kis híján csődbe ment az eset miatt, utólag már bánják, hogy egyáltalán beléptek az orvosi eszközök piacára. És mielőtt bárki is azt gondolná, hogy ez egy egyedi eset volt: abban az időben több más cég is hasonló problémákkal küzdött, tucatjával lelhetők fel beszámolók a különféle orvosi eszközök problémáiról. Sok esetben a szoftver volt a bűnös, melyekben a nagyon ritkán előforduló hibák megtalálására szinte semmilyen remény nem volt.

A nagyon ritkán előforduló programhibák hátterében gyakran egy egészen egyszerű probléma lapul: a szoftver olyan szituációba kerül, amire egészen egyszerűen senki sem gondolt. Így nem is gondolták át, hogy ilyenkor mit kellene a programnak csinálnia, nem is programozták le a viselkedést, és persze nem is tesztelhették azt le. Aztán jön az Élet, és megmutatja: előbb-utóbb a legváratlanabb helyzet is előáll. Ráadásul mindig ott a legnagyobb bizonytalanság: a kezelő ember, és az ő remek ötletei. 

Már a Therac-25-nél is láthattuk, hogy kezelő gyakorlottsága és a kezelő parancsai milyen komoly szerepet játszottak az eseményekben. Még szerencse, hogy sokat tanultunk abból az esetből, így a korszerű módszerekkel készült modern szoftvereknél ilyesmi már nem fordulhat elő!

Panama

2000 novemberében járunk, mikor Victor Garcia belépett a Panamai Nemzeti Rákintézetbe. Sugárkezelésre érkezett. Ekkorra a Therac-25 emlékei már a múlt homályába vesztek, annak kezdetleges adatbeviteli módszereit is korszerűbbre cserélték már: a Nemzeti Rákintézet terápiás röntgengépe, a Cobalt-60 számára már grafikusan kellett bevinni az adatokat. Az amerikai gyártmányú, a (mindössze 15 főt foglalkoztató) Multidata Systems International által fejlesztett kezelés-tervező rendszerben egy 3D grafikus ábrán kellett megadni a kezelendő területet, mégpedig úgy, hogy virtuális pajzsokat kellett definiálni a sugárzástól megvédendő területek lefedésére. A kezelés összes többi paraméterét a szoftver már önállóan számolta. 

Összesen csak négy ilyen „pajzsot” lehetett megadni, de az alakjuk tetszőleges lehetett.

A virtuális pajzsok által le nem fedett területre ezután a program kiszámolta a szükséges dózist és a kezelési időzítéseket, majd elindulhatott a gamma-sugárzás.

Sajnos a négy megadható sokszög sok esetben bizony fájóan kevés volt, gyakran legalább ötre lett volna szükség. Ám a fejlesztő nem tett semmit.

Szerencsére a kezelést irányító fizikus, Olivia Saldaña  (alul a képen) kreatív nő volt, és a kezelői kézikönyv elolvasása után gyorsan rájött, hogyan lehet korrekten megkerülni a problémát. Ehhez a szokásos konvex sokszögek helyett a védendő területet egyetlen nagy, összetett alakzatként definiálta, egy megfelelő alakú lyukkal a közepén. Ezzel az unortodox megoldással a probléma simán megkerülhető volt, a gép nem tiltakozott. 

Saldaña gondosan járt el. A sokszögek definiálása után leellenőrizte az alakzatok feldolgozásából generált kezelési görbéket és időzítéseket, és mivel ezek teljesen hihetőek voltak, minden úgy festett, hogy a dolog működik. Saldaña lelkes volt; ugyan minden kezelésnél ellenőrizte a görbéket, de mikor már a sokadikat is rendben találta, már nem ment bele olyan mélyen az adatok ellenőrzésébe.

Pedig nem ártott volna…

Saldaña megoldását ugyan a kezelői utasítás sehol sem tiltotta, ám a szoftver fejlesztők mégsem gondoltak erre a zseniális megoldásra a program írása során. Így aztán nem is készítették fel rá kellően a gépet, és persze nem is tesztelték a helyes működést ilyen hülye alakú sokszögekre. Ennek ellenére a módszer látszólag teljesen jól működött, ugyanis minden probléma nélkül definiálni lehetett a lyukas sokszög külső peremét és a belsőt is, létre is jött a szokatlan alakzat, és a program nem is jelzett hibát.

Volt viszont egy kis bökkenő, ami eleinte nem szúrt szemet senkinek. Nem volt ugyanis mindegy, hogy a komplex alakzat határainak definiálása során az óramutató járásának megfelelően, vagy éppen ellenkezőleg haladt a kezelő az adatbevitellel. Ha a belső lyukat és a külső határvonalat ellentétes irányban definiálták, akkor minden jól működött. Ha viszont ugyanarra haladva, akkor az alakzatot értelmező szoftverben a két határvonal összekeveredett, és a program nem volt képes normálisan kiszámolni a területeket – így a szükséges sugárdózist sem. Az időzítések és sugáreloszlási ábrák ilyenkor is jónak tűntek, de a dózis 20%-100%-kal több volt, mint a szükséges. Ennek viszont nem volt nyilvánvaló jele, csak a részletekben elmélyedve lehetett volna kiszúrni, hogy a dózisbeállítás duplája a szükségesnek.

A gépen naponta nagyjából 100 kezelést végeztek el, köztük Viktor Garciaét is, aki bizony szerencsésnek nevezheti magát, hogy egyáltalán túlélte az esetet. A szoftver hiba csak akkor vált látványossá, mikor elkezdtek a betegek meghalni, és a statisztikák kimutatták a szokatlan halálozási arányt. Addigra a gép miatt már  legalább  nyolc ember nem érhette meg a halála napját, mert ők előbb meghaltak a túldozírozás miatt. Emellett további 28 páciens szenvedett súlyos sérüléseket.

A vizsgálat során a gyanú elsőként Saldañara terelődött, ő volt ugyanis a felelős a gép beállításáért. Meggyanúsították azzal, hogy rosszul vitte be az adatokat, nem ellenőrizte a beállításokat, így ő okozta a túldozírozást. Gyilkossággal vádolták, és alaposan meghurcolták. Mikor végre kiderült, hogy a Multidata szoftvere a hibás, akkor visszahelyezték az állásába, és ma is ott dolgozik – de annak ellenére, hogy igazából nem ő hibázott, állandó lelkiismeret-furdalása van.

A Cobalt-60 ma is működik, de már nem számítógépes terápiatervezéssel, hanem kézi módszerrel. Ez csak fele annyi beteget tud kiszolgálni naponta, mint annak idején a számítógépes módszer; igaz, ezek legalább életben maradnak. A Multidata is köszöni szépen, és jól van, de a 28 sérültnek fejenként fél-egy millió USD-t kellett kifizetniük fájdalomdíjként. [Forrás]

Tényleg: ki a felelős, ha egy szoftver gyilkol? 
A programozó? Neki esélye sincs hibátlan programot írni.
A kezelő? Ő nem tehet semmiről.
Akkor ki?

Habár ezt az esetet én inkább a Szoftverkrízis utolsó rúgásaként értelmezem, azért jól mutatja: a program a valóságban nagyon más körülmények közé fog kerülni, mint amit a laborban valaha is kipróbálhatnak a fejlesztők. Ezért nem mindegy az sem, hogy miként zajlik le egy szoftver bevezetése, betanítása és használatba vétele. 

Ezt illusztrálandó emlékezzünk most meg a londoni mentőszolgálat legismertebb szoftveres kalandjáról.

Mentőfrász

A londoni mentőszolgálat a világ egyik legnagyobb ilyen szervezete. A National Health Service részeként működő szervezet a folyamatosan növekvő terhelés, és az ezzel párhuzamosan zajló költségcsökkentés miatt már az 1980-as évek elején úgy döntött, hogy automatizálja a hívások fogadását, az erőforrások allokálását és a mentőautók szervezését. Elkezdtek tehát tervezni egy olyan rendszert, mely a tervek szerint központi szerverekből, mobil egységekből, és járművekre szerelt készülékekből állt volna. A tervek szerint ezek az egységek rádiókapcsolatban lettek volna egymással. A bejövő hívások forrását a rendszer automatikus lokalizálta volna, hozzárendelt volna egy mentőautót, és leküldte volna neki az útvonalat. A mentőautó sofőr a helyszínen megadhatta volna, hogy hol van, és mi az állapota. Így a központ folyamatosan tudta volna, hogy a flotta hol van éppen és mit csinál. 

Szépen hangzó terv, de a hatékonyság növelése mellett a másik célja emberek elbocsátása és költségmegtakarítás volt, így nem örvendett osztatlan népszerűségnek.

A feladatot egy kis cég, az IAL kapta meg. Rendkívül szoros határidőket jelöltek meg nekik, és szűkös pénzügyi keretet. Ráadásul tapasztalatuk sem volt a területen. A mentősök 1990-ben akarták az új rendszert indítani, de már sokkal korábban kiderült: az elkészülőfélben lévő rendszer egyszerűen nem lesz képes a várható terhelést kiszolgálni, alkalmatlan lesz a feladatra.

Így gyorsan új pályázatot írtak ki, amit a CAD, egy kis cégekből álló konzorcium nyert meg. Az eredeti terv alapvetően megmaradt, csak a megvalósítást kezdték újra. 1991. februárra készült el végleges a specifikáció, júliusra a rendszerterv, a bevezetést pedig 1992. január 8-ra írták ki. Ez egy ekkora rendszer esetén teljesen tarthatatlan határidő, de a mentők nagyfőnöke ragaszkodott hozzá. Pedig már az első kísérletből tudhatta volna: egy kudarc sokkal többe fog kerülni, mint az esetlegesen megtakarított bérek. Végül a határidőt nem is lehetett betartani: csak 1992 júniusában tartották meg a szoftver első oktatását a leendő kezelőknek. Ez volt egyben az utolsó is, pedig a rákövetkező 6 hónapban sok dolog változott a szoftvereken, az emberek pedig csak felejtettek.

1992. október 26-án, hétfőn reggel álltak át a diszpécserek az új rendszer használatára. Igen, mindenféle előzetes próbaüzemek, párhuzamos működés, tesztek és kiképzések nélkül (láttunk már máshol is ilyet…?). Ekkor 81 hibáról tudtak a szoftverben, de ez csak a jéghegy csúcsa volt.

Az egyes részeket és egységeket külön-külön cégek fejlesztették, és addig sosem próbálták ki együtt valós körülmények között. Nem volt tartós futási teszt, és terhelési teszt sem. Emellett a program csak a normál, tökéletes ügymenetre volt felkészülve, így nem bírt el a tévesen beadott adatokkal (pl. ha a mentőautó-sofőr mellényomott vezetés közben a mobil kütyü idiótán elhelyezett gombjain) és a hardverhibákkal sem. Hibás volt a kezelőfelület, és nehezen használhatók a mentőkocsis egységek. 

A rendszer folyamatosan „ette” az erőforrásokat, ezért idővel egyre lassabb lett. Ennek ellenére az első pár órában jól helyt állt (mivel viszonylag kevés eset volt). Ám utána a lassulás miatt a rendszer elkezdte elveszíteni a bejövő hívásokat, és az állandó ismétlések miatt hamarosan már 30 perces várakozási időkkel néztek szembe a betelefonálók. Kezdett akadozni az adatcsere a mentőautókkal, ráadásul a leküldött útvonal is gyakran hibás volt; így útfelbontásokba, dugókba vezette a sofőröket. A sofőrök is nehezen boldogultak a kezelőfelületükkel, így nagyon sok volt a téves gombnyomás – amit nem lehetett javítani (!), így a központot elárasztották a téves adatok. Így egy idő után a diszpécsereknek már fogalma sem volt róla, hogy az autóik fele hol jár. 

Hétfő estére a hívás-torlódás már odáig jutott, hogy teljes káosz kezdett kialakulni. Ekkor a központi szoftver észlelte, hogy vannak le nem kezelt hívások (naná, állt a káosz), és ezeket figyelemfelhívásul „Kivétel”-ként egy printerre is kinyomtatta. A dolog célja eredetileg az lett volna, hogy külön figyelmeztessék a kezelőket az elmaradásra. De amikor lényegében állandóan ömlött a printerből a kivétel-üzenet, akkor inkább kikapcsolták a nyomtatót. Ez nem segített, mert ezután már a képernyőn jelent meg ugyanez a folyam, azt is ellehetetlenítve. Elvileg lehetett volna törölni a kivétel-listát, de a gyakorlatban ez a funkció nem működött, a grafikus térképek pedig egyre lassabban, majd végül sehogy sem töltődtek be.

Az egész rendszer kezdett összeomlani. Nem lehetett rendesen mentőautót allokálni, emiatt megjelentek a nem kezelt hívások. Ezeket egy idő után ismételték, többször is, ami a sokszorosára növelte a bejövő hívásmennyiséget, pedig már kisebb volumennel sem bírt el a rendszer. Ez egy öngerjesztő folyamat volt, aminek teljes káosz lett a vége. Volt eset, ahol egy halott elszállításához két menőautó toppant be teljes harci díszben, de egy agyvérzéses beteghez csak 10 órával a hívás után ért ki a kocsi. 5 órával azután, hogy a beteg a saját lábán beért a kórházba.

Kedden az operátorok áttértek egy félig papír, félig számítógép-alapú nyilvántartásra. Ez nem sokat segített, mert még további késéseket vitt a rendszerbe – de legalább működgetett valahogy. Ez az állapot 7 napig, november 4-ig állt fent, amikor a program végképp „megette” a memóriát, és belassult, majd hajnali kettőkor összeomlott és leállt. Attól kezdve teljesen manuális lett az irányítás. 

Az új rendszer összesen 9 napot futott. A becslések szerint ezalatt 20-30 ember halt meg feleslegesen, mert nem jutottak időben mentőautóhoz; és akkor az egyéb okozott kárról még nem is beszéltünk. A CAD és az NHS vezetősége annak az iskolapéldáját mutatták be, hogyan NEM szabad egy kritikus szoftver kifejlesztését és bevezetését megszervezni. [Forrás]

Azt hiszem, hogy az itt elkövetett hibákat mind a mai napig előszeretettel ismétlik meg különböző szoftverek esetében, legutóbb például vállalatirányítási programnál láttam ilyet. Igaz, ekkor legalább csak a cég gazdasági működése állt le 4-5 napra a londonihoz hasonló hibák miatt – de legalább a pasziánsz-túladagoláson kívül senkit sem fenyegetett veszély.

Hibapozíció

Amúgy a US légierő is bemutatta 2010 januárjában, hogyan kell egy szoftvert „hatékonyan” és „profin” frissíteni. A cél a GPS rendszer képességeinek javítása volt, ami egyrészt a pontosság növelésében, másrészt a védettség erősítésében öltött testet. Ez a változtatás ugyan kis mértékben a polgári GPS vevőknél is érezteti hatását, de ebben az esetben a fő cél egyértelműen a katonai képességek javítása volt. A művelethez nem csak új műholdakra, hanem egy szoftver frissítésére is szükség volt, amit január 11-én szépen végre is hajtottak.

És azzal a lendülettel leállítottak jó pár ezer olyan harceszközt, melyekben a kaliforniai Trimble Navigation Limited által gyártott vevőegységek voltak. Ezek ugyanis nem voltak képesek az új típusú katonai jeleket értelmezni.

Innentől kezdve elkezdődött az egymásra mutogatás: a katonák szerint a Timble vevői nem voltak kompatíbilisek az új protokollokkal, mivel nem lettek eléggé tesztelve. A Timble szerint viszont ők igenis alaposan tesztelték a cuccot és mindent rendben is találtak; szerintük a hadsereg végül nem azt a programot telepítette, amit ők megkaptak a teszthez…. 

Megjegyzem: nem ez volt az első GPS-leállítós eset, és nyilván nem is az utolsó. A GPS számos konstrukciós problémával küzd, miközben a jelentősége még mindig óriási. A fennakadásmentes korszerűsítése tehát nem triviális feladat. Csak hát…

 

A következő részben a magasba emeljük a színvonalat.
 

40 komment

Címkék: katasztrófa számítógép rakétapajzs

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

johnibyg 2012.04.09. 13:27:05

Grat PZS, jó írás!

Volt olyan eset, mikor szoftverhiba miatt atomháború tört ki majdnem a Hidegháborúban, a radarrendszer azt mutatta, hogy jönnek a rakéták, közbe a szoftver hülyéskedett. De legalább a kezelők rájöttek...

Papírzsepi · http://lemil.blog.hu 2012.04.09. 19:11:44

@johnibyg: lesz egy ilyen esetről is szó, ha Jockey11 végre befejezi a megírását...

Hiryu 2,0 · http://theidf.blog.hu/ 2012.04.09. 20:41:21

"A halottkém szerint ez a páciens sem az örömtől sugárzott"

hú, ezévi morbiditás-díj nagy esélyese ez a mondat.

Megnyugtat, hogy a magyar egészségügyben ilyen dolgok nem fordulhatnak elő! Mert ahhoz olyan gép is kellene......

"És azzal a lendülettel leállítottak jó pár ezer olyan harceszközt, melyekben a kaliforniai Trimble Navigation Limited által gyártott vevőegységek voltak. Ezek ugyanis nem voltak képesek az új típusú katonai jeleket értelmezni."

Gondolom épp ezér fejleszti minden illetékes ország a saját GPS-Glonassz stuxnetjét.....

Lehet hogy dél-koreai diktátornak van igaza tömeghadseregével? Iránytűt nehezebb megzavarni...
Hülyéskedést félretéve: szakanyagot olvasva, szinte már a WC-ajtót is GPS-el és tsaival vezérelnék... Szóval szép hogy törpebombával is megsemmisíthető a cél, mer 10centis pontossággal talál célba a méregdrága cucc... Ha van hozzá GPS....

Mk.82 forever!

Zig Zag · http://lemil.blog.hu/ 2012.04.09. 21:58:05

A mentős esetről a nem kritikus infrastruktúra védelem jutott eszembe: hogyan védhetjük meg az infrastruktúrát saját irányító rendszerétől?

Kullancs1983 2012.04.09. 23:59:46

@Hiryu 2,0: Észak, nem? :) A többiből csak annyit értek, hogy nem szabad megbízni az egészségügyben. :P

Titus Pullo Urbino 2012.04.10. 09:36:13

Szép új világ! Gratula PZS, jó kis írás ez!

CyberPunK 2012.04.10. 10:09:12

Gratula, jó cikk lett. Engem csak egy dolog zavar: "a Therac-25 név addigra már a felelőtlenség és az impotens programkészítés szinonimájává vált."

A programmal nem volt gond, legalábbis abban a gépben jól működött, amelyikbe szánták. :) Az inkább a jó kérdés, hogy hogyan tervezhettek olyan új gépet, ami nem volt fossábiztosítva, mind software-esen, mind mechanikusan.

Papírzsepi · http://lemil.blog.hu 2012.04.10. 10:49:23

@CyberPunK: márpedig ha rákeresel, hogy "Therac-25", elsősorban a balesetről találsz anyagokat. Egyszerűen erről ismert a gép, szakmai körökben egyértelműen az impotens programkészítés díszpéldánya lett.
A programja amúgy már az elődben működve sem volt jobb.
Nem (elsősorban) az volt itt a hiba, hogy a hardverből kivették a mechanikus védelmet. Sok esetben ugyanis eleve nem is lehet ilyet a hardverbe tervezni. Anélkül is megoldható lenne a dolog, de ebben az esetben ez nem sikerült: a fő probléma mindvégig a szoftverrel volt.

CyberPunK 2012.04.10. 11:10:29

@Papírzsepi: Mindig a software-est okolják, ha hiba van. :) Amúgy nekem csak azért meredek az egész, mert egy hardware hibánál a software is megy a levesbe és azért az ember elvárná egy ilyen géptől, hogy ne szerencse alapjon menjen a kezelés. Legalábbis ne ennyire szerencse alapon, rizikó mindig lesz.

Papírzsepi · http://lemil.blog.hu 2012.04.10. 11:18:52

@CyberPunK: nem mindig a szoftver okolják. Csak az esetek 80%-ban, ugyanis a 80-20 az arány az SW-HW hibákban.

Amúgy lehet védekezni a HW hibák ellen, nem is túl nehéz. Az SW hibák ellen is van védelem, de az viszont nehéz ügy.
És van még pár további eset, de ezekről majd a 3. részben.

CyberPunK 2012.04.10. 11:23:05

@Papírzsepi: Amúgy nekem úgy tűnik, hogy az ilyen esetek javarésze arra a hibára vezethető vissza, amit úgy hívnak, hogy kiadási határidő. Egyébként arról nem tudsz valamit, hogy az ilyen "régi" orvosi eszközök fejlesztőcsapata mekkora volt? Értem ezalatt, hogy pár fő garázsproject-ben rakta össze, vagy ténylegesen egy nagy gárda dolgozott össze? Azt persze aláírom, hogy a fejlesztők néha szoktak rendes programot is előállítani, de nem ez a jellemző. :)

Hiryu 2,0 · http://theidf.blog.hu/ 2012.04.10. 11:25:53

Khm.... inlife tapasztalat:

Hardwer:
egy tervező mérnök elszúr valamit, hamarabb kiderülhet, szerencsére a próbagyártás alatt, legalább... blogon előjött már felrobbant űrrakétától Csernobilig sokminden.... Szinte mindenhol kellett a humán faktor hogy katasztrófa legyen...

Meg mondjuk egy gépészmérnöki diploma sem semmi...

de ha boldog-boldogtalan informatikust képez, még a Falmelléki Főiskolán is....Hááááát.....

Hiryu 2,0 · http://theidf.blog.hu/ 2012.04.10. 11:29:01

Ui.... hmmm épp mst olvastam, embert terveznek a Marsra.... Háááát.... elolvasva a fenti elemzést a softwerhibák megtalálhatóságáról.... legfeljebb biciklivel vállalom azt az utat...

Murphy törvénye...

Papírzsepi · http://lemil.blog.hu 2012.04.10. 11:52:10

@CyberPunK: érdekes, hogy a programkészítéshez mindig van egy optimális csapatlétszám, amikor a leggyorsabban és a legjobb minőségben halad a munka. Ha ennél kevesebben dolgoznak, akkor valamelyik munkafázis ki fog maradni (mondjuk a tesztelés és a dokumentálás), vagy a végtelenségig nyúlik a project.
Ha viszont az ideális létszámnál többen vannak, akkor meg akadályozni kezdik egymást, a project össze-vissza kacskaringózik, és végül sosem készül el.
Ezért "garázs projecteknél" és "nagycsapatos" módszer esetén is lehet szar a végeredmény, csak máshogy szar.
A Therac-25 a "pár fő fejlesztget valamit" tipikus tüneteit mutatja, akárcsak az inzulinpumpa és a Cobalt-60 esete.
A GPS inkább a nagycsapatos hiba, ahogy az Ariane-5 is.
A mentős buli mindkét eset tipikus hibáit mutatja, valószínűleg a heterogenitása miatt.
De ezt persze csak a sokévi tapasztalaton alapján tippelem, pontosabb infóm nincs.

molnibalage 2012.04.10. 12:48:28

Valahol elképesztő, hogy ilyen okos vasak mellé ennyire béne agyat voltak képesek írni.

Wendiii · http://hivataliagyhalal.blog.hu 2012.04.10. 13:31:03

Nem ez a Therac 25-ös volt az a masina, amiből a nukleáris katasztrófákról szóló cikk második részében esett szó? Aminek Brazíliában a cézium magját kilopta néhány hajléktalan, majd hazavitték olvasólámpának?

Papírzsepi · http://lemil.blog.hu 2012.04.10. 13:35:12

@Wendiii: Nem ez volt az. A Therac-25 csak egy lineáris gyorsító volt, nem volt sugárzóanyag benne.
Ezt inkább TV-készüléknek vihették volna haza....

Wendiii · http://hivataliagyhalal.blog.hu 2012.04.10. 14:21:37

@Papírzsepi: Bocsánat, igazad van, a Therac 25-öt csak példaként hoztad fel abban a cikkben.

stoppos76 2012.04.10. 16:28:41

@auth.gabor: Nagyszerű esete, hogy hogyan ne csináljuk. Gondolom kevés pénzből, nagyon gyorsan, igényfelmérés nélkül. A BA-k száma is lehetett köbö nulla.

sóskatáska 2012.04.11. 10:41:03

Jó hosszú cikk,de mitől lemil témájú?
Ennyi erővel irhattál volna a harci kutyák szőrszinéröl is.

Legközelebb valami katonásat prezentálj, ennek inkább valami orvosos helyen volna értelme.
Kösz, és üdv.

yenoee 2012.04.11. 13:27:23

@sóskatáska: határvidék, az biztos, de szerintem való ide.

Papírzsepi · http://lemil.blog.hu 2012.04.11. 14:45:15

A szoftverek esetén a gyenge minőség nem szembetűnő (mármint azonnal), és csábít a "rövidebb" út.
A házépítés egy jó analógia.
Minden terv nélkül kimegy a kőműves brigád a rétre, és elkezdik letenni a téglákat a valahogy. Aztán rá a következő sort. Ami nem sikerül, vagy nem tetszik a tulajnak, azt felszedik és leteszik máshogy. Vagy csak hozzácsapnak még pár téglát, hogy le látszódjon a hiba. Mérni nem kell, legfeljebb kicsit görbe lesz a fal, de attól még megáll valahogy... Ha a tulaj bővíteni akar, találomra hozzá lehet csapni még egy szobát valahogy, mindegy. Kell még 5 emelet? Nem probléma. Ja, hogy nincs alap? Minek az, így is megáll az a lábán, esőben meg nem teszteljük.
Na így készültek a szoftverek az elmúlt 50 évben, tisztelet a kivételnek. Ám míg egy háznál ránézésre látszik, hogy girbe-gurba és mindjárt összedől, addig a szoftverekből nem látni semmit. Lehet akármilyen.
És mivel ma már jobb helyeken a WC-t is szoftver segítséggel húzzák le, így egyes termékek a valóságban sokkal rosszabb minőségűek, mint hinnénk. Csak annyi a tünet, hogy a fejlesztők túllépnek minden létező költség- és időkeretet (mert mindig "összedől nekik valamelyik házrész").

Kínos, amikor a Mercedes bejelenti, hogy kihagy a fedélzeti számítógépük szoftveréből 120 funkciót, hogy a többi végre stabilan működjön...
És sajnos ez a hadseregnél sincs máshogy. Méregdrága fegyverrendszerek, sok évnyi botrányokkal kísért fejlesztés... és ebben a szoftverek bizony nyakig benne vannak.

Atrox 2012.04.11. 16:03:14

Mivel tesztelőként dolgozom, valamint fejlesztések átvételéért vagyok felelős egy igen neves cégnél, gondoltam megosztom a reális elvárásokat a teszteléssel kapcsolatban:

A tesztelési időnek ugyanakkorának kell lennie, mint amennyit magába a fejlesztésbe beleölnek. A fejlesztésbe ebben az esetben bele kell érteni az ötletelést, meetingeket, dokumentumok (FS, rendszerterv, követelményterv, igényspecifikáció, stb.) elkészítését, magát a kódolást, illetve a tesztelés során fellelt hibák javítását, melyet később persze vissza kell tesztelni. Ha a tesztelési idő nem teszi ki (a különböző tesztelési dokumentumok elkészítését is beleértve) a telejes projectre fordított idő/erőforrás felét, akkor kijelenthető, hogy a tesztelés hiányos volt, és a fejlesztés átvétele kockázatosnak minősül.

Ha mindez teljesül, az természetesen nem jelent tökéletes biztosnágot, de ezek nélkül felelősen nem lehet kiadni/átvenni semmilyen fejlesztést. Persze ez az optimális állapot :)

hazitroll 2012.04.11. 17:18:32

Volt egy kommentem, egy haverom olvasta is másik gépen, most nem látom. Valaki admin törölte?

wazelin 2012.04.11. 20:53:03

Remek cikk, várom a következő részt :)

molnibalage 2012.04.12. 15:08:03

@hazitroll: General Protection Fault III. :)

tudi 2012.04.12. 17:24:55

Hát ezen dolgok miatt idegenkedek én a teljesen digitális meg szoftver vezérelt dolgoktól, lehet sokkal jobb, ha van mellette vész esetére a régi manuális vezérlás, irányítás.

abatoire 2012.04.12. 17:40:46

Jo a cikk, meg a hatasa alatt vagyok!

Az NHS tortenetet olvasva azt erzem hogy leeg a hajam a felelotlensegtol.

- Tobb "renszervaltast" is levezenyeltem mar es az alapveto hogy eloszor parhuzamos probauzem indul aminek soran az uj rendszer fokozatosan veszi at a teljes feladatot. Igy midig van lehetoseg javitasra vagy visszakozasra, tovabba az uzemeltetes gyakorlati szintu begyakorlasara.
- Ha jol ertem a cikket, mar az elso este komoly nehezsegeik voltak a mukodessel. Annak a szolgalatvezetonek hol volt a jozan esze aki nem csapta le az egesz renszert es tertek vissza teljesen a korabbi modellhez, hiszen valoszinuleg a diszpecserek kepesek lettek volan ra es mindenuk meglett volna hozza.
- Komplex rendszer uzemeltetesenel mindig fontos hogy legyen veszforgatokony, hogy mi van ha lehalnak a szamitogepek vagy a network, neadjuristen a hazi telefonkozpont szervere. Az a rendszer ami a kezem alatt van egy kamera+adatbazis+wireless rendszer human operatorokkal. Szepen kidolgoztunk egy Backup Adminisztraciot, tablazatok, terkepek, listak, CB radiok stb. minden elo van kesztitve. Teljes rendszerleallas eseten kb. 5perc utan minden megy tovabb ahogy kell.

stoppos76 2012.04.13. 12:10:50

@Atrox: Ámen.

Volt szerencsém az Erstének bedolgozni egy nagyon rövid ideig, ott a Change management ITIL alapokon működött. És nem csak úgy, hogy ráfogták, hanem tényleg. Mire a cucc az éles környezetig jutott, betonbiztosan működött.

NAR 2012.04.14. 14:55:23

@Atrox: Az igazán kellemetlen az, hogy attól, hogy a fejlesztés csúszik, a végleges határidő még fix, így egyre csak csökken a tesztelésre szánt idő...

NAR 2012.04.14. 15:02:44

@Papírzsepi: "a programkészítéshez mindig van egy optimális csapatlétszám"

A menedzsment első ötlete a csúszásra mindig az szokott lenni, hogy "akkor állítsunk rá még 2-5-20 embert", nem ismerik a bölcsességet, miszerint "akármennyi nő foglalkozik a feladattal, a gyerek nem fog 9 hónapnál hamarabb megszületni".

A programozás viszont abból a szempontból különleges munka, hogy nagyon nagy különbségek tudnak lenni az egyes emberek teljesítménye között. Gyárban futószalag mellett dolgozó emberek teljesítménye ugyanannyi (a futószalag sebessége), ugyanakkor adott csapaton belül is a leggyengébb és a legjobb programozó között tízszeres teljesítménykülönbség is lehet.

dibbler 2012.04.14. 15:30:56

@sóskatáska: az IT mindenütt mission critical erőforrás, szereplő lett. A szenior szakembereknek vagy lelkes érdeklődőknek (LOL)legalább hallani kell a lehetséges fenyegetésekről, worst case scenario-ról.
Katonai alkalmazási szoftverek katasztrófáiról aligha fogunk egy magyar nyilvános blog-on érdemi infókat olvasni.

Én termelésben vagyok IT-s ember, igyekszünk felmérni a lehetséges fenyegetéseket és előre "quick and dirty solution" dolgokat kitalálni. Ha valami előjön, éjszaka/hétvégén felhív az operációs ember, tudj valami értelmes dolgokat kérdezni és tanácsolni neki.

jacint70 · http://jacint.blog.hu 2012.04.14. 23:16:08

Sziasztok!
Több év "csendes" olvasgatás után az első komment, mivel ehhez a témához értek is egy kicsit...

A felsorolt esetek mindegyike nem szoftverfejlesztői, hanem "menedzseri" illetve megrendelői felelőtlenség.
Ahogy a szerző írja, az informatika elég komplex dolog, ezért könnyebb hibázni, mint például egy tea elkészítésénél. Ez egy ismert probléma, tehát megoldható, legalább is minimalizálható. Erre rengeteg megoldás van, terhelési teszt, stb.
Az is nyilvánvaló, hogy a projekt fontossága, a rendelkezésre állás minél nagyobb százalékos arányú elvárása határozza meg, hogy mennyit "muszáj" beleölni.
Nyilván egy pizzarendelő alkalmazásnál nem érdemes ezer tesztelőt megfizetni, hogy rendeljenek ebédet, hátha kijön valami "kretén" billentyűnyomogatási kombináció, amitől minden szökőévben egyszer valaki éhes marad, mert a tesztelés többe kerül, mint annak a pár embernek a kártalanítása, akik hoppon maradnak...

De ezekben az esetekben emberéletekről volt szó, itt bizony sokat kellett volna áldozni.
Pl. a mentős esetnél nem élesben indítani, hanem egy szabadnapos csapatot (diszpécserek, mentők) megfizetni arra, hogy pl. a saját kocsijukat használva a rendszerrel próbálják végig az előző nap "riasztási anyagát".
Atrox kollégának igaza van abban, hogy amit leírt, az az ideális eset.
De... Amiket ír, azt egy egységsugarú "menedzser" vagy hivatalnok megrendelő a lehető legritkább esetben fogja megérteni, azt meg pláne, hogy az erre fordított munkát - ami kívülről improduktív piszmogásnak látszik - is ugyanúgy ki kell fizetni, mint a vas árát.
Szomorú tapasztalat, hogy a szerződésekbe a végső átadási határidőt azt mindig bele szokták írni - ami akkor is fix, ha a szerződés aláírása hónapokig húzódik -, de hogy mi a pontos megoldandó feladat, az csak menet közben derül ki.
És ha ez a kiderülés azt jelenti, hogy jóval nagyobb a munka - én még sose találkoztam olyannal, hogy kisebb lett volna -, akkor a menedzserek első dolga a "fölösleges cifraságok" - rendes felmérés, részletes rendszerterv, tesztelés - elhagyatása, no meg a projektben résztevők extrém terhelése, ami megint csak a minőség ellenében hat. Azt, hogy balfékek voltak, és fogalmuk sem volt arról, mit vállaltak be, sosem ismerik be...

Elnézést, ha elsőre túl hosszú voltam...

nagyo78 2012.04.17. 14:25:14

G+al nem lehet megosztani a cikket, mert a reklám kitakarja a megosztás gombot.
A sorozat egyébkét nagyon jó, ezért is akartam megosztani. :)

Valami? Amerika? Naná! 2012.04.17. 23:17:59

@nagyo78: Milyen reklám? Adblockról hallottál-e már, komám?

Papírzsepi · http://lemil.blog.hu 2012.04.18. 09:55:39

@nagyo78: sajnos a reklámot és a gombot is a bloghu motorja teszi oda. Bizonyos böngészőkön, bizonyos esetekben nem igazán jól. Szoftverhiba. Ez van.

GrG 2012.04.30. 13:22:20

Sziasztok

Azért azt se felejtsük el, hogy az esetek tekintélyes része a 80-as 90-es éveklején játszodtak, amikor ezt az egész szakmát kitalálták. Akkor jelentek meg az olcsó processzorok és kezdtek el mindenbe csippet rakni. Hát az átállás nem egyszerű és emberek életébe került, mint ahogy az első autók is szedtek olyan áldozatot, ami az átállás számlájára írható. Persze jobb lett volna ezeket az embereket megmenteni, de gyanítom, hogy a halálukkal (és a következmények feldolgozásával) sokak életét mentették meg.

avada 2012.08.26. 14:13:46

Még jó, hogy hozzánk csak később érnek ide ezek a dolgok. :) Legalább a pénzesebb országokban gyilkolják le az embereket amíg kipofozzák a szoftvert...