Belső rugalmassága és alkalmazhatóságának változatossága miatt az informatika egyre növekvő mértékben válik mindennapi életünk részévé, és mélyen átalakítja társadalmunkat. Az informatika először az 1980-as években, a személyi számítógép megjelenésével lépett ki hagyományos szerepéből, amely a tudományos számítások világához és a nagy szervezetek irányításához kötötte. Számos új terep nyílt meg előtte: mindenféle szervezetek irányítása, az üzemek és a közlekedési ágazatok automatizálása, szinte minden területen új koncepciók kidolgozása, technikai és művészeti dokumentumok, játékok előállítása stb. 1995–2000 között aztán az internet elterjedése változtatta meg alaposan a számítógép szerepét, amely így sokkal inkább az információs társadalomhoz kötött hordozó lett, mint a tértől-időtől független számítások eszköze. Ma ott tartunk, hogy a számítógép elveszíti billentyűzetét és monitorát, és a legkülönbözőbb tárgyakba költözik be: autókba, háztartási és audiovizuális gépekbe, mobiltelefonokba, orvosi protézisekbe, és a lista vég nélkül meghosszabbítható. A informatikán alapuló tárgyak nagy hálózattá állnak össze, így állandó kapcsolatba kerülünk azzal az információs rendszerrel, amely életünk minden részét érinti.
Ez a nagy szintetikus idegrendszer olyan anyagi vagy szellemi összetevőkön nyugszik, amelyek messzemenően ismeretlenek a nagyközönség előtt, hiszen tökéletesen láthatatlanok, ellentétben például egy kerékpár vagy egy autó mechanikus alkotórészeivel. Sem egy processzor belseje, sem a működését szabályozó programok nem látszanak, nem érzékelhetők. A megértés szokásos módszerei vagy a tárgyak érzéki benyomásokon alapuló választása itt nem működik, ami nagyrészt megmagyarázza, miért olyan nehéz sok embernek, hogy a társadalom informatizáltságát beépítse saját világképébe. Ez sajnos érvényes az informatizált tárgyak alkotóira is, akiknek nem mindig sikerül optimális minőséget létrehozniuk.
Rövid eszmefuttatásunkban megpróbáljuk megmagyarázni, mi az informatika lényege, melyek a belőle fakadó nehézségek – ezeket igen gyakran alábecsülik –, és mitől várhatjuk az informatizált termékek minőségének javulását.

