A minap hallottam a JUM-on az egyik előadótól:
“Add ide a specit, és akkor megcsináljuk!”
Más alkalommal ugyanennek a személynek a szájából ugyanebben a kontextusban elhangzott az is:
“Jó lenne, ha valaki jól megcsinálná a követelményspecifikációt! Nem lennének benne ellentmondások, hiányzó részek…”
Tehát, aki ezt mondta, az azt feltételezi, hogy egy követelményspecifikációt meg lehet úgy (formalizáltan) írni, hogy abból egyértelmű és teljes legyen a feladat.
Erről két ismerősöm beszélgetése jut eszembe. Az egyik egy programozó matematikus (fiú), a másik pedig egy ügyvéd (lány). A srác azt kívánta, bárcsak olyan világban élnénk, ahol a (jog)szabályok annyira egyértelműek lennének, hogy nem lenne szükség ügyvédekre, bírókra.
Ezt a problémakört a jogi egyetemeken jogelméleti órákon tanítják. A lényege a dolognak, hogy ha a világunk a srác által kitalált “minden élethelyzetre van egy szabály” típusú lenne, akkor a rendszer túlszabályozott lenne. Ennek eredményeképpen a szabályrendszer abszolút rugalmatlanná és irtózatosan bonyolulttá válna. A bonyolultság miatt az értelmezhetőség lehetősége is kérdésessé válik, ami még azt is eredményezi, hogy a rendszer ellentmondásossá is válik. (A jelenlegi magyar jogrend sok területéről a jogászoknak már ma is az a véleménye, hogy eleve túlszabályozott.)
Ha a másik oldalról közelítjük meg, és nincsenek a legapróbb részletekig, minden élethelyzetre megfogalmazva a szabályok, akkor azok követése sem lehet egyértelmű. Ezért van az, hogy a bíró (tehát egy ember) dönti el, hogy bizonyított-e a vád, és hogy a vádlott – a jogszabályokban megfogalmazott kereteken belül – milyen büntetést kap.
A követelményspecifikáció problémája megegyezik az említett jogelméleti kérdéssel. Hogyan szeretnéd a szoftvert fejleszteni? Szeretnéd, ha több száz vagy ezer oldalas lenne a specifikáció? Meg fogod érteni? Kitől kérdezel?
A szoftverfejlesztés nem matematika.
Boncoljuk még, mire “jó” még a formalizmus!
ELTE: Bevezetés a programozáshoz c. tantárgy
Az ELTE-n úgy próbálják a hallgatókhoz “közelebb hozni” a programozást, hogy formális módszerekkel megtanítják nekik, hogy az mit is jelent.
Az idézet Fóthi Ákos: Bevezetés a programozáshoz c. könyvéből származik (2. javított kiadás, 6. fejezet, 76. oldal. ELTE-s jegyzet.)
Kapásból négy kérdés merül fel bennem:
- Ennek a post-nak az olvasói közül (és – mondjuk – vegyük hozzá a Bevezetés a programozáshoz c. tárgy tanárát is), ki tanult meg úgy programozni, hogy egy ilyen módszert követett?
- Hogyan magyaráznád el a ciklust egy kezdő programozónak?
- Ki érti ezt egyáltalán?
- Mire lehet használni?
Az első háromra nem válaszolok (mert szerintem a válasz egyértelmű). Mi van a negyedik kérdéssel? Azt mondhatnánk, hogy annak van értelme, hogy formálisan közelítjük meg a programírást, mert akkor bebizonyíhatjuk, hogy a program helyesen működik. Erre a BME-n is van tantárgy.
Hangsúlyozom:
a szoftverfejlesztés nem matematika.
BME: Formális módszerek c. tantárgy
“Az informatikai rendszerek méretének növekedésével mindinkább követelmény az, hogy a rendszer nem csak funkcionalitásában legyen helyes, hanem az alkalmazott implementáció bizonyítottan helyes konstrukciót eredményezzen. Ennek egyik jellegzetes trendje a formális modellekből kiinduló automatikus kódszintézis.
A rendszertervezés során a kritikus elemek vizsgálatához mindinkább formális modelleken alapuló analízist alkalmaznak a rendszertervezés fázisától kezdve.
A tárgy áttekintést ad az informatikai rendszerek formális minőségi és mennyiségi modelljeinek megalkotásához és analíziséhez szükséges számításelméleti háttérről, ideértve a legfontosabb matematikai leíró paradigmákat, nyelvi realizációjukat, és a kapcsolódó analitikus és szimulációs vizsgálati módszereket.
Keresztmetszeti képet ad a fenti alapismeretek alkalmazásáról az informatika területén, ideértve a rendszerszintű modellezést, a hardver tervezést, a hálózati protokollok analízisét, valamint a szoftver helyességbizonyítást.”
Egy kis értelmezés:
- “A rendszer nem csak funkcionalitásában legyen helyes” = azt csináljuk meg, amire szüksége van a megrendelőnek;
- “Az alkalmazott implementáció bizonyítottan helyes konstrukciót eredményezzen” = amit meg kell csinálni (vagyis: amiről mi azt gondoljuk, hogy meg kell csinálni), azt jól csináljuk meg.
Mivel nem tudjuk pontosan, mit kell megcsinálni (ld. a követelményspecifikáció esetét), akkor hogyan is ellenőrizzük le, hogy helyesen működik az elgondolásunk?
(Megjegyzem, a Formális módszerek c. tárgyban tanított módszerek csak olyan kis állapottereknél működnek, amivel csak kis komplexitású szoftverek rendelkeznek. Egy akár már kisebb játék vagy üzleti alkalmazás is meghaladja ezt a komplexitási szintet.)
Mi értelme akkor ennek az egésznek?
A szoftverfejlesztés nem matematika.
Rakjuk össze!
Tehát ahogy eddig látjuk a helyzetet:
- Nem lehet megírni a követelményspecifikációt úgy, hogy abból el lehessen készíteni a szoftvert. Emberek kellenek ahhoz, hogy az elvárások végül megvalósulhassanak.
- A program nem egy matematikai formalizmus. Hiába ismerem a ciklus definícióját, nincs értelme (és a gyakorlatban nem is lehet) matematikai formalizmussal felírni a szoftvereket. Az egyénileg implementált algoritmusok emberi gondolkodást követnek.
- Nem lehet úgy programot készíteni, hogy annak a helyességét ellenőrizhessük. A program teszteléséhez emberek kellenek. Emberek mondják meg, hogy az készült-e el, amit vártak, és emberek állapítják meg azt is, hogy helyes-e a képernyőn megjelenő eredmény.
Mi valójában a szoftverfejlesztés?
A szoftverfejlesztésben egy valós életbeli problémára adunk megoldást. A fejlesztés folyamatában emberek vesznek részt: emberek mondják el, mit szeretnének, emberek kódolnak, emberek tesztelnek, emberek mondják meg azt is, hogy azt kapták-e, amit vártak.
Miért gondoljuk még mindig azt, hogy egy követelményspecifikáció legyen teljesen részletes, hosszú hónapokat töltsünk a megírásával, és eredményül több száz vagy ezer oldalakat kapjunk, amit végül már senki nem bír követni és megérteni? Miért hibáztatjuk mindig a követelményspecifikáció készítőit? Miért hisszük, hogy ha ez alapján tervezünk és tesztelünk, az jó lesz? Miért?
Amire valójában szükségünk van, az az emberek egymás közötti jó kommunikációja, és egymás iránti bizalma.
A szoftverfejlesztés nem matematika.
Kristóf
Mar 24th, 2010szerintem profizmus az, ha kijelentő módban közlöd azt amire más még gondolni se nagyon mer. grats
Marhefka István
Mar 24th, 2010köszi:)
kocka
Mar 24th, 2010Remélem nem én mondtam ezt egy gyenge pillanatomban
Egyetértek egyébként, nekem is voltak érdekes élményeim az ELTE progmaton. Nincs kifogásom az ellen, hogy ilyet is tanuljunk, de hogy erre építsünk mindent, az elég súlyos.
Marhefka István
Mar 24th, 2010Nem Te voltál az
Én BME-s voltam, de vannak ELTE-s ismerőseim, ezért tudtam a fóthis féle példát felhozni 
Szerencsére nálunk nem vették ennyire “komolyan” a programozást. Amúgy egyetértek, hogy lássunk hasonlókat, csak helyén kell kezelni a dolgokat.
elek
Mar 24th, 2010Azért nem _teljesen_ haszontalan szerintem a Fóthis világ. Pl. ha más nem, jól fejleszti az absztrakt gondolkodás képességét
(Persze az is, ha klasszikus algoritmusokat olvasgatunk még akkor is, ha nincs szükségünk rá. Lehet, annak több haszna van.). Én a Fóthi féle elméletet mindig lenyűgözve néztem, mert azért elég szép szellemi szellemi magasságokat ér el. És még szebb az egészben, hogy tényleg mennyire nincs köze a valósághoz. A szürrealizmus harc.
Szóval szerintem is igazad van. És jó a megfogalmazás.
Viczián István
Mar 24th, 2010Igazad van! De azért szólaltassuk meg a másik oldalt is. Én azért nyugodt vagyok, hogy az autómban lévő ABS-t vezérlő áramkör programhelyesség bizonyításon esett át, ugyanígy mondjuk egy repülőgép robotpilótája. Megvan a helye, de persze nem olyan alkalmazásoknál, amit mi fejlesztünk, ahova inkább két pszichológus, egy politikus, és három gondolatolvasó kell, és nem technológiai szakember (architect, bah!).
repa
Mar 25th, 2010no ez azert nem ilyen egyszeru…formalisan felirni barmit, azert okec, mert minden nyelven okec
. Es mert nem az egyszeru majszosszaju programozok talaltak ki…szoftver helyesseg…verifikacio, validacio…hogyan ellenorzod, hogy helyes-e a programod, mikor te magad irtad 
. Vannak okosok, akik kitalaljak mi a tuti “performance” ugyileg pl. formalizaljak ezeket, egy altaluk tervezett program megeszi a tiedet es kikopkodi a hibaidat, nem csak a szintaxisbelieket…es persze nem mindent, mert ember azert tenyleg kell, nem a programok komplexitasa az erdekes, hanem a szint amin gondolkodunk, azert mert kicsi, meg nem biztos hogy eleg, hogy azt latja a felhasznalo amit akart (ideig oraig)…mindemellett en sem irok fel semmit formalisan…vagy varjunk csak, egyszer felirtam, de az veletlen volt
Tweets that mention A szoftverfejlesztés nem matematika -- Topsy.com
Mar 25th, 2010[...] This post was mentioned on Twitter by István Marhefka, Balazs Brinkus. Balazs Brinkus said: Egesz jo kis cikk: http://infokukac.com/2010/03/a-szoftverfejlesztes-nem-matematika/ [...]
Marhefka István
Mar 25th, 2010Viczi: Miből gondolod, hogy az autód ilyen típusú helyességellenőrzésen ment át?
Biztosan hallottál már autóvisszahívásokról… Például legutóbb a Toyotának voltak gondjai…
Marhefka István
Mar 25th, 2010repa: Pont arról szól a cikk, hogy az egész, amit írtál, nem működik. Lehet szerencsétlenkedni olyan programokkal, amik megpróbálják a hibákat megtalálni egy másik programban. Ez egy eszköz lehet, ami _segít_ a hibák feltárásában, de az teljesen reménytelen, hogy e program segítségével találjuk meg a hibákat a tesztelés alatt álló programunkban. (Btw. hány ilyen eszközt használtál már?)
Kíváncsi lennék, mi lenne, ha ennek a programnak önmagát adnám meg
pcjuzer
Mar 25th, 2010Egyetértek.
A programozás inkább mérnöki tevékenység, mint matematika, akárcsak az építészet vagy a gépészet. Néha ki kell számolni dolgokat, de alapvetően a mérnöki hasnak van a legnagyobb szerepe.
Lehet formálisan a program helyességét bizonyítani, de azt nem lehet _bebizonyítani_, hogy a hardver nem fog elromlani.
Sőt, azt sem lehet garantálni, hogy a bemenő adatok jók lesznek. Lehet rájuk futtatni logikai ellenőrzéseket, de a jelentésüket csak az ember tudja, aki beküldi őket. Vannak is erre ismert példák: Elveszett Mars-szonda, megbokrosodott robotpilóta.
Viszont -akárcsak más mérnöki tudományoknál- egy terv sosem árt.
repa
Mar 25th, 2010Marhefka István: Nem azt mondom, hogy a tema amit a cikk feszeget alapvetoen rossz, vagy helytelen felismereseken alapul. A kijelentes, miszerint “A programozas nem matematika” trivialis…de a formalis nyelvek es elmeletek fontossagat, csak a mi szintunkon lehet ketsegbe vonni. Metrikak keszitese igen is lehetseges es ertelmes tud lenni (meg ha a teljesseg igenye nelkül is keszülnek, mert ha nem is mindent de eleget meg tud egy program talalni ahhoz, hogy az alkalmazas ne menjen at egy minoseg ellenorzesen…azt, hogy “hogy e program segítségével találjuk meg a hibákat a tesztelés alatt álló programunkban” nem en mondtam… egy indulo projektnel nyilvan nincs ertelme, automatizalni a vizsgalatokat, mert mind a mellet, hogy ezekkel majdnem ugyan akkora munka van mint magaval a programmal, abszolut nem rugalmasak es hatalmas koltsege lenne az aktualizalasnak). Sokat foglalkoztam tesztelessel, automatizalassal, metrikak keszitesevel, e mellett vagy ennek ellenere a cikk nagy reszevel egyet ertek, foleg azzal, hogy kezdo programozokat nem szabadna “formalitassal” traktalni, de ezen targyak letezese ertelmenek ketsegbe vonasaval nem ertek egyet…az hogy az emberek tobbsege egesz eleteben nem kap olyan feladatot, hogy hasznalja a fent emlitett targyakat, szinten lehetseges…viszont az emberek többsege nem is kepes “absztrakt” gondolkodasra.
Minden esetre tetszik a post es a tema
Marhefka István
Mar 25th, 2010Személy szerint imádom a matematikát. Hozzásegít a rendszeres gondolkozáshoz, a racionalitáshoz, absztrakcióhoz. Ez kell.
Én a cikkben nem arra gondoltam, hogy a matematikának nincs helye a szoftverekben, csak arra a csapdára szerettem volna felhívni a figyelmet, hogy annak ellenére, hogy sok matekot tanulunk az iskolában, a szoftverfejlesztés folyamatában nem igazán lehet hasznosítani ezeket az ismereteket a követelmények formális leírására és az ez alapján történő szoftverellenőrzésre.
Sokan úgy gondolják, hogy lehet. Az élet viszont nem így működik. (Egy-két nagyon speciális esettől eltekintve, amire Viczi is utalt.)
Az említett tárgyak tematikája és célkitűzései abba a hamis illúzióba ringatják a hallgatót, hogy a világ így működik (vagy így kellene működnie).
Ez a fajta félreinformálás már középiskolában is megfigyelhető, ahol a középiskolai informatikai tanárok, akik általában matematika szakosak is (és nem dolgoztak az iparban), matematikai próblémák megoldásán keresztül tanítják a programozást. (Számold ki programmal a kör területét, oldd meg a másodfokú egyenletet stb.)
A cikk célja nem titkoltan az, hogy provokálja az olvasót, és felhívja a figyelmet arra, hogy a matematika eszköztára (itt a formális módszerekre gondolok) a szoftverfejlesztés napi folyamataiban nem játszik, játszhat szerepet. A problémák megoldásában fontosabbak az emberi kapcsolatok és az együttműködés.
Köszönöm mindenkinek a kommentet!
Nucc
May 2nd, 2010Eloszor is hozzatennem, hogy a modszerek nagyresze nem 5 eve, hanem 40 eve keszult, amikor meg papiron adtak at a programkodot az azt begepelo emberkeknek. El tudod kepzelni ma, hogy ugy megirj egy Fourier trafot gepkozeli nyelven, hogy egy nap, mire eredmeny lesz belole? Ugy gondolom akkor igen is fontos volt formalizalni, es helyesseget bizonyitani. Vannak jelenleg is problemak, amik eloszor a matematika nyelven fogalmaznak meg, keresnek ra megoldast, es csak utana emelik at azt szamitogepre. Igaz, sokat valtozott a vilag azota, es manapsag olyan kodtomegek keszulnek, hogy lehetetlen lenne ezeket matematikai eszkozokkel verifikalni, de egy operacios kernel utemezojenek megtervezesekor nem gondolom, hogy Pistike leult, es a fol enter modszerrel addig reszelte a kodot, amig az el nem indult… Egyebkent meg a formalizmus egyik szerepe az ELTE-n, hogy egy matematikai szemleletet adjon, nem pedig hogy legszebb almodbol felkeltve is visszavagd a ciklus levezetesi szabalyat.
Marhefka István
May 2nd, 2010Nucc: Te is áldozata lettél a provokatív posztomnak! Javaslom, olvasd el a kommenteket is.
Dagenham
Jun 6th, 2010Egykori Fóthi-tanítványként annyit fűznék hozzá, hogy az igaz, hogy “a szoftverfejlesztés nem matematika”, ellenben jócskán használ matematikai eszközöket.
A ciklus programfüggvénye így nagy hirtelen valóban riasztónak hat, azonban emlékeim szerint nagyjából ez a “leghúzósabb” is, ha nem számítjuk a párhuzamos programozás bizonyos elemeit. Ha tudod, miről is szól, akkor meg lehet érteni, meg lehet tanulni.
Követelményspecifikáció is jó lenne, ha lenne, de legtöbbször elegendő az informális, a formális – jó esetben – már maga a kód és a hozzá tartozó tesztesetek összessége. Jó esetben
.
Marhefka István
Jun 6th, 2010Azt hiszem, megfogalmaztál egy nagyon fontos dolgot: maga a kód az, ami specifikálja a működést.
Ha jól emlékszem, Joel fogalmazta meg a kövspecírásról: Amikor kövspecet írsz, ne légy profi!
Téveszmék a szoftverhibák kapcsán
Jul 14th, 2010[...] Egy szoftver jelenlegi ismereteink szerint nem tud hibamentes lenni. Ennek legfőbb oka, hogy egy szoftver nem matematikai alapokon készül. [...]
akocsis
Jul 27th, 2010Csak most találtam rá erre e post-ra, és valami hasonlót követtem el nem olyan régen:
http://pasztor.freeblog.hu/archives/2010/07/09/Az_IT_nem_alkalmazott_matematika/
A történetnek (a programozás miért nem matematika) rengeteg vetülete van. Láttam már matematikust programozni, és az messze van attól mint amit ma a 21. században informatikának nevezünk.
Ez az új tudomány vagy új iparág (kinek melyik tetszik) már annyira elkanyarodott a matematikai gyökereitől, hogy egyre kevésbé érdemes közös pontokat keresni.
Marhefka István
Jul 27th, 2010akocsis: Akkor megelőztelek
Viszont ezzel a témával meg Te előztél meg: http://pasztor.freeblog.hu/archives/2010/07/05/Az_IT_nem_gyrtsor/ 
Takács Ottó
Oct 5th, 20101. A követelményspecet meg lehet formalizáltan írni! Ez tény! Mi változás? A specifikáció is termék, aminek vannak minőségi követelményei. Ha mellé tesszük, hogy a specifikációt javítani olcsóbb, mint egy éles rendszeren verziót váltani akkor azt is látjuk miért fontos. De mit is legyen a specifikációban? Az, hogy az ügyfél milyen üzleti eredményt akar elérni! MÉRHETŐEN! A megoldást hagyd a programozóra. (Ha meredeknek tartod azt, amit írok, akkor olvasd végig szépen a következő írásokat és érteni fogod mire utalok! http://www.malotaux.nl/nrm/English/WrkSlds.htm)
Szerintem a specifikációt ott rontják el, hogy A) nem vizsgálják meg végterméki szempontból – review B) megoldási javaslatokkal tüzdelik tele
2. A formális programhelyességről volt egy élménye. Még kicsi egyetemista voltam és ott tartottak valami országos diákkonferenciát, vagy micsodát. Volt egy hallgató, aki arról tartott beszámolót, hogyan lehet eltávolítani a programból a felesleges részeket. Mivel az elmélkedése igen matematikus volt (magyarán nem azt mondta, hogy futtasd le, mért le és ahová nem futott a program azt töröld) feltettük neki a frankó kérdést: Hogyan kerülnek bele azok a programrészletek, amik egyébként nem is kellenek! A válasz: Pl a programhelyességet igazoló invariánsok (aki tudja miről beszélek az érti, aki meg nem, annak mind1). No comment!
Marhefka István
Oct 5th, 20101. Én nem tartok meredeknek semmit, csak először meg szeretném érteni, mire gondolsz
A két anti-patternnel egyetértek (nem vizsgálják meg végterméki szempontból, ill. hogy megoldási javaslatokkal tüzdelik tele).
Nem tudom viszont, mit gondolsz formalizáltságon és minőségen. Én úgy gondolom, hogy nem lehet és nem is érdemes formalizáltan egy specifikációt megírni. A feladat formalizált leírása helyett inkább lazábban kell fogalmazni úgy, hogy abból egyértelműen kiderüljenek az ügyfél _elvárásai_. (És itt szándékosan fogalmaztam elvárásokat nem pedig követelményeket.)
“Az, hogy az ügyfél milyen üzleti eredményt akar elérni! MÉRHETŐEN! A megoldást hagyd a programozóra.”
Jó gondolat lenne, csak a fejlesztő megrendelés alapján működik, és már eleve lehet, hogy ott van elhibázva a dolog, hogy a rendszert nem is kellett volna kifejleszteni, mert nem lehet vele teljesíteni az elvárt üzleti eredményeket. Erről nem nagyon tehet a fejlesztő.
De egyébként azzal mindenképpen egyetértek, hogy a megoldást hagyd a programozóra (én inkább fejlesztőt írnék a programozó helyett).
2. Azoknak készült ez az írás, akik (még mindig) így gondolkoznak…
Takács Ottó
Oct 6th, 20101. Igazad van. Teljesen egyet is értek. Pont ezt a témát feszegeti Tom Gilb a Principles of Software Engineering Management könyvében. Zseniális olvasmány. Csak ajánlani tudom bárkinek.