*A szoftver
Az első dolog, amit jól meg kell értenünk, a processzorok szerepe. Ez olyan szerkezet, amely meghökkentő sebességgel és csaknem tökéletes megbízhatósággal képes rá, hogy önállóan műveleteket hajtson végre, az érdeklődés legcsekélyebb jele nélkül; a legfontosabb e tekintetben az, hogy vesz valahonnan egy információt, majd elrakja máshova, miután esetleg módosította. Ez csaknem minden processzorra érvényes, a nagy PC-chipektől azokig a kis chipekig, amelyek az autók fékeit vezérlik, vagy a fényképezőgépekben a képet rögzítik. Mind ugyanazon az alapelven működik, egészen jelentéktelen eltérésekkel.
A bámulatos Moore-törvény azt mondja, hogy a teljesítmények 18 havonta megkétszereződnek, azonos költségek mellett. Vagyis 1985 és 2000 között megezerszereződtek. A törvény igaznak bizonyul több mint tizenöt éve, és ma sem látszik, hogy volna időbeli korlátja. A fejlődés különféle jelenségek egybeesésének az eredménye: esetünkben az elektronikus elemek méretének folyamatos csökkenéséről, a gyártási technikák fejlődéséről, a működési frekvenciák növekedéséről (a híres megahertzek) és a processzorok ésszerű architektúrájának állandó fejlődéséről van szó.
A chip azonban csak hűséges szolga; a hozzáadott érték, amelyet létrehoz, csak azoknak az utasításoknak az egymásutánjából jöhet, amelyeket mi adunk neki, és amelyet a szoftverek szállítanak. Szoftvert alkotni nem más, mint meghatározni azt a végrehajtandó műveletsort, amely a számunkra érdekes végeredményt kiadja: kinyomtatni egy szöveget, elkészíteni egy fényképet, zenét hallgatni vagy telefonálni. Minthogy az egyes műveletek szinte semmit sem csinálnak önmagukban, mérhetetlen mennyiség kell belőlük ahhoz, hogy elérjük, amit akarunk. Valójában tucatnyi számítógépen végrehajtott műveletek milliárdjaira van szükség már egy egyszerű telefonhívás lebonyolításához is. Némely műveletre azért van szükség, hogy a hangot 0-s és 1-es információs elemekké alakítsa át, másokra azért, hogy ezekből az elemekből csomagokat állítsanak össze, megint másokra azért, hogy létrehozzák a kapcsolatokat, és a megfelelő csomagokat a megfelelő beszélgetőpartnerhez továbbítsák, és persze egy részükre azért, hogy kiállítsák a számlát.
A legelemibb műveletek többségét többször is végrehajtják az egymást követő adatokon; nincs tehát közvetlen kapcsolat a ténylegesen elvégzett műveletek száma és annak a programnak a mérete között, amelyet a programozó megírt. Ez a méret azonban ettől még igen nagy: a széles körben elterjedt alkalmazások esetében ezernyi, sőt milliónyi különálló programsort kell megírni.
Még a processzorok tervezése is alapvetően szoftver-ügy. Egy-egy chip megtervezése még a közelmúltban is úgy zajlott, hogy az elektromosság és az ésszerűség szabályainak megfelelően összeállították a tranzisztorokat, majd megpróbálták miniatürizálni ezeket az elemeket úgy, hogy adott idő alatt a lehető legtöbb elektromosság áramoljon át rajtuk. Ma már egyetlen chipben is milliónyi összetevő van, és nincs más eszköz a kezeléséhez, mint a speciális szoftver. Ami azt jelenti, hogy az informatikai kígyó saját farkába harapott, és elkerülhetetlen, hogy a múlt gépeit a jövő gépeinek megalkotásához használjuk fel.

*A szoftver sajátos problémája: a bug
Minthogy a nagyságrendek adottak, most már jobban megérthetjük a szoftver két nagy problémáját: hogyan irányítsunk egy tökéletesen buta gépet, és hogyan kezeljünk milliónyi utasítást? Egyszerű hasonlattal élve: képzeljük el, hogy egy nagyvállalat élén állunk, amelynek minden alkalmazottja tökéletes engedelmességgel és hatékonysággal működik, de a legcsekélyebb kezdeményezőképesség is hiányzik belőlük; van-e rá esélyünk, hogy elérjük, amit akarunk? Vajon sikerül-e megírnunk minden művelet minden apró részletét minden egyes beosztott számára? Az emberi társadalmak a szereplők helyi alkalmazkodási képességén nyugszanak, és azon, hogy a szereplők értik cselekedeteik hatását; nem így a mikroprocesszorok. Ha a legcsekélyebb mértékben is hamis utasítás adunk nekik, azt is hibátlan szakmai lelkiismerettel és minden humorérzék nélkül végre fogják hajtani. Tegyük fel azonban, hogy sikerült pontosan meghatároznunk a végrehajtandó műveletet. Minthogy minden apró részletet hiánytalanul meg kell hozzá adnunk, a dokumentációnk túl vaskosra sikeredik, rosszul szerkesztett, és épp annyira szórakoztató, mint egy telefonkönyv. Egy év múltán aztán elhatározzuk, hogy néhány helyen megváltoztatjuk a szoftverünket. Vissza tudunk-e emlékezni, mire való az a rengeteg apró részlet, amellyel korábban dolgoztunk, és ha szükséges, vajon át tudjuk-e adni olyasvalakinek a módosítási munkákat, aki nem csinálta végig az eredeti dokumentáció létrehozását? Nos hát pontosan ezek azok a nehézségek, amellyel az informatikusok szembe találják magukat minden munkájukban.
Ezeken a nehézségeken túl van egy különösen alattomos ellenség: a bug [poloska]. A kifejezés arra utal, hogy az első számítógép-leállások egyikét egy kis rovar okozta. A bug aprócska hiba, amely olykor csak a program néhány karakterét érinti, mégis félelmetes hatásokkal járó láncreakciókat indíthat el: telefonközpontok leállása, rakéták felrobbanása, műholdak elvesztése, PC-k ismételt leállása, biztonsági lyukak keletkezése a hálózatokban – a feketelista végeláthatatlan. Így például a csúcsinformatikával ellátott amerikai Smart Ship hajón történt, hogy az egyik operátor véletlenül 0 értéket írt be pozitív érték helyett valamelyik közönséges paraméterhez. Ez 0-val való osztást eredményezett, amely további problémákat okozott az illető számítógépben, majd magában az egész rendszerben is. Néhány perc elteltével a hajó ellenőrizhetetlenné vált, a motorok leálltak. A bug abszolút mértékben determinálja a folyamatokat: az Ariane V felrobbanása, amely az első kilövéskor bekövetkezett, száz kilövésből százszor megtörtént volna ugyanazon a helyen (ma már természetesen kijavították a hibát).
A számítógéptervezők számára már magának a bugnak a létezése is nagy meglepetés volt. Idézzük fel az informatika egyik úttörője, Maurice Wilkes meglepő gondolatait 1949-ből: „Mihelyt elkezdtünk programokat írni, legnagyobb meglepetésünkre rájöttünk, hogy a feladat korántsem olyan egyszerű, mint hittük. Fel kellett fedeznünk a Ťhibamentesítésť műveletét. Emlékszem arra a pillanatra, amikor rájöttem, életem nagy része a jövőben azzal telik majd, hogy hibák után kutatok a saját programomban.” De ennyire tapasztalt szakemberek miért hoznak létre bugokat? Az ok: roppant bonyolult „interakciók” mennek végbe a szoftver és környezete, illetve a szoftver különböző részei közt. Még egy olyan, látszólag egyszerű szoftvernél is, mint amelyik a telefonhívásokat bonyolítja, a kezelendő esetszám csillagászati méretű lehet, a közvetlen emberi felfogóképesség határain messze túl. Minthogy a szoftvernek nincs semmiféle automatikus alkalmazkodó vagy önjavító képessége, egy eseményre adott válasza pontosan olyan lesz, amilyet beleírtak a programba. De a „beleírt” nem szükségképpen jelenti azt, hogy „végiggondolt”. 
A gyakorlatban sokszor megtörténik, hogy egy nem kifejezetten előre látott esemény a szoftver egyes részeiben átjárókat hoz létre bizonyos helyekhez vagy bizonyos időpillanatokban, kiszámíthatatlan módon, s ez rendellenes akciókhoz vezet, amelyek hatása a környezetre abszolút mértékben tetszőleges lehet. Így okozhatták például betegek halálát egy besugárzó szerkezet vezérlőbillentyűzetének kezelésére írt program igen apró hibái, amelyek hatására a gép rendellenesen nagy dózisokat bocsátott ki. Más típusú, az utolsó pillanatban távvezérléssel kijavított hibák miatt veszett el csaknem a híres Mars-robot, a Sojourner. Jegyezzük meg, hogy a bugok a chipekben is léteznek. Egy elosztótábla látszólag használaton kívüli helyén keletkezett apró hiba okozta a híres bugot az Intel Pentium chipjében. Ez a bug a társaságnak hivatalosan  475 millió dollárjába került.

*A szoftverek ipari fejlesztése
Mint sok más iparágat, az elektronikai és informatikai iparágakat is alapvetően a híres time to market irányítja, amelyet minimalizálni kell. A helyzet azonban változik: ma már maximalizálni is kell, a time to bug-ot. Szaporodnak azok az esetek, ahol a szoftverben vagy a chipen lévő egyetlen bug következményeinek költségei jóval meghaladják a rendszer kifejlesztésének teljes költségét. A költség nemcsak magának a komplikációnak a költsége: egy internetes játék új verziójának letöltése ma már közönséges dolognak számít; korántsem az egy autótípus minden egyes példányánál a motort vezérlő szoftver kijavítása. A bugokon kívül komoly kezelési problémák lépnek fel a projektek összehangolásánál is. Olyan nagy projekteket kellett teljesen leállítani, hihetetlen pénzek ráköltése után, mint az angol tőzsde informatizálása, vagy az Egyesült Államokban az adóívek kezeléséé, vagy bizonyos repülőtereken a csomagkezelésé. Nem könnyű bánni egy olyan projekttel, amely a láthatatlan tartományban működik.

Egyszerű receptjei vannak annak, hogyan kell megírni egy rossz minőségű szoftvert. Nem árt, ha bemutatjuk őket, mert még ma is igen gyakoriak, különösen azokon a helyeken, ahol a probléma létezését még nem fogták fel:
– Ráhagyatkozás a látszólagos rugalmasságra. Minthogy egy szoftver szövegének a kijavítása technikailag egyszerű dolog, gyakran előfordul, hogy a megrendelő nem határozza meg pontosan, mit is akar; abban bízik, hogy később még mindig ráér módosíttatni a programot. A szolgáltatók általában ezt nem tartják bajnak (az ügyfél nem tudja, mit akar, minthogy azonban ő fizet, megcsináljuk neki). Amikor aztán egymás után jönnek a módosítások, a rendszer gyorsan válik egy kártyavárhoz hasonlatossá.
– Spórolás az emberi erőforrásokkal. A szoftverkészítés kevéssé automatizált terület, ahol az emberek termelékenysége rendkívül változó, és nagy mértékben függ a képzettségüktől. A programozók egymással korántsem felcserélhetők, és teljesítményük a végtermékben kifejezve egy és tíz között változik (klasszikus módszer, hogy úgy akarják behozni valamely projektnél a lemaradást, hogy több, kevésbé képzett programozót vesznek fel). Egyébként a tesztek elvégzése rendkívül drága dolog emberben számítva: olykor a projekt költségének 30–50 százaléka is lehet. Ezen a ponton tehát nyilvánvalóan nagy a kísértés a spórolásra – a következményeket ki lehet találni.
– A nem megfelelő eszközhasználat. Gyakran látni eszközökkel kevéssé vagy rosszul felszerelt projekteket. Sokáig volt egyfajta bizalmatlanság a szoftvereszközök iránt: képzettebb személyzetet kívánnak meg (lásd az előző problémát), és az eszközök maguk is tartalmazhatnak vagy keletkeztethetnek bugokat. Gyakori tehát, hogy projekteket a nulláról indítanak el, és újra megcsinálják hozzá az alapeszközök jó részét. Miután rádöbbentek arra, hogy fölösleges újra feltalálni a kereket, a projektvezetők átestek a ló másik oldalára, és elkezdték megkövetelni, hogy munkatársaik következetesen támaszkodjanak a polcokon elheverő komponensekre. Ez azonban sokszor oda vezetett, hogy kevéssé megbízható vagy eredeti céljuktól meglehetősen eltérített, s így gyenge lábakon álló elemeket használtak fel. Az egyensúlyt nem könnyű megteremteni.

Összefoglalva azt mondhatjuk, van egy egyszerű és garantált eszköz arra, hogy bármilyen szoftverprojektet kudarcra ítéljünk: ha nem vesszük kellőképpen komolyan. Megbízható szoftvereket írni, ez a következőket követeli meg: pontosan meg kell érteni az igényeket; a funkcionalitásokat szigorúan a szükséges mennyiségre kell korlátozni; a lehető legalaposabban elemezni kell az interakciókat; mindig a legteljesebb mértékben kell uralni a projektet intellektuálisan is, technikailag is; jó eszközellátottságot kell biztosítani, hogy a szoftvernek a lehető legtöbb sajátosságát láthatóvá tegyük; minél több jól megalapozott szoftverelemet kell újrahasznosítani, defenzív módon programozni, azaz sohasem bízni vakon a többi elem viselkedésében, pontosan dokumentálni, egyszóval minden pillanatban szigorúnak kell lenni.
Különösen nagy figyelmet kell fordítani az „ember–gép-interface”-re, különösen a nagyközönségnek szánt termékeknél. Az ember csak álmélkodik, amikor látja a nagyszámú informatizált jegykiadó-automatát, a nyilvánvalóan kifinomult telefonokat vagy fotómasinákat, amelyek jórészt használhatatlanok, mert az informatikusok nem figyeltek oda rá, hogy végiggondolják, hogyan is fogják megérteni és használni őket az egyszerű halandók.

*A szoftver matematikája
Minthogy a bugok roppant alattomos természetűek, a világ legjobb tervezői sem tudják kiküszöbölni őket. Ahány rendszer csak van, legyen az akár a legegyszerűbb, megtartja a bugját, ha csak empirikus tesztekkel ellenőrizték le, minthogy benne a potenciális interakciók száma kombinatorikusan robban, tehát kevéssé megközelíthető szokásos gondolkodási formáinkkal. De a kutatók az informatika kezdetei óta úgy tekintenek a szoftverre, mint lényege szerint matematikai természetű tárgyra, amelyre alkalmazhatók a formális és olykor automatizálható gondolkodás szabályai.
A „algoritmus” matematikai fogalma vagy a mechanikusan végrehajtható műveletek egymásutánja igen régi találmány, amelyet eredetileg a számok és alakzatok kezelésére fejlesztettek ki. A számítógép születése új lendületet adott az algoritmuskutatásnak. A modern algoritmusok alkalmazási területei igen különbözőek: mindenféle információkezelés, igen nagy mennyiségű adatban való keresés, hang- és képvezérlés, titkosítás stb. Ma már megbízható algoritmus-könyvtárral rendelkezünk sok állandó problémára. Nemrégiben jelentek meg az „elosztott” algoritmusok, amelyek több aritmetikai egységet iktattak be; ezek igen fontosak az olyan új alkalmazásoknál, mint az elektronikus kereskedelem, de roppant nehéz felfogni és elemezni őket. Az erősen matematikai irányultságú algoritmuskutatást általában az algoritmusok fogalma és teljesítményük tanulmányozása érdekli. A központi nehézség abban áll, hogy a fontos problémák pontosan a gyakorlatban kivitelezhető és kivitelezhetetlen határán vannak. Ennek a határnak a meghatározása a terület legnagyobb tudományos kihívása.

Az informatika tudományának másik ága az, amelyet „szemantikának” hívnak. Ez a megírt programok jelentését próbálja megérteni és uralni, és például kimutatni, hogy egy program a legcsekélyebb tévedés nélkül valósít meg egy absztrakt módon elgondolt algoritmust. A szemantika alapjai egyrészt a görögökig, a logikai dedukció tanulmányozásáig, másrészt a 20. század eleji matematikai alapokig mennek vissza. A terület hatalmas lendületet kapott Church, Gödel és Turing munkái nyomán, még a számítógépek megjelenése előtt. Nagykorúvá akkor vált, amikor rájöttek, hogy a logikai és szemantikai megközelítések nélkülözhetetlenek a jól felépített és jól meghatározott programnyelvek létrehozásához: ezeknél a nyelveknél alapkérdés a minőségük, minthogy ők hordozzák a programírást. Végül a területen végbement tudományos előrelépés nyomán az is lehetővé vált, hogy kifejlesszék a programok vagy a chipek megfelelő viselkedésének matematikai verifikációs technikáit. Ez a tárgykör, amely nemrég még a tiszta tudományos kutatás terepéhez tartozott, ma már figyelemre méltó áttörést ért el az iparban, hiszen itt elsődleges érdek, hogy felderítsék az alattomos bugokat, még mielőtt a következményeiket el kellene viselni.

      MIHANCSIK ZSÓFIA FORDÍTÁSA

(A szerző 2001-ig az Alkalmazott matematikai kutatások központjának kutatási igazgatója, Párizs, École des Mines; azóta az Esterel Technologies tudományos igazgatója. Előadása 2000. szeptember 10-én hangzott el Párizsban az UTLS keretében.)